Android性能优化[启动优化]

启动优化的目的

APP启动如果得到很好的优化，增强用户体验增加用户流量；如果app启动时间过长影响用户体验，从而会造成流失用户。所以做启动优化是有必须的。

谷歌官方针对以下三种启动方式做了详细的介绍，具体可以参考https://developer.android.com/topic/performance/vitals/launch-time。从官网得知APP启动所需的时间为：冷启动时间>温启动时间>热启动时间

启动分三种:

• 冷启动

  当应用在设备开机或者系统主动 kill APP 进程之后，用户点击桌面icon图标启动，称之为冷启动。

• 温启动

  温启动是APP进程还存活，因为内存不足Activity被回收了，当再次启动APP时就会重新执行Activity生命周期，布局绘制等操作。

• 热启动

  当后台存在该应用的进程或者服务时，用户点击icon图标启动，称之为热启动。一般是用户按了home键回到桌面，或者返回键没有杀进程，或者app本身做了进程重启的机制。

冷启动

冷启动的的过程：

• 加载和启动APP
• 显示一个白色的Window窗口
• 创建APP进程
• 创建Application
• 创建MainActivity
• 加载布局
• 首帧绘制

应用的启动过程

  冷启动启动流程——当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类（attachBaseContext()–>OnCreate()）、创建MainActivity类、加载主题样式Theme中的　windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了，最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，应用的第一次启动才算完成，这时候看到的界面也就是首帧。

大致流程如下：

• 点击桌面图标，Launcher会启动程序默认的Acticity，之后再按照程序的逻辑启动各种Activity。
• 启动Activity通过应用程序框架层的ActivityManagerService服务启动(Service也是由ActivityManagerService来启动的)。ActivityManagerService是一个非常重要的接口，它负责启动和管理Activity和Service。
    1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口。
    2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息。
    3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了。
    4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity。
    5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动。
     6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作。
    7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。

所以相应的优化方案

• 减少 onCreate方法的工作量。
• 不要让Application参与业务逻辑。
• 不要在Application中做耗时操作，一些初始化操作可以开启子线程来完成。
• 不要以静态变量方式在Application中保存数据。
• 布局优化/mainThread尽量延迟初始化。
• 启动画面的初始化可以使用设置主题背景的方式，速度回更快。

启动主题优化

冷启动阶段:

1. 加载并启动应用程序。
2. 启动后立即显示应用程序空白的启动窗口。
3. 创建应用程序进程。

  启动主题优化，就是应用程序在冷启动的时候(1~2阶段)，设置启动窗口的主题。因为现在 App 应用启动都会先进入一个闪屏页(LaunchActivity) 来展示应用信息。

默认主题情况

  如果我们对App没有做处理(设置了默认主题)，并且在 Application 的onCreate()初始化了其它第三方的服务(假设需要加载2000ms)，那么系统默认会在启动应用程序的时候启动空白窗口 （产生一个白屏），直到 App 应用程序的入口 Activity 创建成功，视图绘制完毕。( 大概是onWindowFocusChanged方法回调的时候 )

解决白屏或黑屏问题
  在默认主题的情况下并且Application初始化服务耗时过长就会出现白屏。如果出现白屏或黑屏闪现，查看设置Style的Theme。

透明主题优化

  为了解决启动窗口白屏问题，许多开发者都是使用透明主题来解决这个问题，但是治标不治本。虽然解决了上面这个问题，但是仍然有些不足。已经测试虽然无白屏了，不过从点击到App仍然存在视觉延迟。

设置闪屏图片主题

  为了更顺滑无缝衔接闪屏页，可以在启动 Activity 的 Theme中设置闪屏页图片（如上面代码），这样启动窗口的图片就会是闪屏页图片，而不是白屏。这样设置的话，就会在冷启动的时候，展示闪屏页的图片，等App进程初始化加载入口 Activity (也是闪屏页) 就可以无缝衔接。其实这种方式并没有真正的加速应用进程的启动速度，而只是通过用户视觉效果带来的优化体验。

