Jetpack学习之 App Startup

1. 概述

紧接着 ​​Jetpack学习之 Hilt​​​ 来学习Jetpack另外一个新成员：​​App Startup​​。目前官方文档还没有翻译成中文，但勉强也能看，还有很多大神都发表了文章，毕竟是Jetpack家族，所以追新有保障。

先来说下 App Startup的官方定义：

App Startup提供了一种更加简单、高效的启动应用程序的组件。SDK开发和应用开发人员都可以使用这个组件来简化启动序列，并且设置初始化顺序。
App Startup不用你在为每一个需要初始化的组件提供 Content Provider，而是每个需要初始化的组件都共享同一个Content Provider

一句话概括就是：App Startup 提供了一个 ContentProvider 来帮助你的更快的启动App
那为啥启动要和ContentProvider挂钩呢？

1.1 背景

我们在使用别的人库或自己写的一些组件时，会在 ​​Application.onCreate()​​ 做一些初始化操作，例如：

class App : Application() {

    override fun onCreate() {
        super.onCreate()

        // 初始化LeakCanary
        LeakCanary.init(this)
        // 初始化Logger
        MyLogger.init(this)
        ..
    }
}

因为这些是全局都会使用的组件，所以它们初始化最好的地方就是在App启动的时候，代入Application的Context，在之后的使用中就不用考虑一些复杂的初始化问题了。

随着项目接入的库越来越多，onCreate要初始化的代码将会越来越多，这样会代码开始变得臃肿。

在 App 启动的时候，会找到 ​​AndroidManifest.xml​​ 中注册的所有的 ​​<provider>​​，然后执行这些 ContentProvider 的 ​​onCreate()​​方法。

一些三方库会根据这个原理，会要求你在 ​​AndroidManifest.xml​​​ 中加他们的 ContentProvider（或者他们在自己的 AndroidManifest 去加），这样他们就可以在他们自己的 ​​ContentProvider.onCreate()​​​ 中拿到上下文，进行初始化。 这样，你就不用再在 ​​Application.onCreate()​​ 中手动初始化了。

举个例子，FaceBook的SDK会让我们在AndroidManifest中注册一个provider标签：

<provider
            android:name="com.facebook.FacebookContentProvider"
            android:authorities="com.facebook.app.FacebookContentProvider{xxxx}"
            android:exported="true"/>

那么在启动App时，就回去调用 ​​FacebookContentProvider.onCreate​​ ：

public class FacebookContentProvider extends ContentProvider {
    ...
    @Override
    public boolean onCreate() {
       // 初始化工作
       ...
    }
}

1.2 ContentProvider的缺点

注册 ​​ContentProvider​​，“偷偷”进行初始化，看起来对开发者来说少写了一些代码，是一件挺好的事情。但是这种做法也是有缺点的。

它仅有一个缺点就是它是一个ContentProvider，ContentProvider是什么？ContentProvider可是四大组件，它是根启动时，会去Framework层通过​​ActivityMangaerService​​​来创建的一个组件，而且它的创建时机是放在Application之前的。
(这里附一篇ContentProvider启动流程：​​​Android深入四大组件（五）Content Provider的启动过程​​)

它太重了，减少了一行初始化代码，却增加了多余的性能开销，当很多库都这样做的话，性能消耗将会很多。来看下下面这个Google官方统计的图：

在不断加入空的 ContentProvider 组件的情况下，启动耗时会线性增加，这还是没有加上那些初始化的代码。

所以在库增多时，我宁愿在 Application 写那一行 ​​.init()​​ ，也不情愿再加 ContentProvider 了。

1.3 App Startup作用

​​App Startup​​​ 的出现，就是为了解决这一个问题。
这样再去看他的定义就很简单理解了，它能做的事情是：

• 将所有 ContentProvider 合并到一个 ContentProvider，这样可以减少 ContentProvider 的数量，间接减少启动耗时
• 可以对这些要初始化的组件排序执行

这也说明了啥？如果你的 App 或 SDK库 没有大量出现上面这种，使用 ContentProvider 来初始化的，那么 App Startup并不会降低启动耗时

2. App Startup使用

2.1 前置

因为 ​​App Startup​​​ 需要有使用到 ContentProvider 做初始化的场景，所以我们需要模拟那种使用 ContentProvider 做初始化的库。这里我选择使用官方文档中使用的 ​​WorkManager​​，在项目中导入：

