ios启动时间优化--实践

一般而言，启动时间是指从用户点击 APP 那一刻开始到用户看到第一个界面这中间的时间。我们进行优化的时候，我们将启动时间分为 pre-main 时间（详细的pre-main介绍）和 main 函数到第一个界面渲染完成时间这两个部分。

因为 APP 的入口在 main 函数 ，在 main 函数之后我们的业务代码（除了+load方法）才会执行。

这里有两个阶段

1. pre-main阶段

1.1. 加载应用的可执行文件 ， Mach-O文件

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

我们把 pre-main阶段称为 t1，main()阶段一直到首个页面加载完成称为 t2。

t1 时间的优化分析   

苹果为查看 pre-main 提供了支持，具体配置如下在 Xcode 中 Edit scheme -> Run -> Auguments，配置的 key 为：DYLD_PRINT_STATISTICS。

还需要勾选下面这个选项：

然后再运行项目，Xcode 就会在控制台输出这部分 pre-main 的耗时：

//结果为
Total pre-main time: 1.4 seconds (100.0%)
         dylib loading time: 1.3 seconds (89.4%)
        rebase/binding time:  36.75 milliseconds (2.5%)
            ObjC setup time:  35.65 milliseconds (2.4%)
           initializer time:  80.97 milliseconds (5.5%)
           slowest intializers :
             libSystem.B.dylib :  12.63 milliseconds (0.8%)
//解读
1、main()函数之前总共使用了1.4s

2、在94.33ms中，加载动态库用了1.3s，指针重定位使用了36.75ms，ObjC类初始化使用了35.65ms，各种初始化使用了80.97ms。

3、在初始化耗费的80.97ms中，用时最多的初始化是libSystem.B.dylib。

可以看到,我的 dylib loading time 花费了 1.3s时间，dyld的加载主要分为4步：

加载dylib
分析每个dylib（大部分是iOS系统的），找到其Mach-O文件，
打开并读取验证有效性，找到代码签名注册到内核，这个验证代码签名的可以看这里,https://blog.csdn.net/u014600626/article/details/103794633 . 调试打的包只能安装在指定的设备上,就是在这一步验证的  
最后对dylib的每个segment调用mmap(), mmap将一个文件或者其它对象映射进内存。。

rebase/bind
dylib加载完成之后，它们处于相互独立的状态，需要绑定起来。

在dylib的加载过程中，系统为了安全考虑，引入了ASLR（Address Space Layout Randomization）技术和代码签名。
由于ASLR的存在，镜像（Image，包括可执行文件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有一个偏差（slide），dyld需要修正这个偏差，来指向正确的地址。
Rebase在前，Bind在后，Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。
Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。

OC setup
OC的runtime需要维护一张类名与类的方法列表的全局表。
dyld做了如下操作：

对所有声明过的OC类，将其注册到这个全局表中（class registration）
将category的方法插入到类的方法列表中（category registration）
检查每个selector的唯一性（selector uniquing）

Initializers

到了这一阶段，dyld开始运行程序的初始化函数，调用每个Objc类和分类的+load方法，调用C/C++ 中的构造器函数（用attribute((constructor))修饰的函数），和创建非基本类型的C++静态全局变量。Initializers阶段执行完后，dyld开始调用main()函数。

在这一步，我们可以做的优化有：

1. 少在类的+load方法里做事情，尽量把这些事情推迟到+initiailize

2. 减少构造器函数个数，在构造器函数里少做些事情

3. 减少C++静态全局变量的个数

如果在各个 OC 类别的 ‘load’方法里做了不少事情(如在里面使用 Method swizzle),那么这是pre-main阶段最耗时的部分。dyld运行APP的初始化函数，调用每个OC类的+load方法，调用C++的构造器函数（attribute((constructor))修饰），创建非基本类型的C++静态全局变量，然后执行main函数。
 

所以T1阶段的优化思路是

1. 移除不需要用到的动态库
2. 移除不需要用到的类
3. 合并功能类似的类和扩展
4. 尽量避免在+load方法里执行的操作，可以推迟到+initialize方法中。

---

t2 时间的优化分析

