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
优化的步骤:
- 实现
Initializer
接口,完成初始化工作和依赖配置 - 删掉原有的
<provider>
标签和 ContentProvider - 在
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