iOS性能优化 - APP启动时间优化

废话不说，直接上干货！

一、APP启动过程

1.解析Info.plist

加载相关信息，例如如闪屏
沙箱建立、权限检查

2.Mach-O加载

如果是胖二进制文件，寻找合适当前CPU类别的部分
加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
定位内部、外部指针引用，例如字符串、函数等
执行声明为attribute((constructor))的C函数
加载类扩展（Category）中的方法
C++静态对象加载、调用ObjC的 +load 函数

3.程序执行

调用main()
调用UIApplicationMain()
调用applicationWillFinishLaunching

二、监测启动时间

1.开启时间分析功能

在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到Run → Environment Variables → +，添加name为DYLD_PRINT_STATISTICSvalue为1的环境变量。

image

运行后会在控制台看到如下内容：

Total pre-main time:  94.33 milliseconds (100.0%)
dylib loading time:  61.87 milliseconds (65.5%)
rebase/binding time:   3.09 milliseconds (3.2%)
ObjC setup time:  10.78 milliseconds (11.4%)
initializer time:  18.50 milliseconds (19.6%)
slowest intializers :
libSystem.B.dylib :   3.59 milliseconds (3.8%)
libBacktraceRecording.dylib :   3.65 milliseconds (3.8%)
MyTest :   7.09 milliseconds (7.5%)

得出结论：

main()函数之前总共使用了94.33ms
在94.33ms中，加载动态库用了61.87ms，指针重定位使用了3.09ms，ObjC类初始化使用了10.78ms，各种初始化使用了18.50ms。
在初始化耗费的18.50ms中，用时最多的三个初始化是libSystem.B.dylib、libBacktraceRecording.dylib以及MyTest。

三、影响APP启动性能的因素

1.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()来完成的，就尽量不要用到以上的方法。

2.main()函数之后耗时的影响因素

从main()函数开始至didFinishLaunchingWithOptions结束，我们统一称为main()函数之后的部分。

执行main()函数的耗时
执行didFinishLaunchingWithOptions的耗时
rootViewController及其childViewController的加载、view及其subviews的加载

3.didFinishLaunchingWithOptions的耗时

其实 didFinishLaunchingWithOptions 方法里我们一般都有以下的逻辑：

初始化第三方 SDK
配置 APP 运行需要的环境，比如rootViewController加载
自己的一些工具类的初始化

四、制定优化目标

分为四个部分：

main()函数之前
main()函数之后至didFinishLaunchingWithOptions完成
App完成所有本地数据的加载并将相应的信息展示给用户
App完成所有联网数据的加载并将相应的信息展示给用户

五、优化方案

1.`main()`函数之前的优化

移除不需要用到的动态库。
移除不需要用到的类。
合并功能类似的类和扩展（Category）。
压缩资源图片。
减少load 方法中执行的代码。

2.`main()`函数之后至`didFinishLaunchingWithOptions`完成的优化

这一步主要优化didFinishLaunchingWithOptions方法中的代码和rootViewController加载的优化。

didFinishLaunchingWithOptions优化
对于 didFinishLaunchingWithOptions，这里面的初始化是必须执行的，但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。对于我们项目，我将初始化分为三个类型：

日志、统计等必须在 APP 一起动就最先配置的事件
项目配置、环境配置、用户信息的初始化、推送、IM等事件
其他 SDK 和配置事件

对于第一类，由于这类事件的特殊性，所以必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。第二类事件，这些功能在用户进入 APP 主体的之前是必须要加载完的，所以我们可以把它放在第二批，也就是用户已经看到广告页面，再进行广告倒计时的时候再启动。第三类事件，由于不是必须的，所以我们可以放在第一个界面渲染完成以后的 viewDidAppear 方法里，这里完全不会影响到启动时间。

rootViewController加载优化
这个只能看具体的逻辑和业务了，尽量把不必要的业务和网络请求等延后加载。