从App使用角度来看，用户在使用上会感觉到卡顿的场景，主要分为两种：

• 用户在操作之后无法进行下一步，卡死在当前页面，过一会才恢复。（主线程阻塞）

• 滑动页面，点击操作出现反应比较慢，但用户仍可继续操作。（网络原因，子线程阻塞，如文件读写，低效计算，数据转换等）

火焰图（Flame Graph）是以一个全局的视野来看待时间分布，它从底部往顶部，列出所有可能导致性能瓶颈的堆栈。在卡顿监控中，堆栈通过以火焰图形成展示，可以很清楚地发现占用时间长的方法，让开发者更能直观地发现问题点。 

在 iOS应用中，主线程是默认开启 Runloop功能。Runloop 是一个 Event Loop 模型，可以让主线程处于接收消息、处理事件、进入等待等状态而不会立刻退出，其状态流如下图所示。在进入事件的前后，Runloop 会向注册的 Observer 通知相应的事件。 

卡顿监控开辟一个子线程定时检查主线程的状态，并记录下主线程在各个运行状态的时间点，当主线程的运行状态超过一定的时间阈值后，则认为主线程卡顿。记录这时的堆栈信息，并进行相应的处理。

if (isSame) {         NSUInteger lastTimeInterval_t = intervalTime;         intervalTime = lastTimeInterval + intervalTime;         lastTimeInterval = lastTimeInterval_t;         ...     } else {         intervalTime = 1;         ...     } 

// intervalTime, 时间间隔，初始值为1，由退火算法来控制期大小 for (int i = 0; nCnt < intervalTime; i++) {     if (mThreadHandle && bMonitor) {       // periodTime == 1秒 perStackInterval == 50毫秒       int intervalCount = periodTime / perStackInterval;       if (intervalCount <= 0) {         usleep(checkPeriodTime);       } else {         // intervalCount = 20 perStackInterval = 50毫秒          //忽略其他方法执行时间 总睡眠时间为1秒          for (int index = 0; index < intervalCount; index++) {           usleep(perStackInterval);           // 获取主线程堆栈信息，并保存           ...         }       }     } else {       usleep(checkPeriodTime);     }   }

堆栈获取策略 

最耗时堆栈信息获取 

子线程检测到主线程 Runloop 时，会获得当前的线程快照当做卡顿文件。但是这个当前的主线程堆栈不一定是最耗时的堆栈，不一定是导致主线程超时的主要原因。所以需要找出最耗时堆栈信息。

• 以栈顶函数为特征，认为栈顶函数相同的即整个堆栈是相同的；

• 取堆栈的间隔是相同的，堆栈的重复次数近似作为堆栈的调用耗时，重复越多，耗时越多；

• 重复次数相同的堆栈可能很有多个，取最近的一个最耗时堆栈。

通过以上策略，获得的最近最耗时堆栈会附带到卡顿文件中。 

整体方案流程图如下，在App中，SDK采样了卡顿数据，并上传到阿里云平台。Flink服务则实时地把卡顿数据同步到APM服务器中，并把数据写入本地数据库中。

符号化脚本服务定时运行，不断地从APM服务器中获取未经过符号化解析的卡顿堆栈数据，经过符号化解析后，推送到APM服务器中，并落库。

前端平台从APM服务器获取经过处理后的卡顿数据，并在前端平台展示。

• 配置设计

• 在卡顿监控开启后，通过配置，分别设置来实现全部堆栈采集功能和最耗时堆栈采集。通过合理配置采样数据量及采集时间，使得数据采集量和数据可用性达到最优

• 数据采集

• 当发生卡顿时，获取主线程堆栈信息，并获取所有堆栈信息列表，通过退火算法来过滤相同堆栈，并分析出最耗时堆栈信息。同时采样CPU信息，用以辅助分析卡顿时性能

• 数据结构设计

• 标识主线程堆栈，区分堆栈信息组和最耗时堆栈信息。调整优化上报信息，去除无用信息

整体设计流程图如下 ：

什么是符号化

在日常开发中，应用难免会发生崩溃。通常，我们直接从用户导出来的崩溃日志都是未符号化或者部分符号化的，是一堆十六进制内存地址的集合，可读性较差。未符号化或者部分符号化的崩溃日志对闪退问题的解决几乎毫无帮助，如下所示: 

Last Exception Backtrace:0   CoreFoundation  0x1ca4cd27c 0x1ca3b5000 + 11475161   libobjc.A.dylib  0x1c96a79f8 0x1c96a2000 + 230322   CoreFoundation  0x1ca3ded94 0x1ca3b5000 + 1714123   TestBacktrace  0x102a47464 0x102a40000 + 297964   UIKitCore  0x1f6c86e30 0x1f63d3000 + 9125424