dependencies {
  def work_version = "2.4.0"
    implementation "androidx.work:work-runtime:$work_version"
    implementation "androidx.work:work-runtime-ktx:$work_version"
  }

然后我们可以在 WorkManager 的jar包中找到他的 ​​AndroidManifest.xml​​​，这里面就有 ​​<provider>​​ 标签：

可以看下 ​​WorkManagerInitializer​​ 的代码：

public class WorkManagerInitializer extends ContentProvider {
    @Override
    public boolean onCreate() {
        // 初始化操作
        WorkManager.initialize(getContext(), new Configuration.Builder().build());
        return true;
    }
    ..
}

也就是说 ​​WorkManager​​ 库是典型的使用 ContentProvider 来做初始化工作的库。我们假设自己是 WorkManager 的设计者，接下来就是用 App Startup 来优化这个库。

2.2 导入App Startup

我们先来配置 App Startup，首先导入：

implementation "androidx.startup:startup-runtime:1.0.0"

2.3 使用接口

App Startup提供了一个接口 ​​Initializer<T>​​，它用于执行初始化：

public interface Initializer<T> {

    @NonNull
    T create(@NonNull Context context);
    
    @NonNull
    List<Class<? extends Initializer<?>>> dependencies();
}

该接口有两个方法：

• ​​T create(@NonNull Context context)​​​ 该方法用来做初始化的工作，就是我们做 ​​.init()​​ 的地方
• ​​List<Class<? extends Initializer<?>>> dependencies()​​​ 该组件在初始化时，需要依赖哪些组件的初始化，返回一个列表，这个列表里的组件都实现 ​​Initializer​​ 接口
  也就是说，这个方法可以用来决定初始化顺序

假如我们要将 WorkManager 写入到我们 App Startup 的启动优化项里，那我们需要给其实现这个接口:

class WorkManagerInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        // 照搬 WorkManagerInitializer 的 onCreate 代码
        WorkManager.initialize(context, Configuration.Builder().build())
    }

    override fun dependencies(): MutableList<Class<out Initializer<*>>> {
        return mutableListOf()
    }
}

我学着 WorkManager 在这里做了初始化，因为大部分的组件都是不依赖别的组件初始化的，所以 ​​dependencies()​​ 方法我返回了空列表。

2.4 配置AndroidManifest

就和注解一样，在给所有需要 ContentProvider 初始化的组件实现了 ​​Initializer​​​ 接口后，需要在 AndroidManifest 中声明 App Startup 自己的 ​​<provider>​​ 标签：

<provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="${applicationId}.androidx-startup"
            android:exported="false"
            tools:node="merge">
            <meta-data
                android:name="com.example.app_startup_demo.WorkManagerInitializer"
                android:value="androidx.startup"/>
        </provider>

上面只有 ​​<meta-data>​​ 里的name使我们可以指定的，其他的值我们都不能更改，否则 App Startup就不能运行。

这样就完成了一次启动优化啦~

2.5 延迟初始化

有些库可能不会在 App 初始化的时候就去初始化，而是要等使用的时候再去，即 延迟初始化，和kotlin的 ​​by lazy​​似的。

而 App Startup 也考虑到了这一点，只需 AndroidManifest 中加入这个：

<provider
            android:name="androidx.startup.InitializationProvider"
            ...>
            <meta-data
                android:name="com.example.app_startup_demo.WorkManagerInitializer"
                tools:node="remove"/>
        </provider>

​​tools:node="remove"​​ 说明在打包的时候会把所有 WorkManagerInitializer 全部删除掉，这样就不会在 App 启动的时候去做初始化了。

如果想要使用，则要在代码中手动使用下面代码延迟初始化：

AppInitializer.getInstance(this).initializeComponent(WorkManagerInitializer::class.java)

3. 浅析原理

3.1 清单文件解析

上面我们可以总结出让一个使用 ContentProvider 初始化的库，来用 ​​App Startup​​ 优化的步骤：

1. 实现​​Initializer​​ 接口，完成初始化工作和依赖配置
2. 删掉原有的​​<provider>​​ 标签和 ContentProvider
3. 在​​AndroidManifest.xml​​​ 中加入​​InitializationProvider​​​ 的标签，并再​​<meta-data>​​ 中填入实现了 Initializer 接口的路径名

