iOS启动速度优化

iOS启动速度优化
背景
7⽉26号我们阿⾥数据iOS端发布了4.4.0版本，这次版本主要是优化了性能，其中main()阶段的启动耗时优化成果⽐较明显，从之前的0.5-0.7秒，降低为⽬前的0.1-0.2秒（main()第⼀⾏代码到didFinishLaunchingWithOptions最后⼀⾏代码的耗时），⽤户体验提升明显。

在这⾥梳理⼀下优化的⼀些经验，欢迎⼤家⼀起交流。

应⽤启动流程
iOS应⽤的启动可分为pre-main阶段和main()阶段，其中系统做的事情依次是：
1. pre-main阶段
1.1. 加载应⽤的可执⾏⽂件
1.2. 加载动态链接库加载器dyld（dynamic loader）
1.3. dyld递归加载应⽤所有依赖的dylib（dynamic library 动态链接库）
2. main()阶段
2.1. dyld调⽤main()
2.2. 调⽤UIApplicationMain()
2.3. 调⽤applicationWillFinishLaunching
2.4. 调⽤didFinishLaunchingWithOptions
启动耗时的测量
在进⾏优化之前，我们⾸先应该能测量各阶段的耗时。

1. pre-main阶段
对于pre-main阶段，Apple提供了⼀种测量⽅法，在 Xcode 中 Edit scheme -> Run -> Auguments 将环境变量DYLD_PRINT_STATISTICS 设为1
：
pre-main阶段启动耗时测量.png
设置好后把程序跑起来，控制台会有如下输出，pre-main阶段各过程的耗时⼀览⽆余(Apple这个Demo有点过于夸张
...)
pre-main阶段启动耗时测量.png
2. main()阶段
对于main()阶段，主要是测量main()函数开始执⾏到didFinishLaunchingWithOptions执⾏结束的耗时，就需要⾃⼰插⼊代码到⼯程中了。

