APP启动优化的总结与思考

APP从点击icon到首页显示这个过程中到底做了哪些事情？有哪些地方可以优化的空间？

常见的APP启动都会执行这几个步骤：
main函数-->AppDelegate-->key Window-->rootViewController

目前总结了三个方面：

1. 业务层

 基于上面的过程，将那些没必要在上述过程中执行的代码逻辑移除掉，尽量精简上述过程中无关的逻辑

2. main函数之前进行优化

那APP在我们熟知的main函数之前到底做了哪些事情呢？
这得从我们的应用二进制文件的加载过程说起，也就是Mach-O文件的加载过程，这里不单独说这个知识点。

我们知道，Mach-O文件中有LC_COMMAND块，里面链接大量的动态链接库(包括系统的和我们自己定义的 .dylib,.framework)，app启动过程中，dyld会去加载所有的这些库到内存中，这是一个递归的过程，依赖的动态库可能还会依赖别的动态库，所以dyld会递归每个动态库，直至所有的依赖库都被加载完毕。
所以，我们在项目中要尽可能的减少引用我们没要用到的系统库以及我们自己的动态库，一般我们自己的动态库最好不要超过4个，如果实在过多，要对他们进行合并，且我们在编写相应的库时也要减少不必要的类和方法，从而缩小库的体积。

3. 二进制文件重排

首先来说几个概念：
a、我们的APP在被启动的时候，以前的操作系统会将整个app数据一股脑儿的加载进内存，这样是不合理的，这会导致我们的内存空间不够用，所以出现了虚拟内存的概念，虚拟内存并不是说真正的利用磁盘空间开辟了一个新的空间来载入应用数据，而是指操作系统创建了一张虚拟地址表，应用程序中所使用到的变量对应的地址都是虚拟地址，该虚拟地址是指向内存中的一个真正物理地址，而这张虚拟地址表就是存放虚拟地址和物理地址对应关系的表
b、同样的，此时操作系统并没有将整个app数据一起加载进内存，而是将我们这个APP数据进行分页，每页的数据大小为16K，只有那些是APP启动所需要的页才会被加载进内存。
那么问题来了，哪些是APP启动所需要的呢？首先，上述所说的main函数到rootViewController过程中所调用的代码肯定是被需要，另外还有一个NSObject的 +load 方法和+Initializers方法[只有在接收到消息后才调用]，这两个方法是在main函数之前会被调用的[因此，可以减少不必要的load方法，或是尽量将load方法放到少量的类文件中，不要大量类文件中都有load方法]
如果main函数到rootViewController过程中所调用的代码被分散到多个页码块中时，app在启动时就需要加载这所有的代码所在的页码块（此过程由操作系统的“缺页异常”引发），如果这样的页码块太多是会影响启动加载速度的，因此，我们需要把这个过程中涉及到的代码全部都放置于同一个或几个页码块中

所以：

第一步：

图片.png

第二步：

图片.png

自己编写一个xxx.order文件，文件中按优先顺序罗列出优先需要加载的方法，然后指定到"Build Settings"的“Order File”选项中，xxx.order文件如下：

-[ViewController init]
-[ViewController viewDidLoad]
_CGRectMake
-[ViewController tto]
...   #每行写错不要紧，xcode编译器会忽略掉有错或app中根本不存在的方法

如何编写xxx.order文件？
a、TARGETS-->Build Settings-->Write Link Map File,打开为YES:

图片.png

b、build编译之后，在程序生成目录的上上目录中，找到那个test-LinkMap-normal-x86_64.txt文件：[Intermediates.noindex-->test.build-->Debug-iphonesimulator-->test.build-->test-LinkMap-normal-x86_64.txt]

图片.png

c、xxx-LinkMap-normal-xxx.txt文件如下：[一个类文件中方法的编排顺序就是我们在xcode中编写时，从上到下的顺序，跟我们编写的顺序有关]

图片.png