iOS App启动过程分析及优化

原因

一般来说App在早期的时候，启动是不需要去优化的，不会有明显的性能问题。随着时间的推移，项目的迭代，资源的替换，导致整个项目冗余的文件、资源和一些非系统库越来越多，启动时需要做的事，需要启动的内容也越来越多。所以就导致性能越来越差，启动也就越来越慢。

App启动类型

我们一般把App启动分为两种：

冷启动

进程没有在运行，也没有在后台。这个时候点击桌面应用图标，加载并创建应用进程，直到App内容显示完毕。

热启动

这个时候的App是还在运行的，比如你刚刚打开的应用，然后摁下Home键回到了桌面，然后你又点击图标启动了App。

热启动通常情况下都是没什么问题的，启动起来也都比较快。主要优化的目标还是冷启动。我们先了解一个冷启动的过程中，系统都做了什么：

启动时间

1. 加载系统dylib和可执行文件的时间。（pre-main）

1. 从main到applicationWillFinishLaunching结束的时间。（main-启动完成）

image

启动时间分析

1.开启时间分析功能

在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到 Run → Environment Variables →+，添加name为DYLD_PRINT_STATISTICS value为1的环境变量。

image

QQ20200426-093133.png

2.解读

main()函数之前总共使用了137.26ms
在137.26ms中，加载动态库用了39.94ms，指针重定位使用了31.29ms，ObjC类初始化使用了8.21ms，各种初始化使用了57.82ms。
在初始化耗费的57.82ms中，用时最多的几个初始化是libSystem.B.dylib、libBacktraceRecording.dylib、libglInterpose.dylib以及libMTLInterpose.dylib。

3.耗时的影响因素

1. main()函数之前耗时的影响因素

• 动态库加载越多，启动越慢。
• ObjC类越多，启动越慢
• C的constructor函数越多，启动越慢
• C++静态对象越多，启动越慢
• ObjC的+load越多，启动越慢

2. main()函数之后耗时的影响因素

从main()函数开始至applicationWillFinishLaunching结束，我们统一称为main()函数之后的部分。

• 执行main()函数的耗时
• 执行applicationWillFinishLaunching的耗时
• rootViewController及其childViewController的加载、view及其subviews的加载

解决策略

我们可以通过开启时间分析功能，首先来查看并判断出在启动时间内，主要消耗时间的流程是在main()函数之前还是main()函数之后。

我们上面也对关于main()函数之前和之后的影响因素进行了分析。既然知道了影响因素，那我们要做的事情就很明了了。

1. 对于main() 之前的耗时因素进行优化：

1. 减少非系统库的依赖
2. 合并非系统库
3. 使用静态资源，比如把代码加入主程序
4. 减少Objc类数量， 减少selector数量
5. 减少C++虚函数数量
6. 转而使用swift struct（其实本质上就是为了减少符号的数量）
7. 减少不必要的framework，因为动态链接比较耗时
8. 检查 framework应当设为optional和required，如果该framework在当前App支持的所有iOS系统版本都存在，那么就设为required，否则就设为optional，因为optional会有些额外的检查
9. 合并或者删减一些OC类，清理项目中没用到的类。

2. 对于main() 之后的耗时因素进行优化：

1. 纯代码方式而不是storyboard加载首页UI，storyboard启动起来更加消耗资源。
2. 对实现了+load()方法的类进行分析，尽量将load里的代码延后调用。由于我们的项目现在主要语言是swift，苹果在swift里面已经拒绝开发者使用+load方法，更加鼓励我们去使用initializer,所以这一条我们不用太担心。
3. 对于viewDidLoad以及viewWillAppear方法中尽量去尝试少做，晚做，不做。

对于 didFinishLaunchingWithOptions，这里面的初始化是必须执行的，但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。对于我们项目，我将初始化分为三个类型：

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

对于第一类，由于这类事件的特殊性，所以必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。第二类事件，这些功能在用户进入 APP 主体的之前是必须要加载完的，所以我们可以把它放在第二批，也就是用户已经看到广告页面，再进行广告倒计时的时候再启动。第三类事件，由于不是必须的，所以我们可以放在第一个界面渲染完成以后的 viewDidAppear 方法里，这里完全不会影响到启动时间。

参考文章：
[贝聊科技]一次立竿见影的启动时间优化