App 的启动 ： 冷启动 + 热启动
App 的启动主要包括三个阶段：
1.main() 函数执行前；
系统主要做的几件事：
（1）加载可执行文件 （App的.o文件的集合）
（2）加载动态链接库，进行rebase指针调整和bind符号绑定
（3）Objc运行时的初始处理，包括Objc相关类的注册，category注册，selector唯一性检查等
（4）初始化，包括了执行+load()方法，attribute((constructor))修饰的函数的调用、创建c++静态全局变量
attribute((constructor)) 修饰的函数在main函数之前执行
attribute((destructor)) 修饰的函数在main函数之后执行
见：函数调用
可优化的点
(1) 减少动态库加载，每个库本身都有依赖关系，苹果公司建议使用更好的动态库，并且建议在使用动态库的数量较多时，尽量将多个动态库进行合并，数量上，苹果公司最多可以支持6个非系统动态库合并为一个。
(2) 减少加载启动后不会去使用的类或者方法
(3) +load()方法里面的内容可以放在首屏渲染完成后再执行的，或者使用+initialize()方法替换掉，因为，在一个+load()方法里，进行运行时方法替换操作会带来4毫秒的消耗，不要小看这4毫秒，积少成多，执行+load()方法对启动速度的影响会越来越大
(4) 控制c++全局变量的数量
2. main() 函数执行后；
main() 函数执行后的阶段，指的是从 main()函数执行开始，到appDelegate的didFinishLaunchingWithOptions方法里首屏渲染相关方法执行完成
系统主要做的几件事：
(1)首屏初始化所需配置文件的读写操作
(2)首屏列表大数据的读取
(3)首屏渲染的大量计算等
可优化的点
从功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是app启动必要的初始化功能，而哪些是只需要在对应功能开始使用时才需要初始化的，梳理完了以后，将这些初始化功能分别放到合适的阶段进行，
3.首屏渲染完成后；
首屏渲染完成后的这个阶段，主要完成的是，非首屏其他业务服务模块的初始化，监听的注册，配置文件的读取等，从函数上来看，这个阶段指的就是截止到didFinishLaunchingWithOptions方法作用域内执行首屏渲染以后的所有方法执行完成，简单说，这个极端就是从 渲染完成时开始，到didFinishLaunchingWithOptions方法作用域结束时结束
此阶段能看到app的首页信息了，所以优化的优先级排最后，但是，那些会卡住主线程的方法还是需要最优先处理的，不然还是会影响到用户后面的交互操作
优化角度
1.功能级的启动优化：从main（）函数执行后这个阶段下手
思路: main（）函数开始执行后到首屏渲染完成前只处理首屏相关的业务，其他非首屏业务的初始化、监听注册、配置文件读取等都放在首屏渲染完成后去做
2.方法级别启动优化：
在这之后，我们需要进一步做的，是检查首屏渲染完成前主线程上有哪些耗时方法，将没必要的耗时方法滞后或者异步执行.通常情况下，耗时较长的方法主要发生在计算大量数据的情况下，具体的表现就是加载、编辑、存储图片和文件等资源。
像 +load() 方法，一个耗时 4 毫秒，100 个就是400 毫秒
比如 我以前使用的 ReactiveCocoa 框架（这是一个iOS 上的响应式编程框架），每创建一个信号都有 6 毫秒的耗时,这样，稍不注意各种信号的创建就都被放在了首屏渲染完成前，进而导致 App 的启动速度大幅变慢
因此 需要一个能够对启动方法耗时进行全面、精确检查的 手段
手段1:
定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时，xcode自带Time Profiler
缺点，不是特准确
优点，简单，成本低，设置定时间隔为0.01秒，基本够用
手段2:
对objc_msgSend方法进行hook来掌握所有方法的执行耗时
缺点，只针对oc的方法，对c和block不行，但是可以使用libffi的ffi_call方法来达到hook，但编写维护相关工具门槛高
优点：精准
hook objc_msgSend
objc_msgSend是oc方法执行的必经之路，能够控制所有的oc的方法
objc_msgSend用汇编语言写的，这样做原因：
1.objc_msgSend调用频率最高，在他上面优化能提升整个app生命周期的性能，汇编语言性能优化属于原子级优化。能优化到极致
2.其他语言难以实现未知参数跳转到任何函数指针的功能
怎么hook
Facebook 开源了一个库叫fishhook
fishhook大致思路：通过重新绑定符号，可以实现对c方法的hook，dyld是通过更新Mach-O二进制的__DATA segment特定的部分中的指针来绑定lazy和non-lazy符号，通过确认传递给rebind_symbol里每个符号名称更新位置，就可以找出对应替换来重新绑定这些符号
陈铭写的一个检测方法耗时的，github搜索
GCDFetchFeed
在需要检测耗时时间的地方调用[SMCallTrace start]，结束时调用 stop和 save 就可以打印出方法的调用层级和耗时了你还可以设置最大深度和最小耗时检测，来过滤不需要看到的信息。
有了这样一个检查方法耗时的工具，你就可以在每个版本开发结束后执行一次检查，统计总耗时以及启动阶段每个方法的耗时，有针对性地观察启动速度慢的问题如果你在线上做个灰度开关，还可以监控线上启动慢的一些特殊情况。
