程序员徐公

微信公众号：【徐公】

0%

Android 启动优化（七） - JetPack App Startup 使用及源码浅析

发表于 更新于
本文字数： 12k 阅读时长 ≈ 11 分钟
Android 启动优化（七） - JetPack App Startup 使用及源码浅析

本文收录于 https://github.com/gdutxiaoxu/AndroidGuide 「Android学习+面试指南」一份涵盖大部分 Android 程序员所需要掌握的核心知识。准备 Android 面试，首选 AndroidGuide！微信公众号：程序员徐公

前言

前一阵子，写了几篇 Android 启动优化的文章，主要是从两个方面论述的。

  1. Application 多线程异步加载，以及怎么解决多线程任务依赖的问题
  2. 首页布局优化，从常规的布局嵌套优化到渐进式加载，再到异步加载。

Android 启动优化（一） - 有向无环图

Android 启动优化（二） - 拓扑排序的原理以及解题思路

Android 启动优化（三）- AnchorTask 开源了

Android 启动优化（四）- AnchorTask 是怎么实现的

Android 启动优化（五）- AnchorTask 1.0.0 版本正式发布了

Android 启动优化（六）- 深入理解布局优化

发布在掘金之后，几篇文章都被推荐上了掘金首页，深得大家的喜欢，阅读量也挺不错的。

有不少公众号粉丝在后台问我 JetPack App Startup 是什么，跟我开源的 AnchorTask 有什么区别？

今天，就让我们来聊一聊 JetPack App Startup。

目录大概是这样的

1 什么是 JetPack App Startup

2 JetPack App Startup 能解决什么问题

3 JetPack App Startup 基本使用

4 JetPack App Startup 进阶使用

5 JetPack App Startup 源码浅析

6 小结

什么是 JetPack App Startup

我们先来看一下官方的解释，官方地址：https://developer.android.com/topic/libraries/app-startup

The App Startup library provides a straightforward, performant way to initialize components at application startup. Both library developers and app developers can use App Startup to streamline startup sequences and explicitly set the order of initialization.

Instead of defining separate content providers for each component you need to initialize, App Startup allows you to define component initializers that share a single content provider. This can significantly improve app startup time.

翻译过来就是：

  1. App Startup 这个库提供了一个组件，可以在应用程序启动的时候初始化。
  2. 开发人员可以使用这个组件精简启动序列和显式地设置初始化的顺序。 　
  3. 我们不需要为每个组件定义单独的 ContentProvider,App Startup 允许您定义的所有组件化共享一个内容提供者。这样可以极大地减少高应用程序的启动时间

JetPack App Startup 能解决什么问题

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

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

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

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

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

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

1
2
3
4
5
6
7
8
<application ...>

    <provider
        android:name=".xxSDkProvider"
        android:authorities="${applicationId}.xxSDkProvider"
        android:exported="false" />

</application>
1
2
3
4
5
6
7
8
9
10
11
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 文件添加依赖

1
2
3
dependencies {
    implementation "androidx.startup:startup-runtime:1.0.0"
}

第二步：自定义实现 Initializer 类

主要有两个方法

  1. T create(@NonNull Context context) 初始化一个组件，返回给 Application
  2. List<Class<? extends Initializer<?>>> dependencies() 当前的 Initializer 依赖于哪些 Initializers，通过这个可以确定先后启动的顺序

我们以官方的例子来讲解

1
2
3
4
5
6
7
8
9
10
11
12
// Initializes WorkManager.
class WorkManagerInitializer : Initializer<WorkManager> {
    override fun create(context: Context): WorkManager {
        val configuration = Configuration.Builder().build()
        WorkManager.initialize(context, configuration)
        return WorkManager.getInstance(context)
    }
    override fun dependencies(): List<Class<out Initializer<*>>> {
        // No dependencies on other libraries.
        return emptyList()
    }
}

WorkManagerInitializer 返回一个 WorkManager，它不需要依赖于其他的 Initializer，直接返回 emptyList() 即可。

如果需要依赖其他的 Initializer，重写 dependencies 方法，返回即可。如下面的 ExampleLoggerInitializer 依赖于 WorkManagerInitializer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Initializes ExampleLogger.
class ExampleLoggerInitializer : Initializer<ExampleLogger> {
    override fun create(context: Context): ExampleLogger {
        // WorkManager.getInstance() is non-null only after
        // WorkManager is initialized.
        return ExampleLogger(WorkManager.getInstance(context))
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        // Defines a dependency on WorkManagerInitializer so it can be
        // initialized after WorkManager is initialized.
        return listOf(WorkManagerInitializer::class.java)
    }
}

class  ExampleLogger(val workManager: WorkManager){

}

第三步：在 AndroidManifest 里面配置自定义的 InitializationProvider

1
2
3
4
5
6
7
8
9
<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <!-- This entry makes ExampleLoggerInitializer discoverable. -->
    <meta-data  android:name="com.xj.anchortask.appstartup.ExampleLoggerInitializer"
        android:value="androidx.startup" />
</provider>

它是有固定格式的，配置者只需要配置 meta-data 中的 name 即可。
android:name="com.xj.anchortask.appstartup.ExampleLoggerInitializer" 这里的 name 是我们自定义的 Initializer 全路径。

程序运行跑起来，可以看到以下输出结果，符合我们的预期

