1、虚拟内存 -> 映射表 -> 物理内存

2、虚拟页表 -> 物理内存
（Mac OS 和Lunix 一页4K）
（iOS一页16K）
对于APP只会把活跃的页面通过虚拟页表加载到物理内存中
每次加载一页数据（iOS一页16K，称为内存分页管理）每次映射一页（页内存 + 页数据整体偏移值）
（1）如果物理内存没有需要的数据，就会有缺页异常（APP启动的时候是缺页异常最多的时候）
（2）缺页置换，物理内存满了之后，会把不活页面替换（覆盖）成将要活跃的页面数据

3、在项目中
（1）在ViewController添加如下代码

（2）command + B编译后生成的LinkMap文件

（3）关于LinkMap文件内部的结构

Symbols：（符号）

Address、Size、File、Name

Address方法实现的内存地址
Size 该方法占用的内存大小
File 该方法出现在哪个源文件里的
Name 方法名称

（4）关于调整编译顺序
编译顺序是跟Build Phases -> Compile Sources相关

调整后LinkMap中的编译顺序发生变化

所以可以总结，可以通过一下步骤进行优化程序启动时长
1、尽量减少启动时调用的方法，可以进行后续加载
2、(按照启动时的调用顺序进行排列)排列好首次启动需要加载的类和方法，尽量将他们都集中到一起归类在几页虚拟内存页中

（5）关于Apple使用的二进制排列顺序文件（libobjc.order）

Xcode使用的链接器是LD（-order_file）

（5）在项目中创建hank.order（hank.order）

编辑hank.order

Build Settings -> Order File -> 添加 ./hank.order

添加完Order文件后，LinkMap编译顺序发生改变（hank hello方法因为文件里没有，编译器自动帮助忽略）

关于启动时常如何检测
（1）工程配置
在Project -> Scheme -> Edit Scheme
找到Run -> Environment Variables -> +
DYLD_PRINT_STATISTICSvalue为1的环境变量

（2）LLDB输出
Total pre-maintime:94.33milliseconds(100.0%)
dylib loadingtime:61.87milliseconds(65.5%)
rebase/bindingtime:3.09milliseconds(3.2%)
ObjC setuptime:10.78milliseconds(11.4%)
initializertime:18.50milliseconds(19.6%)
slowest intializers :
libSystem.B.dylib :3.59milliseconds(3.8%)
libBacktraceRecording.dylib :3.65milliseconds(3.8%)
GTFreeWifi :7.09milliseconds(7.5%)

解读数据
1、main（）函数之前总共使用了94.33ms
94.33ms中，加载动态库用了61.87ms
指针重定位使用了3.09ms
ObjC类初始化使用了10.78ms
各种初始化使用了18.50ms
在初始化过程中最耗费时间的是1、libSystem.B.dylib 2、libBacktraceRecording.dylib 3、GTFreeWifi

2、从main（）函数开始至applicationWillFinishLaunching，我们统称为main（）函数之后的部分

（3）优化部分
1、main（）函数之前耗时的影响因素
动态库加载过多、启动越慢
ObjC类越多、启动越慢
C的constructor函数越多启动越慢（attribute(constructor)）
C++静态对象越多启动越慢
Objc的+load越多，启动越慢

（缺少的图片晚些时候补全）