文章翻译自：
https://developer.android.google.cn/topic/performance/launch-time.html
用户都希望 app 一点即开（当然，我们开发者更希望这样），启动慢的 app 因为体验差会被嫌弃，被打低分，甚至被卸载。
文章先从 app 进程启动内部流程介绍，然后讨论如何分析启动性能，最后列出几个常见的启动时间问题和解决方案。
启动内部原理
app 可能从三个状态启动，每种状态从开始启动到对用户可见的时长不同。三种状态分别为：冷启动（Cold Start），热启动（Warm Start），温启动（Lukewarm Start）。
冷启动
冷启动指一个 app 从零开始启动：系统中不存在 app 对应的进程，直到 app 开始启动，才创建其对应的进程。冷启动发生在设备重启后 app 第一次被启动，或者系统杀死 app 后。这种类型的启动相对于其它两种类型的启动来说，系统和 app 需要做更多的工作，对于降低启动时间来说，挑战性最大。
在冷启动开始时，系统需要完成三个任务：
- 加载并启动 app；
- 在 app 启动后立刻展示一个空白的window；
- 创建 app 对应的进程。
app 的进程一旦创建完成，这个进程会负责下面的步骤：
- 创建 app 对象；
- 启动 main thread；
- 创建 main activity；
- 渲染 views；
- 界面布局；
- 执行初始化绘制。
一旦初始化绘制完成，系统进程会使用 main actiity 替换显示的背景window，用户可以开始使用 app。
图一展示了系统和APP进程间工作的切换：
在 app 和 activity 创建期间可以提升性能。
Application 的创建
当 app 启动时，空白的开始 window 一直保留在屏幕上，直到系统初次完成APP绘制，替换空白 window。
如果你已经重载了 Application.onCreate() 方法，系统会调用你的 app 对象中的 onCreate() 方法。之后，app 创建 main thread，即 UI thread，并且使用 main thread 创建 main activity。
到此位置，系统和 app 级别进程按照 app 生命周期 继续工作。
app 生命周期：https://developer.android.google.cn/guide/components/activities/process-lifecycle.html
Activity 的创建
在 app 进程创建 activity 后，activity 会进行如下的操作：
- 初始化值；
- 调用构造方法；
- 根据当前的 activity 生命周期阶段调用回调方法，例如 Activity.onCreate()。
通常来说，onCreate() 方法对于加载时间来说影响最大，因为它执行开销最大的工作：加载并渲染 views，并且初始化 activity 运行时需要的对象。
热启动
热启动相对于冷启动而言，更简单并且开销更低。在热启动时，系统需要做的是把 activity 重新放到前台。如果 app 的 activities 仍然驻留在内存中，app 就可以避免重复的对象初始化，界面布局和渲染。
然而，如果内存已经因响应内存清理事件而被清理，例如 onTrimMemory()，那么，那些对象在热启动时会被重新创建。
热启动与冷启动场景有同样的屏幕显示行为：系统进程显示空白屏幕，直到 app 完成 activity 绘制。
温启动
温启动包含一些冷启动时的子操作；同时，开销又比热启动小。有许多可能的状态可被认为是温启动，例如：
- 用户退出 app，但随后又重新启动。进程可能继续运行，但是 app 必须调用 onCreate() 重新创建 activity。
- 系统杀死了 app，然后重新启动。进程和 activity 需要重启，但是task 可以从已保存的通过 onCreate() 犯法传递的 bundle 得到一些需要的东西。
分析启动性能
为了准确的确定启动性能参数，可以跟踪 app 启动所需时长参数。
初次显示时长
从 Android 4.4（API 19）开始，logcat 输出行包含名为 Displayed 的值。这个值代表从进程启动到完成对应 activity 屏幕绘制的时长。这个时长包括以下事件：
- 启动进程；
- 初始化对象；
- 创建并初始化 activity；
- 界面布局；
- 初次绘制 application。
日志输出如下：
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms
Displayed 值并不是代表直到所有资源都加载完所消耗的时长，这个值忽略了在 layout 文件中没有引用或 app 做为对象初始化的一部分所创建的资源。之所以排除这些资源，是因为这些资源的加载是一个内部处理过程，不会阻塞 app 的初次显示。
有时候 Displayed 值的显示格式如下：
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)
这种情况下，初次计算只是包含第一个显示的 activity 的时长。total 时长计算开始于 app 进程开始，并且可能包含其它在开始时已经启动但并未显示在屏幕上的 activity。只有当单个 activity 和总启动时间不同时，才会显示 total 时长。
也可以使用 ADB 命令查看初次显示所消耗时长：
adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN
显示如下：
Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete
ADB 命令参考：
https://developer.android.google.cn/studio/command-line/adb.html#shellcommands
完全显示时长
可以使用 reportFullyDrawn() 方法获取从 app 启动到所有资源和 view 层级显示完成的时长。当 app 使用懒加载时，这个值很有用。在懒加载中，app 不会阻塞 window 的初始化绘制，取而代之的是异步加载资源和更新 view 层级。
如果因为懒加载，app 的初次显示没有包含所有的资源，可以认为所有资源和 view 的完全加载和显示测量是分开的：例如，UI 已经完全加载，并且显示了一些文字，但是还没有显示必须从网络获取的图片。
可以通过调用 reportFullyDrawn() 让系统知道 activity 已经完成懒加载。当调用这个方法后，logcat 会显示从 application 对象创建到这个方法调用的时长，输出如下：
system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms
如果 app 的显示比期望值长，可以尝试查找启动时的瓶颈。
查找瓶颈
两个查找瓶颈的好方法是 Android Studio 的 Method Tracer 工具和内部追踪。
Android Studio 的 Method Tracer 工具参考如下：
https://developer.android.google.cn/studio/profile/am-methodtrace.html
如果不能使用 Method Tracer 工具，可以在 application 和 activity 的 onCreate() 方法中使用内部追踪，参考如下：
Trace 功能：https://developer.android.google.cn/reference/android/os/Trace.html
Systrace 工具：https://developer.android.google.cn/studio/profile/systrace-commandline.html
常见问题
本章节主要讨论一些影响 app 启动性能的问题。这些问题主要涉及 app 和 activity 对象的初始化，也会涉及屏幕的加载。
app 重初始化
如果重写 Application 并且在初始化对象的时候执行繁重的工作或负载的逻辑，启动性能会受到很大的影响。如果 Application 的子类执行没必要的初始化工作，app 会在启动期间浪费时间。一些初始化可能完全没必要：例如，保存 一个实际上由 intent 启动的 app 中的 main activity 的状态信息。
其它在 app 启动期间影响性能的操作还有垃圾回收，或者同步磁盘 I/O，会阻塞初始化进程。垃圾回收只是针对于 Dalvik 虚拟机来说，Art 虚拟机同步执行垃圾回收，最小化了这个操作的影响。
问题诊断
可以使用方法追踪或内部追踪尝试诊断问题。
方法追踪
运行 Method Tracer 工具时，callApplicationOnCreate() 方法最终会调用 com.example.customApplication.onCreate 方法。如果这个工具显示这些方法执行时间很长，那么应该认真查找方法中执行了哪些操作。
内部追踪
使用内部追踪倾向于发现以下方面是否存在问题：
- app 初次 onCreate() ；
- app 初始化的任何全局单例对象；
- 任何在瓶颈期可能形成的磁盘I/O，反序列化或紧凑循环。
解决方案
不论问题是否由非必要的初始化或磁盘I/O引起，解决方案都是懒加载对象：只初始化那些需要立即使用的对象。例如，相比于创建全局 static 对象，可以使用单例模式，只有第一次被访问时对象才会创建。也可以考虑使用 Dagger 之类的依赖注入框架，当第一次被注入时才创建对象和依赖。
Activity 重初始化
Activity 的创建通常包含大量高负载工作。一般来说，可以通过考虑以下方面的问题来优化工作提高性能：
- 加载比较大或复杂的布局；
- 磁盘或网络 I/O 阻塞屏幕绘制；
- 加载和解码 bitmap；
- 调整 VectorDrawable 对象的大小；
- activity 中子系统的初始化。
问题诊断
同样，使用方法追踪和内部追踪。
方法追踪
当运行 Method Tracer 工具是，主要的关注点是 app 中 Application 子类的构造方法和 com.example.customApplication.onCreate() 方法。
如果工具显示完成执行时间较长，那么应该认真查找这部分做了哪些工作。
内部追踪
- app 初次 onCreate() ；
- app 初始化的任何全局单例对象；
- 任何在瓶颈期可能形成的磁盘I/O，反序列化或紧凑循环。
解决方案
有很多可能的瓶颈，两个常见的问题和解决方法如下：
- view 的层级越多，布局的时候就会花更多时间，可以通过两个步骤优化：
- 通过减少重复和布局嵌套是布局变得扁平化。
- 不要加载启动时对用户不可见的布局，可以使用 ViewStub。
- 把所有资源的初始化放到 main thread 中也会减慢启动速度，可以这样优化：
- 使用懒加载或非 main thread 初始化资源。
- 允许 app 先展示 view，然后再更新 bitmap 或其它可见资源。
主题化启动屏幕
你或许希望主题化 app 的加载体验，这样可以使 app 的启动屏幕与其它界面保持主题一致，而不是使用系统主题，也可以使 activity 的启动看起来没那么慢。
通常实现启动屏幕主题化的方法是使用 windowDisablePreview 属性去关闭初次启动时的白屏。然而，使用这种方法会导致更长的启动时间，并且，当用户点击启动图标后可能会因为无界面反馈而使用户感到疑惑。
问题诊断
通常可以通过观察 app 启动时是不是没有响应来确定是不是存在问题。
解决方案
相比于禁用 preview window，可以遵循 Material Design 模式。可以使用 acitivity 的 windowBackground 属性为启动屏幕提供一个简单的图标。
例如，可以创建一个 xml 布局文件：
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque">
<!-- The background color, preferably the same as your normal theme -->
<item android:drawable="@android:color/white"/>
<!-- Your product logo - 144dp color version of your app icon -->
<item>
<bitmap
android:src="@drawable/product_logo_144dp"
android:gravity="center"/>
</item>
</layer-list>
对应的 Manifest 文件：
<activity ...
android:theme="@style/AppTheme.Launcher" />
最简单的切换为正常主题的方式是在调用 super.onCreate() 和 setContentView() 前调用 setTheme(R.style.AppTheme) ：
public class MyMainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
// Make sure this is before calling super.onCreate
setTheme(R.style.Theme_MyApp);
super.onCreate(savedInstanceState);
// ...
}
}
