克魔助手 - iOS 性能检测平台

​

前言

众所周知，如今的用户变得越来越关心 app 的体验，开发者必须关注应用性能所带来的用户流失问题。目前危害较大的性能问题主要有：闪退、卡顿、发热、耗电快、网络劫持等，但是做过 iOS 开发的人都知道，在开发过程中我们没有一个很直观的工具可以实时的知道开发者写出来的代码会不会造成性能问题，虽然 Xcode 里提供了耗电量检测、内存泄漏检测等工具，但是这些工具使用效果并不理想（如 Leak 无法发现循环引用造成的内存泄漏）。所以这篇文章主要是介绍一款实时监控 app 各项性能指标的工具，包括 CPU 占用率、内存使用量、内存泄漏、FPS、卡顿检测，并且会分析造成这些性能问题的原因。

CPU

CPU 是移动设备最重要的组成部分，如果开发者写的代码有问题导致 CPU 负载过高，会导致 app 使用过程中发生卡顿，同时也可能导致手机发热发烫，耗电过快，严重影响用户体验。 如果想避免 CPU 负载过高可以通过检测 app 的 CPU 使用率，然后可以发现导致 CPU 过高的代码，并根据具体情况优化。那该如何检测 CPU 使用率呢？大学期间学过计算机的应该都上过操作系统这门课，学过的都知道线程 CPU 是调度和分配的基本单位，而应用作为进程运行时，包含了多个不同的线程，这样如果我们能知道 app 里所有线程占用 CPU 的情况，也就能知道整个 app 的 CPU 占用率。幸运的是我们在 Mach 层中 thread_basic_info 结构体发现了我们想要的东西，thread_basic_info 结构体定义如下：

CPU 内存监控

克魔助手提供了分析内存占用、查看 CPU 实时活动数据以及追踪特定应用程序的功能，让开发者可以更好地了解应用程序的运行情况。 以下是一些示例截图：

​

同样，克魔助手还提供了内存、GPU 性能监控、网络监控等功能，开发者可以查看实时数据活动和追踪应用程序的特定功能。 如下：

内存监控

以下是内存监控的示例截图：

Memory

物理内存（RAM）与 CPU 一样都是系统中最稀少的资源，也是最有可能产生竞争的资源，应用内存与性能直接相关 - 通常是以牺牲别的应用为代价。 不像 PC 端，iOS 没有交换空间作为备选资源，这就使得内存资源尤为重要。

App 占用的内存

获取 app 内存的 API 同样可以在 Mach 层找到，mach_task_basic_info 结构体存储了 Mach task 的内存使用信息，其中 resident_size 就是应用使用的物理内存大小，virtual_size 是虚拟内存大小。

#define MACH_TASK_BASIC_INFO 20 /* always 64-bit basic info */ struct mach_task_basic_info { mach_vm_size_t virtual_size; /* virtual memory size (bytes) */ mach_vm_size_t resident_size; /* resident memory size (bytes) */ mach_vm_size_t resident_size_max; /* maximum resident memory size (bytes) */ time_value_t user_time; /* total user run time for terminated threads */ time_value_t system_time; /* total system run time for terminated threads */ policy_t policy; /* default policy for new threads */ integer_t suspend_count; /* suspend count for task */ };

最后得到获取当前 App Memory 的使用情况：

- (CGFloat)usedMemory { task_basic_info_data_t taskInfo; mach_msg_type_number_t infoCount = TASK_BASIC_INFO_COUNT; kern_return_t kernReturn = task_info(mach_task_self(), TASK_BASIC_INFO, (task_info_t)&taskInfo, &infoCount); if (kernReturn != KERN_SUCCESS) { return NSNotFound; } CGFloat value = (CGFloat)(taskInfo.resident_size / 1024.0 / 1024.0); return value; }

设备已使用的内存

+ (CGFloat)deviceUsedMemory { size_t length = 0; int mib[6] = {0}; int pagesize = 0; mib[0] = CTL_HW; mib[1] = HW_PAGESIZE; length = sizeof(pagesize); if (sysctl(mib, 2, &pagesize, &length, NULL, 0) < 0) { return 0; } mach_msg_type_number_t count = HOST_VM_INFO_COUNT; vm_statistics_data_t vmstat; if (host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmstat, &count) != KERN_SUCCESS) { return 0; } int wireMem = vmstat.wire_count * pagesize; int activeMem = vmstat.active_count * pagesize; return (CGFloat)(wireMem + activeMem) / 1024.0 / 1024.0; }

