影响启动性能的因素
App启动过程中每一个步骤都会影响启动性能,但是有些部分所消耗的时间少之又少,另外有些部分根本无法避免,考虑到投入产出比,我们只列出我们可以优化的部分:
main()函数之前耗时的影响因素
- 动态库加载越多,启动越慢。
- ObjC类越多,启动越慢
- C的constructor函数越多,启动越慢
- C++静态对象越多,启动越慢
- ObjC的+load越多,启动越慢
实验证明,在ObjC类的数目一样多的情况下,需要加载的动态库越多,App启动就越慢。同样的,在动态库一样多的情况下,ObjC的类越多,App的启动也越慢。需要加载的动态库从1个上升到10个的时候,用户几乎感知不到任何分别,但从10个上升到100个的时候就会变得十分明显。同理,100个类和1000个类,可能也很难查察觉得出,但1000个类和10000个类的分别就开始明显起来。
同样的,尽量不要写
__attribute__((constructor))
的C函数,也尽量不要用到C++的静态对象;至于ObjC的
+load
方法,似乎大家已经习惯不用它了。任何情况下,能用
dispatch_once()
来完成的,就尽量不要用到以上的方法。
main()函数之后耗时的影响因素
- 执行main()函数的耗时
- 执行applicationWillFinishLaunching的耗时
- rootViewController及其childViewController的加载、view及其subviews的加载
applicationWillFinishLaunching的耗时
总结 :
- 利用DYLD_PRINT_STATISTICS分析main()函数之前的耗时
-
- 重新梳理架构,减少动态库、ObjC类的数目,减少Category的数目
- 定期扫描不再使用的动态库、类、函数,例如每两个迭代一次
- 用dispatchonce()代替所有的__attribute__((constructor))函数、C++静态对象初始化、ObjC的+load
- 在设计师可接受的范围内压缩图片的大小,会有意外收获
- 利用锚点分析applicationWillFinishLaunching的耗时
-
- 将不需要马上在applicationWillFinishLaunching执行的代码延后执行
- rootViewController的加载,适当将某一级的childViewController或subviews延后加载
- 如果你的App可能会被后台拉起并冷启动,可考虑不加载rootViewController
- 不应放过的一些小细节
-
- 异步操作并不影响指标,但有可能影响交互体验,例如大量网络请求导致数据拥堵
- 有时候一些交互上的优化比技术手段效果更明显,视觉上的快决不是冰冷的数据可以解释的,好好和你们的设计师谈谈动画