【IT168 评论】背景

　　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. 调用applicationWillFinishLaunching2.4. 调用didFinishLaunchingWithOptions

　　启动耗时的测量

　　在进行优化之前，我们首先应该能测量各阶段的耗时。

　　1. pre-main阶段

　　对于pre-main阶段，Apple提供了一种测量方法，在 Xcode 中 Edit scheme -> Run -> Auguments 将环境变量DYLD_PRINT_STATISTICS 设为1 ：

　　设置好后把程序跑起来，控制台会有如下输出，pre-main阶段各过程的耗时一览无余(Apple这个Demo有点过于夸张...)

　　2. main()阶段

　　对于main()阶段，主要是测量main()函数开始执行到didFinishLaunchingWithOptions执行结束的耗时，就需要自己插入代码到工程中了。先在main()函数里用变量StartTime记录当前时间：

　　CFAbsoluteTime StartTime;int main(int argc, char * argv[]) {

　　StartTime = CFAbsoluteTimeGetCurrent();

　　再在AppDelegate.m文件中用extern声明全局变量StartTime

　　extern CFAbsoluteTime StartTime;

　　最后在didFinishLaunchingWithOptions里，再获取一下当前时间，与StartTime的差值即是main()阶段运行耗时。

　　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()阶段的优化

Tags：

转载请标注：SEO三人行——阿里数据iOS端启动速度优化的一些经验