Android性能优化系列篇（二）：启动优化

前言

汇总了一下众多大佬的性能优化文章，知识点，主要包含：

UI优化/启动优化/崩溃优化/卡顿优化/安全性优化/弱网优化/APP深度优化等等等~

本篇是第二篇：启动优化！ [非商业用途,如有侵权,请告知我,我会删除]

强调一下： 性能优化的开发文档跟之前的面试文档一样，想要的跟作者直接要。

二、启动优化

2.1 我们为什么要做启动优化？

用户希望应用能够快速打开。启动时间过长的应用不能满足这个期望，并且可能会令用户失望。轻则鄙视你，重则直接卸载你的应用。

用户不会在乎你的项目是不是过大，里面是不是有很多初始化的逻辑。他只在乎你-慢了。

所以咱们这篇文章有两个目的：

• 启动速度提升(用户眼中的大神就是你)

• 优化代码逻辑和规范(别让自己成为继任者中的XX)

今天咱们就来了解一下应用启动内部机制和启动速度优化。

2.2 启动内部机制

应用有三种启动状态：

• 冷启动；

• 温启动；

• 热启动。

2.2.1 冷启动

冷启动是指应用从头开始：冷启动发生在设备启动后第一次启动应用程序 (Zygote>fork>app) ，或系统关闭应用程序后。

在冷启动开始时，系统有三个任务。 这些任务是：

• 加载和启动应用程序。

• 启动后立即显示应用程序的空白启动页面。

• 创建应用程序进程。

一旦系统创建了应用程序进程，应用程序进程就负责接下来的阶段：

• 创建应用的实体。

• 启动主线程。

• 创建主页面。

• 绘制页面上的View。

• 布局页面。

• 执行首次的绘制。

如下图：

• Displayed Time：初始显示时间

• reportFullyDrawn()：完全显示的时间

注意：在创建 Application 和创建 Activity 期间可能会出现性能问题。

创建 Application

当应用程序启动时，空白启动页面保留在屏幕上，直到系统首次完成应用程序的绘制。

如果你重写了Application.onCreate()，系统将调用Application 上的onCreate()方法。之后，应用程序生成主线程，也称为UI线程，并将创建主Activity的任务交给它。

创建Activity

应用进程创建你的Activity后，Activity会执行以下操作：

• 初始化值。

• 调用构造函数。

• 调用 Activity 当前生命周期状态的回调方法，如 Activity.onCreate()。

注意：onCreate() 方法对加载时间的影响最大，因为它执行开销最高的工作：加载UI的布局和渲染，以及初始化Activity运行所需的对象。

2.2.2 热启动

热启动时，系统将应用从后台拉回前台，应用程序的 Activity 在内存中没有被销毁，那么应用程序可以避免重复对象初始化，UI的布局和渲染。

如果 Activity 被销毁则需要重新创建。

和冷启动的区别： 不需要创建 Application。

2.2.3 温启动

温启动介于冷启动和热启动中间吧。例如：

• 用户按返回键退出应用，然后重新启动。进程可能还没有被杀死，但应用必须通过调用onCreate（）重新创建 Activity。

• 系统回收了应用的内存，然后用户重新运行应用。应用进程和Activity都需要重新启动。

咱们看看他们共同消耗多长时间。

2.3 查询的启动时间

2.3.1 初始显示时间(Time to initial display)

在 Android 4.4（API 级别 19）及更高版本中，logcat 包含一个输出行，其中包含一个名为 Displayed 的值。 此值表示启动流程和完成在屏幕上绘制相应活动之间经过的时间量。 经过的时间包含以下事件序列：

• 启动进程。

• 初始化对象。

• 创建并初始化Activity。

• 加载布局。

• 第一次绘制你的应用程序。

注意这里查看日志需要如下操作：

报告的日志行类，如下图：

//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s355ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s46ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +289ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +253ms

图例讲解：

第一个时间，冷启动时间：+1s355ms。

然后我们在后台杀死进程，再次启动应用；

第二个时间，温启动时间：+1s46ms。

这里咱们在后台杀死进程所以：应用进程和Activity需要重新启动。

第三个时间：热启动时间：+289ms 和 +253ms

按返回键，仅退出activity。所以耗时比较短。

当然整体看这个应用开启时间并不长，因为 Demo 的 Application 和 Activity 都没有进行太多的操作。

2.3.2 完全显示时间(Time to full display)

你可以使用 reportFullyDrawn() 方法来测量应用程序启动和所有资源和视图层次结构的完整显示之间经过的时间。在应用程序执行延迟加载的情况下，这可能很有价值。在延迟加载中，应用程序不会阻止窗口的初始绘制，而是异步加载资源并更新视图层次结构。

这里我在Activity.onCreate()中加了个工作线程。并在里面调用reportFullyDrawn() 方法。代码如下：

@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Log.e(this.getClass().getName(), "onCreate");
    setContentView(R.layout.activity_main);
    ...
    new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                Thread.sleep(3000);
                reportFullyDrawn();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }).start();
}

报告的日志行类，如下图：

I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s970ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s836ms
I/ActivityTaskManager: Fully d