为什么这样做就可以降低启动耗时呢？ 这边来简单的解析一下它做了什么。

其实最关键的地方还是在于它在 ​​AndroidManifest.xml​​ 文件中声明的标签，我们来分析一下里面的参数吧：

<provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="${applicationId}.androidx-startup"
            android:exported="false"
            tools:node="merge">
        </provider>

• name
  指向​​​androidx.startup.InitializationProvider​​，它是初始化执行类
• authorities
  授权方列表，没有默认值且该值必须是整个手机唯一的，所以一般会在前面加 applicationId 的前缀
• exported
  其他应用程序是否可以使用这个内容提供器，这里设置为false，表示不可以
• tools:node
  这个是XML文件的属性，它标志着该节点（即标签）的行为

可以看到 ​​tools:node="merge"​​，这个属性代表了合并相同name的节点。

举个例子，我们的项目有主项目和引用的jar包，它们都会使用用一个 name 为 ActivityOne 的 ​​Activity​​​，但是启动方式稍微有点不一样，它们都在清单文件中声明了标签： ​​<activity>​​。

这样就会出现一个问题，你两个清单文件都使用到了含有同一个 name 的标签，那么打包编译时肯定会出现问题，因为最终编译出来的 activity 的标签要是唯一的，这个地方就不知道使用哪一个。

Android提供的一种解决方式就是使用 ​​tools:node="merge"​​​，它会根据清单文件的优先级，来合并相同 name 的标签。在上面的例子中，主项目的清单文件优先级肯定是高于第三方jar包的。
下面是两个清单文件：

// 第三方jar包----低优先级清单文件
<activity android:name="com.example.ActivityOne"
    android:windowSoftInputMode="stateUnchanged">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

// 主项目----高优先级清单文件
<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    tools:node="merge">  // 这里进行节点merge，合并所有name为 com.example.ActivityOne 的 activity标签
</activity>

打包后，形成的新的标签为：

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    android:windowSoftInputMode="stateUnchanged">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

所以 ​​App Startup​​ 的共享 ContentProvider 的原理就是这个！
通过 ​​​tools:merge​​​，将所有 name 为 ​​androidx.startup.InitializationProvider​​​ 的 ​​<provider>​​ 标签进行合并。

那么在打包之后，一个应用只有一个 ContentProvider，然后执行它的 ​​onCreate()​​ 方法，我们来看下他的初始化代码。

3.2 初始化代码解析

点进 ​​InitializationProvider​​，它的 onCreate() 是这样的：

public final class InitializationProvider extends ContentProvider {
    @Override
    public boolean onCreate() {
        Context context = getContext();
        if (context != null) {
            // 1
            AppInitializer.getInstance(context).discoverAndInitialize();
        } else {
            throw new StartupException("Context cannot be null");
        }
        return true;
    }
}

注释1处，执行 ​​AppInitializer​​​ 单例的 ​​discoverAndInitialize()​​ 方法，我们点进这个方法看看。

// AppInitializer.java
    void discoverAndInitialize() {
        try {
            Trace.beginSection(SECTION_NAME);
            ComponentName provider = new ComponentName(mContext.getPackageName(),
                    InitializationProvider.class.getName());
            // 1
            ProviderInfo providerInfo = mContext.getPackageManager()
                    .getProviderInfo(provider, GET_META_DATA);
            // 2
            Bundle metadata = providerInfo.metaData;
            String startup = mContext.getString(R.string.androidx_startup);
            if (metadata != null) {
                Set<Class<?>> initializing = new HashSet<>();
                Set<String> keys = metadata.keySet();
                // 3
                for (String key : keys) {
                    String value = metadata.getString(key, null);
                    if (startup.equals(value)) {
                        Class<?> clazz = Class.forName(key);
                        if (Initializer.class.isAssignableFrom(clazz)) {
                            Class<? extends Initializer<?>> component =
                                    (Class<? extends Initializer<?>>) clazz;
                            // 4
                            mDiscovered.add(component);
                            if (StartupLogger.DEBUG) {
                                StartupLogger.i(String.format("Discovered %s", key));
                            }
                            // 5
                            doInitialize(component, initializing);
                        }
                    }
                }
            }
        } catch (PackageManager.NameNotFoundException | ClassNotFoundException exception) {
            throw new StartupException(exception);
        } finally {
            Trace.endSection();
        }
    }