2021-04-17 17:48:42.049 28059-28059/com.xj.anchortask I/AnchorTaskApplication: attachBaseContext:
2021-04-17 17:48:42.077 28059-28059/com.xj.anchortask I/AnchorTaskApplication: create: WorkManagerInitializer init
2021-04-17 17:48:42.077 28059-28059/com.xj.anchortask I/AnchorTaskApplication: create: ExampleLoggerInitializer init
2021-04-17 17:48:42.084 28059-28059/com.xj.anchortask I/AnchorTaskApplication: onCreate:

AppStartUp 进阶使用

手动初始化

上面我们讲解了 AppStartUp 的基本使用步骤，如果我们不像在 Application onCreate 之前执行我们的 ExampleLoggerInitializer，要怎么使用呢？

其实很简单，

  1. 第一步，在 AndroidManifest InitializationProvider 中移除 移除 <meta-data 标签
  2. 在代码中调用 AppInitializer initializeComponent 方法初始化
1
2
3
4
5
6
7
<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
  
</provider>
1
AppInitializer.getInstance(context).initializeComponent(ExampleLoggerInitializer::class.java)

App start up 源码分析

我们首先来看一下他的结构，只有简单的几个类

Initializer 这个接口就没有必要说了，很简单，只有两个方法。

InitializationProvider 继承了 ContentProvider，借助了 ContentProvider 会在 Application onCreate 之前执行的特点。来执行一些初始化操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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;
    }
    
    ----
    
}

我们可以看到在 onCreate 方法中调用 AppInitializer discoverAndInitialize 方法进行初始化。

  1. 找到 AndroidManifest InitializationProvider 下的 meta 便签
  2. 判断 meta 便签下 value 的值是不是 androidx.startup
  3. 判断是不是实现 Initializer 接口，是的话，执行 doInitialize 方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
void discoverAndInitialize() {
    try {
        Trace.beginSection(SECTION_NAME);
        ComponentName provider = new ComponentName(mContext.getPackageName(),
                InitializationProvider.class.getName());
        ProviderInfo providerInfo = mContext.getPackageManager()
                .getProviderInfo(provider, GET_META_DATA);
        Bundle metadata = providerInfo.metaData;
        String startup = mContext.getString(R.string.androidx_startup);
        // 找到 metadata 标签
        if (metadata != null) {
            Set<Class<?>> initializing = new HashSet<>();
            Set<String> keys = metadata.keySet();
            for (String key : keys) {
                String value = metadata.getString(key, null);
                // 判断 value 的值是不是 androidx.startup
                // 判断是不是实现了 Initializer 接口，是的话，反射初始化
                if (startup.equals(value)) {
                    Class<?> clazz = Class.forName(key);
                    if (Initializer.class.isAssignableFrom(clazz)) {
                        Class<? extends Initializer<?>> component =
                                (Class<? extends Initializer<?>>) clazz;
                        mDiscovered.add(component);
                        if (StartupLogger.DEBUG) {
                            StartupLogger.i(String.format("Discovered %s", key));
                        }
                        doInitialize(component, initializing);
                    }
                }
            }
        }
    } catch (PackageManager.NameNotFoundException | ClassNotFoundException exception) {
        throw new StartupException(exception);
    } finally {
        Trace.endSection();
    }
}


doInitialize 方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<T> T doInitialize(
        @NonNull Class<? extends Initializer<?>> component,
        @NonNull Set<Class<?>> initializing) {
    synchronized (sLock) {
        boolean isTracingEnabled = Trace.isEnabled();
        try {
            if (isTracingEnabled) {
                // Use the simpleName here because section names would get too big otherwise.
                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;
            if (!mInitialized.containsKey(component)) {
                initializing.add(component);
                try {
                    Object instance = component.getDeclaredConstructor().newInstance();
                    Initializer<?> initializer = (Initializer<?>) instance;
                    List<Class<? extends Initializer<?>>> dependencies =
                            initializer.dependencies();

                    if (!dependencies.isEmpty()) {
                        for (Class<? extends Initializer<?>> clazz : dependencies) {
                            if (!mInitialized.containsKey(clazz)) {
                                doInitialize(clazz, initializing);
                            }
                        }
                    }
                    if (StartupLogger.DEBUG) {
                        StartupLogger.i(String.format("Initializing %s", component.getName()));
                    }
                    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();
        }
    }
}


可以看到在执行初始化的时候，先判断了是否有依赖项，有的话先执行依赖项的初始化

小结

  • App start up，我觉得他的设计初衷应该是为了收拢 ContentProvider，实际上对启动优化的帮助不是很大。
  • 如果你的项目都是同步初始化的话，并且使用到了多个ContentProvider，App Startup可能有一定的优化空间，毕竟统一到了一个ContentProvider中，同时支持了简单的顺序依赖。
  • ContentProvider 初始化的这个思想，目前有挺多 SDK 这么做的，像 FaceBook 广告 SDK，友盟 SDk 等。我们在启动优化的时候，是不是可以去掉相应的 ContentProvider，减少创建 Provider 的时间
  • 实际项目中 启动优化，大多数啊都会使用多线程异步加载，这时候 App start up 就显得很鸡肋了，没用

参考博客：
Jetpack新成员，App Startup一篇就懂

本文收录于 https://github.com/gdutxiaoxu/AndroidGuide 「Android学习+面试指南」一份涵盖大部分 Android 程序员所需要掌握的核心知识。准备 Android 面试，首选 AndroidGuide！微信公众号：程序员徐公