App 启动时长优化

背景：在后台查看 App 启动时间有的能达到 2-15s 不等，中东的甲方爸爸受不了决定抽出时间优化启动时长。

优化结果

由原先的 2-15s 不固定时长降低到 800ms 左右

启动过程

冷启动耗时

首先看下冷启动耗时，主要分为了 pre-main 阶段和 main() 阶段，接下来分别在这两个阶段查看耗时以及优化。

1. pre-main 阶段耗时

1. dylib loading time：动态库载入耗时

   内嵌的定制化 IMLib SDK 就有 8 个，能用到的就 2 个，一直没有处理

   imlib
   imlibcore  
   chatroom  
   location  
   customerservice  
   discussion  
   publicserice  
   translation

2. rebase/binding time：修正符号和绑定符号的耗时

   2.1 rebase：image list 打印的项目的地址 + linkMap 中的 _main 的 Address Size 就是实际的 main 函数的内存地址也就是准确地址（ dis-s 0x00000001049+0x6194）

   2.2 binding：iOS 系统在 App 的可执行文件中，添加一个符号，等到运行的时候，由系统去绑定我们的符号，找到真正的外部函数。

   App 的 UI 修改了几遍，页面和架构也重构了两三次，剩余一堆冗余的代码未清理。

3. ObjC setup time：Objc 类的注册、category 的定义插入方法列表、保证 selector 唯一的耗时

4. initializer time：Objc 类的 +load()、C++ 的构造函数属性函数的构造函数、C++ 的静态全局变量创建的耗时

2. main() 阶段耗时

主要是 application:didFinishLaunchingWithOptions: 中的 SDK 初始化、业务注册、各个模块业务处理等耗时

优化方案

1. pre-main 阶段优化

1. 动态库处理

   删除/合并 5 个动态库，最终剩余 3 个。

   1. 移除 IMLib 对 customerservice、discussion、publicserice 的依赖，并从打包脚本中删除命令
   2. 因为只使用了 location 库中的位置消息，其他均未使用，所以合并 location 的消息到 IMLib 中，并删除 location 库

2. 清理无用类、分类、方法

   通过 AppCode 里的 Code->Inspect Code 进行静态分析，二次确认无用后删除

3. 减少 C++ 的构造函数

   C++ 对象基本在底层协议栈中，未处理。

4. 二进制重排（Clang 插桩）

   领导不建议这个阶段调整，未处理。

   PageFault 次数和代码量相关，如何减少 Page in 次数：启动时刻把需要调用的方法放在一起，不需要调用的，放在后面（优化可执行文件）

2. main() 阶段优化

不重要的业务后移（启动项后置）

1. IM 连接迁移到子线程（因为某些情况下会被协议栈卡住）
2. 除了 injector 注册等必须的业务在 application:didFinishLaunchingWithOptions: 之外，其他的迁移到 applicationDidBecomeActive

3. 启动优化的骚操作

冷启动时 App 先加载一个和启动图一模一样的 VC，等 VC 显示后再初始化业务的 rootVC。

4. 其他处理

GCD 多线程优化

开发者创建的 GCD 队列，默认的 QoS 实际为 User-Initiated，User-Interactive 和 User-Initiated 对主线程有明显抢占。尽量将启动无关的线程设置为 Utility 或者 Background，减少对主线程的抢占。

参考文章：不改一行业务代码，飞书 iOS 低端机启动优化实践