对于iOS App的首次启动优化，主要关注两个点，一个是main之前的耗时，一个就是main函数到root VC viewWillAppear执行完之间的耗时

针对main函数到首页展示之间的耗时

• 避免在这之间有阻塞主线程的任务
• 避免大量的IO操作
• 能延后的任务就延后再处理

针对main函数之前的耗时

1.pre-main耗时检测

我们可以通过设置环境变量来统计pre-main的耗时

• 操作路径：Edit Scheme -- 选择一个Scheme（比如：Run）-- 选择Arguments -- Environment Variables -- 点击添加 -- 设置 name： DYLD_PRINT_STATISTICS value ： ${DEBUG_ACTIVITY_MODE}

具体如下图所示：

1576824195149.png

启动app看下打印如下：

Total pre-main time: 276.51 milliseconds (100.0%)
         dylib loading time:  43.44 milliseconds (15.7%)
        rebase/binding time: 170.22 milliseconds (61.5%)
            ObjC setup time:  24.74 milliseconds (8.9%)
           initializer time:  37.80 milliseconds (13.6%)
           slowest intializers :
             libSystem.B.dylib :   8.75 milliseconds (3.1%)
    libMainThreadChecker.dylib :  13.70 milliseconds (4.9%)
  libViewDebuggerSupport.dylib :   6.38 milliseconds (2.3%)

通过日志我们发现，在main之前有哪些时间消耗

• dylib loading ：加载可执行文件（App 的.o 文件的集合）， 加载动态链接库；
• rebase/binding ：对动态链接库进行 rebase 指针调整和 bind 符号绑定；
• Objc setup ：Objc 运行时的初始处理，包括 Objc 相关类的注册、category 注册、selector 唯一性检查等；
• initializer：包括了执行 +load() 方法、attribute((constructor)) 修饰的函数的调用、创建 C++ 静态全局变量

那么我们知道在pre-main有哪些时间消耗阶段，针对性的对症下药就可以优化一些启动的时间：

• 减少动态库的个数，如果太多就使用合并的方式控制，这样可以节约dylib loading及rebase/binding的时间
• 清理项目中未用到的类、类别、方法等，这样可以节约Objc setup的时间
• 对于可以不在+load中处理的逻辑可以放到其他的函数中去处理，比如：+initialize；控制 C++ 全局变量的数量；这样可以节约initializer的时间

当我们做了以上的工作，对pre-main的时间有所优化之后，如果还想再进行优化，那就需要借助LLVM为我们提供的优化方式了，下面就介绍两种方式：二进制重排、PGO

2.二进制重排

二进制重排，主要是优化我们启动时需要的函数非常分散在各个页，启动时就会多次Page Fault造成时间的损耗

2.1 Page Fault

进程如果能直接访问物理内存无疑是很不安全的，所以操作系统在物理内存的上又建立了一层虚拟内存。为了提高效率和方便管理，又对虚拟内存和物理内存又进行分页（Page）。当进程访问一个虚拟内存Page而对应的物理内存却不存在时，会触发一次缺页中断（Page Fault），分配物理内存，有需要的话会从磁盘mmap读人数据。

通过App Store渠道分发的App，Page Fault还会进行签名验证，所以一次Page Fault的耗时比想象的要多：

1576828087955.png

2.2 如何查看app启动产生的Page Faults

检测app启动Page Faults次数

2.3 重排

编译器在生成二进制代码的时候，默认按照链接的Object File(.o)顺序写文件，按照Object File内部的函数顺序写函数。

静态库文件.a就是一组.o文件的ar包，可以用ar -t查看.a包含的所有.o

图片.png

简化问题：假设我们只有两个page：page1/page2，其中绿色的method1和method3启动时候需要调用，为了执行对应的代码，系统必须进行两个Page Fault。

但如果我们把method1和method3排布到一起，那么只需要一个Page Fault即可，这就是二进制文件重排的核心原理。

图片.png

2.4 Xcode配置Order

那么我们需要将启动时候调用的函数进行重排，让它们尽可能的分配在同一个页；比如load方法我们就将其找出来，放到一起；LLVM支持我们通过设置order来达到这个效果

图片.png

2.4.1 首先打开Write Link Map File查看

