Android启动过程
Anroid应用启动在应用层主要分为如下几个阶段：Application初始化，Activity初始化，Service初始化，视图Tranversal
从快速启动的角度来看，应用需要优先展现用户可见界面，Service初始化在快速启动阶段不是必须的，Application初始化，Activity初始化和视图Tranversal是必须。
这里将启动过程分为快速启动阶段和延迟初始化阶段。快速启动阶段定义为应用启动到视图初始呈现的过程。快速启动阶段以快速展现用户界面为首要目的，所有的程序执行都围绕此目的进行；延迟初始化阶段进行应用启动必要但不紧急的初始化。
快速启动设计模型主要包括两方面的工作：
- 确定快速启动阶段任务
- 确定快速启动结束时机
快速启动阶段
根据启动过程，可以基本确定快速启动阶段的三大任务：
Application初始化
Activity初始化
视图Tranversal
Application初始化
Application初始化的作用在于对整个应用程序进行必要的初始化。主要在onCreate方法中进行。
快速启动模型中，应用层没有必要的初始化逻辑。
当然，如果要设置应用异常，并且不想遗漏启动过程出现的异常，可以在onCreate中设置UncaughtExceptionHandler。
Activity初始化
Activity初始化围绕其启动生命周期进行：onCreate，onStart，onResume。
由于业务逻辑的复杂性，可能导致Activity生命周期非常臃肿，但是对快速展现用户界面而言，很多逻辑不是必须的，最重要的逻辑无非是往Activity中设置一个视图。
快速启动模型仅在onCreate回调中设置视图。其他任务归于延时启动。
这里牵涉到两个问题：
- 如何实现Activity生命周期的两种流程：快速启动流程和正常流程
- 设置视图就关于到视图的创建，视图创建的时间也是快速启动的关键
Activity启动流程设计
Activity两种启动流程采用Delegate思想实现，Activity拥有两种Delegate：FastDelegate和FullDelegate。应用启动阶段阶段设置为FastDelegate，快速启动阶段结束后设置为FullDelegate。
ActivityDelegate提供Activity启动生命周期接口。接口定义：
onCreate
onStart
onResume
FastActivityDelegate和FullActivityDelegate提供不同的实现。Activity持有ActivityDelegate的实例，在onCreate中初始化为FastActivityDelegate，并在快速启动阶段结束后设置为FullActivityDelegate，同时在启动生命周期回调中调用ActivityDelegate的对应接口。
FastActivityDelegate实现onCreate接口，为Activity设置视图。
FullActivityDelegate用于完整功能实现。
FastActivityDelegate的接口实现：
onCreate完成必要的初始化，并设置setContentView。
onStart和onResume为空实现。需要在onStart和onResume中完成的也许实现移至延迟初始化阶段。
FullActivityDelegate接口实现：
onCreate为空实现
onStart和onResume完成具体的业务实现。
视图创建和Tranversal
由于业务的复杂性，视图的实现可以比较复杂。主要表现在：
- 在视图构建时进行诸多初始化操作
- 实现复杂的
onMeasure，onLayout，onDraw逻辑
其中，视图构建会影响Activity初始化流程；视图布局绘制会影响视图Tranversal过程。这其中复杂的逻辑在快速启动阶段其实是用不到的，因此需要在快速启动阶段去除不必要的处理，仅保留必要的逻辑。
快速启动视图设计
同Activity启动流程设计思想类似，视图也采用FastDelegate和FullDelegate的方式。
ViewDelegate提供视图呈现接口。接口定义：
onInit
onMeasure
onLayout
onDraw
FastViewDelegate实现视图的最小化实现。
FullViewDelegate用于视图的完整实现。
举个例子，主视图中要呈现一个icon，icon包含一个静态图标和一个动态更新标记。快速启动模型中，静态图标在FastViewDelegate中实现，动态更新标记在FullViewDelegate中实现，更新状态在延迟初始化阶段确定。
到这里，快速启动阶段任务就基本确定了。简单来说，就是创建最小化的视图，然后设置到Activity中。
快速启动结束时机
快速启动结束后需要执行延迟初始化，所以需要确定快速启动结束的时机。这里其实包含了两个时机：
设置FullDelegate的时机
真正延迟初始化的时机。
需要分别考虑Activity的时机和视图的时机，从首先展现视图的角度来看， 优先考虑视图的时机。
首先考虑视图FullDelegate的设置时机。在视图执行完一次tranversal之后，即可设置FullDelegate，当然应该是post执行，不影响正常的tranversal。实现时可以考虑在视图的onDraw或onLayout回调之后（对于需要自定义onDraw的视图选择在onDraw回调之后，否则选择在onLayout之后）。
理论上，视图的延迟初始化时机应该在视图进行完全tranversal之后（通常情况下，需要2次tranversal才能完全呈现视图）。考虑到多CPU的优势，可以在完全tranversal之前，在异步线程中来完成延时初始化。在实现时，主视图的延迟初始化可以选择在根视图的初次onMeasure回调。
Activity设置FullDelegate的时机和延迟初始化时机应该选择在视图展现之后，可以根据应用的具体实现情况来定。通常来讲，可以定在主视图延迟初始化后，即将呈现视图之前。
Activity的延迟初始化任务通常包括：快速启动之外的初始化，原本应该在Activity中完成的业务逻辑，业务更新，启动后提示等。
快速启动实现Guidelines
准确划分任务的优先级，确保快速启动阶段任务尽量少。
在应用实现时，启动流程可能包含诸多逻辑，尽量将非必需的任务放到延迟初始化阶段。不要在快速启动阶段启动Service。
Service的启动是在主线程，如果在快速启动阶段启动，会延后视图的呈现。尤其要注意的是Provider，Provider在应用启动时会跟随创建，所以不要在其创建过程中启动Service。可以降正常的启动流程细分为启动片段，并在Delegate中进行片段的组合和排序。
Activity延迟初始化要充分利用多核的优势。
延迟初始化任务可以在多个线程中执行，同时要考虑任务的依赖关系。采用热启动重用模型。
对于热启动，可以采用模块重用模型，通常重用减少模块加载时间来提升启动速度。
总结
快速启动模型将为Activity创建最小化视图作为快速启动阶段任务，然后在视图即将展现时进行延时初始化，达到快速启动的目的；使用Delegate模型实现快速启动流程和正常流程的切换。
