概述
Time Profiler主要用来检测应用CPU的使用情况,可以帮助我们分析代码/方法的执行时间,找出程序变慢的原因,告诉我们时间都去哪了
在开发过程中,点击按钮,或者跳转页面时有卡顿,即延迟,就可以使用Time Profiler找出耗时的函数
原理
Time Profiler是按照固定时间间隔(1ms)来跟踪每一个线程的调用堆栈信息进行采样,然后通过统计比较时间间隔之间的堆栈状态,来推算某个方法的执行时间,并获取一个近似值。如下所示,图中虚线是采样点,最后统计出调用栈和对应函数调用的次数
从图中看出,method3并不在统计结果中,这说明只要方法运行的足够快时,是很可能无法统计到的。对于耗时分析来说,并不会有什么问题,因为主要是分析执行慢的方法,执行快的方法一般都不会引起性能问题。
而且Time Profiler并不会精确的统计出方法的执行时间,当线程处于挂起或者等待执行状态时,Time Profiler并不能统计到此时的线程,它只能统计到真正在CPU上执行的线程
注意事项
1、必须在iOS真机上调试
因为模拟器是运行在Mac上的,然后Mac的CPU一般都比iOS设备快,两者的GPU也完全不同,所以如果在模拟器上进行调试,会导致模拟器的性能数据和用户真机的数据相差甚远。
2、必须在release环境下调试
主要是因为Xcode在debug环境下会禁用Watch Dog。而在release环境打包时,编译器会引入一系列提高性能的优化,例如去掉调试符号、移除并重组代码等。同时,iOS引入了Watch Dog(看门狗)机制,在不同的场景下,Watch Dog会监测应用的性能,如果超出了该场景所规定的的运行时间,Watch Dog会强制终结App的进程。开发者可以看到对应的crash log。
使用
- 创建两个页面A和B,从Apush到B,在B的viewDidLoad方法中调用下面的方法
- (void)testLongTime{
for (int i = 1; i < 10000000; i ++) {
NSLog(@"i = %d", i);
}
}
-
通过Xcode - Product - Profile - 选择Time Profiler,配置Call Tree
- Separate by State:按状态分开,分析数据。
- Separate by Thread(建议选择):线程分离,只有这样才能在调用路径中能够清晰看到占用CPU最大的线程.每个线程应该分开考虑。只有这样你才能揪出那些大量占用CPU的"重"线程,按线程分开做分析,这样更容易揪出那些吃资源的问题线程。特别是对于主线程,它要处理和渲染所有的接口数据,一旦受到阻塞,程序必然卡顿或停止响应。
- Invert Call Tree(不建议选择)反向显示调用:调用树倒返过来,将习惯性的从根向下一级一级的显示,如选上就会返过来从最底层调用向一级一级的显示。如果想要查看那个方法调用为最深时使用会更方便些。
- Hide System Libraries(建议选择)隐藏系统库:选上它只会展示与应用有关的符号信息,一般情况下我们只关心自己写的代码所需的耗时,而不关心系统库的CPU耗时。
- Flatten Recursion(一般不选)合并递归:选上它会将调用栈里递归函数作为一个入口。
- Top Functions(可选)置顶耗时方法:选上它会将最耗时的函数降序排列,而这种耗时是累加的,比如A调用了B,那么A的耗时数是会包含B的耗时数。
-
点击左上角运行程序,开启耗时检测,运行结果如下
从图中可以看出,大部分时间占用在-[SecondViewController testLongTime]方法中,双击进入源代码页面,可以具体查看某一行的占用情况
如果选择汇编展示
如果选择查看次数
-
还可以进一步设置耗时范围,过滤出想要的数据,比如设置最小耗时为50,过滤50以下的
所以综上所述,Time Profiler的基本调试逻辑为
- 运行项目,开始分析
- 找到最大的占用函数
- 修复耗时的方法
- 继续分析...直到完全修复
- 注:有时自定义的方法也会引起系统代码卡顿,所以查看系统库的耗时方法也是很有必要的
参考文章
iOS性能优化 - 工具Instruments之Time Profiler
iOS 性能优化 - TimeProfiler分析代码耗时
ios Instruments之Time Profiler
iOS App启动优化(二)—— 使用“Time Profiler”工具监控App的启动耗时