代码优化

  当然上面使用设置主题的方式优化用户体验效果治标不治本，关键还在于对代码的优化。首先我们可以统计一下应用冷启动的时间。

启动耗时的测量方式

• 通过adb 命令统计启动耗时时间
• 手动埋点计算时间差

adb 命令统计
adb命令 : adb shell am start -S -W 包名/启动类的全限定名 ， -S 表示重启当前应用
更多的ADB命令

G:\AS_Project_Work\Demo>adb shell am start -S -W com.lu.demo/com.lu.demo.MainActivity
Stopping: com.lu.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lu.demo/.MainActivity }
Status: ok
Activity: com.lu.demo/.MainActivity
ThisTime: 508
TotalTime: 508
WaitTime: 586
Complete

ThisTime : 最后一个 Activity 的启动耗时(例如从 LaunchActivity - >MainActivity「adb命令输入的Activity」 , 只统计 MainActivity 的启动耗时)。
TotalTime : 启动一连串的 Activity 总耗时.(有几个Activity 就统计几个)。
WaitTime : 应用进程的创建过程 + TotalTime 。

ThisTime<=TotalTime<=WaitTime

这时应用就启动了(注意：此时是冷启动)，当我点击home将应用切到后台之后，再次执行adb shell am start -W 包名/启动类的全限定名的命令，这时可以发现，这三个时间都缩短了，而且提示Warning: Activity not started, its current task has been brought to the front表示当前启动是一个热启动。

G:\AS_Project_Work\Demo>adb shell am start -W com.lu.demo/com.lu.demo.MainActivity
Stopping: com.lu.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lu.demo/.MainActivity }
Warning: Activity not started, its current task has been brought to the front
Status: ok
Activity: com.lu.demo/.MainActivity
ThisTime: 508
TotalTime: 508
WaitTime: 586
Complete

手动埋点计算时间差
手动埋点在什么时机开始计算时间，什么时候结束计算时间？一般会在 Application attachBaseContext 中开始埋点计算开始时间，然后在 Activity 中第一个 View 中preDraw 时结束埋点计算结束时间，两者之差就是启动耗时时间。从上面的启动过程得知，一般会在 Application attachBaseContext 中开始埋点计算开始时间，然后在启动MainActivity 中第一个 View 中preDraw 时结束埋点计算结束时间。参照启动过程下面开始代码实现：

//Application.java
@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    //开始计算启动时间（埋点）
    LaunchTime.startRecord();
}

//MainActivity.java
TextView text = findViewById(R.id.text);
text.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
    @Override
    public boolean onPreDraw() {
        // 结束计算启动时间(埋点)
        LaunchTime.stopRecord("TextView preDraw");
        return true;
    }
});

//LaunchTime.java
public class LaunchTime {
    private static final String TAG = LaunchTime.class.getSimpleName();
    private static long startTime = 0;
    //开始记录计时
    public static void startRecord() {
        startTime = System.currentTimeMillis();
    }
    //停止计时 打印出时间差
    public static void stopRecord(String tag) {
        //打印日志
        Log.e(TAG, tag + "CostTime:" + (System.currentTimeMillis() - startTime));
    }
}

//打印日志
06-1267 21:38:37.230 1701-1701/? E/LaunchTime: TextView preDrawCostTime:398

手动计算启动耗时时间是比较精确的方式，可以带到线上使用，不过需要注意结束埋点的时机，这个时机也可以选择 addOnDrawListener 但是这个是在API16以上才能使用。

优秀的启动优化文章

总结

• 记录启动优化日后好复习。
• 了解APP启动过程，更好设置优化方案。
• 了解主题启动优化方案处理白屏黑屏闪现等问题。
• 代码优化及启动耗时测量方式，方案选择。