一、App启动分类
1.冷启动 Cold start
在启动应用前,系统还没有App的任何进程。比如设备开机后应用的第一次启动,系统杀掉应用进程 (如:系统内存吃紧引发的 kill 和 用户主动产生的 kill) 后 的再次启动等。那么自然这种方式下,应用的启动时间最长。
2.热启动 Warm start
当应用中的 Activities 被销毁,但在内存中常驻时,应用的启动方式就会变为暖启动。相比冷启动,暖启动过程减少了对象初始化、UI的布局和渲染。启动时间更短。但启动时,系统依然会展示一个空白背景,直到第一个 Activity 的内容呈现为止。
3.温启动 Lukewarm start
用户退出您的应用,但随后重新启动。该过程可能已继续运行,但应用程序必须通过调用onCreate()从头开始重新创建活动。系统从内存中驱逐您的应用程序,然后用户重新启动它。进程和Activity需要重新启动,但任务可以从保存的实例状态包传递到onCreate()中。
启动速度优化主要是针对冷启动方式。下面看下冷启动的时候会做哪些工作。
#二、冷启动
应用发生冷启动时,系统有三件任务要做:
- 加载启动App;
- App启动之后立即展示出一个空白的Window;
- 创建App的进程;
创建App进程后,会马上执行以下任务:
- 初始化应用中的对象 (比如 Application 中的工作);
- 启动主线程 (UI 线程) ;
- 创建第一个 Activity;
- 加载内容视图 (Inflating) ;
- 计算视图在屏幕上的位置排版 (Laying out);
- 进行第一次绘制 (draw)。
只有当应用完成第一次绘制,系统当前展示的空白背景才会消失,才会被 Activity 的内容视图替换掉。也就是这个时候,用户才能和我们的应用开始交互。下图展示了冷启动过程系统和应用的一个工作时间流:
三、优化思路
作为普通应用,App进程的创建等环节我们是无法主动控制的。开发人员唯一能做的就是**在Application 和 第一个 Activity 中,减少 onCreate() 方法的工作量,从而缩短冷启动的时间。**像应用中嵌入的一些第三方 SDK,都建议在 Application 中做一些初始化工作,开发人员不妨采取懒加载的形式移除这部分代码,而在真正需要用到第三方 SDK 时再进行初始化。
Google也给出了启动加速的方向:
1、利用提前展示出来的Window,快速展示出来一个界面,给用户快速反馈的体验;
2、 避免在启动时做密集沉重的初始化(Heavy app initialization);
3、 定位问题:避免I/O操作、反序列化、网络操作、布局嵌套等
四、正确测量评估启动性能的方法
1.display time
从Android KitKat版本开始,Logcat中会输出从程序启动到某个Activity显示到画面上所花费的时间。这个方法比较适合测量程序的启动时间。
2.reportFullyDrawn
我们通常来说会使用异步懒加载的方式来提升程序画面的显示速度,这通常会导致的一个问题是,程序画面已经显示,可是内容却还在加载中。为了衡量这些异步加载资源所耗费的时间,我们可以在异步加载完毕之后调用activity.reportFullyDrawn()方法来告诉系统此时的状态,以便获取整个加载的耗时。
3.Traceview
告诉我们每一个方法执行了多长时间.这个工具可以通过 Android Device Monitor 或者从代码中启动。
3.1 Android Device Monitor启动
启动应用,点击 Start Method Tracing,应用启动后再次点击,会自动打