深入探索Android 启动优化（七） - JetPack App Startup 使用及源码浅析(1)

---

听了上面的介绍，是不是还有点懵？

App Startup 能减少高应用程序的启动时间，它是怎么做到的？

做过 Android 启动优化的，可能都知道，Android 的启动流程是这样的。

从 Application#attachBaseContext 到 ContentProvider#onCreate，到 Application#onCreate 再到 MainActivity#onCreate。

而 App Startup 设计的初衷，正是为了收拢 ContentProvider。有不少第三方的 SDk，为了使用者不必手动调用 SDK#init 方法，使用了 ContentProvider 这一个骚操作。

在 AndroidManifest 里面注册了自己的 xxSDkProvider，然后在 xxSDkProvider 的 onCreate 方面里面进行初始化，确实调用者不需要自己初始化了，可却增加了启动耗时，如果要作优化，还得自己剔除 ContentProvider 的初始化，值不值得，我是感觉没必要，这操作是真的骚。

<application …>

<provider

android:name=“.xxSDkProvider”

android:authorities=“${applicationId}.xxSDkProvider”

android:exported=“false” />

class XXSDKProvider : ContentProvider() {

override fun onCreate(): Boolean {

Log.d(TAG, “XXSDKProvider create()”)

XXSDK.init()

return true

}

…

}

同时，这里给做启动优化的同学提供了一种思路。打开你的 Apk，看一下 AndroidManiest 里面有多少 provider，看一下是否有这样的骚操作。如果有，改一下，说不定启动优化，一下子就减少了 100 多 毫秒。

接下来，我们来看一下 AppStartUp 怎么使用

AppStartUp 基本使用

---

简单来说，分为三步

1. gradle 文件引入App Startup 库。

2. 自定义一个用于初始化的 Initializer。

3. 将自定义 Initializer 配置到 AndroidManifest.xml 当中。

第一步，在 build.gradle 文件添加依赖

dependencies {

implementation “androidx.startup:startup-runtime:1.0.0”

}

第二步：自定义实现 Initializer 类

主要有两个方法

1. T create(@NonNull Context context) 初始化一个组件，返回给 Application

2. List<Class<? extends Initializer<?>>