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 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越少越好。在这一步，咱们能够作的优化有：

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. 监控好灰度版本启动速度的变化趋势，尽早发现&解决拖慢启动速度的问题。

参考资料

• WWDC Optimizing App Startup Time

• attribute 总结

• dyld 加载 Mach-O

• 优化 App 的启动时间

• 今日头条iOS客户端启动速度优化