Android Note - 启动优化

应用的三种启动方式

冷启动 指的是应用彻底从头开始启动,遵循下面的步骤

  1. 加载和启动应用
  2. 在启动应用后立即为应用生成并展示一个空白的启动窗口
  3. 创建应用进程

当应用进程创建完毕后,系统将任务交给应用进程本身,应用进程将负责下面操作

  1. 创建应用对象
  2. 启动主线程 main thread
  3. 创建应用入口的 Activity
  4. 填充加载布局 View
  5. 在屏幕上执行 View 的绘制过程 measure -> layout -> draw

如果你重载了 Application.oncreate(),应用将通过调用这个方法去启动。在这之后,应用将会产生主线程,也就是 UI 线程,并且主线程将会创建你的主 Activity。

也就是说,在调用 Application.oncreate() 的时候并没有产生主线程。

Activity.onCreate() 方法对加载时间有最大的影响,因为它执行了最高开销的工作:加载和填充 view,并且初始化了供 Activity 运行的对象。

网图,侵删

热启动 热启动比冷启动的开销更低。在热启动里,系统所做的就是把你的应用带到前台,可以避免重复的对象初始化,布局加载和填充。

温启动 可以理解成包含了一些冷启动操作的热启动,比冷启动开销小。


使用工具评估启动时间

Displayed 是 Logcat 自带的参数输出,其结果表示了应用从启动进程到完成初次屏幕绘制经过的时间。注意,这个时间并不是应用实际的总耗时。

Time/? I/ActivityManager: Displayed com.xxx.xxx/.launch.SplashActivity: +553ms (total +4s89ms)
Time/? I/ActivityManager: Displayed com.xxx.xxx/.launch.MenuIrrActivity: +1s241ms
复制代码

ADB Shell Activity Manager 使用 adb 命令来测量启动时长,命令如下

adb shell am start -W -S [packageName]/[ActivityPath]
复制代码
  • -W 列出启动过程中统计到的具体数据
  • -S 强制停止当前的 Activity ,重新启动
D:\SDK\Android\platform-tools>adb shell am start -W -S com.xxx.xxx/.launch.MainActivity
复制代码

运行结果如下

Stopping: com.xxx.xxx
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.datayes.irr/.launch.MainActivity }
Status: ok
Activity: com.datayes.irr/.launch.SplashActivity
ThisTime: 1276
TotalTime: 5244
WaitTime: 5334
Complete
复制代码
  • ThisTime 最后一个启动的 Activity 的启动耗时
  • TotalTime 启动流程里所有的 Activity 的启动耗时
  • WaitTime ActivityManagerService 启动 App 的 Activity 的总耗时

具体优化方案

因为 App 应用进程的创建过程是由手机的软硬件决定的,所以我们只能在这个创建过程中进行视觉优化

主题启动优化

给闪屏页设置一个默认的启动图片以避免白屏

<item name="android:windowBackground">@drawable/launch</item>
复制代码

广告页优化

使用 IntentService 下载启屏广告

在入口 Acitivity 中开启 IntentService 或者是其它异步下载操作来下载启屏广告。在广告页图片文件流完全写入后记录图片大小,或者记录一个标识。在下次的广告页加载中可以判断是否已经下载好了广告页图片以及图片是否完整,否则删除并且再次下载图片。

代码优化

在 Application 中完成繁重的初始化操作和复杂的逻辑就会影响到应用的启动性能。而且有很多第三方组件(包括 App 应用本身)都在 Application 中抢占先机,完成初始化操作。

常见问题

  1. 复杂繁琐的布局初始化
  2. 阻塞主线程 UI 绘制的操作,如 I/O 读写或者是网络访问.
  3. Bitmap 大图片或者 VectorDrawable 加载
  4. 其它占用主线程的操作

解决方案

  1. 必要的组件在 App 主线程中立即初始化(入口 Activity 可能立即会用到)
  2. 其它组件在 App 主线程中初始化,但是可以延迟初始化。
  3. 某些组件可以在子线程中初始化。例如可以将 Bugly 、x5 内核初始化,SP 的读写,友盟等放到子线程中初始化
  4. 将需要在主线程中初始化但是可以不用立即完成的动作延迟加载(数据库等)