我们都知道在App启动的时候Page Faults次数多了会影响启动速度;那么如何查看我们的app启动的时候Page Faults的次数以及它对app启动的耗时影响了。本文就一起来学习下使用Instruments
的System Trace
来检测
检测app首次打开的场景
启动Instruments
使用Xcode选择要检测的app,Cmd+i(Profile),启动Instruments-
选择System Trace,点击Choose
-
录制
我们记录app启动到首屏展示的这个过程
按停止之后等待工具生成数据
- 查看数据
在搜索框搜索main
,可以看到我们检测的app,点击展开选中Main Thread
,下面的看板选择Summary:Virtual Memory
,如下图所示:
查看系统数据File Backed Page In
就记录了启动的时候发生Page In的次数了
- 我们可以看到,Page In的平均每次耗时是140.79us,积少成多当可以看到3699次的时候,影响的时间就到了百毫秒的级别了520.79ms
- 假如你的项目很庞大,启动的时候有很多模块加载之类的。那么这个次数就是以千计万计了,这个Page Faults产生的耗时就是比较明显了;这样当你做了二进制重排就有明显的提升了
检测app退到后台再打开
可以看到,app从后台回来Page In的次数很少
检测杀掉app再打开
测试了一两次发现跟从后台打开一样很少或者没有
检测杀掉app然后打开多个其他的app
杀掉app打开多个其他app(我打开了大概十来个吧),来看看Page In的次数,发现有200来次
这里就有疑问了,app首次打开的时候Page Fault的次数很多,打开之后再打开的话就比较少,当打开多个其他app的时候,在打开检测的app发现也会有不少Page Faults
这是由于操作系统的机制,当应用杀掉了,他所访问的物理内存不是立马就清空;它所访问的物理内存,需要通过其他app申请开辟覆盖释放掉,可以通过多打开几个应用来验证发现Page Fault次数变多了的。
至此我们已经知道怎么去检测app的PageFault是的次数了。那么如果影响很大的话,就可以采用一些优化的方式[二进制重排、PGO]来提升app的启动时间了
app启动优化可以参考:二进制重排和Profile Guided Optimization