浅谈Android启动时间

【触发背景】面对海量APP的今天，APP用户量和活跃度成为评价一款APP是否成功的重要因素。用户下载APP后，APP性能体验比如启动时间，直接影响用户使用频率，甚至决定是否卸载APP。想和大家分享【APP性能关于启动时间】的资料和心得。

一、APP启动方式

通常来说，APP中启动方式分为两种：冷启动和热启动。
1.冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。

2.热启动：当启动应用时，后台已有该应用的进程（例：按back键/home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。

请注意：上面说的启动是点击app的启动图标来启动的，而另外一种方式是进入最近使用的列表界面来启动应用，这种不应该叫启动，应该叫恢复。

以Android系统举例

冷启动：冷启动后系统会重新创建一个新的进程分配给它，所以先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后经过渲染显示在app界面。
热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application，因为一个应用从新进程的创建到进程的销毁，Application只会初始化一次。

Android系统上，APP无进程状态，启动流程见下：
Application的构造器方法 ——>attachBaseContext() ——>onCreate() ——>Activity的构造方法 ——>onCreate() ——>配置主题中背景等属性 ——>onStart() ——>onResume() ——>测量布局绘制显示在界面上。

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

Android启动流程原理详情请点击这里

二、什么是启动时间？
1.冷启动时间
当用户点击目标app图标的 timepoint到显示界面第一帧的时间段（当用户点击你的app那一刻到系统调用Activity.onCreate()之间的时间段）
在这个时间段内，WindowManager会先加载app主题样式中的windowBackground做为app的预览元素，然后再真正去加载activity的layout布局。

2.热启动时间
用户把目标app切换至后台后，点击app图标的timepoint到显示界面第一帧的时间段

3.过程
首先我们要知道当打开一个Activity的时候发生了什么，在一个Activity打开时，如果该Activity所属的Application还没有启动，那么系统会为这个Activity创建一个进程（每创建一个进程都会调用一次Application，所以Application的onCreate()方法可能会被调用多次），在进程的创建和初始化中，势必会消耗一些时间，在这个时间里，WindowManager会先加载APP里的主题样式里的窗口背景（windowBackground）作为预览元素，然后才去真正的加载布局。如果加载windowBackground时间过长，而默认的背景又是黑色或者白色，这样会给用户造成一种错觉，APP不流畅，影响用户体验。

【补充解释】WindowManager：Windows Manager是一款窗口管理终端，可以远程连接到Linux的X桌面进行管理，与服务器端产生一个session相互通信。详情请点击这里

三、使用命令获得启动时间

使用命令获得启动时间
$adb shell am start -W -n packagename/packageName.MainActivity

1.获得packagename和入口MainActivity信息
$ aapt dump badging <apk路径>
搜'package' 'launchable-activity',获得如下信息

0DB01250-05A2-43FC-BCF8-DDCA09DFA9AA.png 74BA413B-B5B0-4B8B-8FA5-4034050FE793.png

2.获得packagename、入口MainActivity，填入命令

B2E37528-4F3A-47ED-937D-29E39A9D162F.png

3.得到结果
1）冷启动结果：

629C8139-AEED-4FCD-A0D4-FCCA4C8E7FD6.png

2）热启动结果：

E724720F-DA74-4187-B851-5A98C8999445.png

4.启动时间数据分析

执行成功后将返回三个测量到的时间：

1）ThisTime:一般和TotalTime时间一样，除非在应用启动时开了一个透明的Activity预先处理一些事再显示出主Activity，这样将比TotalTime小。
2）TotalTime:应用的启动时间，包括创建进程+Application初始化+Activity初始化到界面显示。
3）WaitTime:一般比TotalTime大点，包括系统影响的耗时。

关于ThisTime/TotalTime/WaitTime的区别,下面是其解释：“adb shell am start -W ”的实现在『frameworks\base\cmds\am\src\com\android\commands\am\Am.java』文件中。其实就是跨Binder调用ActivityManagerService.startActivityAndWait() 接口（后面将ActivityManagerService简称为AMS），这个接口返回的结果包含上面打印的ThisTime、TotalTime时间.

• startTime记录的刚准备调用startActivityAndWait()的时间点
• endTime记录的是startActivityAndWait()函数调用返回的时间点
• WaitTime = startActivityAndWait()调用耗时。

ThisTime、TotalTime 的计算在 frameworks\base\services\core\java\com\android\server\am\ActivityRecord.java 文件的 reportLaunchTimeLocked() 函数中。

