冷启动:
在启动应用时,系统中没有该应用的进程,这时系统会创建一个新的进程分配给该应用;
热启动:
在启动应用时,系统中已有该应用的进程(例:按back键、home键,应用虽然会退出,但是该应用的进程还是保留在后台);
二、冷启动、热启动的区别
冷启动:系统没有该应用的进程,需要创建一个新的进程分配给应用,所以会先创建和初始化Application类,再创建和初始化MainActivity类(包括一系列的测量、布局、绘制),最后显示在界面上。 热启动: 从已有的进程中来启动,不会创建和初始化Application类,直接创建和初始化MainActivity类(包括一系列的测量、布局、绘制),最后显示在界面上。
三、冷启动时间的计算
API19 之后,系统会出打印日志输出启动的时间; 冷启动时间 = 应用启动(创建进程) —> 完成视图的第一次绘制(Activity内容对用户可见);
四、冷启动流程
Zygote进程中fork创建出一个新的进程; 创建和初始化Application类、创建MainActivity; inflate布局、当onCreate/onStart/onResume方法都走完; contentView的measure/layout/draw显示在界面上;
总结:
Application构造方法 –> attachBaseContext() –> onCreate() –> Activity构造方法 –> onCreate() –> 配置主题中背景等属性 –> onStart() –> onResume() –> 测量布局绘制显示在界面上。
五、冷启动的优化
减少在Application和第一个Activity的onCreate()方法的工作量; 不要让Application参与业务的操作; 不要在Application进行耗时操作; 不要以静态变量的方式在Application中保存数据; 减少布局的复杂性和深度;
1. 冷启动的定义
冷启动:启动应用前,系统中没有该应用的任何进程信息Application等,启动5s+。
1.1 冷启动时间的计算
这个时间值是从应用启动(创建进程)开始计算,到完成视图的第一次绘制(即Activity内容对用户可见)为止。
2. 热启动的定义
热启动:启动应用时,后台已有该应用的进程,内存中有应用相关Activity(home键退到桌面),启动1.5s+。
3. 温启动的定义
有一些文章有温启动这个启动类型。
温启动:启动应用时,后台已有该应用的进程,内存中没有应用相关Activity(back键退出应用,未清除进程),启动2s+。
冷热启动过程中,会执行的步骤不一样。
冷启动:系统会重新创建一个新的进程分配给它,所以会先创建和初始化Application类,再创建和初始化MainActivity类(包括一系列的测量、布局、绘制),最后显示在界面上。
热启动:一个应用从新进程的创建到进程的销毁,Application只会初始化一次,所以不必创建和初始化Application,直接走MainActivity(包括一系列的测量、布局、绘制)。
二.冷启动流程
当点击app的启动图标时,安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用,之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上,所以直到这里,应用的第一次启动才算完成,这时候我们看到的界面也就是所说的第一帧。详细的参考:App(Activity)启动流程。
总结应用的启动流程如下:
Application的构造器方 -> attachBaseContext() -> onCreate() -> Activity的构造方法 -> onCreate() -> 配置主题中背景等属性 -> onStart() -> onResume() -> 测量布局绘制显示在界面上。
三.如何对冷启动的时间进行优化。
冷启动时,加载Application过程中,可能会消耗很多时间。如果不采取任何措施就会产生长时间的白屏或黑屏效果,让用户以为这个应用很卡。消除启动时的白屏/黑屏,请参考:Android冷启动实现APP秒开。
1、什么是Android的冷启动时间?
冷启动时间是指用户从手机桌面点击APP的那一刻起到启动页面的Activity调用onCreate()方法之间的这个时间段。
2、在冷启动的时间段内发生了什么?
首先我们要知道当打开一个Activity的时候发生了什么,在一个Activity打开时,如果该Activity所属的Application还没有启动,那么系统会为这个Activity创建一个进程(每创建一个进程都会调用一次Application,所以Application的onCreate()方法可能会被调用多次),在进程的创建和初始化中,势必会消耗一些时间,在这个时间里,WindowManager会先加载APP里的主题样式里的窗口背景(windowBackground)作为预览元素,然后才去真正的加载布局,如果这个时间过长,而默认的背景又是黑色或者白色,这样会给用户造成一种错觉,这个APP很卡,很不流畅,自然也影响了用户体验。
原因在于:
minSdkVersion 设置低了。
如果你的 minSdkVersion 设置为 21 或更高值,你只需在模块级 build.gradle 文件中将 multiDexEnabled 设置为 true,如此处所示:
android {
defaultConfig {。
...
minSdkVersion 21。
targetSdkVersion 28。
multiDexEnabled true。
}
...
但是,如果您的 minSdkVersion 设置为 20 或更低值,则您必须按如下方式使用:
修改模块级 build.gradle 文件以启用 Dalvik 可执行文件分包,并将 Dalvik 可执行文件分包库添加为依赖项,如此处所示:
android {
defaultConfig {。
...
minSdkVersion 15。
targetSdkVersion 28。
multiDexEnabled true。
}
...
dependencies {
compile 'com.android.support:multidex:1.0.3'。
根据是否要替换 Application 类,执行以下操作之一:
如果您没有替换 Application 类,请编辑清单文件,按如下方式设置 。
标记中的 android:name:
...
如果您替换了 Application 类,请按如下方式对其进行更改以扩展 MultiDexApplication(如果可能):
public class MyApplication extends MultiDexApplication { ... }。
或者,如果您替换了 Application 类,但无法更改基本类,则可以改为替换 attachBaseContext() 方法并调用 MultiDex.install(this) 来启用 Dalvik 可执行文件分包:
public class MyApplication extends SomeOtherApplication {。
@Override
protected void attachBaseContext(Context base) {。
super.attachBaseContext(base);。
MultiDex.install(this);。
}
getApplicationContext() 返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁 Activity.this的context 返回当前activity的上下文,属于activity ,activity 摧毁他就摧毁 getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文。
getApplicationContext() 返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁 Activity.this的context 返回当前activity的上下文,属于activity ,activity 摧毁他就摧毁 getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文。