启动优化

[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方法中
• 按需加载