这段代码不是很难，来分析一下：
注释1： 打包后，清单文件里面只有一个 InitializationProvider 的 ​​​<provider>​​​ 标签，这里代码就是拿到这个标签下的信息 ​​ProviderInfo​​

注释2： 根据注释处的对象，获取到该标签下的 ​​meta-data​​

注释3：遍历 ​​meta-data​​ ，并获取它们的 value，即类名

注释4：一直筛选，符合实现 ​​Initializer​​ 接口的类，然后放到 mDiscovered 这个 Set 中。

注释5：执行 ​​doInitialize()​​，代入注释4中筛选好的类（注意不是实例，而是 class）

这个方法就是遍历 ​​<provider>​​​ 里面的 ​​<meta-data>​​，拿到所有需要优化启动的库。

接下来看下 ​​doInitialize()​​ ：

// AppInitializer.java
    <T> T doInitialize(
            @NonNull Class<? extends Initializer<?>> component,
            @NonNull Set<Class<?>> initializing) {
        synchronized (sLock) {
            boolean isTracingEnabled = Trace.isEnabled();
            try {
                if (isTracingEnabled) {
                    Trace.beginSection(component.getSimpleName());
                }
                if (initializing.contains(component)) {
                    String message = String.format(
                            "Cannot initialize %s. Cycle detected.", component.getName()
                    );
                    throw new IllegalStateException(message);
                }
                Object result;
                // 1
                if (!mInitialized.containsKey(component)) {
                    initializing.add(component);
                    try {
                        // 2
                        Object instance = component.getDeclaredConstructor().newInstance();
                        // 3
                        Initializer<?> initializer = (Initializer<?>) instance;
                        // 4
                        List<Class<? extends Initializer<?>>> dependencies =
                                initializer.dependencies();

                        if (!dependencies.isEmpty()) {
                            // 5
                            for (Class<? extends Initializer<?>> clazz : dependencies) {
                                if (!mInitialized.containsKey(clazz)) {
                                    doInitialize(clazz, initializing);
                                }
                            }
                        }
                        if (StartupLogger.DEBUG) {
                            StartupLogger.i(String.format("Initializing %s", component.getName()));
                        }
                        // 6
                        result = initializer.create(mContext);
                        if (StartupLogger.DEBUG) {
                            StartupLogger.i(String.format("Initialized %s", component.getName()));
                        }
                        initializing.remove(component);
                        mInitialized.put(component, result);
                    } catch (Throwable throwable) {
                        throw new StartupException(throwable);
                    }
                } else {
                    result = mInitialized.get(component);
                }
                return (T) result;
            } finally {
                Trace.endSection();
            }
        }
    }

这段源码也比较好理解。
注释1：先判断该类是否已经初始化，如果没有执行初始化方法，就继续执行下面程序

注释2、3、4：拿到该类的构造函数，然后创建一个实例，执行实例的 ​​dependencies()​​ 方法，获取依赖列表。

注释5：递归执行 依赖列表里的 ​​doInitialize()​​ 方法，让这些依赖的类先初始化

注释6： 执行实例的 ​​create()​​ ，完成初始化工作。

到这里，大概就已经知道了 App Startup 的运作方式了。源码还是挺简单的

4. 总结

App Startup 的作用：

• 低层提供一个 InitializerContentProvider ， 让那些需要 ContentProvider 来初始化的组件共享这个内容提供器
• 为这些要初始化的组件提供顺序性的启动

App Startup 解决了什么：
只解决一个问题：多个使用 ContentProvider 来进行初始化的库导致的启动速度下降

App Startup使用的地方：

• 使用 ContentProvider 进行初始化的SDK库，设计者可以使用该库，让接入这个SDK库的 App 优化启动速度
• 使用 ContentProvider 进行初始化自己写的组件的 App， 但是这种情况比较少

同时满足 大量使用 这些条件的库，否则启动优化并不会很明显，如果你只有一两个、两三个这样的三方库，反而你的启动速度还会变的更慢。。

参考文章

​​官方文档：App Startup​​​​Jetpack新成员，App Startup一篇就懂​​​​Jetpack 最新成员 AndroidX App Startup 实践以及原理分析​​​​探究 | App Startup真的能减少启动耗时吗​​​​我为何弃用Jetpack的App Startup?​​​​App Startup​​