main()函数启动分块.png
t1阶段，main()之前的处理所需时间，称为pre-main
t1阶段.png
t2阶段，main()及main()之后处理所需时间
t2阶段耗时的主要是业务代码
推荐 BLStopwatch，这个工具可以打点统计业务耗时
本部分优化根据各自业务需求自行处理。
把下载的代码拖入工程后，将代码.m的方法改一下
image.png
然后在你想测试性能的地方加入代码（这里测试延时操作）
Appdelegate.m.png
ViewController.m.png
运行后方法调用的耗时的结果：
结果.png
检测启动时间
Xcode 测量 pre-main (t1阶段) 时间DYLD_PRINT_STATISTICS
Xcode 中提供了测量 pre-main 的时间 Edit scheme -> Run -> Auguments 添加环境变量 DYLD_PRINT_STATISTICS，value设为YES。
edit scheme.png
启动以后可以看到启动时长
启动时长.png
DYLD_PRINT_STATISTICS_DETAILS
把上面的DYLD_PRINT_STATISTICS环境变量替换成DYLD_PRINT_STATISTICS_DETAILS可以看到更详细的信息
更详细的信息.png
分析启动时长
dylib loading time
加载dylib
分析每个dylib（大部分是系统的），找到其Mach-O文件，打开并读取验证有效性；找到代码签名注册到内核，最后对dylib的每个segment调用mmap()。
在dylib的加载过程中系统为了安全考虑引入了ASLR（Address Space Layout Randomization）技术和代码签名。ASLR技术：镜像Image、可执行文件、dylib、bundle在加载的时候会在其指向的地址（preferred_address）前面添加一个随机数偏差（slide），防止应用内部地址被定位。
rebase/binding time
dylib加载完成之后，它们处于相互独立的状态，需要绑定起来。Rebase将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。Bind是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。
ObjC setup time
runtime会维护一张类名与类的方法列表的全局表。
读取所有类，将类对象其注册到这个全局表中（class registration）
读取所有分类，把分类加载到类对象中（category registration）
检查selector的唯一性（selector uniquing）
initializer time
这部分其实就是load方法的耗时
优化思路
1.移除不需要用到的动态库，尽量使用系统库，且苹果建议动态库数量控制在 6 个以下（超过6个建议合并），防止劣化，需要严格管控动态库的引入；
源码形式的是可以通过CocoaPods命令转静态库的，如下:
# CocoaPods 打包静态库 命令
# 其中 –library 指定打包成.a文件，如果不带上将会打包成.framework文件。–force 是指强制覆盖。
pod package xxxx.podspec --force
CocoaPods不使用 use_frameworks! 字段，全部引入静态库
2.移除不需要用到的类；合并功能类似的类和扩展；经测试 20000 个类会增加约 800毫秒；
3.尽量进行懒加载，尽量避免在load()方法里执行操作，把操作推迟到initialize()方法；
4.利用好多核多线程，但也要注意控制好线程的数量和优先级；
5.可以尝试让代码执行更快。比如，频繁访问的可以只获取一次就存下来。
物理内存/虚拟内存分析
物理内存
在以前的古老操作系统app占用的是使用物理内存，比如说一个app占用4G内存，启用4个app就用完了，而你使用这个app并不是所有的页面所有的功能都会去使用，它就一次性加载了。
不安全：能让A进程访问到B进程的地址
致命缺点：1、内存不足 2、安全问题
虚拟内存分析
内存是分页管理的，映射表不能以字节为单位，是以页为单位。
Linux以4K为一页
macOS以4K为一页
iOS以16K一页
$ pageSize // 终端输入pageSize，得到结果是4096
// 返回的就是4 * 1024 = 4096
虚拟内存 : 解决安全问题、解决内存使用率问题
用户使用时并不会使用到全部内存，如果 App 一启动就全部加载到内存中会浪费很多内存空间。 虚拟内存技术 的出现就是为了解决这个内存浪费问题。
App 启动后会认为自己已经获取到整个 App 运行所需的内存空间，但实际上并没有在物理内存上为他申请那么大的空间，只是生成了一张虚拟内存和物理内存关联的表 。
虚拟内存.png
地址翻译
当 App 需要使用某一块虚拟内存的地址时，会通过这张表查询该虚拟地址是否已经在物理内存中申请了空间。
如果已经申请了则通过表的记录访问物理内存地址，
如果没有申请则申请一块物理内存空间并记录在表中（Page Fault）。
这个通过进程映射表映射到不同的物理内存空间的操作叫 地址翻译 ，这个过程需要 CPU 和操作系统配合。
Page Fault
当数据未在物理内存会进行下列操作:
1.系统阻塞该进程（终断进程）
2.将磁盘中对应Page的数据加载到内存
3.把虚拟内存指向物理内存（继续进程）
上述行为就就是Page Fault
Page Fault.png
灵活内存管理
虽然解决了浪费问题，但是万一物理内存空间全都被申请了呢？还是有可能产生内存不足的情况的，为保证当前App的正常使用，数据加载遵循以下原则：
1.如果有空闲内存空间就放空的内存空间中
2.如果没有就覆盖其他进程的数据
3.具体覆盖由操作系统处理
解决安全问题
空间问题已经解决了，但是安全问题是怎么解决的呢？
在dylib的加载过程中系统为了安全考虑引入了ASLR（Address Space Layout Randomization）技术和代码签名。ASLR技术：镜像Image、可执行文件、dylib、bundle在加载的时候会在其指向的地址（preferred_address）前面添加一个随机数偏差（slide），防止应用内部地址被定位。