设备可用的内存

+ (CGFloat)deviceAvailableMemory { vm_statistics64_data_t vmStats; mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT; kern_return_t kernReturn = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount); if (kernReturn != KERN_SUCCESS) { return NSNotFound; } return (CGFloat)(vm_page_size * (vmStats.free_count + vmStats.inactive_count) / 1024.0 / 1024.0); }

FPS

FPS 即屏幕每秒的刷新率，范围在 0-60 之间，60 最佳。FPS 是测量用于保存、显示动态视频的信息数量，每秒钟帧数愈多，所显示的动作就会愈流畅，优秀的 app 都要保证 FPS 在 55-60 之间，这样才会给用户流畅的感觉，反之，用户则会感觉到卡顿。 对于 FPS 的计算网上争议颇多，这边使用的和 YYKit 中的 YYFPSLabel 原理一样，系统提供了 CADisplayLink 这个 API，该 API 在屏幕每次绘制的时候都会回调，通过接收 CADisplayLink 的回调，计算每秒钟收到的回调次数得到屏幕每秒的刷新次数，从而得到 FPS，具体代码如下：

首先，为了使用克魔助手检查 iOS 游戏的帧率，需要在电脑上安装爱思助手或者 iTunes 驱动。随后，通过 USB 连接苹果手机到电脑，并启动克魔助手。

设备选择

第二步，在工具左侧菜单栏中，打开“设备”窗口。窗口中会显示你连接的所有苹果设备，选择要查询的设备，然后选中设备。

查看 FPS 和 fps 监测

第三步，点击“开始监听”，在右侧的“FPS 曲线”查看当前应用程序的帧率。另外，在克魔助手中可以看到每秒图像

更新多少次，以及总图像更新次数，从而了解游戏性能如何。

CPU 占比和应用追踪及特定 APP 数据

第四步，查看帧率是保证游戏顺畅性的重要因素，所以应用程序开发人员将会经常使用克魔助手检查苹果手机玩游戏的帧率。当然，游戏还有很多需要优化的地方，可以提高游戏整体性能，所以克魔助手不仅提供了监控帧率，还提供了可以分析内存占用，查看 CPU 实时活动数据，以及追踪特定 app 时等功能，让开发者可以更好地了解游戏运行情况。

通过克魔助手的帮助，开发者可以方便快捷地检查苹果手机玩游戏的帧率。了解帧率和游戏性能对增加游戏用户量，增强用户体验和游戏的质量都非常重要，所以在开发过程中不要忘记检查苹果手机的帧率。

值得注意的是基于 CADisplayLink 实现的 FPS 在生产场景中只有指导意义，不能代表真实的 FPS，因为基于 CADisplayLink 实现的 FPS 无法完全检测出当前 Core Animation 的性能情况，它只能检测出当前 RunLoop 的帧率。

Freezing

为什么会出现卡顿

从一个像素到最后真正显示在屏幕上，iPhone 究竟在这个过程中做了些什么？想要了解背后的运作流程，首先需要了解屏幕显示的原理。iOS 上完成图形的显示实际上是 CPU、GPU 和显示器协同工作的结果，具体来说，CPU 负责计算显示内容，包括视图的创建、布局计算、图片解码、文本绘制等，CPU 完成计算后会将计算内容提交给 GPU，GPU 进行变换、合成、渲染后将渲染结果提交到帧缓冲区，当下一次垂直同步信号（简称 V-Sync）到来时，最后显示到屏幕上

上文中提到 V-Sync 是什么，以及为什么要在 iPhone 的显示流程引入它呢？在 iPhone 中使用的是双缓冲机制，即上图中的 FrameBuffer 有两个缓冲区，双缓冲区的引入是为了提升显示效率，但是与此同时，他引入了一个新的问题，当视频控制器还未读取完成时，比如屏幕内容刚显示一半时，GPU 将新的一帧内容提交到帧缓冲区并把两个缓冲区进行交换后，视频控制器就会把新的一帧数据的下半段显示到屏幕上，造成画面撕裂现象，V-Sync 就是为了解决画面撕裂问题，开启 V-Sync 后，GPU 会在显示器发出 V-Sync 信号后，去进行新帧的渲染和缓冲区的更新。

