Android启动速度优化

最近做了一些Android App启动速度的优化，有一些心得，整理整理

影响启动速度的原因

高耗时任务

数据库初始化、某些第三方框架初始化、大文件读取、MultiDex加载等，导致CPU阻塞

复杂的View层级

使用的嵌套Layout过多，层级加深，导致View在渲染过程中，递归加深，占用CPU资源，影响Measure、Layout等方法的速度

类过于复杂

Java对象的创建也是需要一定时间的，如果一个类中结构特别复杂，new一个对象将消耗较高的资源，特别是一些单例的初始化，需要特别注意其中的结构

主题及Activity配置

有一些App是带有Splash页的，有的则直接进入主界面，由于主题切换，可能会导致白屏，或者点了Icon，过一会儿才出现主界面

一些典型的例子及优化方案

MultiDex

由于Android 5.0以下使用的Dalvik虚拟机天生对MultiDex支持不好，导致在4.4（及以下）的系统上，如果使用了MultiDex做为分包方案，启动速度可能会慢的多，实际数值跟dex文件的大小、数量有关，估计会慢300~500ms

• 解决方案：

  限制APP在5.0以上使用：目前大多数用户已经在使用Android 5.0以上的版本了，当然，还有很多4.4用户，很多APP也是只支持4.4以上（比如：百度APP），为了用户体验，可以考虑舍弃一部分用户

  优化方法数：尽量避免方法超过65535个，同时可以开启Release配置的Minify选项，打包时删掉没有用的方法，不过如果框架引用的较多，基本没效果

  少用一些不必要的框架：有些框架功能很强大，但不一定都能用得上，引进来会新增很多的方法，导致必须开启MultiDex，可以自己造轮子，或者找轻量级的框架

  慎用Kotlin：由于Kotlin现在还没有内置在Android系统中，所以APP如果使用了Kotlin，可能会导致引入很多的Kotlin方法，导致必须分割Dex，这个有待Google在Android P中解决

  Dex懒加载：在APP功能日益复杂的今天，MultiDex几乎是已经无法避免了，为了启动速度的优化，可以将启动时必需的方法，放在主Dex中（即classes.dex），方法是在Gradle脚本中配置multiDexKeepFile或者multiDexKeepProguard属性（代码如下），详见：官方文档，待App启动完成后，再使用MultiDex.install来加载其他的Dex文件。这种方法风险比较高，而且实现成本比较大，如果启动依赖的库比较多，还是无法实现

  android {
      buildTypes {
          release {
              multiDexKeepFile file('multidex-config.txt')        // multiDexKeepFile规则 
              multiDexKeepProguard file('multidex-config.pro')    // 类似ProGuard的规则
          }
      }
  }

  配置文件示例：

  # 常规的multiDexKeepFile规则
  
  com/example/MyClass.class
  com/example/MyOtherClass.class
  
  # 类似ProGuard规则
  
  -keep class com.example.MyClass
  -keep class com.example.MyClassToo
  
  -keep class com.example.** { *; } // All classes in the com.example package

  插件化或H5/React Native方案：即端只提供Native调用能力和容器，业务由插件来做，本地只需要加载基础的Native能力相关类即可，其他完全下发，或内置成资源文件调用

Glide及其他图片框架

Glide是一个很好用的图片加载框架，除了常用的图片加载、缓存功能以外，Glide支持对网络层进行定制，比如换成OkHttp来支持HTTP 2.0。不过，如果在追求启动速度的情况下，在Splash页或主界面加载某一张图片时，往往是第一次使用Glide，由于Glide没有初始化，会导致这次图片加载的时间比较长（不管本地还是网络），特别是在其他操作也在同时抢占CPU资源的时候，慢的特别明显！而后面再使用Glide加载图片时，还是比较快的

Glide初始化耗时分析：Glide的初始化会加载所有配置的Module，然后初始化RequestManager（包括网络层、工作线程等，比较耗时），最后还要应用一些解码的选项（Options）