F78E77FE-97FE-4647-94DC-58EA1C4BCFE9.png

• curTime表示该函数调用的时间点.
• displayStartTime表示一连串启动Activity中的最后一个Activity的启动时间点.
• mLaunchStartTime表示一连串启动Activity中第一个Activity的启动时间点.

51B3F8CB-AE1C-4525-BBE8-227BFF289BD6.png

其余参考资料，详情请点击这里

四、竞品结果分析
判断是否存在优化必要性：对比竞品是否存在明显延时。

【竞品产品】A银行、B银行，
【背景】为保证数据不被其他app影响，重启手机后，只开启被测app
【目的】对比竞品，检查冷启动时间
【测试方法】
1重启手机后等2min，启动app，观察冷启动时间
2kill进程，启动app，观察冷启动时间
ps: 重启手机后立即启动你的App的可能会受到系统自启动app的影响

输入命令，查询结果：
A银行
1.重启手机后等2min，启动app，观察冷启动时间

0C864430-E860-4488-802F-C7F5E4C15E24.png

2.kill进程，启动app，观察冷启动时间

EFCCEE73-6E77-498E-B3A7-3861CEDEC347.png

B银行
1.重启手机后等2min，启动APP，观察冷启动时间

B73453C2-146E-47F4-ADFB-17EA6A2C204E.png

2.kill进程，启动APP，观察冷启动时间

EB826749-6114-4D4E-A0A8-EBA16E6C5345.png

提取TotalTime对比，分析结果：
1.重启手机后等2min，启动app，观察冷启动时间
A银行TotalTime：1523ms

B银行TotalTime：510ms
【结论】通过对比可以看到，重启手机后，B银行冷启动时间明显优于A银行冷启动时间

2.kill进程，启动APP，观察冷启动时间
A银行TotalTime：1319ms
B银行TotalTime：130ms

【结论】通过对比可以看到，kill进程，启动APP，B银行冷启动时间明显优于A银行冷启动时间

3.重启手机和kill进程，启动APP
A银行
重启手机TotalTime：1523ms
kill进程，启动APPTotalTime：1319ms
B银行
重启手机TotalTime：510ms
kill进程，启动APPTotalTime：130ms
【结论】通过对比可以看到，kill进程后启动APP，冷启动时间更快

五、优化建议
1.减少应用启动时的耗时
针对冷启动时候的一些耗时，如上测得这个应用算是中型的app，在冷启动的时候耗时已经快xxx ms了，如果项目再大点在Application中配置了更多的初始化操作，这样将可能达到xx s，这样每次启动都明显感觉延迟，所以app初始化时考虑如下操作：消除启动时的白屏/黑屏

在用户点击手机桌面APP的时候，看到的黑屏或者白屏其实是界面渲染前的第一帧，可将Theme里的windowBackground设置成希望用户看到的页面：

a 将背景图设置成我们APP的Logo图，作为APP启动的引导，现在市面上大部分的APP也是这么做的。

<style name="AppWelcome" parent="AppTheme">
<item name="android:windowBackground">@mipmap/bg_welcome_start</item>
</style>

b 将背景颜色设置为透明色，这样当用户点击桌面APP图片的时候，并不会"立即"进入APP，而且在桌面上停留一会，其实这时候APP已经是启动的了，只是我们心机的把Theme里的windowBackground的颜色设置成透明的，用户体验到延迟也会觉得是手机硬件系统导致的，非APP导致的，降低用户对APP指责度。

<style name="Appwelcome" parent="android:Theme.Translucent.NoTitleBar.Fullscreen"/>

ps：透明化这种做法需要注意的一点，如果直接把Theme引入Activity，在运行的时候可能会出现如下异常：

java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.

这个是因为使用了不兼容的Theme，例如Activity继承了AppCompatActivity，解决方案很简单：

• 1）让其Activity集成Activity而不要集成兼容性的AppCompatActivity
• 2）在onCreate()方法里的super.onCreate(savedInstanceState)之前设置我们原来APP的Theme

public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
setTheme(R.style.AppTheme);
super.onCreate(savedInstanceState);
}
}

上面的2种做法，我们都需要将Theme引入对应的Activity

<activity
  android:name=".app.main.MainActivity"
  android:theme="@style/AppWelcome"
  android:screenOrientation="portrait">
  <intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
  </intent-filter>
</activity>