背景iOS App一般在长期的业务迭代过程中，性能体验的伤痕也会慢慢有所累积。在冷启动优化这一指标上，就会需要做一波启动优化实践。如果还没做过历史相关优化。就需要做一次从0-1的整体优化。这篇文章主要对之前启动优化0-1做的一次整理，从分析App启动的过程开始，希望后续优化时可以有所借鉴。一共分为五个部分：一、App的启动流程二、确定起止口径三、针对分段耗时的优化四、数据对比五、展望一、App的启动流程准备做启动优化，首先要了解启动的各个流程，然后才能对各个环节去做针对性措施苹果对APP启动过程的划分，借用WWDC对启动阶段的定义图：映射常规App的结构如下：1. pre-main1.1 System Interface加载App可执行文件Load dylibs加载动态链接器dyld ，dyld会递归加载App依赖的动态库，然后执行符号绑定Rebase，Bind。一般应用会加载 100 到400个dylib文件，幸运是大部分是系统库，且系统会在操作系统启动时计算和缓存系统动态库。Apple为了解决安全问题，引入ASLR和Code Sign，如果不作符号修正，程序将没法正常运行，所以会有Rebase和Bind过程。Rebase在镜像内部调整指针的指向，其实就是将内部指针都加上偏移量（Slide=实际新地址-旧地址）Bind修正指外部的指针，比如上图中malloc，这个符号不存在于我们App的Mach-O中，需要从外部的镜像中获取，这时候就需要Bind操作把这个关联起来。libSystem init调用系统的一些初始化方法，这部分一般时间比较固定，可以不用太关注。1.2 Runtime InitObjc和Swift的初始化通过_dyld_objc_notify_register注册回调，在image加载完时初始化语言相关。加载category在上面语言初始化完之后，会加载所有category，处理category的所有方法，协议和属性等。调用所有+load也是通过向 dyld 注册回调，在image加载完时，通过load_images 触发，处理该image相关的所有+load方法，按照继承层级依次调用：父类+load→子类+load→category +loa
)
)
)