解决方案：在Application的onCreate方法中，在工作线程调用一次GlideApp.get(this)

override fun onCreate() {
    super.onCreate()
    // 使用Anko提供的异步工作协程，或者自行创建一个并发线程池
    doAsync {
        GlideApp.get(this)   // 获取一个Glide对象，Glide内部会进行初始化操作
    }
}

greenDAO和其他数据库框架

greenDAO实现了一种ORM框架，数据库基于SQLite，使用起来很方便，不需要自己写SQL语句、控制并发和事务等等，其他常见的数据库框架如：Realm、DBFlow等等，使用起来也很方便，但他们的初始化，尤其是需要升级、迁移数据时，往往会带来不小的CPU和I/O开销，一旦数据量比较多（比如：很长时间的聊天记录、浏览器浏览历史记录等），往往都需要专门一个界面来告知用户：APP正在做数据处理工作。所以，如果为了提高APP启动速度，避免在APP启动时做数据库的耗时任务，很有必要！

• 解决方案：

  必要数据避免使用数据库：如果首屏的展示内容需要根据配置来决定，那么干脆放弃数据库存储和读取，直接放在文件、SharedPreference里面，特别是多组键值对的读取，如果使用数据库，在除过初始化占用的时间以后，可能还需要30~50ms来完成（因为需要多次读取），而如果存在SharedPreference中，即使是转换成JSON并解析，可能也就在10ms之内

  数据库预先异步初始化：使用greenDAO时，预先初始化很有必要，可以保证在第一次读取数据库时，不占用主线程资源，防止拖慢启动速度，具体做法如下：

  // Application
  override fun onCreate() {
      super.onCreate()
      // 使用Anko提供的异步工作协程，或者自行创建一个并发线程池
      doAsync {
          DbManager.daoSession   // 获取一次greenDao的DaoSession实例化对象即可
      }
  }
  
  // DBManager（数据库相关单例）
  object DbManager {
  
      // greenDAO的DaoMaster，用来初始化数据库并建立连接
      private val daoMaster: DaoMaster by lazy {
          val openHelper = DaoMaster.OpenHelper(ContextUtils.getApplicationContext(), "Test.db")
          DaoMaster(openHelper.writableDatabase)
      }
  
      // 具体的数据库会话
      val daoSession: DaoSession by lazy {
          daoMaster.newSession()
      }
  }

View和主题

View层级

主要在于首屏/Splash页的Layout布局层次过深，导致View在渲染时，递归加深，消耗过多的CPU和内存资源，阻塞主线程，所以最根本的思路就是解决层级问题，检查一个App的View层级，可以使用Android Studio自带的Layout Inspector工具，如图：

在选择了需要检查的进程及Window（Dialog可能会创建新的Window，但显示的Activity是同一个）以后，就可以看到Android Studio自动进行的Capture的内容了

根据左边View层级显示的内容，分析不必要的嵌套布局，通过改造，即可对View层级进行优化

除了根据上面的方法分析层级以外，可以使用Google最新推出的ConstraintLayout，官网链接：ConstraintLayout

ConstraintLayout采用的约束布局概念，类似于iOS的AutoLayout，但使用起来，远比AutoLayout方便、强大，个人感觉吸取了RelativeLayout的方便、FrameLayout的灵活、LinearLayout的高效等特点，通过控件见相互的约束控制，可以构建出近乎平面的布局，这样就可以减少布局层级，只用ConstraintLayout一层Layout实现复杂的UI布局，非常值得学习和使用！

如果分别使用RelativeLayout、FrameLayout、LinearLayout和ConstraintLayout构建一个复杂的布局，或许，ConstraintLayout，就要比其他几种布局快50~100ms！

App主题

我们可以做个实验，使用以下几种主题，看看APP的启动速度（以ActivityManager的Log为准）：

@android:style/Theme.NoTitleBar.Fullscreen

@android:style/Theme.Black

默认（根据操作系统自动选择）

其中，MainActivity的根布局是一个空的LinearLayout，将App杀死冷启动5，取平均时间

