- 创建应用程序进程。
一旦系统创建应用程序进程,应用程序进程就会负责下一阶段。
这些阶段是:
-
创建app对象.
-
启动主线程(main thread).
-
创建应用入口的Activity对象.
-
填充加载布局Views
-
在屏幕上执行View的绘制过程.measure -> layout -> draw
应用程序进程完成第一次绘制后,系统进程会交换当前显示的背景窗口,将其替换为主活动。此时,用户可以开始使用该应用程序。
因为App应用进程的创建过程是由手机的软硬件决定的,所以我们只能在这个创建过程中视觉优化。
冷启动阶段 :
1. 加载并启动应用程序。
2. 启动后立即显示应用程序空白的启动窗口。
3. 创建应用程序进程。
所谓的主题优化,就是应用程序在冷启动的时候(1~2阶段),设置启动窗口的主题。
因为现在 App 应用启动都会先进入一个闪屏页(LaunchActivity) 来展示应用信息。
1.默认情况
如果我们对App没有做处理(设置了默认主题),并且在 Application 初始化了其它第三方的服务(假设需要加载2000ms),那么冷启动过程就会如下图 :系统默认会在启动应用程序的时候 启动空白窗口 ,直到 App 应用程序的入口 Activity 创建成功,视图绘制完毕。( 大概是onWindowFocusChanged方法回调的时候 )
2.透明主题优化
为了解决启动窗口白屏问题,许多开发者使用透明主题来解决这个问题,但是治标不治本。
虽然解决了上面这个问题,但是仍然有些不足。
3.设置闪屏图片主题
为了更顺滑无缝衔接我们的闪屏页,可以在启动 Activity 的 Theme中设置闪屏页图片,这样启动窗口的图片就会是闪屏页图片,而不是白屏。
这样设置的话,就会在冷启动的时候,展示闪屏页的图片,等App进程初始化加载入口 Activity (也是闪屏页) 就可以无缝衔接。
其实这种方式并没有真正的加速应用进程的启动速度,而只是通过用户视觉效果带来的优化体验。
_3_代码优化
当然上面使用设置主题的方式优化用户体验效果治标不治本,关键还在于对代码的优化。
首先我们可以统计一下应用冷启动的时间。
adb 命令统计
参考如何计算 App 的启动时间
http://www.androidperformance.com/2015/12/31/How-to-calculation-android-app-lunch-time/
adb命令 : adb shell am start -S -W 包名/启动类的全限定名 , -S 表示重启当前应用
更多adb命令
https://github.com/mzlogin/awesome-adb
C:\Android\Demo>adb shell am start -S -W com.example.moneyqian.demo/com.example.moneyqian.demo.MainActivity
Stopping: com.example.moneyqian.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.moneyqian.demo/.MainActivity }
Status: ok
Activity: com.example.moneyqian.demo/.MainActivity
ThisTime: 2247
TotalTime: 2247
WaitTime: 2278
Complete
-
ThisTime : 最后一个 Activity 的启动耗时(例如从 LaunchActivity - >MainActivity「adb命令输入的Activity」 , 只统计 MainActivity 的启动耗时)
-
TotalTime : 启动一连串的 Activity 总耗时.(有几个Activity 就统计几个)
-
WaitTime : 应用进程的创建过程 + TotalTime .
-
在第①个时间段内,AMS 创建 ActivityRecord 记录块和选择合理的 Task、将当前Resume 的 Activity 进行 pause.
-
在第②个时间段内,启动进程、调用无界面 Activity 的 onCreate() 等、 pause/finish 无界面的 Activity.
-
在第③个时间段内,调用有界面 Activity 的 onCreate、onResume.
//ActivityRecord
private void reportLaunchTimeLocked(final long curTime) {
final long thisTime = curTime - displayStartTime;
final long totalTime = stack.mLaunchStartTime != 0 ?
(curTime - stack.mLaunchStartTime) : thisTime;
}
最后总结一下 : 如果需要统计从点击桌面图标到 Activity 启动完毕,可以用WaitTime作为标准,但是系统的启动时间优化不了,所以优化冷启动我们只要在意 ThisTime 即可。
系统日志统计
另外也可以根据系统日志来统计启动耗时,在Android Studio中查找已用时间,必须在logcat视图中禁用过滤器(No Filters)。因为这个是系统的日志输出,而不是应用程序的。你也可以查看其它应用程序的启动耗时。
过滤displayed输出的启动日志.
根据上面启动时间的输出统计,我们就可以先记录优化前的冷启动耗时,然后再对比优化之后的启动时间。
Application 优化
Application 作为 应用程序的整个初始化配置入口,时常担负着它不应该有的负担~
有很多第三方组件(包括App应用本身)都在 Application 中抢占先机,完成初始化操作。
但是在 Application 中完成繁重的初始化操作和复杂的逻辑就会影响到应用的启动性能
通常,有机会优化这些工作以实现性能改进,这些常见问题包括:
-
复杂繁琐的布局初始化
-
阻塞主线程 UI 绘制的操作,如 I/O 读写或者是网络访问.
-
Bitmap 大图片或者 VectorDrawable加载
-
其它占用主线程的操作
我们可以根据这些组件的轻重缓急之分,对初始化做一下分类 :
-
必要的组件一定要在主线程中立即初始化(入口 Activity 可能立即会用到)
-
组件一定要在主线程中初始化,但是可以延迟初始化。
-
组件可以在子线程中初始化。
放在子线程的组件初始化建议延迟初始化 ,这样就可以了解是否会对项目造成影响!
所以对于上面的分析,我们可以在项目中 Application 的加载组件进行如下优化 :
将Bugly,x5内核初始化,SP的读写,友盟等组件放到子线程中初始化。(子线程初始化不能影响到组件的使用)
new Thread(new Runnable() {
@Override
public void run() {
//设置线程的优先级,不与主线程抢资源
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
//子线程初始化第三方组件
Thread.sleep(5000);//建议延迟初始化,可以发现是否影响其它功能,或者是崩溃!
}
}).start();
将需要在主线程中初始化但是可以不用立即完成的动作延迟加载(原本是想在入口 Activity 中进行此项操作,不过组件的初始化放在 Application 中统一管理为妙.)
handler.postDelayed(new Runnable() {
@Override
public void run() {
//延迟初始化组件
}
}, 3000);
**闪屏
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
页业务优化**
最后还剩下那些为数不多的组件在主线程初始化动作,例如埋点,点击流,数据库初始化等,不过这些消耗的时间可以在其它地方相抵。
需求背景 : 应用App通常会设置一个固定的闪屏页展示时间,例如2000ms,所以我们可以根据用户手机的运行速度,对展示时间做出调整,但是总时间仍然为 2000ms。
闪屏页政展示总时间 = 组件初始化时间 + 剩余展示时间。
也就是2000ms的总时间,组件初始化了800ms,那么就再展示1200ms即可。
我们先了解一下 Application的启动过程,图片摘自 :
如何统计Android App启动时间
https://www.jianshu.com/p/59a2ca7df681
虽然这个以下图片的源码并不是最新源码(5.0源码),不过不影响整体流程。(7.0,8.0方法名会有所改变)。
冷启动的过程中系统会初始化应用程序进程,创建Application等任务,这时候会展示一个 启动窗口 Starting Window,上面分析了过,如果没有优化主题的话,那么就是白屏。
如果要了解更多启动过程源码,可以看我的博客 :
Launcher 启动 Activity 的工作过程
https://blog.csdn.net/qian520ao/article/details/78156214
分析源码后,我们可以知道 Application 初始化后会调用 attachBaseContext() 方法,再调用 Application 的 onCreate(),再到入口 Activity的创建和执行 onCreate() 方法。所以我们就可以在 Application 中记录启动时间。
//Application
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
SPUtil.putLong(“application_attach_time”,
System.currentTimeMillis());//记录Application初始化时间
}
有了启动时间,我们得知道入口的 Acitivty 显示给用户的时间(View绘制完毕),在博客( View的工作流程)中了解到,在onWindowFocusChanged()的回调时机中表示可以获取用户的触摸时间和View的流程绘制完毕,所以我们可以在这个方法里记录显示时间。
https://blog.csdn.net/qian520ao/article/details/78657084
//入口Activity
@Override
public void onWindowFocusChanged(boolean hasFocus) {
super.onWindowFocusChanged(hasFocus);
long appAttachTime = SPUtil.getLong(“application_attach_time”);
long diffTime = System.currentTimeMillis() - appAttachTime;//从application到入口Acitity的时间
//所以闪屏页展示的时间为 2000ms - diffTime.
}
所以我们就可以动态的设置应用闪屏的显示时间,尽量让每一部手机展示的时间一致,这样就不会让手机配置较低的用户感觉漫长难熬的闪屏页时间(例如初始化了2000ms,又要展示2000ms的闪屏页时间.),优化用户体验。
广告页优化
闪屏页过后就要展示金主爸爸们的广告页了。
因为项目中广告页图片有可能是大图,APng动态图片,所以需要将这些图片下载到本地文件,下载完成后再显示,这个过程往往会遇到以下两个问题 :
-
广告页的下载,由于这个是一个异步过程,所以往往不知道加载到页面的合适时机。
-
广告页的保存,因为保存是 I/O 流操作,很有可能被用户中断,下次拿到破损的图片。
因为不清楚用户的网络环境,有些用户下载广告页可能需要一段时间,这时候又不可能无限的等候。所以针对这个问题我们可以开启 IntentService 用来下载广告页图片。
-
在入口 Acitivity 中开启 IntentService 来下载广告页。 或者是其它异步下载操作。
-
在广告页图片 文件流完全写入后 记录图片大小,或者记录一个标识。
在下次的广告页加载中可以判断是否已经下载好了广告页图片以及图片是否完整,否则删除并且再次下载图片。
另外因为在闪屏页中仍然有 剩余展示时间,所以在这个时间段里如果用户已经下载好了图片并且图片完整,就可以显示广告页。否则进入主 Activity , 因为 IntentService 仍然在后台继续默默的下载并保存图片~
优化前 :
| Displayed | LaunchActivity | MainActivity |
| — | :-: | --: |
| | +2s526ms | +1s583ms |
| | +2s603ms | +1s533ms |
| | +2s372ms | +1s556ms |
优化后 :
| Displayed | LaunchActivity | MainActivity |
| — | :-: | --: |
| | +995ms | +1s191ms |
| | +911ms | +1s101ms |
| | +903ms | +1s187ms |
通过上面的几台手机的启动测试,发现优化后App冷启动的启动速度均提升了60% !!! ,并且我们可以再看一下手机冷启动时候的内存情况 :
优化前 : 伴随着大量对象的创建回收,15s内系统GC 5次。
内存使用波澜荡漾。
优化后 : 趋于平稳上升状态创建对象,15s内系统GC 2次。(后期业务拓展加入新功能,所以代码量增加。)之后总内存使用平缓下降。
**Other :**应用使用的系统不确定如何分类的内存。
**Code :**应用用于处理代码和资源(如 dex 字节码、已优化或已编译的 dex 码、.so 库和字体)的内存。
Stack : 应用中的原生堆栈和 Java 堆栈使用的内存。 这通常与您的应用运行多少线程有关。
Graphics:图形缓冲区队列向屏幕显示像素(包括 GL 表面、GL 纹理等等)所使用的内存。 (请注意,这是与 CPU 共享的内存,不是 GPU 专用内存。)
**Native :**从 C 或 C++ 代码分配的对象内存。即使应用中不使用 C++,也可能会看到此处使用的一些原生内存,因为 Android 框架使用原生内存代表处理各种任务,如处理图像资源和其他图形时,即使编写的代码采用 Java 或 Kotlin 语言。
**Java :**从 Java 或 Kotlin 代码分配的对象内存。
**Allocated :**应用分配的 Java/Kotlin 对象数。 它没有计入 C 或 C++ 中分配的对象。
更多查看 :
https://developer.android.google.cn/studio/profile/memory-profiler?hl=zh-cn
优化完我们的代码后,分析一下启动窗口的源码。基于 android-25 (7.1.1)
启动窗口是由 WindowManagerService 统一管理的 Window窗口,一般作为冷启动页入口 Activity 的预览窗口,启动窗口由 ActivityManagerService 来决定是否显示的,并不是每一个 Activity 的启动和跳转都会显示这个窗口。
WindowManagerService 通过窗口管理策略类 PhoneWindowManager 来创建启动窗口。
拿我之前源码分析的文章中的启动流程图来看看大致 :
Launcher 启动 Activity 的工作过程
https://blog.csdn.net/qian520ao/article/details/78156214
直奔主题,在 ActivityStarter的startActivityUnchecked()方法中,调用了ActivityStack(Activity 状态管理)的startActivityLocked()方法。此时Activity 还在启动过程中,窗口并未显示。
先上一张流程图,展示了启动窗口的显示过程。
首先,由 Activity 状态管理者ActivityStack开始执行显示启动窗口的流程。
//ActivityStack
final void startActivityLocked(ActivityRecord r, boolean newTask, boolean keepCurTransition,
ActivityOptions options) {
if (!isHomeStack() || numActivities() > 0) {//HOME_STACK表示Launcher桌面所在的Stack
// 1.首先当前启动栈不在Launcher的桌面栈里,并且当前系统已经有激活过Activity