启动优化
[toc]
- 冷启动：从零开始启动App（主要优化方向）
- 热启动：App已经在内存中卡在后台存活着，再次点击图标启动App
监控启动时间
通过添加环境变量可以打印出APP的启动时间分析（Edit scheme -> Run -> Arguments）
- DYLD_PRINT_STATISTICS设置为1
- 如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS_DETAILS设置为1
DYLD_PRINT_STATISTICS执行结果如下
Total pre-main time: 38.40 milliseconds (100.0%)
dylib loading time: 53.87 milliseconds (140.2%)
rebase/binding time: 126687488.9 seconds (363540810.8%)
ObjC setup time: 8.40 milliseconds (21.8%)
initia lizer time: 39.71 milliseconds (103.4%)
slowest intializers :
libSystem.B.dylib : 4.76 milliseconds (12.4%)
libBacktraceRecording.dylib : 7.03 milliseconds (18.3%)
libobjc.A.dylib : 1.36 milliseconds (3.5%)
CoreFoundation : 1.77 milliseconds (4.6%)
libMainThreadChecker.dylib : 21.30 milliseconds (55.4%)
libLLVMContainer.dylib : 1.08 milliseconds (2.8%)
-
Total pre-main time总时间 -
dylib loading time：dylb动态库加载耗费时间 -
ObjC setup time:：oc结构体的准备耗时时间 -
initia lizer time：初始化耗费时间 -
slowest intializers：列出比较慢的加载
DYLD_PRINT_STATISTICS_DETAILS加载结果
total time: 546.34 milliseconds (100.0%)
total images loaded: 341 (334 from dyld shared cache)
total segments mapped: 21, into 383 pages
total images loading time: 378.72 milliseconds (69.3%)
total load time in ObjC: 11.54 milliseconds (2.1%)
total debugger pause time: 314.03 milliseconds (57.4%)
total dtrace DOF registration time: 0.00 milliseconds (0.0%)
total rebase fixups: 16,059
total rebase fixups time: 1.40 milliseconds (0.2%)
total binding fixups: 492,691
total binding fixups time: 111.76 milliseconds (20.4%)
total weak binding fixups time: 0.02 milliseconds (0.0%)
total redo shared cached bindings time: 175.93 milliseconds (32.2%)
total bindings lazily fixed up: 0 of 0
total time in initializers and ObjC +load: 42.87 milliseconds (7.8%)
libSystem.B.dylib : 5.64 milliseconds (1.0%)
libBacktraceRecording.dylib : 7.61 milliseconds (1.3%)
libobjc.A.dylib : 1.55 milliseconds (0.2%)
CoreFoundation : 2.02 milliseconds (0.3%)
libMainThreadChecker.dylib : 22.31 milliseconds (4.0%)
libLLVMContainer.dylib : 1.11 milliseconds (0.2%)
total symbol trie searches: 1164440
total symbol table binary searches: 0
total images defining weak symbols: 35
total images using weak symbols: 89
冷启动阶段
APP的冷启动可以概括为3大阶段
- dyld:加载动态库阶段
- runtime:runtime初始化OC结构，分类等oc信息
- main:main函数
image.png
App的启动 -dyld阶段
含义：dyld（dynamic link editor），Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）
启动APP时，dyld所做的事情
- 装载APP的可执行文件，同时会递归加载所有依赖的动态库
- 当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理
App的启动 -runtime
启动APP时，runtime所做的事情:
- 调用map_images进行可执行文件内容的解析和处理
- 在load_images中调用call_load_methods，调用所有Class和Category的+load方法
- 进行各种objc结构的初始化（注册Objc类 、初始化类对象等等）
- 调用C++静态初始化器和attribute((constructor))修饰的函数
到此为止，可执行文件和动态库中所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理
App的启动 -main
main函数中的方法
总结
APP的启动由dyld主导，将可执行文件加载到内存，顺便加载所有依赖的动态库
并由runtime负责加载成objc定义的结构
所有初始化工作结束后，dyld就会调用main函数
接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法
APP的启动优化
dyld阶段
- 减少动态库、合并一些动态库（定期清理不必要的动态库）
- 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）
- 减少C++虚函数数量
- Swift尽量使用struct
runtime阶段
用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++静态构造器、ObjC的+load
main阶段
- 在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中
- 按需加载