Black

平均启动时间：160ms

FullScreen

平均启动时间：126.8ms

默认：

平均启动时间：174.8ms

可以得出一个结论：使用一个没有ActionBar的主题，比较快，而如果连StatusBar也去掉了，速度最快！

原因是这样的，启动一个Activity的时候，系统会创建包含一个DecorView的Window，而StatusBar也好，ActionBar也好，都是这个View中的子元素，多了一个View，当然多了一层布局，肯定是耗时的

所以，如果想提高APP的启动速度，尤其是使用Splash的App，务必将第一个Activity的主题设为FullScreen的，这样能有效提高启动速度

进一步优化

某些APP，如：微博，能够做到点了图标就立即做出响应，显示出它的Splash页，如下图：

而像一些没有Splash页的APP就不行，要么是点了桌面Icon以后没反应，过一会儿出主界面，要么是点了以后白屏一会儿才出主界面（在Android 4.4上由于MultiDex等问题特别明显）

这是因为微博这样有Splash页的APP，其Splash页在使用了FullScreen主题以后，又将主题的Background进行了处理，使得Splash在启动时根本没有加载实际的View，而仅仅是加载了主题，待Activity初始化完成以后，再渲染广告位等View，这样就避免了白屏和空屏的等待时常，让用户感觉到启动速度快，我们来看一下微博在启动过程中View的变化

从上面的录屏GIF中，可以看到：当微博启动时，并没有实际的View布局，而是一整个Layer，过了一会儿，Slogan和Logo的ImageView布局才以渐现动画的方式逐渐加载出来，后面继续加载广告位的Layout

这么做的理由很简单，为了让用户感觉到快！

apktool一下微博的apk，可以发现微博对首页的主题背景，使用了一个drawable来实现

<!-- styles.xml -->
<style name="NormalSplash" parent="@android:style/Theme">
    <item name="android:windowBackground">@drawable/welcome_layler_drawable</item>
    <item name="android:windowNoTitle">true</item>
    <item name="android:windowContentOverlay">@null</item>
    <item name="android:scrollbarThumbVertical">@drawable/global_scroll_thumb</item>
    <item name="android:windowAnimationStyle">@style/MyAnimationActivity</item>
</style>

<!-- welcome_layler_drawable.xml -->
<?xml version="1.0" encoding="utf-8"?>
<layer-list
xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:id="@id/welcome_background" android:drawable="@drawable/welcome_android" />
    <item android:bottom="@dimen/login_icon_padding_bottom">
        <bitmap android:gravity="bottom|center" android:src="@drawable/welcome_android_logo" />
    </item>
    <item android:top="@dimen/splash_slogan_margin_top">
        <bitmap android:gravity="center|top" android:src="@drawable/welcome_android_slogan" />
    </item>
    <item android:top="20.0dip" android:right="20.0dip">
        <bitmap android:gravity="center|right|top" android:src="@drawable/channel_logo" />
    </item>
</layer-list>

由此可见，使用layer-list的形式，可以使一系列的Bitmap按照类似View布局的形式来排布，通过将生成的drawable设置为background的形式，最终并不会生成任何View，极大程度减小View绘制占用的时间，提升启动速度！

通过实验，发现市面上很多的APP（高德地图、大众点评、百度地图、ofo小黄车等）都是采取了类似的方式，通过设置一个FullScreen主题的Activity，并设置background为和Splash布局类似的形式，能够做到点下图标的即刻，展现界面

对于多线程的思考

在App启动时，为了加快启动速度，通常会使用多线程手段来并行执行任务，充分发挥多核CPU的优势，提高运算效率。此方法固然能够对启动速度的优化，起到一定作用，但实际开发中，有以下几点值得深思：

并发的线程数，多少合适？（效率高但不至于阻塞）

频繁切换线程，是否带来负面影响？（频繁地从主线程扔进辅助线程操作再将结果抛回来会不会比直接执行更慢）

何时并行？何时串行？（有的任务能只能串，有的任务可以并行）