搞清楚了 iPhone 的屏幕显示原理后，下面来看看在 iPhone 上为什么会出现卡顿现象，上文已经提及在图像真正在屏幕显示之前，CPU 和 GPU 需要完成自身的任务，而如果他们完成的时间错过了下一次 V-Sync 的到来（通常是 1000/60=16.67ms），这样就会出现显示屏还是之前帧的内容，这就是界面卡顿的原因（离屏渲染就是典型的卡顿问题）。不难发现，无论是 CPU 还是 GPU 引起错过 V-Sync 信号，都会造成界面卡顿。

那如何检测卡顿呢？比较常见的思路是：开辟一条单独的子线程，让这条子线程去实时检测主线程的 RunLoop 情况，实时计算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 两个状态之间的耗时是否超过某个阀值，如果超过阈值即认定主线程发生了卡顿。下面是代码实现：

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) { MyClass *object = (__bridge MyClass*)info; // 记录状态值 object->activity = activity; // 发送信号 dispatch_semaphore_t semaphore = moniotr->semaphore; dispatch_semaphore_signal(semaphore); } - (void)registerObserver { CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL}; CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &runLoopObserverCallBack, &context); CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes); // 创建信号 semaphore = dispatch_semaphore_create(0); // 在子线程监控时长 dispatch_async(dispatch_get_global_queue(0, 0), ^{ while (YES) { // 假定连续 5 次超时 50ms 认为卡顿(当然也包含了单次超时 250ms) long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC)); if (st != 0) { if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting) { if (++timeoutCount < 5) continue; // 检测到卡顿，进行卡顿上报 } } timeoutCount = 0; } }); }

当检测到卡顿后可以进一步收集卡顿现场，如堆栈信息等，关于收集堆栈信息这里就不细说，很多第三方库都有实现，我之前是使用了项目中已经集成的收集崩溃信息的三方库，通过这个库在收集堆栈信息。

MemoryLeak

内存泄漏也是造成 app 内存过高的主要原因，如果 iPhone 手机的性能都很强，如果一个 app 会因为内存过高被系统强制杀掉，大部分都是存在内存泄漏。内存泄漏对于开发和测试而言表现得并不明显，如果它不泄漏到一定程度是用户是无法察觉的，但是这也是开发者必须杜绝的一大问题。

查找内存泄漏

对于内存泄漏 Xcode 提供了 Leak 工具，但是使用过的人都知道 Leak 无法查出很多泄漏（如循环引用），在这里检测内存泄漏使用的是微信读书团队 Mr.佘 提供的工具 MLeakFinder。 这里大致讲一下实现原理，当一个 VC（或者 View）被 pop 或者被 dismiss 2 秒后还没有被销毁则认定该 VC（或 View）发生了泄漏。那如何知道 2 秒后该对象有没有被释放呢，

+ (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ [self swizzleSEL:@selector(popViewControllerAnimated:) withSEL:@selector(swizzled_popViewControllerAnimated:)]; }); }

通过方法交换将系统的 pop 方法换掉，然后注入自己的代码实现，当调用 pop 时会调用 willDealloc 方法，该方法实现如下：

- (BOOL)willDealloc { __weak id weakSelf = self; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ __strong id strongSelf = weakSelf; [strongSelf assertNotDealloc]; }); return YES; }

添加图片注释，不超过 140 字（可选）

通过弱引用持有自身，并在 2 秒后调用 assertNotDealloc, 如果 2 秒内该对象已释放这里的 weakSelf 为 nil，也就什么都不会发生，反之则认为发生了内存泄漏，进行下一步操作，如弹出警告等。 这里只是大致讲一下 MLeakFinder 的原理，详细介绍可以去 https://keymob.com/详细了解。

查找循环引用

查找循环引用使用的是 Facebook 开源库 FBRetainCycleDetector ,具体也可以去网上查找相关资料，这里就不详细说。

​