转载自腾讯云
App启动过程
- 解析Info.plist
加载相关信息，例如如闪屏
沙箱建立、权限检查 - Mach-O加载
如果是胖二进制文件，寻找合适当前CPU类别的部分
加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
定位内部、外部指针引用，例如字符串、函数等
执行声明为attribute((constructor))的C函数
加载类扩展（Category）中的方法
C++静态对象加载、调用ObjC的 +load 函数 - 程序执行
调用main()
调用UIApplicationMain()
调用applicationWillFinishLaunching
一、main()函数之前耗时
main函数启动之前耗时，对于一般的小型APP来说，影响微乎其微，但对于大型APP(动态库超过50或二进制文件超过30MB)来说，就会变得很明显，官方也提供了支持。
一般来说main()函数之前耗时 不宜超过400毫秒，之前与之后整体时间不宜超过20秒，如果超过20秒，系统会关闭进程，无法启动APP。
1、设置耗时日志输出，添加如下图所示变量环境
name：DYLD_PRINT_STATISTICS
value：1
2、运行Xcode，得到耗时报告
输出日志：
Total pre-main time: 460.69 milliseconds (100.0%)
dylib loading time: 85.29 milliseconds (18.5%)
rebase/binding time: 290.96 milliseconds (63.1%)
ObjC setup time: 57.51 milliseconds (12.4%)
initializer time: 26.80 milliseconds (5.8%)
slowest intializers :
libSystem.B.dylib : 2.63 milliseconds (0.5%)
libMainThreadChecker.dylib : 15.46 milliseconds (3.3%)
日志解释
main函数之前 共耗时460.69毫秒
动态库(dylib)加载 耗时85.29毫秒 占耗时18.5%
指针定位 耗时290.96 占耗时63.1%
类初始化 耗时57.51 占耗时12.4%
其它初始化 耗时 26.80 占耗时5.8%
比较耗时（或者说初始化慢的）有：
libSystem.B.dylib 耗时 2.63 占耗时0.5%
libMainThreadChecker.dylib 15.46 占耗时3.3%
main函数之前影响启动性能的因素
动态库加载越多，启动越慢。
- ObjC类越多，启动越慢
- C的构造函数越多，启动越慢
- C++静态对象越多，启动越慢
- ObjC的+load越多，启动越慢
二、main()函数之后耗时
从main函数开始至applicationWillFinishLaunching结束，称为main函数之后的部分。
main函数之后影响启动性能的因素
- 执行main()函数的耗时
- 执行applicationWillFinishLaunching的耗时
- 根控制器(rootViewController)及其子控制器(childViewController)的加载、视图(view)及其子视图(subviews)的加载耗时
三、优化的目标
启动过程分为四个部分：
1、 main()函数之前
2、main()函数之后至applicationWillFinishLaunching完成
3、App完成所有本地数据的加载并将相应的信息展示给用户
4、App完成所有联网数据的加载并将相应的信息展示给用户
1+2一起决定了我们需要用户等待多久才能出现一个主视图，同时也是技术上可以精确测量的时长。
1+2+3决定了用户视觉上的等待出现有用信息所需要的时长。1+2+3+4决定了我们需要多少时间才能让我们需要展示给用户的所有信息全部出现。
四、优化策略
- 移除不需要用到的动态库（利用 DYLD_PRINT_STATISTICS 变量来定位）
- 移除不需要用到的类（可以使用fui进行辅助移除）
- 合并功能类似的class和category
- 压缩资源图片（Xcode在编译App的时候，已经自动把需要打包到App里的资源图片压缩过一遍了。然而Xcode的压缩会相对比较保守）
- 优化applicationWillFinishLaunching（将不需要马上在此方法中执行的代码延后执行）
- 优化rootViewController加载（适当将某一级的childViewController或subviews延后加载）
- 异步操作不影响耗时，但影响交互体验（视觉上的优化有时比技术手段效果更好）
网友评论