这个时候，拿Android经典的AsyncTask类来说事，再合适不过了！

private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
// We want at least 2 threads and at most 4 threads in the core pool,
// preferring to have 1 less than the CPU count to avoid saturating
// the CPU with background work
private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1;

上面的代码是AsyncTask确定线程池数量的部分，其中，核心执行池保证最少2个线程，最多不超过CPU可用核数-1，最大线程池数量为CPU核数的2倍+1

这样配置线程池的目的很简单：防止并发过大，导致CPU阻塞，影响效率

而AsyncTask从Android 3.0开始，就改为串行执行了，实际上也是为了防止并发过大，导致任务抢夺CPU时间片，造成阻塞，或者错误

这样做，也是为了让有前后依赖关系的任务按照我们希望的顺序执行，以便控制数据流程，防止造成不一致的情况，导致Crash或数据错误

虽然AsyncTask功能强大，但经常由于使用不当，造成内存泄露等问题，而且代码量比较多，所以在实际使用过程中，一般都使用自行封装的任务队列，更轻量，这样便于在需要的时候，让任务串行执行，以免造成过高的开销，使得速度不升反降

这里贴一段轻量串行队列的实现代码，可以在需要的时候进行参考：

package com.xiyoumobile.kit.task

import android.os.Handler
import android.os.Looper
import android.os.Message
import java.util.concurrent.Executor
import java.util.concurrent.Executors
import java.util.concurrent.LinkedBlockingQueue

/**
* 加入到串行工作队列中，并执行
*/
fun dispatchSerialWork(task: (() -> Unit)): Runnable {
    val runnable = Runnable {
        task()
    }
    addSerialTask(runnable)
    return runnable
}

/**
* 加入到主线程队列中，并执行
*/
fun dispatchMainLoopWork(task: (() -> Unit)): Runnable {
    val runnable = object : MainTask {
        override fun run() {
            task()
        }
    }
    val msg = Message()
    msg.obj = runnable
    msg.what = runnable.hashCode()
    MAIN_HANDLER.sendMessage(msg)
    return runnable
}

private val BACKGROUND_SERIAL_EXECUTOR = BackgroundSerialExecutor()

private fun addSerialTask(runnable: Runnable) {
    BACKGROUND_SERIAL_EXECUTOR.execute(runnable)
}

private class BackgroundSerialExecutor : Executor {
    private val tasks = LinkedBlockingQueue<Runnable>()
    private val executor = Executors.newSingleThreadExecutor()
    private var active: Runnable? = null

    @Synchronized
    override fun execute(r: Runnable) {
        tasks.offer(Runnable {
            try {
                r.run()
            } finally {
                scheduleNext()
            }
        })
        if (active == null) {
            scheduleNext()
        }
    }

    @Synchronized
    private fun scheduleNext() {
        active = tasks.poll()
        if (active != null) {
            executor.execute(active)
        }
    }
}

private val MAIN_HANDLER = MainLooperHandler()

private class MainLooperHandler : Handler(Looper.getMainLooper()) {

    override fun handleMessage(msg: Message?) {
        super.handleMessage(msg)
        if (msg?.obj is MainTask) {
            (msg.obj as MainTask).run()
        }
    }
}

private interface MainTask : Runnable

其次，可以配合Kotlin的协程doAsync进行后台并发运行，其内部也使用了Executor，但基于更轻量的协程操作，开销更小，适合做一些需要并发的操作，但不可随意使用，防止阻塞

总结

在APP功能日益增加和用户体验不断改良的今天，APP启动速度，已然成为影响用户体验的第一道门槛。所谓快，其实是在用户感官上的一种反应，如果能够使用以上的手段对APP的启动速度优化，虽然实际上启动时的总操作量可能并没有真正减少，但经过合理的先后顺序安排，可以使得某些不必要的任务，延后再执行，起到在APP启动时，更轻量、更灵敏的作用，这样能够比较快的响应用户从Launcher点击Icon的操作，提升用户体验，让用户感觉到『快』。