iOS启动优化(上)-概念篇

前言

启动App是给用户第一印象，如果启动比较慢，很可能会导致这个用户流失，那么启动时间的优化就显得尤为重要，本文结合启动时间从一些基本的概念入手分析

启动时间

启动根据main分为两个阶段：main函数之前(pre-main)和main函数之后，在pre-main阶段，程序最早能执行的代码是+load函数，但load之前还有很多步骤，例如加载动态库的时间等，这些我们怎么去检测呢，这个时候就需要用到DYLD检测，也就是通过配置环境变量，它会将这个阶段相关的耗时反馈给开发者。 - 新建个工程，然后cmd + shift + ,-> Run -> Arguments配置环境变量DYLD_PRINT_STATISTICS，也可以设置DYLD_PRINT_STATISTICS_DETAILS这个会详细些。本文配置DYLD_PRINT_STATISTICS来讲

- 在真机上运行，结果如下：

- 这个代表本次pre-main时间用了338.68毫秒： - dylib loading time：是动态库载入耗时。系统提供的动态库已经载入在共享缓存空间，已经做了优化，但自定义动态库并没有这个优化，苹果建议创建的动态库不能超过6个，如果大于这个数就需要做动态库合并 - rebase/binding time：是重定位/绑定耗时，涉及到动态库合并 - ObjC setup time：OC注册类。在做项目时，可以删除废弃的(不使用的)类，只要在里面就会影响启动时间 - initializer time：执行load、构造函数的耗时。 - slowest intializers：最慢的动态库耗时

下面着重讲rebase/binding相关的知识

物理内存和虚拟内存

物理内存

• 在早期的操作系统，CPU直接从内存条读取数据，这就导致了内存不够用问题，如下图：

- 应用需要加载时就会直接加载到内存条中，然后CPU去内存条读取。当加载的应用多了，再加载新的应用时内存就不够用了，这时候就需要干掉一些应用然后再去打开这个新的应用。 - 加载到内存条中的应用都是根据内存地址去读，那么如果通过一些外挂加载到内存，然后可以在遍历内存条中地址访问到其他应用的内容，就导致账号被盗等安全问题，所以这个方式也是不安全的 - 怎么解决这些问题呢？工程师们发现加载到内存中的应用，大多数之用到一小部分功能，这就导致了资源的浪费，于是就产生了懒加载。懒加载是引用加载到内存中时，先加载启动相关的，后面要用到就再加载到内存条。

这样虽然会减少内存的占用，但是应用接下来的内存不知道要分配到哪，这样就导致代码不连续，需要在运行过程不断计算地址很不方便，而且效率很低，于是工程师们就创造了虚拟表，也就引出了虚拟内存

虚拟内存

• 有了虚拟表，应用程序就只读代码，而代码计算地址的事情交给CPU和硬件MMU，MMU是内存管理单元，它只做一件事：翻译地址：

- 这样应用程序的在运行时访问的内存就是连续的，而访问的内存就是虚拟内存，虚拟内存对应的就是计算好的物理地址。 - 虚拟地址和物理地址不是一个字节一个字节对印的，这样效率就很低。由于现在的应用内存是一块一块的，干脆就以块为单位去对印，单位就是page，此刻就产生了内存分页管理的概念

映射表(内存分页)

• 页的大小在不同的操作系统中是不一样的。在iOS中(64位)一页是16K，在MAC中是4K。在MAC中可以使用环境变量PAGESIZE查看：

• 现在内存连续的问题得以解决，安全问题也解决了。由于一个应用只访问自己的虚拟表，而翻译出来的物理地址也是固定的，所以那些外挂就无法访问其它应用。内存溢出的问题也解决了，因为现在内存都是一页一页的访问，所以就不会产生溢出。
• 当应用加载时，首先启动需要的代码会直接加到内存，当要执行新的代码时，cpu发现这段代码内存中没有就会把代码卡住，然后操作系统会将这页加到物理内存中，这个现象就叫做缺页中断(pagefault)。
• 操作系统需要执行的一页代码载入到物理内存中时，会往空缺处插入。但手机启动后，物理内存就没有空位了，里面都放了其它的一些数据，但到底往哪里加呢，这个由操作系统决定。操作系统提供一个算法：页面置换算法，它会覆盖掉不那么活跃的部分。所以有时候多打开些应用后，再去进入第一次打开的应用时会重新启动。
• 有时候在访问内存时会访问比App当前大的内存，因为虚拟表有8G大小，能访问的有4G，那么他会访问到其它应用吗？不会，这块虚拟内存是没有数据，它指向NULL：

rebase/binding

• binding是绑定，当内部文件访问外部方法，就要通过内部符号绑定访问外部，现在的绑定方式都是懒加载

• rebase是重定位。由于虚拟内存产生后，每次内存都是从0开始，这个时候相应的安全就不存在了，所以操作系统就出现了一个新技术ASLR：让每次生成的虚拟页面，不要从0开始，从随机的值开始，应用的每次启动的起始位置都是随机的。此时行数的位置就成了ASLR+OFFSET，也就是rebase重定向

• 一页的缺页中断是感知不到的，时间是毫秒级别，基本感知不到。但同时有大量的缺页中断，这个时候用户就能感知到了，冷启动时就会产生大量的缺页异常。如下面例子：

• 重签名一个微信7.0.8的ipa，然后跑到自己的工程。运行起来后Cmd+i打开instruments，然后选择System Trace，搜索Main Thread，之后选择Virtual Memory

• File Backed Page In可以看到缺页中断的个数以及所用的时间：

• 通过观察发现消耗的总时间中，PageFault占绝大部份
  
• 再启动一次发现耗时要少的多，此时应用的物理内存还没被覆盖，所以启动会时间会少很多
• 冷启动：应用在物理内存中没有占用时的启动是冷启动。例如第一次打开App，或者APP被杀死后，一段时间过后再打开，都是冷启动

• 热启动：应用编译在物理内存中的内存还存在的启动就是热启动，例如短时间APP从后台返回，APP杀死后立即打开，此时它的物理内存还存在，此时就是热启动。

• 如果减少PageFault的个数，就会达到优化的目的，具体操作下篇文章再进行讲解