热启动呢:就是你已经打开过APP但是实际上面你使用home键等。就是还存在后台的应用。再次打开的时候算是属于热启动了。
冷启动呢:属于你第一次打开APP,系统在给你开一个进程。
这个时候我在说明一下热启动的作用。我这边公司想知道他APP开了几次。而且需要准确的数据。这个时候,使用热启动。其实热启动很多地方都可以使用到。
一、应用的启动
启动方式
通常来说,在安卓中应用的启动方式分为两种:冷启动和热启动。
特点
1、冷启动:冷启动因为系统会重新创建一个新的进程分配给它,所以会先创建和初始化Application类,再创建和初始化MainActivity类(包括一系列的测量、布局、绘制),最后显示在界面上。
2、热启动:热启动因为会从已有的进程中来启动,所以热启动就不会走Application这步了,而是直接走MainActivity(包括一系列的测量、布局、绘制),所以热启动的过程只需要创建和初始化一个MainActivity就行了,而不必创建和初始化Application,因为一个应用从新进程的创建到进程的销毁,Application只会初始化一次。
上面说的启动是点击app的启动图标来启动的,而另外一种方式是进入最近使用的列表界面来启动应用,这种不应该叫启动,应该叫恢复。
二、应用启动的流程
在安卓系统上,应用在没有进程的情况下,应用的启动都是这样一个流程:当点击app的启动图标时,安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用,之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上,所以直到这里,应用的第一次启动才算完成,这时候我们看到的界面也就是所说的第一帧。
所以,总结一下,应用的启动流程如下:
Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量布局绘制显示在界面上。
三、测量应用启动的时间
在上面这个启动流程中,任何一个地方有耗时操作都会拖慢我们应用的启动速度,而应用启动时间是用毫秒度量的,对于毫秒级别的快慢度量我们还是需要去精确的测量到到底应用启动花了多少时间,而根据这个时间来做衡量。
什么才是应用的启动时间
从点击应用的启动图标开始创建出一个新的进程直到我们看到了界面的第一帧,这段时间就是应用的启动时间。
我们要测量的也就是这段时间,测量这段时间可以通过adb shell命令的方式进行测量,这种方法测量的最为精确,命令为:
adb shell am start -W [packageName]/[packageName.MainActivity]
执行成功后将返回三个测量到的时间:
1、ThisTime:一般和TotalTime时间一样,除非在应用启动时开了一个透明的Activity预先处理一些事再显示出主Activity,这样将比TotalTime小。
2、TotalTime:应用的启动时间,包括创建进程+Application初始化+Activity初始化到界面显示。
3、WaitTime:一般比TotalTime大点,包括系统影响的耗时。
可以看到在进程已经存在的情况下,只需要重新初始化MainActivity,这样的启动比较快,不过大多数情况下应用的启动都是冷启动,因为用户都会在任务列表中手动关闭遗留的应用进程。
四、减少应用启动时的耗时
针对冷启动时候的一些耗时,如上测得这个应用算是中型的app,在冷启动的时候耗时已经快700ms了,如果项目再大点在Application中配置了更多的初始化操作,这样将可能达到1s,这样每次启动都明显感觉延迟,所以在进行应用初始化的时候采取以下策略:
安卓应用的启动方式分为三种:冷启动、暖启动、热启动,不同的启动方式决定了应用UI对用户可见所需要花费的时间长短。顾名思义,冷启动消耗的时间最长。基于冷启动方式的优化工作也是最考验产品用户体验的地方。谈及优化之前,我们先看看这三种启动方式的应用场景,以及启动过程中系统都做了些什么工作。
在安卓系统中,系统为每个运行的应用至少分配一个进程 (多进程应用申请多个进程) 。从进程角度上讲,冷启动就是在启动应用前,系统中没有该应用的人和进程信息 (包括 Activity、Service 等) 。所以,冷启动产生的场景就很容易理解了,比如设备开机后应用的第一次启动,系统杀掉应用进程 (如:系统内存吃紧引发的 kill 和 用户主动产生的 kill) 后 的再次启动等。那么自然这种方式下,应用的启动时间最长,因为相比另外两种启动方式,系统和我们的应用要做的工作最多。
应用发生冷启动时,系统有三件任务要做:
开始加载并启动应用;
应用启动后,显示一个空白的启动窗口;
创建应用进程信息;
系统创建应用进程后,应用就要做下面这些事情:
初始化应用中的对象 (比如 Application 中的工作);
启动主线程 (UI 线程) ;
创建第一个 Activity;
加载内容视图 (Inflating) ;
计算视图在屏幕上的位置排版 (Laying out);
绘制视图 (draw)。
只有当应用完成第一次绘制,系统当前展示的空白背景才会消失,才会被 Activity 的内容视图替换掉。也就是这个时候,用户才能和我们的应用开始交互。下图展示了冷启动过程系统和应用的一个工作时间流:
这其中有两个 creation 工作,分别为 Application 和 Activity creation。从图中看出,他们均在 View 绘制展示之前。所以,在应用自定义的 Application 类和 第一个 Activity 类中,onCreate() 方法做的事情越多,冷启动消耗的时间越长。
当应用中的 Activities 被销毁,但在内存中常驻时,应用的启动方式就会变为暖启动。相比冷启动,暖启动过程减少了对象初始化、布局加载等工作,启动时间更短。但启动时,系统依然会展示一个空白背景,直到第一个 Activity 的内容呈现为止。
相比暖启动,热启动时应用做的工作更少,启动时间更短。热启动产生的场景很多,常见如:用户使用返回键退出应用,然后马上又重新启动应用。
从 Android 4.4 (API 19) 开始,Logcat 自动帮我们打印出应用的启动时间。这个时间值从应用启动 (创建进程) 开始计算,到完成视图的第一次绘制 (即 Activity 内容对用户可见) 为止。如:
11-15 14:06:25.710 1071-1130/? I/ActivityManager: Displayed com.yifeng.qqtemp/.MainActivity: +3s610ms
对应在 logcat 窗口上的显示如图 (记得修改过滤条件) :
对于用户来讲,看不到具体的启动时间,而是应用启动时白屏展示的体验问题。举个例子来对比一下冷热启动的实际启动情况。新建一个工程,为了更好地模拟演示冷热启动效果,这里我在自定义 Application 类的 onCreate 方法中添加了如下代码来延长应用的冷启动时间:
public class MyApplication extends Application { @Override public void onCreate() { super.onCreate(); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } } }然后第一次编译运行,应用采取冷启动的方式打开 (使用菜单键关闭最近打开的应用,也能达到促使应用使用冷启动方式,延长启动时间的效果) ;接着使用返回键退出应用,再点击桌面应用图标,应用将采用热启动的方式打开。整个操作流程对应的效果如图:
可以看到,冷启动方式下,应用要经历一个短暂的白屏时间 (这个时间的长短视具体情况而定),用户体验极其不好。相比而言,热启动方式下,用户可以较快进入 Activity 主界面与应用发生交互行为。
应用的冷启动总是无法避免的,也就是说冷启动时用户总要经历一个启动等待时间。开发人员唯一能做的就是在 Application 和 第一个 Activity 中,减少 onCreate() 方法的工作量,从而缩短冷启动的时间。像应用中嵌入的一些第三方 SDK,都建议在 Application 中做一些初始化工作,开发人员不妨采取懒加载的形式移除这部分代码,而在真正需要用到第三方 SDK 时再进行初始化。
还有一种简单粗暴的方式就是通过主题设置,不显示启动时的白屏背景。新建一个主题样式,并添加如下属性:
或
- "android:windowDisablePreview">true
然后将这个主题样式设置给第一个启动的 Activity ,如:
".MainActivity" android:theme="@style/LaunchStyle"> "android.intent.action.MAIN" /> "android.intent.category.LAUNCHER" />
备注:这里没有将该主题设置在 Application 标签里,主要是该主题只适用于第一个 Activity,如果放置在 Application 标签中会修改所有 Activity 的主题样式。
再修改该 Activity 类的代码,在加载布局视图前,将主题修改回来:
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setTheme(R.style.AppTheme); setContentView(R.layout.activity_main); }
设置之后,效果图:
可以看到,冷启动方式下,用户点击桌面图标,没有任何反应,过一段时间应用才打开。其实这里只是将白屏背景透明化或者隐藏起来而已。
很显然,这种处理方式用户体验也极差。不过可喜的是,我们可以通过主题中的 windowBackground 属性,自定义应用启动时的窗口背景。至于这个背景如何设计,Google 已经在官网上给了建议和规范,可以参考:Launch screens(需要)。其实就是两种样式,如图:
左图采用应用的 Logo 和 Slogan (甚至为了简单,Slogan 都可以不要),可以增强品牌推广效应;右图利用了 placeholder ,与主界面的 UI 框架保持一致,给用户产生一种应用启动非常快的视觉感受。这两种方案各自目的和应用场景有所不同,但设计理念确实不错。下面我们一一模仿实现,先看第一种。
新建一个名为 shape_launch.xml 的 drawable 文件,内容如下:
"1.0" encoding="utf-8"?>然后修改 styles.xml 文件中的主题样式:"http://schemas.android.com/apk/res/android" android:opacity="opaque"> - "@color/colorPrimary"/>
"@mipmap/ic_launcher" android:gravity="center" />
最后将这个主题设置给启动的 Activity,设置过程和上面隐藏启动窗口时的设置一样。效果如图:
第二种,使用与主界面 UI 框架一致的 placeholder 内容,这种情况下需要计算诸如 Statusbar、Toolbar 控件的高度,shape_launch.xml 内容如下:
"1.0" encoding="utf-8"?>这里模拟了一个高度为25dp的状态栏和一个高度为56dp的标题栏,给用户一种错觉:点击桌面图标,应用立即启动并进入主界面。效果如图:"http://schemas.android.com/apk/res/android" android:opacity="opaque"> - "@color/colorPrimaryDark"/>
- "@color/colorPrimary" android:top="25dp"/>
- "81dp" android:drawable="@android:color/white">
以上两种方式是按照 Google 的建议实现的 UI 效果,当然你还可以有更好的设计方式,只要能够解决冷启动带来的白
屏过渡问题,都能带来不错的用户体验。比如你还可以适度结合 Activity 内容视图使用动画过渡效果,比如:
或者这样:
以上两种效果来自 GitHub 上的开源项目 saulmm/onboarding-examples-android