Link Map File中文直译为链接映射文件，它是在Xcode生成可执行文件的同时生成的链接信息文件，用于描述可执行文件的构造部分，包括了代码段和数据段的分布情况
我们可以在Xcode的配置中将Write Link Map File设置为YES来生成Map File

图片.png

Run下一app，查看Map File

Map File路径：
$(TARGET_TEMP_DIR)/$(PRODUCT_NAME)-LinkMap-$(CURRENT_VARIANT)-$(CURRENT_ARCH).txt
可以选中app，Show In Finder -- 找到build目录 -- 按照下面的举例的路径就可以找到:
Build/Intermediates.noindex/RuntimeLearning.build/Debug-iphoneos/RuntimeLearning.build/RuntimeLearning-LinkMap-normal-arm64.txt

打开Map File可以看到load方法分散的很开，当启动执行的函数很多的话，那就可能load分散在不同的页了。

图片.png

2.4.2 将load方法设置order再看看Map File

• 新建xxx.order文件
• Xcode的Build Setting中设置Order文件

图片.png

• 编辑order文件如下：

+[UIViewController(Test) load]
+[UIFont(Test) load]
+[SubTestUnsafeSwizzle load]
+[TestCategorySwizzle(Log) load]
+[TestCategorySwizzle(EventTrack) load]
+[TestCategorySwizzle(ClassMethod) load]
+[NSObject(RLSafe) load]
-[AppDelegate application:didFinishLaunchingWithOptions:]
-[AppDelegate applicationWillResignActive:]
-[AppDelegate applicationDidEnterBackground:]
-[AppDelegate applicationWillEnterForeground:]
-[AppDelegate applicationDidBecomeActive:]
-[AppDelegate applicationWillTerminate:]
-[AppDelegate window]
-[AppDelegate setWindow:]
-[AppDelegate .cxx_destruct]

• 再次运行，查看Map File文件

  
  
  图片.png

可以看到Map File已经按照我们order配置的顺序了；这里只是讲述了如何使用order，具体的细节、原理和实践可以参照抖音二进制重排实践；他们的数据是启动优化了15%。

3. PGO

Profile Guided Optimization简称PGO，这个也是LLVM提供的一个优化，我们可以直接在Xcode中进行配置；它是一种改进应用程序的编译器优化的方法。PGO利用应用程序的特殊工具构建来生成有关最常用代码路径和方法的配置文件信息。然后，编译器使用此配置文件信息将优化工作集中在最常用的代码上，从而利用有关程序通常如何表现的额外信息来更好地完成优化工作

配置文件引导式优化（PGO）是一项高级功能，可让您从应用中获取所有性能的最后一点点。它并不难使用，但是需要一些额外的构建步骤和一些注意事项来收集良好的配置文件信息。根据您应用程序代码的性质，PGO可以将性能提高5％到10％，但并非所有应用程序都会从​​中受益。如果您对性能敏感的代码需要进行额外的优化，则PGO可以提供帮助。

原理上简单说如下：

1. 编译一个所有方法插桩了的可执行文件，
2. 运行可执行文件（启动一次app），此时插桩的方法会把执行过的方法都记录下来，并记录方法的执行频率。例如下图的profdata文件。
3. 重新build（原则上只是链接时需要profdata），让链接器按照profdata的信息把（启动中用到的、或者频率高的方法）放到一起。

此时这个新的可执行文件就完成了二进制文件重排，减少了page交换（加载）的次数，提高了系统加载和运行app二进制文件的IO性能，加快了执行速度；这个相比较order的方式，这个优化还考虑了函数调用频率的问题

Xcode配置

• 打开Use Optimization Profile

  
  
  图片.png

• 选择Action生成Profile

  
  
  图片.png

图片.png

• Run之后，会在根目录自动创建一个文件OptimizationProfiles
  
  图片.png

PGO也是官方提供的一个优化手段，具体细节可以参照苹果官方文档：Xcode Profile Guided Optimization；对于有多大的提升我这边跑了几次发现每次数据都有些出入，加上demo比较小，看着也不是很明显，感兴趣的可以在自己的项目中使用这项LLVM的优化

如何获取app启动都调用了哪些函数

iOS App启动时间优化--Clang插桩获取启动调用的函数符号

参考文档

• Xcode Profile Guided Optimization
• 抖音二进制重排实践
• 由「抖音二进制文件重排」想到的
• iOS调优 | 深入理解Link Map File