main之后主要做了这些事情 ,https://blog.csdn.net/u014600626/article/details/104597424,
t2使用了来自NewPan大大 的打点计时器BLStopwatch

生活中，我们计量一段时间一般是用计时器。这里我们要想知道哪些操作，或者说哪些代码是耗时的，我们也需要一个打点计时器。用过 profile 的朋友都知道这个工具很强大，可以使用它来分析出哪些代码是耗时的。但是它不够灵活，我们来看一下我们的这个计时器应该怎么设计。

如上图所示，在时间轴上，我们从 start 开始打点计时，然后我们在第一个小红旗那里打了一个点，记录这段代码的耗时，然后又在第二个小红旗那里打了一个点，记录这中间代码的耗时。然后在结束的地方打一个点，然后把所有打点的结果展示出来。同时，我们为每段计时加上标注，用来区分这段时间是执行了什么操作花费的时间。这样一来，我们就能快速精准的知道究竟是谁拖慢了启动。

大致原理就是这样，现在到工程中：

检测耗时

可以看到，我的 APP 加载时间并没有很慢，但是也想看一看有没有优化的空间。

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

初始化第三方 SDK
配置 APP 运行需要的环境
自己的一些工具类的初始化
...

这里主要参考[iOS]一次立竿见影的启动时间优化
从优化图可以看到，我的应用的跳转逻辑是 打开 -> 广告页 -> 首页，首页的UI 架构是:

但是如果 UI 架构如上，并且在didFinishLaunchingWithOptions里面设置了根视图

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSLog(@"didFinishLaunchingWithOptions 开始执行");

    self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    TestTabBarController *tabBarVc = [TestTabBarController new];
    self.window.rootViewController = tabBarVc;
    [self.window makeKeyAndVisible];

    NSLog(@"didFinishLaunchingWithOptions 跑完了");

    return YES;
}

然后我们来到 TestTabBarController 里的 viewDidLoad方法里进行它的 viewControllers 的设置，然后再进入到每个 viewController 的 viewDidLoad 方法里进行更多的初始化操作。那么你觉得从 didFinishLaunchingWithOptions 到最后显示展示的 viewController 的 viewDidLoad 这些方法的执行顺序是怎么样的呢？

didFinishLaunchingWithOptions 开始执行 
开始加载 TestTabBarController 的 viewDidLoad
didFinishLaunchingWithOptions 跑完了
开始加载 TestViewController 的 viewDidLoad, 然后执行一堆初始化的操作

在TestTabBarController 中操作了 TestViewController 的 view 的话，那么调用顺序将会是这样：

didFinishLaunchingWithOptions 开始执行 
开始加载 TestTabBarController 的 viewDidLoad
开始加载 TestViewController 的 viewDidLoad, 然后执行一堆初始化的操作
didFinishLaunchingWithOptions 跑完了

这样的问题就是当我们把界面的初始化、网络请求、数据解析、视图渲染等操作放在了viewDidLoad 方法里，这样一来每次启动 APP 的时候，在用户看到第一个页面之前，我们要把这些事件全部都处理完，才会进入到视图渲染阶段。

一般来说，我们放到didFinishLaunchingWithOptions执行的代码，有很多初始化操作，如日志，统计，SDK配置等。尽量做到只放必需的，其他的可以延迟到MainViewController展示完成viewDidAppear以后。

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

• 第一类，必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。

• 第二类，这些功能在用户进入 APP 主体的之前是必须要加载完的，我把他放到广告页面的viewDidAppear启动。

• 第三类，由于启动时不是必须的，所以我们可以放在第一个界面的 viewDidAppear 之后处理，这里完全不会影响到启动时间。

 

T2阶段的优化思路是

梳理各个三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的viewDidAppear方法里。

梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。

避免复杂/多余的计算。避免归档解档，读取本地文件的操作

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

采用性能更好的API。

首页控制器用纯代码方式来构建。

 

总结

性价比最高的优化阶段就是t2的一些逻辑整理，尽量将不需要的耗时操作延迟到首屏展示之后执行。
同时一般来说，优化应该在项目完成稳定之后进行，避免过早优化.