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模型实现快速启动流程和正常流程的切换。