企业官网建设流程全解析

背景

        iOS App一般在长期的业务迭代过程中，性能体验的伤痕也会慢慢有所累积。在冷启动优化这一指标上，就会需要做一波启动优化实践。如果还没做过历史相关优化。就需要做一次从0->1的整体优化。

        这篇文章主要对之前启动优化0->1做的一次整理，从分析App启动的过程开始，希望后续优化时可以有所借鉴。一共分为五个部分：

一、App的启动流程 

二、确定起止口径 

三、针对分段耗时的优化

四、数据对比

五、展望

一、App的启动流程 

准备做启动优化，首先要了解启动的各个流程，然后才能对各个环节去做针对性措施

苹果对APP启动过程的划分，借用WWDC对启动阶段的定义图：

映射常规App的结构如下：

1. pre-main

1.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 Init

• Objc和Swift的初始化

通过_dyld_objc_notify_register注册回调，在image加载完时初始化语言相关。

• 加载category

在上面语言初始化完之后，会加载所有category，处理category的所有方法，协议和属性等。

• 调用所有+load

也是通过向 dyld 注册回调，在image加载完时，通过load_images 触发，处理该image相关的所有+load方法，按照继承层级依次调用：父类+load→子类+load→category +loa