Last Exception Backtrace:0    CoreFoundation 0x1ca4cd27c __exceptionPreprocess + 2281    libobjc.A.dylib 0x1c96a79f8 objc_exception_throw + 552   CoreFoundation 0x1ca3ded94 -[__NSSingleObjectArrayI objectAtIndex:] + 1273    TestBacktrace 0x102a47464 -[AppDelegate Application:didFinishLaunchingWithOptions:] + 29796 (AppDelegate.m:23)4    UIKitCore 0x1f6c86e30 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 411

解析脚本功能

• 脚本解析数据

• 从APM服务器获取未解析数据，解析完后把数据上传到APM服务器

• 自动化解析堆栈信息，通过重组并利用App符号表和系统符号表来解析堆栈信息

• 解析堆栈数据结构，并对堆栈信息组和最耗时堆栈分别解析。

解析脚本设计

符号化脚本服务与APM服务交互流程如图所示 

服务端工作流程如下图，Flink实时同步阿里云数据，并存入到数据库中。APM服务器则从数据库中获取数据，经过符号化脚本解析后，再存回到数据库中。当前端展示时，APM服务器再从数据库中获取数据，并传输到前端中展示出来。数据流如下图： 

联调测试及性能测试 

测试设备：iPad mini 5

实测数据如下列表：

以下三种情况，其CPU占用和内存占用大体相同，如下所示

1. 关闭卡顿检测，并无卡顿发生

2. 关闭卡顿检测，并有卡顿发生

3. 开启卡顿检测时，并无卡顿发生 

4. 开启卡顿检测时，并有卡顿发生时

参数：总体CPU和内存占比，CPU: 6%，内存：122M

说明: 在首页延迟25s，执行卡顿方法。检测到卡顿时，CPU有较高的瞬时波峰。

对线程占用CPU情况分析

对卡顿监控子线程进行分析，从图片可以看下如下两点

1. 检测到运行卡顿后，CPU会有个脉冲式的高CPU占用。如下面第一张图中红框内所示。

2. 在第二张图中，线程block_monitor_123，为检测卡顿子线程，当检测到卡顿时，会有脉冲式CPU占比，未检测到卡顿时，CPU占比比较小。

卡顿检测线程，本身为非连续高频检测，最小检测时间为1秒，当子线程多次检测到卡顿后，有以下两种情况。

1. 如果堆栈信息相同，则只会有第一次计算最耗时堆栈信息和获取全部堆栈信息，并写入缓存，这部分动作最耗性能。其它次，则只取主线程堆栈信息，而且会由退火算法不断地减少读取次数；

2. 如果堆栈信息不同，则会计算最耗时堆栈信息和获取全部堆栈信息，并写入缓存。

由此看，虽然卡顿检测线程不会占用太长时间CPU，但其处理堆栈信息部分和写入缓存部分还是存在一定的性能损耗的，通过上面二张图对比发现，子线程占用CPU和主线程卡顿占用CPU重合，这样就加剧了瞬时的性能损耗。 

性能优化策略，主要是通过延迟子线程执行损耗性能任务的时机，来降低CPU瞬时损耗。

在子线程中任务分成两部分，第一部分是是获取检测主线程卡顿和主线程堆栈信息。第二部分是计算最耗时堆栈信息和获取全部堆栈信息，并存入缓存。其中损耗CPU的是第二部分功能。

针对主线程卡顿和卡顿子线程叠加情况，本方案设计了延迟子线程损耗性能部分功能的执行操作。

1. 开劈线程block_monitor_deal_data，每隔三秒执行一次

2. 判断主线程Runloop状态是否进入kCFRunLoopBeforeWaiting状态，CPU使用率小于40%，缓存队列中存在未处理堆栈信息

3. 当条件都满足时，处理子线程的第二部分任务功能。

如下测试1和测试2中，明显可以看到，子线程对CPU的瞬时占用与主线程卡顿占用CPU的波形没有叠加。

测试1：队列中只有一个堆栈信息时

测试2：队列中有多条堆栈信息时 

总结

本文介绍了iOS卡顿监控策略，包括卡顿检测原理，整体架构方案的设计，平台数据展示，性能优化等，在实施过程中也借鉴了业内优秀方案的思路，站在巨人的肩膀上实现了自己的一套整体实现方案。后续还有很多优化点，比如本文只实现的监测主线程阻塞导致卡顿情况，还有其他导致卡顿情况未实现，符号化脚本也可以做成专用脚本服务等。有了起点后，在此基础上不断优化，团队的技术才能更好地发展，不断地向前。