前言
- 2020 年 10 月 28 日，JetPack | App Startup 1.0.0 终于迎来正式发布，正好最近在总结组件化架构专题，所以也专门学习下 App Startup 的工作原理；
- 在这篇文章里，我将带你总结 App Startup 的使用方法 & 实现原理 & 源码分析。如果能帮上忙，请务必点赞加关注，这真的对我非常重要。
相关文章
- 《Android | 使用 ContentProvider 无侵入获取 Context》
- 《Android | 一个进程有多少个 Context 对象（答对的不多）》
- 《Android | 食之无味！App Startup 可能比你想象中要简单》
目录
1. 为什么要使用 App Startup?
这一节，我们来讨论为什么要使用 App Startup ，也就是 App Startup 解决了什么问题。
在我之前写过的一篇文章里，我曾经讲过一种基于 ContentProvider 启动机制实现的无侵入获取 Contex 的方法：《Android | 使用 ContentProvider 无侵入获取 Context》。在这里我简单复述一下：
- 1、在二方库或三方库中，经常需要获取 Context 进行初始化；
- 2、因为 ContentProvider 会在应用启动的时候初始化，所以很多库都利用了 ContentProvider 的启动机制，在
Application#onCreate()中进行初始化，例如 LeakCanary 2.4：
AppWatcherInstaller.java
internal sealed class AppWatcherInstaller : ContentProvider() {
internal class MainProcess : AppWatcherInstaller()
internal class LeakCanaryProcess : AppWatcherInstaller()
override fun onCreate(): Boolean {
val application = context!!.applicationContext as Application
AppWatcher.manualInstall(application)
return true
}
// 其他方法直接 return
}
- 3、这种做法的风险是 ContentProvider 过多，启动过多的 ContentProvider 会增加应用的启动时间。
- 4、AppStartup 的做法是：合并所有用于初始化的ContentProvider ，减少创建 ContentProvider，并提供全局管理。
2. 使用步骤
这一节，我们来总结 App Startup 的使用步骤，依赖如下：
build.gradle
implementation "androidx.startup:startup-runtime:1.0.0"
2.1 为组件实现 Initializer 接口
Initializer接口是 Startup 封装的组件接口，用于指定组件的初始化逻辑和初始化顺序（也就是依赖关系）。
Initializer.java
public interface Initializer<T> {
1、初始化操作，返回的初始化结果将被缓存
@NonNull
T create(@NonNull Context context);
2、依赖关系，返回值是一个依赖组件的列表
@NonNull
List<Class<? extends Initializer<?>>> dependencies();
}
- 1、
create(...)初始化操作： 返回的初始化结果将被缓存，其中context参数是 Application； - 2、
dependencies()依赖关系： 返回值是一个依赖组件的列表，如果不需要依赖于其它组件，返回一个空列表。App Startup 在初始化当前组件时，会保证所依赖的组件已经完成初始化。
2.2 自动初始化
前面提到，App Startup 合并所有用于初始化的 ContentProvider，合并后的 ContentProvider 就是 InitializationProvider，我们需要在AndroidManifest中进行声明，例如：
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
android:exported="false"
tools:node="merge">
<meta-data
android:name="com.example.ExampleLoggerInitializer"
android:value="androidx.startup" />
</provider>
要点如下：
- 1、组件名必须是
androidx.startup.InitializationProvider； - 2、需要声明
android:exported="false"，以限制其他应用访问此组件； - 3、要求
android:authorities在整个手机唯一，通常使用${applicationId}作为前缀； - 4、需要声明
tools:node="merge"，确保manifest merger tool能够正确解析冲突的节点； - 5、meta-data
name为组件的 Initializer 实现类全限定名，value为androidx.startup。
提示： 为什么要将
androidx.startup设置为value，而不是name？因为键值对中，name是唯一的，而value是允许重复的。
关于AndroidManifest中声明组件后，App Startup 是如何自动执行初始化的，我在 第 3 节说。
2.3 手动初始化
在组件需要进行懒加载时（耗时任务），可以进行手动初始化。需要手动初始化的 Initializer 不需要在AndroidManifest中进行声明，也不应该被其它组件依赖。调用以下方即可进行手动初始化：
AppInitializer.getInstance(context)
.initializeComponent(ExampleLoggerInitializer::class.java)
需要注意的是，App Startup 中会缓存初始化后的结果，重复调用initializeComponent()不会导致重复初始化。关于 App Startup 手动执行初始化部分的源码分析，我在 第 3 节说。
2.4 取消自动初始化
假如有些库已经使用 第 2.2 节 的方法配置了自动初始化，而我们又希望进行懒加载时，就需要利用manifest merger tool的合并规则来移除这个库对应的 Initializer。具体如下：
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
android:exported="false"
tools:node="merge">
<meta-data
android:name="com.example.ExampleLoggerInitializer"
tools:node="remove" />
</provider>
2.5 禁止自动初始化
假如需要禁止 App Startup 自动初始化，同样也需要利用manifest merger tool的合并规则：
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
tools:node="remove" />
3. 源码分析
3.1 InitializationProvider 分析
前面我们提到，在AndroidManifest文件中配置的组件名必须为androidx.startup.InitializationProvider，现在我们来看这个类的源码：
InitializationProvider.java
已简化
public final class InitializationProvider extends ContentProvider {
@Override
public boolean onCreate() {
Context context = getContext();
if (context != null) {
初始化
AppInitializer.getInstance(context).discoverAndInitialize();
} else {
throw new StartupException("Context cannot be null");
}
return true;
}
@Override
public Cursor query(...) {
throw new IllegalStateException("Not allowed.");
}
@Override
public String getType(...) {
throw new IllegalStateException("Not allowed.");
}
@Nullable
@Override
public Uri insert(...) {
throw new IllegalStateException("Not allowed.");
}
@Override
public int delete(...) {
throw new IllegalStateException("Not allowed.");
}
@Override
public int update(...) {
throw new IllegalStateException("Not allowed.");
}
}
可以看到：
- 1、
InitializationProvider其实也是利用了 ContentProvider 的启动机制，在ContentProvider#onCreate(...)中执行初始化； - 2、由于 ContentProvider 的其他方法是没有意义的，所以都抛出了
IllegalStateException。
3.2 自动初始化源码分析
从一节可以看到，App Startup 在 ContentProvider 中调用了AppInitializer#discoverAndInitialize()执行自动初始化。AppInitializer是 App StartUp 框架的核心类，整个 App Startup 框架的代码其实非常少，其中很大部分核心代码都在 AppInitializer 类中。
AppInitializer.java
final Set<Class<? extends Initializer<?>>> mDiscovered;
已简化
void discoverAndInitialize() {
1、获取 androidx.startup.InitializationProvider 组件信息
ComponentName provider = new ComponentName(mContext.getPackageName(), InitializationProvider.class.getName());
ProviderInfo providerInfo = mContext.getPackageManager().getProviderInfo(provider, GET_META_DATA);
2、androidx.startup 字符串
String startup = mContext.getString(R.string.androidx_startup);
3、获取组件信息中的 meta-data 数据
Bundle metadata = providerInfo.metaData;
4、遍历 meta-data 数据
if (metadata != null) {
Set<Class<?>> initializing = new HashSet<>();
Set<String> keys = metadata.keySet();
for (String key : keys) {
String value = metadata.getString(key, null);
4.1 判断 meta-data 数据中，value 为 androidx.startup 的键值对
if (startup.equals(value)) {
Class<?> clazz = Class.forName(key);
4.2 检查指定的类是 Initializer 接口的实现类
if (Initializer.class.isAssignableFrom(clazz)) {
Class<? extends Initializer<?>> component = (Class<? extends Initializer<?>>) clazz;
4.3 将 Class 添加到 mDiscovered Set 中
mDiscovered.add(component);
4.4 初始化此组件
doInitialize(component, initializing);
}
}
}
}
}
-> 4.3 mDiscovered 用于判断组件是否已经自动启动
public boolean isEagerlyInitialized(@NonNull Class<? extends Initializer<?>> component) {
return mDiscovered.contains(component);
}
上面的代码已经非常简化了，主要关注以下几点：
- 1、获取
androidx.startup.InitializationProvider组件信息（在各个 Module 中声明的组件信息，会在manifest merger tool的处理下合并）； - 2、
androidx.startup字符串 - 3、获取组件信息中的 meta-data 数据
- 4、遍历 meta-data 数据
- 4.1 判断 meta-data 数据中，value 为 androidx.startup 的键值对
- 4.2 检查指定的类是 Initializer 接口的实现类
- 4.3 将 Class 添加到 mDiscovered Set 中，这将用于后续 判断组件是否已经自动启动
- 4.4 初始化此组件
AppInitializer.java
private static final Object sLock = new Object();
缓存每个组件的初始化结果
final Map<Class<?>, Object> mInitialized;
-> 4.4 初始化此组件
已简化
<T> T doInitialize(Class<? extends Initializer<?>> component, Set<Class<?>> initializing) {
1、对 sLock 加锁，我后文再说。
Object result;
2、判断 initializing 中存在当前组件，说明存在循环依赖
if (initializing.contains(component)) {
String message = String.format("Cannot initialize %s. Cycle detected.", component.getName());
throw new IllegalStateException(message);
}
3、检查当前组件是否已初始化
if (!mInitialized.containsKey(component)) {
3.1 当前组件未初始化
3.1.1 记录正在初始化
initializing.add(component);
3.1.2 通过反射实例化 Initializer 接口实现类
Object instance = component.getDeclaredConstructor().newInstance();
Initializer<?> initializer = (Initializer<?>) instance;
3.1.3 遍历所依赖的组件
List<Class<? extends Initializer<?>>> dependencies = initializer.dependencies();
if (!dependencies.isEmpty()) {
for (Class<? extends Initializer<?>> clazz : dependencies) {
如果所依赖的组件未初始化，递归执行初始化
if (!mInitialized.containsKey(clazz)) {
doInitialize(clazz, initializing); 注意：这里将 initializing 作为参数传入
}
}
}
3.1.4 （到这里，所依赖的组件已经初始化完成）初始化当前组件
result = initializer.create(mContext);
3.1.5 移除正在初始化记录
initializing.remove(component);
3.1.6 缓存初始化结果
mInitialized.put(component, result);
} else {
3.2 当前组件已经初始化，直接返回
result = mInitialized.get(component);
}
return (T) result;
}
上面的代码已经非常简化了，主要关注以下几点：
- 1、对 sLock 加锁，我后文再说。
- 2、判断 initializing 中存在当前组件，说明存在循环依赖（这是因为递归初始化所依赖的组件时，会将 initializing 作为参数传入，如果 initializing 中存在当前组件，说明依赖关系形成回环，如果不抛出异常，将形成无限递归。）
- 3、检查当前组件是否已初始化，如果已经初始化过，则直接返回（3.2），否则：
- 3.1.1 记录正在初始化
- 3.1.2 通过反射实例化 Initializer 接口实现类
- 3.1.3 遍历所依赖的组件，如果所依赖的组件未初始化，递归调用
doInitialize(...)执行初始化 - 3.1.4 （到这里，所依赖的组件已经初始化完成）初始化当前组件
- 3.1.5 移除正在初始化记录
- 3.1.6 缓存初始化结果
3.3 手动初始化源码分析
现在我们来看手动初始化（懒加载）的源码分析:
AppInitializer.java
public <T> T initializeComponent(@NonNull Class<? extends Initializer<T>> component) {
调用 doInitialize(...) 方法：
return doInitialize(component, new HashSet<Class<?>>());
}
其实非常简单，就是调用上一节的doInitialize(...)执行初始化。需要注意的是，这个方法是允许在子线程调用的，换句话说，自动初始化与手动初始化是存在线程同步问题的，那么 App Startup 是如何解决的呢？
还记得我们前面有一个sLock没有说吗？其实它就是用来保证线程同步的锁：
AppInitializer.java
<T> T doInitialize(Class<? extends Initializer<?>> component, Set<Class<?>> initializing) {
1、对 sLock 加锁
synchronized (sLock) {
...
}
}
4. 总结
-
优点：
使用 App Startup 框架，可以简化启动序列并显式设置初始化依赖顺序，在简单、高效这方面，App Startup 基本满足需求。 -
不足：
App Startup 框架的不足也是因为它太简单了，提供的特性太过简单，往往并不能完美契合商业化需求。例如以下特性 App Startup 就无法满足：- 缺乏异步等待：同步等待指的是在当前线程先初始化所依赖的组件，再初始化当前组件，App Startup 是支持的，但是异步等待就不支持了。举个例子，所依赖的组件需要执行一个耗时的异步任务才能完成初始化，那么 App Startup 就无法等待异步任务返回；
- 缺乏依赖回调：当前组件所依赖的组件初始化完成后，未发出回调。
参考资料
- 《App Startup》 —— Android Developers
- 《合并多个清单文件》 —— Android Developers
- 《AndroidX: App Startup》 —— Husayn Hakeem 著
- 《Jetpack新成员，App Startup 一篇就懂》 —— 郭霖 著
- 《我为何弃用 Jetpack 的 App Startup?》 —— 午后一小憩 著
- 《更快！这才是我想要的 Android Startup 库！》 —— idisfkj 著
- 《组件化：代码隔离也难不倒组件的按序初始化》 —— leobert-lan 著
- 《从源码看 Jetpack（5）Startup 源码详解》 —— 叶志陈 著
推荐阅读
- 密码学 | Base64是加密算法吗？
- 算法面试题 | 回溯算法解题框架
- 算法面试题 | 链表问题总结
- 计算机组成原理 | Unicode 和 UTF-8是什么关系？
- 计算机网络 | 图解 DNS & HTTPDNS 原理
- Android | 带你探究 LayoutInflater 布局解析原理
- Android | View & Fragment & Window 的 getContext() 一定返回 Activity 吗？
感谢喜欢！你的点赞是对我最大的鼓励！欢迎关注彭旭锐的GitHub！
网友评论