前言

当我们的应用程序非常庞大的时，打开我们的App感觉非常卡，启动比较缓慢，非常影响用户的体验，那么如何才能使我们的App启动比较流畅，给用户很好的体验，这篇文章将给大家带来App启动优化相关的知识。

1 App启动流程分析

App的启动我们一般分为两个部分：main函数之前即pre-main和main函数之后

1.1 pre-main阶段流程

我们通过DYLD监测一下pre-main的时间消耗，我们在xcode中设置一个参数，如图

截屏2021-09-03 下午4.51.09.png

我们启动App，看下输出结果，如下图

image

这时显示了在pre-main阶段流程的耗时，这是一个空工程，是在模拟器运行，所以时间不准，真机一个工程大概在400ms左右。

dylib loading 加载动态库的时间
rebase/binding 重定向/绑定的时间
ObjC setup OC类的注册时间
initializer 注册方法的时间(load，构造函数的耗时)
这是pre-main的基本流程

1.2 dylib动态的加载

dylib的加载的耗时是必然的，系统的动态库是已经载入共享缓存空间，系统动态库已经做了高速的优化，但是我们自定义的动态库不一样，所以苹果的建议不要大于6个动态库，如果大于6个，尽量合并。

1.3 ObjC setup

因为我们的OC是动态语言，OC类的注册

读取Mach-o的data字段，找到OC类的相关信息
注册OC类，OC的runtime需要维护映射表即SEL/IMP的映射以及类名与类的全局表，当加载Mach-o的时候，这些所有的类都要注册到全局表中，除些之外，还有类别，协议信息要插入到方法列表中，这是必然的损耗，所以这里的优化减少OC的类的定义、删除无用的OC的类文件（只要这个类存在即使没有用到，也会造成时间损耗）

1.4 initializer

在load方法以及构造函数中，尽量不要做延迟加载的事情，把消耗的任务放在子线程去，以减少主线程的开销，数据可以缓存。

以上几点的优化都比较简单，下理我们来介绍rebase/binding 重定向/绑定，再介绍之前，我们先来讲来虚拟内存相关的知识

2 虚拟内存介绍

2.1 虚拟地址的概念

操作系统在早期加载应用程序时，直接把应用程序载入到物理内存，这时应用程序的地址就是真实在物理内存条的地址，这么做什么有问题呢？

导致内存不够用：应用直接被加载物理内存中，如果加载很多应用，会报内存不足，这个时候把之前的应用杀掉，才可以访问
不安全，原因：比如游戏外挂，可以直接访问物理内存，定位到代码的相关内存，可直接修改。

为了解决内存不足的问题，这个时候虚拟内存。
加载到内存的应用，用户一般不会使用应用的所有功能，这也说明完全加载到内存的应用，有一块内存有可能没有用到，这就导致内存的浪费。
为了解决这些问题，就用懒加载的方式，把应用分成一块一块，当我们启动应用程序时，启动时需要加载的代码载入到内存中，当用到新的功能时，再加载这块内存，这就是懒加载。
但是这个时候有一个问题，会造成我们的代码不连续，程序访问会变得很复杂，每次要重新计算地址。
虚拟内存表的出现解决了这个问题，存储应用程序与真实物理内存之间的映射关系。

image

这张图很好的说明了虚拟内存表与物理内存之前的映射关系。
为了提高效率和性能，这个时候出现了Page（分页）加载，目前在iOS中一页的大小是16k，Mac(PAGESIZE命令)上是4k。

这时解决内存不足的问题，同时也解决相对安全，因为这个时候游戏外挂是不可能直接访问到物理内存，只能访问虚拟内存，再通过MMU翻译，访问物理内存，这个时候游戏外挂只能访问到自己的进程内存空间，进程之间的安全隔离。

2.2 内存分页的原理

我们分析下应用程序是怎么加载到内存中的。
虚拟内存表是4G的大小
我们看下图

image

在这张图中：

进程1的虚拟页表中，P1,P3,P5启动时加载到内存中，当用户在操作过程中，当需要用到P2的数据，发现P2未加载到内存，操作系统会发出缺页异常（缺页中断），这个时候CPU要执行代码会中断掉，操作系统会把P2的数据加载到物理内存中，哪里有空闲位置就插入到这里，一般来说，手机启动后一段时间，基本没有空闲位置，操作系统会通过页面置换算法覆盖掉不活跃的内存
PAGEZERO，当我们访问到大于或小于我们代码空间时，会指向空，在真实物理内存中就是一个小小的标记，做到进程之间的隔绝。
我们能输入最大的地址是8G，不可能超过8G，我们的内存是用8个字节表示一个地址。
我们能访问最大是8G，也就是从0x0000010000000（4G）开始访问，但是前面4G是不能访问的，是为了隔离32位，64位程序要兼容32位，为了区分64位与32位，所以64位都是从1开始访问。
系统为了给进程之间合法的通讯，就提供的专用的接口，通过kernel发信号。

