背景
冷启动时长是App性能的重要指标，作为用户体验的第一道“门”，直接决定着用户对App的第一印象。 招聘客户端App都对启动时长或多或少都进行过一些优化，但相对于主流App启动时长差了不少，仍然有较大的优化空间。
方向
本次启动专项分析从两个方向重点进行分析：
一、美团启动分析（美团App启动为什么快？）
二、招才猫启动分析（我们App启动为什么比美团慢？）
三、后续规划
定义
冷启动定义
虽然冷iOS启动有：开机启动App（完全冷启动）和短时间内再次启动App（温启动）两种，但对于启动流程和将要做的启动优化来说并无区别。一般而言，可以把iOS冷启动的过程定义为：从用户点击App图标开始到第一个页面展示为止。
启动过程阶段定义
启动过程可以分为三个阶段进行分析：
T1：main函数之前，系统会进行加载动态库、注册Objc类等系统操作
T2：main函数到didFinishLaunching方法执行完成期间会进行SDK初始化等操作
T3：didFinishLaunching执行完成到首页面展示期间会进行页面的创建和渲染工作
美团App启动分析
一、如何统计第三方App
关于如何统计竞品或者主流App的启动耗时情况，市面上包含知乎团队采用的方案是进行屏幕录制+脚本，分析视频图像相似度的关键时间节点。此方案弊端较多，这里以逆向分析的方向提供两种统计方案：
- Theos+Tweak 越狱开发工具包，可注入代码到正版App中
- Frida+Monkey 砸壳重装，注入代码重新安装App且可进行- Debug调试
此次分析采用的是Frida+Monkey的方式，最终都会将注入代码以.dylib的方式注入到App中， 新注入的dylib库会增加一定的耗时，需要忽略掉。
libmeituanDylib.p : 34.00 milliseconds (1.6%) // 忽略
imeituan : 107.84 milliseconds (5.0%)
二、准备注入的代码
将App启动过程中T2、T3阶段关键时间节点方法进行hook：
- 1、利用sysctl函数获取进程创建时间
- 2、利用切面Hook，对系统方法 didFinishLaunchingWithOptions 的开始和结束调用进行打点
- 3、利用MoneyDev中的Logos语法，找到首页的Controller，对viewDidAppear方法进行hook打点。 （ps：如果直接对UIViewController的viewDidAppear进行hook，拿到的时长一般都是TabBarVC、NavigationVC显示的时长）
打点：
%hook MBCContainerViewController
- (void)viewDidAppear:(BOOL)animated {
%orig;
// 打点
}
%end
三、美团App启动阶段时长分析
T1阶段耗时分析
添加Xcode配置 DYLD_PRINT_STATISTICS_DETAILS 得出 pre-main 阶段耗时
以美团为标准，招才猫的pre-main耗时比美团多350ms：
- dylib loading time： 动态库加载时长，经过分析美团的动态库数量为148个，招才猫为73个，耗时相差85ms，转换成真实启动耗时影响较小，且系统已经对动态库的加载做过优化，这部分耗时属于正常。
- rebase/binding、Objc setup time：这部分耗时与项目中包含的类、方法数量形成正比，从美团250M，招才猫120M的包大小估算，这阶段耗时属于正常。
- initializer time： 此阶段会调用每个Objc和分类的+load方法，调用C/C++的构造函数等操作，从分析结果来看，招才猫在此阶段耗时明显过多，需重点排查，着重排查+load方法。
T2阶段耗时分析
T2阶段为 -application:didFinishLaunchingWithOptions: 中SDK初始化、任务创建等App部分功能初始化相关工作，对美团的MTAppdelegate类中的didFinishLaunching进行逆向分析。
中间省去N多静态分析和动态调试。。。
最终得到美团App的启动任务管理列表：
didFinishLaunchingWithOptions 阶段
- 可以看出，美团App在didFinishLaunchingWithOptions中执行的主线程Task是相当少的，而且很大一部分是属于基础类、基础数据配置的构造，这部分耗时是非常少的，必要的几个任务也放在了子线程处理，以最优的方式使-didFinishLaunchingWithOptions快速的执行完成，直接去展示页面，可以说美团在这方面是做得很好。
- 可以发现这阶段中首先有个任务叫 RunAllLoadFunctions，可以大胆猜测一下，美团是否把本应该在main()函数之前在+load方法中需要做的事情，放在了这个Task中，以减少+load的数量。
LaunchForeground 阶段
大部分App应该都没有这个阶段的一些操作处理，美团也只是在这里进行了一些状态操作，耗时可以忽略的。
viewDidAppear 阶段
美团将大量（42个）的任务放在了TabBarController显示完成之后执行，其中包含了Pay、IM、Spotlight、Location、Push、CrashReporter等核心且耗时较大的任务。但即使放在了TabBar显示之后，也对耗时大的任务放在了子线程中，以保证首页在刚展示后可以流畅的滑动、点击，不受这些任务的影响。
notifyT3Completed 阶段
根据这个阶段获取到的堆栈信息，可以猜测分析出应该是美团App在页面渲染完成之后做的一些任务操作，这些任务不会影响到App的启动，所以可以根据项目需要决定有可借鉴的东西。
美团任务管理方案：
美团除了将任务划分做很好之外，任务的管理中心也做得很好，美团的任务管理核心可以分为三大部分：
RegisterCenter：对Task进行注册、划分、创建、获取等等。
TaskRunner：运行启动阶段流程中的任务。
StartTask：任务者，存储任务的信息，监控任务的执行状态和耗时等。
美团将每个业务线的任务通过attribute 方式 Chain 到了mach-o中（未验证，也可能是其他方式），将任务与模块、业务线之间直接进行了解耦，在启动过程中获取每个阶段中任务的函数指针进行执行。
美团对每个Task做了很多处理，可以对每个业务线的任务耗时进行监控。对于在didFinishLaunching内任务比较重或需要进行任务解耦的App，美团的方案是一个不错的参考。
简约模仿的任务管理流程图：
T3阶段耗时分析
T3阶段涉及东西较多，简单对这阶段进行一个分析。
1、从上面内容知道美团的T3阶段是到 MTGroupTabbarController的viewDidAppear方法执行为止，对此方法添加断点可以看见美团的启动首屏。 通过控制台log输出及其他信息，基本上可以确定首屏上半部分的元素内容是暂时静态的，在未拉取最新内容之前有可展示的区域，不会发生内容白屏的假启动现象。
整体耗时对比分析：
以美团为标准，我们对比一下招才猫和美团的温启动耗时：
T1阶段：上面已经对T1阶段进行了分析，着重排查+load方法造成的影响，从真实的统计时长看，在T1阶段招才猫比美团App多耗时了257ms，从两个App的体量分析，招才猫App的T1阶段耗时在180ms以内才属于正常范围。
T2阶段：虽然招才猫之前已经将非必要的SDK初始化或其他任务进行了管理，减少或延后到了启动完成后去执行，但以美团标准看来，需要再次对必须在启动时完成初始化的SDK、任务进行梳理，是否仍有延后的可能或在线程中进行处理。
T3阶段：美团和招才猫在此阶段耗时相差并不大，但从观感上来看，体验却相差明显。主要原因是美团首屏页可以直接看见一些静态展示区域，而招才猫无论是消息页面还是附近求职者，目前都无法在第一时间提供页面元素， 导致从观感上认为仍然处于启动阶段。
启动通用优化方案
iOS 启动优化市面上有大量的文章、优化方案， 但大家都会发现为什么自己App在优化后，仍然与美团等主流App存在较大的差距。
分析完美团的启动过程，我们基本上能了解到美团大部分所做的启动优化工作也是大家所熟知的一些方案，但也能得到一些更为重要的信息：
标准：针对于每个App的启动优化，我们需要优化到什么程度，在每个阶段的耗时应该处于什么样的一个水平，我们有了一个比较清晰的标准去做对比衡量。
监控：美团对自己的每一个启动任务都做了一系列的粒度拆分和监控，在对持续的版本迭代所造成的增量影响和保持良好的启动时长能有一个更好的管控机制。
感悟：如果要做到极致的启动速度，就需要对Icon点击到页面展示的整个通道，就如同在一个新的App上去重新铺好这条路，去过滤不必要或可以优化的点。
技术：美团可能将+load方法所做的事情放在了main()函数之后，是否可提高启动速度？(待确认)
招才猫App启动分析
以美团为标准，以招才猫为例，对App的温启动时长进行分析。
一、招才猫分析汇总
主要分析方式：工具分析、阶段/任务打点、通道重铺、代码查看、三方库逆向分析
招才猫启动过程分析发现的部分问题：
。
。
。
省略
