APP的启动流程与优化

声明：

本文旨在学习APP启动流程并着力优化本公司项目，部分知识点非自创，如各位大佬发现本文存在抄袭侵权之处，请及时指出改正，谢谢！

一、背景

APP的启动一般分为冷启动和热启动。

1、冷启动：当用户启动应用程序时，后台没有该应用程序的进程，这时系统会重新给应用程序分配一个进程，这种方法就叫冷启动。
2、热启动：当用户启动应用程序时，后台已经有了该程序的进程（通过home键退出）当再次点开APP马上能够恢复到上次使用的状态，不需要再回到手机的首页打开应用程序，这个方式就叫热启动。
3、热启动通常不需要优化，APP的启动流程优化一般指的是冷启动优化。
APP的冷启动大致分为三个阶段
1、APP的启动加载（从点击APP到执行main()函数）

APP启动加载流程

2、APP的初始化（从main()函数执行到didFinishLaunchingWithOptions方法执行）
3、APP的运行时生命周期（从didFinishLaunchingWithOptions函数执行到首屏渲染结束）

App启动流程示意图

启动流程参考链接一
启动流程参考链接二
冷启动时长是App性能的重要指标，直接决定着用户对App的第一印象。随着越来越多版本的迭代开发，产品形态不断完善，业务功能日趋复杂，在App冷启动的时候需要完成更多更复杂的功能，这给App的冷启动性能带来了挑战。因此，对冷启动进行优化工作，提高用户体验，是一项重要的工作。

二、APP的启动流程

1、启动加载项（pre-main）

当我们点击APP时，XNU内核(提供基础服务，像线程，进程管理，进程间通信，文件管理)先将我们的App加载进内存，之后加载一个“中间件”:dyld这是(开源地址)。之后dyld会负责分析App的Mach-O文件(Exectuable文件、Dylib:动态库、Bundle、Image、Framework: 包含资源文件、头文件等的dylib)以加载所需的dynamic libraries。之后利用Rebasing和Binding修正内部和外部指针指向。最后加载runtime组件，runtime组件加载好后就会向需要初始化的object发送消息，开始初始化。 至此，main函数之前的步骤结束。之后App开始在AppDelegate里面初始化我们自定义的服务以及渲染首屏等。

Dyld所做的事情

优化方式

dyld 3已经做了大部分优化(在dyld 2时代，所有我们之前提到的启动步骤都是发生在内核分配给你的进程中的(in-process); 而在dyld 3中，关于Mach-O文件的解析发生在App第一次安装或者是之后的更新过程中。解析过后，关于App启动的信息会被存到磁盘，供App启动时使用。这两步大大提升了App加载的速度，系统库是有共享缓存的，所以加载速度会相对较快。)
main()之前的加载过程影响因素大概有下面几种：
1、动态库加载越多，启动越慢。
2、ObjC类，方法越多，启动越慢。
3、ObjC的+load越多，启动越慢。
4、C的constructor函数越多，启动越慢。
5、C++静态对象越多，启动越慢。
针对以上几点，可以做如下一些优化工作。
1、代码瘦身
把无用的方法和类删除一下。
2、+load优化
目前项目中存在一些+load方法，如果不是非必须加载可以删掉或者换成+initialize方法(+load和+initialize的区别)。
3、优化耗时操作（借助Instrument工具的Time Profiler插件）
启动时减少图片资源的处理
减少动画图片组的数量，替换大图资源等。
推迟执行的一些耗时任务。

2、初始化（main）

1.执行main 的函数
2.执行UIApplicationMain的方法
2.1 会创建UIApplication对象，并设置它的代理
2.2 会开启一个事件循环（主运行循环即死循环，保证程序不退出）
2.3 加载info.plist
2.4 通知应用程序代理，应用程序启动完毕，执行didFinishLaunchingWithOptions
（这个阶段一般都是必做的事 优化空间不大）。

3、APP的运行时生命周期（didFinishLaunchingWithOptions）

过程是从AppDelegate的didFinishLaunchingWithOptions方法到首页离屏渲染结束。
梳理出来didFinishLaunchingWithOptions方法到第一个主界面导致延迟加载的原因并改进。例如网络数据的加载，界面的加载，第三方SDK的初始化，新版本弹窗检查，广告弹窗检查等。

广告页加载优化示意图