3 PageFault调试&启动优化的原理

3.1 CPU的32位和64位的概念

CPU的32位和64位指的是CPU上的一个部件，叫数据总线。
CPU上有很多针脚，主板有一排一排的线，这是导线，每根线，只有1和0两种状态组成，8根线一次通信表示1个字节，32位是4字节，所在32位系统中，地址都是4G以内，这是数据总线。
32位和64位指的就是CPU的吞吐量，一次放电能读或者写多大的数据。
在64位中，一个内存地址占用8字节，在面向对象语言中，对象的传递也是8字节（指针），这样最高效。

3.2 binding/绑定

为什么会有绑定的过程？
在内部文件要访问外部的函数时，我们是通过内部的符号绑定之后去访问，所以绑定的耗时是必然有的。
要想减少这部分的耗时只能减少去外部函数的访问，但是这里的绑定是懒加载的绑定方式，所以减少这部分耗时也不会有什么效果

3.3 rebase/重定向

当我们虚拟内存出现之后，虚拟内存都是从0开始，这样只要计算出偏移地址就可以进行访问，造成相对的不安全的，为了解决这个问题，就引入了ASLR技术，这样每次生成的虚拟内存表从一个随机值开始，每次都不一样，这样每次启动应用，起始地址都不一样，就无法直接通过计算文件偏移地址访问。
但是ASLR的出现，内部的文件都要通过这个ASLR计算偏移后才能访问。
我们的代码在编译后在Mach-o中已经确定好地址，如图

image

这里的offset就是代码在文件的偏移量，它是固定的，由于ASLR技术，每次执行的时候，就是ASLR+offset才能找到对应的函数和方法，这个过程就是rebase/重定向。

3.4 二进制重排

二进制重排可以对我们的启动时间优化，这是为什么呢，我们来分析下。
上文中，我们讲过当我们的代码访问到没有被载入内存的Page数据时，这个时候会发生PageFault即缺页异常/缺页中断。
发生一次PageFault，耗时虽然是毫秒级别的，如果同时发生的PageFault非常多时，这个时间加起来就会很长。
什么时候会出现大量的缺页异常？
答案肯定在启动的时候，准确点叫冷启动
我们先调试PageFault，我们测下启动时间和PageFault数据，如图

image

PageFault图

image

这里的File Backed Page in就是PageFault，占用1.25秒，总耗是1.27秒，PageFault占用大量的时间。

如何优化这个PageFault的时间。

我们在Build Setting 搜下Write Link Map File,如下所示

image

我们编译后，打开我们编译的App文件，如图所示

image

打开Demo-LinkMap-normal-x86_64.txt文件,如下所示

# Symbols:
# Address   Size        File  Name
0x100001E90 0x00000030  [  2] +[AppDelegate load]
0x100001EC0 0x00000080  [  2] -[AppDelegate application:didFinishLaunchingWithOptions:]
0x100001F40 0x00000120  [  2] -[AppDelegate application:configurationForConnectingSceneSession:options:]
0x100002060 0x00000070  [  2] -[AppDelegate application:didDiscardSceneSessions:]
0x1000020D0 0x00000030  [  3] +[ViewController load]
0x100002100 0x00000039  [  3] -[ViewController viewDidLoad]
0x100002140 0x0000008E  [  4] _main
0x1000021D0 0x000000B0  [  5] -[SceneDelegate scene:willConnectToSession:options:]
0x100002280 0x00000040  [  5] -[SceneDelegate sceneDidDisconnect:]
0x1000022C0 0x00000040  [  5] -[SceneDelegate sceneDidBecomeActive:]
0x100002300 0x00000040  [  5] -[SceneDelegate sceneWillResignActive:]
0x100002340 0x00000040  [  5] -[SceneDelegate sceneWillEnterForeground:]
0x100002380 0x00000040  [  5] -[SceneDelegate sceneDidEnterBackground:]
0x1000023C0 0x00000020  [  5] -[SceneDelegate window]
0x1000023E0 0x00000040  [  5] -[SceneDelegate setWindow:]

这里是所有方法代码实现的排列的顺序。
这里的Address+ASLR就是在方法在虚拟内存的地址。
Address相当于Page的顺序，Name方法的编译的顺序
我们调整下文件顺序，如图

