通常用户期望app响应和加载速度越快越好。一个启动速度慢的app很可能会给用户留下不好的印象除了导致用户在应用市场上的打分低之外很有可能导致致用户直接卸载。
这篇文章提供了优化app启动时间的方法。先解释了app进程启动的内部流程。然后讨论如何优化启动的性能。最后列出几个常见的启动问题和解决方案。
一 启动内幕
App启动可能发生在以下三种状态 之一每一种都会影响到展现给用户的时间冷启动、热启动和温启动翻译的有点怪介于冷和热之间吧。
冷启动下app所做的事情不较多其它两种情况系统只需要将app从后台切到前台。建议你在冷启动的基础上做优化这样也会提升热启动和温启动的性能。
为了更好地优化app的启动了解系统和app层做了什么以及如何相互影响很有必要。
1.1 冷启动
冷启动指在app启动之前系统的进程还没有直到app启动创建app的进程。冷启动会发生在device重启或者app被杀死的情况下。这种启动在优化启动时间上有更大的挑战因为相比其它两种启动方式系统和app有更多的工作需要处理。
冷启动之前系统会执行以下三个task
1、加载并启动app
2、在app启动后立即展示空白的window
3、创建app进程
一旦系统创建了app进程那么app进程就会执行以下步骤
1、创建app对象
2、启动main thread
3、创建MainActivity
4、Inflate view
5、布置屏幕
6、进行首次绘制
一旦app进程完成了第一次绘制系统进程就会用main activity替换已经展示的background window。之后用户才可以使用app。
下图展示了系统和app进程互相如何工作的展示了app启动时期的几个重要部分在创建app和main activity之间我们可以提升性能问题
Application的创建
当应用启动的时候空白的window在app第一次完成绘制之前都会存在。在那之后系统进程才会替换启动窗口允许用户开始和app交互。
如果你复写了 Application.oncreate() 方法app启动的时候会调用该方法。之后app会孵化主线程UI线程并通过它来创建main activity。
从这之后系统和app级别的进程将会按照app lifecycle stages 执行。
Activity的创建
在app进程创建了Activity之后Activity将会执行以下操作
1、初始化值
2、调用构造函数
3、调用毁掉方法比如Activity.onCreate()。
通常onCreate方法会对加载时间有比较大的影响。因为它将执行繁重的工作加载和填充view并初始化Activity运行期间需要用的对象。
1.2 热启动
相对于冷启动热启动会简单的多。如果app的所有Activities还存在内存中那么系统需要做的就是将activity切换到前台。这样app会避免进行的对象初始化布局填充和渲染。
但是如果一些内存在触发内存回调方法的时候被回收了比如onTrimMemory()那么这些对象就需要重新创建。
热启动会和冷启动有相同的行为。系统也会展示一个空白的window知道app完成Activity的渲染。
1.3 温启动
温启动做的工作介于冷热启动之间。这里列举几种可能被认为是温启动的状态
1、用户离开了app然后重新启动它。这时进程还在继续运行但是Activity被回收了app需要重新创建activity。
2、系统将你的app回收了然后用户重新启动app。进程和Activity都需要重新启动但它们可以从onCreate方法保存的bundle中恢复。
二 优化启动性能
为了确定启动时间的性能问题我们需要先确定app启动花费了多少时间。
2.1 Time to initial display
从4.4API 19开始logcat会输出带有Displayed的log。该值代表从app启动进程到完成Activity第一次绘制的时间。该时间内完成了一下流程
启动进程
初始化对象
创建和初始化Activity
填充布局
第一次绘制app
打出的log如下
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms |
如果你从命令行或者终端跟踪log的话可以比较直接的定位到该log。如果在AndroidStudio中别忘记关闭filter。
Displayed值并没有捕获所有资源都被加载和展示的总时间。那些不在layout文件中或者创建app初始化所需要对象的时间不包含在内。因为这些资源是在一个内部进程中加载的并且不会阻塞app的初始化展示。
2.2 Time to full display
你可以调用reportFullyDrawn())方法去测量从应用启动到所有资源和view层级都被绘制出来的时间。这对于app执行懒加载的情况很有用。在懒加载中app不会阻塞window的初始化绘制但同步进行资源加载和view的更新会阻塞。
由于懒加载app的初始化展示不会包含所有的资源。你可以考虑完全加载并展示所有资源和view的时候作为一个考量。比如UI可能完全加载了包括一些text的绘制但是由于图片需要从网络获取这时还没有展示。
为了处理这种情况你可以手动地调用reportFullyDrawn方法让系统知道你的activity已经通过懒加载完成了。但你是用该方法的时候logcat展示的时间就包含从应用被创建到reportFullyDrawn方法被调用的时间。
定位瓶颈
两种方式可以帮助你定位问题AndroidStudio中的Method Tracer和内嵌tracing代码的方式。更多可以参考documentation.
如果无法使用Method Tracer Tool 或者觉得trace的时机不够准确那么你可以通过在app和Activity的onCreate方法中嵌入代码进行追踪比如写下追踪代码。更多信息可以参考Trace 、Systrace
三 常见的问题
3.1 繁重的App初始化
当你继承了Application对象又在Application对象进行初始化的时候执行繁重的工作或者复杂的逻辑那么就可能导致启动的性能问题。在启动的时候花一些时间去初始化一些子类可能完全没必要。
在app初始化的时候其它的挑战包括垃圾回收事件繁重的操作比如I/O都有可能会阻塞进程的初始化。对于Dalvik运行环境来说垃圾回收是一个需要特别考虑的点Art运行环境会并发的执行垃圾回收以便最小化垃圾回收产生的影响。
3.1.1 定位为题
使用method tracing或者内嵌代码来定位这个问题
Method tracing
Running the Method Tracer tool reveals that the callApplicationOnCreate() method eventually calls yourcom.example.customApplication.onCreate method. If the tool shows that these methods are taking a long time to finish executing, you should explore further to see what work is occurring there.
内嵌代码的方式
可以对以下代码进行追踪
1、App的onCreate方法
2、onCreate中初始化的所有全局单例对象
3、所有I/O反序列化或者可能导致性能问题的循环
3.1.2 解决方案
如果是由于不必要的初始化或者硬盘I/O操作导致的问题解决方案就是懒初始化对象只初始化立即需要的。而不是在一开始就创建全局的静态对象可以将它们的初始化放在一个单例中当app首次访问它们的时候再初始化对象。
3.2 繁重的Activity初始化
Activity的创建有时会承担大量的复杂操作。通常这里存在可以优化的点。常见的问题有
1、填充大量复杂的布局
2、硬盘操作或者网络操作阻塞了绘制
3、加载或者编码bitmap
4、栅栏化VectorDrawable对象
5、Activity中其它子系统的初始化
3.2.1 定位问题
和定位App启动问题类似也是通过method tracing或者嵌入代码来定位。
Method tracing
当执行Method Tracer tool的时候你应该关注继承于Application的子类的构造函数和onCreate方法。
如果该工具表明代码中花了很长时间去执行那么你就应该进一步查看这里的具体操作。
嵌入代码的方式
追踪的部分可能是以下代码块和App初始化一样
1、App的onCreate方法
2、启动时初始化的所有全局单例对象
3、所有I/O反序列化或者可能导致性能问题的循环
3.2.2 解决方案
上面可能有很多潜在的问题这列举两种通用的问题和解决方案
view的层级越庞大app就会花越多的时间去填充它
减少多余的或者嵌套的布局
不填充哪些不需要在启动时就需要展示的view。可通过ViewStub来实现在需要的时候再填充
在main thread中做资源的初始化也会减慢启动速度。可以通过下面来解决
延迟所有的资源初始化或者放在其它线程中去做
允许app先加载和展示view那些依赖于bitmap或者其它资源之后再去更新
三 主题化的启动屏幕
我们可以通过主题化app的启动屏幕来改善启动体验。这样整个app的启动和接下来的操作会显得更加连贯。但这样只是将Activity的慢启动问题隐藏了。
一种常用的方式实现主题启动屏幕的方式是使用 windowDisablePreview主题属性关闭系统进程在app启动时绘制的初始化空白屏幕。但是这种方式会导致更长时间。同样的这样也会迫使用户等到Activity启动后才会得到反馈会让用户产生app本身是否有问题的困惑。
解决方案
建议你不应该禁止预览窗口你应该遵循 Material Design 标准。使用Activity的windowBackground主题属性来为启动的Activity提供一个简单的drawable。
布局文件
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque"> <!-- The background color, preferably the same as your normal theme --> <item android:drawable="@android:color/white"/> <!-- Your product logo - 144dp color version of your app icon --> <item> <bitmap android:src="@drawable/product_logo_144dp" android:gravity="center"/> </item></layer-list> |
Manifest file:
<activity ...android:theme="@style/AppTheme.Launcher" /> |
然后在代码中将主题切换回app的主题最简单的方式是在super.onCreate() 和setContentView()方法之前调用 setTheme(R.style.AppTheme)
public class MyMainActivity extends AppCompatActivity {@Overrideprotected void onCreate(Bundle savedInstanceState) {// Make sure this is before calling super.onCreatesetTheme(R.style.Theme_MyApp);super.onCreate(savedInstanceState);// ...}} |