iOS性能测试实战篇（一）
作者：陈华媛 2016-12-12 {{allComments.length}} 131899 干货分享背景介绍
说起性能调优，感觉枯燥的语言不能引起大家对于性能调优的重视，所以举个不太恰当的例子。
曾经有这么一家工厂，他们的产品从原材料到出厂一共需要经过30条产品线。这家公司的老板对底下的员工曾多次强调过质量的重要性，员工们却不以为然，他们觉得自己做的都很不错。
有一次，老板去视察，走到了一条产品线上，问起工人，这条产品线的合格率能达到多少，那个工人自豪的说，“98%”。老板却并没有十分满意，摇着头走开了。那位工人非常的疑惑。这么高的合格率，老板为什么还是不满意呢？于是这位工人就去向领导打听，领导也不知道，于是后来这位工人直接找到了老板家里，向老板请教。
老板很是诧异，于是就给这位工人简单科普了一下，一条产品线的合格率是98%，并不代表最后总的合格率是98%。应该是这样计算最后的合格率的：x=0.98*0.98*0.98...=0.545
所以，这家公司的生产线的合格率实际上只有54.5%。
这个故事说明的问题其实很简单，我们开发的app的最终性能，都是由每一个细小的部分组合而成的，其中很多部分的内容是进行的乘法，而不是加减，所以想要自己设计的app让用户用的爽，任何一个小的性能问题我们都不能忽略。那么，iOS性能测试是什么？
iOS性能测试是：
l 资源消耗
l 内存泄漏
l 流量消耗
l 耗电功率
l 渲染效果
l 加载时间
l 。。。
性能调优的方式：
l 通过专门的性能调优工具instruments
l 通过优化代码
instruments的三种打开方式：
l Open Developer Tool->instruments
l 右键点击Xcode->Open Developer Tool->instruments
l 工具通过Xcode工具栏中Product->Profile可以启动
（1） Open Developer Tool->instruments
图1
（2）右键点击Xcode->Open Developer Tool->instruments
图2
（3）工具通过Xcode工具栏中Product->Profile可以启动
图3
启动后界面如下：
图4
性能工具按需求分类如下：
图5
下面根据需求分类详细介绍instruments。
时间
我们就启动耗时来分析。
l Time profiler
CPU Usage估量时间
Call Tree计算时间
l NSLog
1.1启动耗时--Time profiler
1.1.1根据CPU Usage估量时间
l Profiler你的app，手动测量，点击Record开始运行
图6
l 根据CPU峰值推拽估量时间
1.1.2根据Call Tree 去计算时间
l instruments -> Time Profiler
l Profiler你的app
l 切换到CPU strategy view，找到你的app的启动的第一帧
刚开始我们拿到分析数据时往往是这样的：
图7
这里显示的是执行代码完整路径，其中系统和应用本身一些调用路径完全揉捏在一起。完全看不到我们关心的应用程序中实际代码执行耗时和代码路径实际所在位置。
怎么办？我们可以看到右侧有一个“齿轮形状”的设置按钮。
图8
Call Tree:
Separate By Thread：线程分离,只有这样才能在调用路径中能够清晰看到占用CPU最大的线程；
Invert Call Tree：从上到下跟踪堆栈信息.这个选项可以快捷的看到方法调用路径最深方法占用CPU耗时,比如FuncA{FunB{FunC}},勾选后堆栈以C->B->A把调用层级最深的C显示最外面；
Hide System Libraries：这个就更有用了,勾选后耗时调用路径只会显示app耗时的代码,性能分析普遍我们都比较关系自己代码的耗时而不是系统的.基本是必选项.注意有些代码耗时也会纳入系统层级，可以进行勾选前后前后对执行路径进行比对会非常有用。
Top Functions：按耗时降序排列。
简单的方式可以快速勾选右边Call Tree中Separate by Thread和Hide System Libraries两个选项[后面会解释选项作用]:
图9-10
勾选Invert Call Tree:
图11
勾选前后对比：
图12
图13
l 算出启动时间。
首次加载坐了如下操作：
A: 链接和载入：可以在Time Profile中显示dyld载入库函数，库会被映射到地址空间，同时完成绑定以及静态初始化。
B: UIKit初始化：如果应用的Root View Controller是由XIB实现的，也会在启动时被初始化.
C: 应用回调：调用UIApplicationDeleagte的回调：application:didFinishLaunchingWithOptions。
D: 第一次Core Animation调用：在启动后的方法-[UIApplication _resportAppLaunchFinished]中调用CA::Transaction::commit实现第一帧画面的绘制。
应用程序首次加载中启动方法willFinishLaunchingWithOptions和didFinishLaunchingWithOptions只做应用程序首次启动必须的要操作,而针对_dyid_start在初始化库framework函数的操作。不必要的Framework不要链接，避免首次加载耗时。
搜索-[UIApplication_reportAppLaunchFinished]的最后一帧，即可算出启动时间。
图14
Running Time列中显示运行每个方法所耗费的时间，根据耗时和占比猜测是否有代码需要优化。双击中间主窗口中的方法名进入具体的代码行查看，耗时多的代码行有颜色标记，并显示占比。
图15
当然对于开发而已，这种利用Time Profiler的方式计算启动耗时比较麻烦，他们更喜欢埋点。
1.2 启动耗时--NSLog
l 获取某段代码的执行时间MKBlockTimer
l 利用类库测试代码的运行时间MGBenchmark
评估总体运行时间;
评估单步代码的运行时间;
找到所有代码x最耗时的代码;
找到代码的平均运行时间;
可以对不同的线程进行评估（thread safe）
l 启动时间
看之前XXX的性能资料，是在AppDelegate里打点并不合理。算出的只是main
调用AppDelegate文件的时间。
图16
图17
所以是错误的。
业界对此的算法不同。贴吧是在内存创建完成就算是启动成功，即：didLoad
个人觉得其实应该是didAppear，即ui展示出来为准。
埋点步骤：
在main.m中记当前时间StartTime:
图18
不能在ALATabBarController.h函数里面声明，会被多次调用，相当于多次声明全局变量；所以在ALATabBarController.m里面定义全局变量。
图19
但是不可见，所以在ALATabBarController.h文件用extern，将extern置于变量或者函数前，以表示变量或者函数的定义在别的文件中，即CFAbsoluteTime StartTime在ALATabBarController.m文件中声明过。
图20
计算启动时间（didLoad）:
图21
计算启动时间（didAppear）:
图22
在log输出窗口看准确时间输出：
图23
如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~
