用户希望应用能够快速打开。启动时间过长的应用不能满足这个期望,并且可能会令用户失望。轻则鄙视你,重则直接卸载你的应用。
用户不会在乎你的项目是不是过大,里面是不是有很多初始化的逻辑。他只在乎你-慢了。
所以咱们这篇文章有两个目的:
今天咱们就来了解一下应用启动内部机制和启动速度优化。
应用有三种启动状态:
冷启动是指应用从头开始:冷启动发生在设备启动后第一次启动应用程序 (Zygote>fork>app) ,或系统关闭应用程序后。
在冷启动开始时,系统有三个任务。 这些任务是:
一旦系统创建了应用程序进程,应用程序进程就负责接下来的阶段:
如下图:
注意:在创建 Application 和创建 Activity 期间可能会出现性能问题。
当应用程序启动时,空白启动页面保留在屏幕上,直到系统首次完成应用程序的绘制。
如果你重写了Application.onCreate(),系统将调用Application 上的onCreate()方法。之后,应用程序生成主线程,也称为UI线程,并将创建主Activity的任务交给它。
应用进程创建你的Activity后,Activity会执行以下操作:
注意:onCreate() 方法对加载时间的影响最大,因为它执行开销最高的工作:加载UI的布局和渲染,以及初始化Activity运行所需的对象。
热启动时,系统将应用从后台拉回前台,应用程序的 Activity 在内存中没有被销毁,那么应用程序可以避免重复对象初始化,UI的布局和渲染。
如果 Activity 被销毁则需要重新创建。
和冷启动的区别: 不需要创建 Application。
温启动介于冷启动和热启动中间吧。例如:
三种启动介绍完了。我们能改进的大概就两个方面:
咱们看看他们共同消耗多长时间。
在 Android 4.4(API 级别 19)及更高版本中,logcat 包含一个输出行,其中包含一个名为 Displayed 的值。 此值表示启动流程和完成在屏幕上绘制相应活动之间经过的时间量。 经过的时间包含以下事件序列:
注意这里查看日志需要如下操作:
打印日志,如下:
//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s355ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s46ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +289ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +253ms
图例讲解:
第一个时间,冷启动时间:+1s355ms。
然后我们在后台杀死进程,再次启动应用;
第二个时间,温启动时间:+1s46ms。
这里咱们在后台杀死进程所以:应用进程和Activity需要重新启动。
第三个时间:热启动时间:+289ms 和 +253ms
按返回键,仅退出activity。所以耗时比较短。
当然整体看这个应用开启时间并不长,因为 Demo 的 Application 和 Activity 都没有进行太多的操作。
你可以使用 reportFullyDrawn() 方法来测量应用程序启动和所有资源和视图层次结构的完整显示之间经过的时间。在应用程序执行延迟加载的情况下,这可能很有价值。在延迟加载中,应用程序不会阻止窗口的初始绘制,而是异步加载资源并更新视图层次结构。
这里我在Activity.onCreate()中加了个工作线程。并在里面调用reportFullyDrawn() 方法。代码如下:
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.e(this.getClass().getName(), "onCreate");
setContentView(R.layout.activity_main);
...
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(3000);
reportFullyDrawn();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
打印日志,如下:
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s970ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s836ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s107ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s149ms
图例讲解:
然后你会发现界面出来好一会才打这个日志。看到这里我觉得好多人已经知道怎么去优化启动速度了。
看到上面的实验其实三种启动情况,受我们影响的方面在于 application 和 activity 。
当你的代码覆盖 Application 对象并在初始化该对象时执行繁重的工作或复杂的逻辑时,启动性能可能会受到影响。 产生的原因包括:
解决方案
无论问题在于不必要的初始化还是磁盘I/O,解决方案都是延迟初始化。换句话说,你应该只初始化立即需要的对象。不要创建全局静态对象,而是转向单例模式,应用程序只在第一次需要时初始化对象。
此外,考虑使用依赖注入框架(如Hilt)
活动创建通常需要大量高开销工作。 通常,有机会优化这项工作以实现性能改进。
产生的原因包括:
解决方案如下。
<include/>和 <merge/>
)
关于这两块的优化后续会有单独的文章去写。
public class SccApp extends Application {
@RequiresApi(api = Build.VERSION_CODES.P)
@Override
public void onCreate() {
super.onCreate();
String name = getProcessName();
MLog.e("ProcessName:"+name);
getProcessName("com.scc.demo");
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public class MainActivity extends ActivityBase implements View.OnClickListener {
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.e(this.getClass().getName(), "onCreate");
setContentView(R.layout.activity_main);
...
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(3000);
reportFullyDrawn();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
打印日志,如下:
//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +5s458ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +8s121ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +5s227ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +7s935ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +2s304ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +5s189ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +2s322ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +5s169ms
这个就是把代码放在如下代码中执行即可,就不全部贴出来了。
new Thread(new Runnable() {
@Override
public void run() {
...
}
}).start();
运行结果如下:
//冷启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s227ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s957ms
//温启动(进程被杀死)
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +1s83ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s828ms
//热启动
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +324ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s169ms
I/ActivityTaskManager: Displayed com.scc.demo/.actvitiy.MainActivity: +358ms
I/ActivityTaskManager: Fully drawn com.scc.demo/.actvitiy.MainActivity: +3s207ms
Android 应用启动时,尤其是大型应用, 经常出现几秒钟的黑屏或白屏,黑屏或白屏取决于主界面 Activity 的主题风格。
Android 应用启动时很多大型应用都会有一个广告(图片及视频)页或闪屏页(2-3S),这是为了避免上述启动白屏导致用户体验很差(当然也有打广告的目的)。当然你可以珍惜这2-3秒做一个异步加载或者请求。
当然Android 12 的SplashScreen也给了我们很好的选择。
感兴趣的可以去:https://juejin.cn/post/7026188311198695432 查看一下
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。