背景
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
3
|
cfabsolutetime starttime;
int main(int argc, char * argv[]) {
starttime = cfabsolutetimegetcurrent();
|
再在appdelegate.m文件中用extern声明全局变量starttime
|
1
|
extern cfabsolutetime starttime;
|
最后在didfinishlaunchingwithoptions里，再获取一下当前时间，与starttime的差值即是main()阶段运行耗时。
|
1
|
double launchtime = (cfabsolutetimegetcurrent() - starttime);
|
pre-main阶段的优化
要对pre-main阶段的耗时做优化，需要再学习下dyld加载的过程，根据apple在wwdc上的介绍，dyld的加载主要分为4步：
1. load dylibs
这一阶段dyld会分析应用依赖的dylib，找到其mach-o文件，打开和读取这些文件并验证其有效性，接着会找到代码签名注册到内核，最后对dylib的每一个segment调用mmap()。
一般情况下，ios应用会加载100-400个dylibs，其中大部分是系统库，这部分dylib的加载系统已经做了优化。
所以，依赖的dylib越少越好。在这一步，我们可以做的优化有：
尽量不使用内嵌（embedded）的dylib，加载内嵌dylib性能开销较大
合并已有的dylib和使用静态库（static archives），减少dylib的使用个数
懒加载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计算。
所以，指针数量越少越好。在这一步，我们可以做的优化有：
减少objc类（class）、方法（selector）、分类（category）的数量
减少c++虚函数的的数量（创建虚函数表有开销）
使用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()函数。
在这一步，我们可以做的优化有：
少在类的+load方法里做事情，尽量把这些事情推迟到+initiailize
减少构造器函数个数，在构造器函数里少做些事情
减少c++静态全局变量的个数
main()阶段的优化
这一阶段的优化主要是减少didfinishlaunchingwithoptions方法里的工作，在didfinishlaunchingwithoptions方法里，我们会创建应用的window，指定其rootviewcontroller，调用window的makekeyandvisible方法让其可见。由于业务需要，我们会初始化各个二方/三方库，设置系统ui风格，检查是否需要显示引导页、是否需要登录、是否有新版本等，由于历史原因，这里的代码容易变得比较庞大，启动耗时难以控制。
所以，满足业务需要的前提下，didfinishlaunchingwithoptions在主线程里做的事情越少越好。在这一步，我们可以做的优化有：
梳理各个二方/三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的viewdidappear方法里。
梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。
避免复杂/多余的计算。
避免在首页控制器的viewdidload和viewwillappear做太多事情，这2个方法执行完，首页控制器才能显示，部分可以延迟创建的视图应做延迟创建/懒加载处理。
采用性能更好的api。
首页控制器用纯代码方式来构建。
阿里数据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. 监控好灰度版本启动速度的变化趋势，尽早发现&解决拖慢启动速度的问题。