# Symbols:
# Address   Size        File  Name
0x100001E90 0x00000030  [  2] +[ViewController load]
0x100001EC0 0x00000039  [  2] -[ViewController viewDidLoad]
0x100001F00 0x0000008E  [  3] _main
0x100001F90 0x00000030  [  4] +[AppDelegate load]
0x100001FC0 0x00000080  [  4] -[AppDelegate application:didFinishLaunchingWithOptions:]
0x100002040 0x00000120  [  4] -[AppDelegate application:configurationForConnectingSceneSession:options:]
0x100002160 0x00000070  [  4] -[AppDelegate application:didDiscardSceneSessions:]
0x1000021D0 0x000000B0  [  5] -[SceneDelegate scene:willConnectToSession:options:]
0x100002280 0x00000040  [  5] -[SceneDelegate sceneDidDisconnect:]
0x1000022C0 0x00000040  [  5] -[SceneDelegate sceneDidBecomeActive:]
0x100002300 0x00000040  [  5] -[SceneDelegate sceneWillResignActive:]
0x100002340 0x00000040  [  5] -[SceneDelegate sceneWillEnterForeground:]
0x100002380 0x00000040  [  5] -[SceneDelegate sceneDidEnterBackground:]
0x1000023C0 0x00000020  [  5] -[SceneDelegate window]

这个时候发现顺序变了，证实了我们刚才说的。

这里应该怎么优化？
当我们的应用程序的时候，加载很多PAGE，如果某一页只有一个方法被调用，这一页也是需要加载到内存，这样就会浪费内存，这个时候，我们可以把程序启动要加载的方法排列到最前面，这样就大量减少PageFault的次数，这就需要用到二进制重排技术。

3.5 二进制重排使用

我们在objc源码文件中，发现一个libobjc.order文件，打开如下所示：

__objc_init
_environ_init
_tls_init
_lock_init
_recursive_mutex_init
_exception_init
_map_images
_map_images_nolock
__getObjcImageInfo
__hasObjcContents
__objc_appendHeader

这里显示的都是一个个的符号名称，这个order是给编译器用到，当编译读取到这个oder文件时，会按照这里的顺序对二进制进行排序。

我们新建一个order文件，放在根目下，然后编辑，如下所示

-[SceneDelegate sceneWillResignActive:]
-[SceneDelegate sceneWillEnterForeground:]
-[SceneDelegate sceneDidEnterBackground:]
-[SceneDelegate window]
_main
+[ViewController load]
+[AppDelegate load]

我们在Build Settings,搜索Order File

image

配置我们自定义order的文件路径。

编译后，我们再看下link-map.txt文件，如下所示

# Address   Size        File  Name
0x100001E90 0x00000040  [  5] -[SceneDelegate sceneWillResignActive:]
0x100001ED0 0x00000040  [  5] -[SceneDelegate sceneWillEnterForeground:]
0x100001F10 0x00000040  [  5] -[SceneDelegate sceneDidEnterBackground:]
0x100001F50 0x00000020  [  5] -[SceneDelegate window]
0x100001F70 0x0000008E  [  2] _main
0x100002000 0x00000030  [  3] +[ViewController load]
0x100002030 0x00000030  [  4] +[AppDelegate load]
0x100002060 0x00000039  [  3] -[ViewController viewDidLoad]

这个顺序就是按照我们自己编辑的顺序排列的，如果符号不存在的话，会被去掉。

但是这里有一个问题
我们做的是启动的优化，就需要知道启动要调用的方法，方法非常多，方法还有嵌套，这个时候通过手动去编写这个顺序，是非常复杂的，如果我们通过HOOK这个objc_msgSend方法可以拦截到OC的方法，但是C函数，Block是无法通过这个HOOK掉的，这里留一个伏笔，我们将会在后续文章来解决这些问题。

总结

这篇文章介绍App启动的流程、虚拟地址、虚拟内存，PageFault的原理以及二进制重排的原理的知识，这篇文章让本人重新巩固了不少知识，也希望能让大家有所收获。

iOS 通过二进制重排进行App启动优化

前言

1 App启动流程分析

1.1 pre-main阶段流程

1.2 dylib动态的加载

1.3 ObjC setup

1.4 initializer

2 虚拟内存介绍

2.1 虚拟地址的概念

2.2 内存分页的原理

3 PageFault调试&启动优化的原理

3.1 CPU的32位和64位的概念

3.2 binding/绑定

3.3 rebase/重定向

3.4 二进制重排

3.5 二进制重排使用

总结

你可能感兴趣的:(iOS 通过二进制重排进行App启动优化)