先在main()函数⾥⽤变量StartTime记录当前时间：
1 2 3CFAbsoluteTime StartTime;
int main(int argc, char * argv[]) {
StartTime = CFAbsoluteTimeGetCurrent();
再在AppDelegate.m⽂件中⽤extern声明全局变量StartTime
1extern CFAbsoluteTime StartTime;
最后在didFinishLaunchingWithOptions⾥，再获取⼀下当前时间，与StartTime的差值即是main()阶段运⾏耗时。

1double launchTime = (CFAbsoluteTimeGetCurrent() - StartTime);
pre-main阶段的优化
1. Load dylibs
这⼀阶段dyld会分析应⽤依赖的dylib，找到其mach-o⽂件，打开和读取这些⽂件并验证其有效性，接着会找到代码签名注册到内核，最后对dylib的每⼀个segment调⽤mmap()。

⼀般情况下，iOS应⽤会加载100-400个dylibs，其中⼤部分是系统库，这部分dylib的加载系统已经做了优化。

所以，依赖的dylib越少越好。

在这⼀步，我们可以做的优化有：
1. 尽量不使⽤内嵌（embedded）的dylib，加载内嵌dylib性能开销较⼤
2. 合并已有的dylib和使⽤静态库（static archives），减少dylib的使⽤个数
3. 懒加载dylib，但是要注意dlopen()可能造成⼀些问题，且实际上懒加载做的⼯作会更多
2. Rebase/Bind
在dylib的加载过程中，系统为了安全考虑，引⼊了ASLR（Address Space Layout Randomization）技术和代码签名。

由于ASLR的存在，镜像（Image，包括可执⾏⽂件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有⼀个偏差（slide），dyld需要修正这个偏差，来指向正确的地址。

Rebase在前，Bind在后，Rebase做的是将镜像读⼊内存，修正镜像内部的指针，性能消耗主要在IO。

Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。

所以，指针数量越少越好。

在这⼀步，我们可以做的优化有：
1. 减少ObjC类（class）、⽅法（selector）、分类（category）的数量
2. 减少C++虚函数的的数量（创建虚函数表有开销）
3. 使⽤Swift structs（内部做了优化，符号数量更少）
3. Objc setup
⼤部分ObjC初始化⼯作已经在Rebase/Bind阶段做完了，这⼀步dyld会注册所有声明过的ObjC类，将分类插⼊到类的⽅法列表⾥，再检查每个selector的唯⼀性。

在这⼀步倒没什么优化可做的，Rebase/Bind阶段优化好了，这⼀步的耗时也会减少。

4. Initializers
到了这⼀阶段，dyld开始运⾏程序的初始化函数，调⽤每个Objc类和分类的+load⽅法，调⽤C/C++ 中的构造器函数（⽤
attribute((constructor))修饰的函数），和创建⾮基本类型的C++静态全局变量。

Initializers阶段执⾏完后，dyld开始调⽤main()函数。

在这⼀步，我们可以做的优化有：
1. 少在类的+load⽅法⾥做事情，尽量把这些事情推迟到+initiailize
2. 减少构造器函数个数，在构造器函数⾥少做些事情
3. 减少C++静态全局变量的个数
main()阶段的优化
这⼀阶段的优化主要是减少didFinishLaunchingWithOptions⽅法⾥的⼯作，在didFinishLaunchingWithOptions⽅法⾥，我们会创建应⽤的window，指定其rootViewController，调⽤window的makeKeyAndVisible⽅法让其可见。

由于业务需要，我们会初始化各个⼆⽅/三⽅库，设置系统UI风格，检查是否需要显⽰引导页、是否需要登录、是否有新版本等，由于历史原因，这⾥的代码容易变得⽐较庞⼤，启动耗时难以控制。

所以，满⾜业务需要的前提下，didFinishLaunchingWithOptions在主线程⾥做的事情越少越好。

在这⼀步，我们可以做的优化有：
1. 梳理各个⼆⽅/三⽅库，找到可以延迟加载的库，做延迟加载处理，⽐如放到⾸页控制器的viewDidAppear⽅法⾥。

2. 梳理业务逻辑，把可以延迟执⾏的逻辑，做延迟执⾏处理。

⽐如检查新版本、注册推送通知等逻辑。

3. 避免复杂/多余的计算。

4. 避免在⾸页控制器的viewDidLoad和viewWillAppear做太多事情，这2个⽅法执⾏完，⾸页控制器才能显⽰，部分可以延迟创建的视图
应做延迟创建/懒加载处理。

5. 采⽤性能更好的API。

6. ⾸页控制器⽤纯代码⽅式来构建。

阿⾥数据iOS端优化实践
在以上的认知指导下，阿⾥数据iOS端开始着⼿优化，在pre-main阶段和main()阶段分别做了⼀系列优化，取得了⼀定的成果。

1. pre-main阶段的优化
1.1. 排查⽆⽤的dylib，移除不再使⽤的libicucore.tbd
1.2. 删除⽆⽤⽂件&库，合并重复⽂件（多个重复的分类）。

移除不再使⽤的库UMSocial、PSTCollectionView、
MCSwipeTableViewCell，移除功能重复的库Mantle。

1.3. 梳理各个类的+load⽅法，将多个类中+load⽅法做的事延迟到+initiailize⾥去做。

优化前pre-main阶段耗时:
优化前pre-main阶段耗时.png
优化后pre-main阶段耗时：
优化后pre-main阶段耗时.png
测试环境：Xcode8.3.3 iOS10.2的模拟器，热启动。

备注：测试发现，pre-main阶段耗时有⼀定波动，冷启动时波动更⼤，这⾥截图贴的是⼀个中位数⽔平。

可以看到热启动下，pre-main阶段耗时有⼀定下降。

2. main()阶段的优化
2.1. 去掉其中100ms的dispatch_after...检查代码发现之前会故意让启动图多显⽰100ms，不知道是什么逻辑...
2.2. 将多个⼆⽅/三⽅库延迟加载。

包括TBCrashReporter、TBAccsSDK、UT、TRemoteDebugger、ATSDK等。

2.3. 将若⼲系统UI配置、业务逻辑延迟执⾏。

包括注册推送、检查新版本、更新Orange配置等。

2.4. 避免多余的计算。

之前会前后两次获取是否要显⽰⼴告图，每次获取都需要反序列化Orange中的配置信息，再⽐较配置中的开始/结束时间，⼤约耗时20ms。

⽬前的解决⽅案是第⼀次计算后，⽤⼀个BOOL属性缓存起来，下次直接取⽤。

2.5. 延迟加载&懒加载部分视图。

快捷密码验证页是启动图消失后⽤户看到的第⼀个页⾯，这个页⾯由于涉及到图⽚的解码、多个视图的创建&布局，viewDidLoad阶段会耗时100ms左右。

⽬前的解决⽅案是把其中密码输⼊框视图延迟到viewDidAppear⾥加载，对密码错误提⽰视图做成懒加载，耗时降低到30m左右。

通过instruments的Time Profiler分析，优化后启动速度有明显提升，didFinishLaunchingWithOptions耗时在75ms左右（iPhone6s
iOS10.3.3）
启动耗时..png
其中⽬前耗时最多的是快捷密码验证页（PAPasscodeViewController）的创建&布局，其次是DTLaunchViewControlle⾥对是否要显⽰⼴告页的判断代码。

可以看到PAPasscodeViewController的viewDidAppear耗时了78ms，但已经没有太⼤关系，此时⽤户已经看到了页⾯，准备去验证指纹/密码了。

总结&后续规划
1. 总结
总结起来，好像启动速度优化就⼀句话：让系统在启动期间少做⼀些事。

当然我们得先清楚⼯程⾥做的哪些事是在启动期间做的、对启动速度的影响有多⼤，然后case by case地分析⼯程代码，通过放到⼦线程、延迟加载、懒加载等⽅式让系统在启动期间更轻松些。

2. 后续规划
2.1. 替代部分庞⼤的库，采⽤更轻量级的解决⽅案。

2.2. 整理代码，去除重复的实现，避免出现功能重复的类&分类&⽅法。

2.3. 梳理和移除已经下线的业务涉及的类&分类&⽅法。

2.4. 监控好灰度版本启动速度的变化趋势，尽早发现&解决拖慢启动速度的问题。

参考资料。