浅谈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>

推荐阅读更多精彩内容