Jetpack-App Startup

Android 11系统已经来了，随之而来的是，Jetpack家族也引入了许多新的成员。

其实以后Android的更新都会逐渐采用这种模式，即特定系统相关的API会越来越少，更多的编程API是以Jetpack Library的形式提供给我们的。这样我们就不需要专门针对不同的系统版本去写很多的适配逻辑，而是统一用Jetpack提供的接口即可。Android也是在用这种方式去解决长期以来的碎片化问题。

而今年的Jetpack家族当中又加入了两名重磅的新成员，一个是Hilt，另一个是App Startup。

Hilt是一个依赖注入组件库，功能非常强大，但是由于想把依赖注入讲清楚还是一个相对比较困难的工作，我准备过段时间再好好想想怎样去写好一篇关于Hilt的文章。

本篇文章的主题是App Startup。

App Startup是一个可以用于加速App启动速度的一个库。很多人一听到可以加速App的启动速度？那这是好东西啊，迫不及待地想要将这个库引入到自己的项目当中，结果研究了半天，发现越看越不明白，怎么学着学着还和ContentProvider扯上关系了？

所以，在学习App Startup的用法之前，首先我们需要搞清楚的是，App Startup具体是用来解决什么问题的。

关注我比较久的朋友应该都知道，LitePal是由我编写并长期维护的一个Android数据库框架。这个框架可以帮助大家自动管理表的创建与升级，并提供方便的数据库操作API。

而用过LitePal的朋友一定知道，LitePal有提供一个initialize()接口，在进行所有的数据库操作之前，我们需要在自己的Application当中去调用这个接口进行初始化：

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        LitePal.initialize(this)
    }
    ...
}

为什么LitePal要求先进行初始化呢？因为Android的数据库中有需要操作都是需要依赖于Context的，在初始化的时候传入一次Context，LitePal会在内部将其保存下来，这样所以有其他数据库接口就不需要再传入Context参数了，从而让API变得更加精简。

这确实是个不错的主意，但是并不是只有LitePal想到了这一点，许多库也提供了类似的初始化接口，因此如果你在项目当中引入了非常多的第三方库，那么Application中的代码就可能会变成这个样子：

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        LitePal.initialize(this)
        AAA.initialize(this)
        BBB.initialize(this)
        CCC.initialize(this)
        DDD.initialize(this)
        EEE.initialize(this)
    }
    ...
}

这样的代码就会显得有些凌乱了对不对？随着你引用的第三方库越来越多，这种情况真的是有可能发生的。

于是，有些更加聪明的库设计者，他们想到了一种非常巧妙的办法来避免显示地调用初始化接口，而是可以自动调用初始化接口，这种办法就是借助ContentProvider。

ContentProvider我们都知道是Android四大组件之一，它的主要作用是跨应用程序共享数据。比如为什么我们可以读取到电话簿中的联系人、相册中的照片等数据，借助的都是ContentProvider。

然而这些聪明的库设计者们并没有打算使用ContentProvider来跨应用程序共享数据，只是准备使用它进行初始化而已。我们来看如下代码：

class MyProvider : ContentProvider() {

    override fun onCreate(): Boolean {
        context?.let {
            LitePal.initialize(it)
        }
        return true
    }
    ...
}

这里我定义了一个MyProvider，并让它继承自ContentProvider，然后我们在onCreate()方法中调用了LitePal的初始化接口。注意在ContentProvider中也是可以获取到Context的。

当然，继承了ContentProvider之后，我们是要重写很多个方法的，只不过其他方法在我们这个场景下完全使用不到，所以你可以在那些方法中直接抛出一个异常，或者进行空实现都是可以的。

另外不要忘记，四大组件是需要在AndroidManifest.xml文件中进行注册才可以使用的，因此记得添加如下内容：

<application ...>

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

</application>

authorities在这里并没有固定的要求，填写什么值都是可以的，但必须保证这个值在整个手机上是唯一的，所以通常会使用${applicationId}作为前缀，以防止和其他应用程序冲突。

那么，自定义的这个MyProvider它会在什么时候执行呢？我们来看一下这张流程图：

可以看到，一个应用程序的执行顺序是这个样子的。首先调用Application的attachBaseContext()方法，然后调用ContentProvider的onCreate()方法，接下来调用Application的onCreate()方法。

那么，假如LitePal在自己的库当中实现了上述的MyProvider，会发生什么情况呢？

你会发现LitePal.initialize()这个接口可以省略了，因为在MyProvider当中这个接口会被自动调用，这样在进入Application的onCreate()方法时，LitePal其实已经初始化过了。

有没有觉得这种设计方式很巧妙？它可以将库的用法进一步简化，不需要你主动去调用初始化接口，而是将这个工作在背后悄悄自动完成了。

那么有哪些库使用了这种设计方式呢？这个真的有很多了，比如说Facebook的库，Firebase的库，还有我们所熟知的WorkManager，Lifecycles等等。这些库都没有提供一个像LitePal那样的初始化接口，其实就是使用了上述的技巧。

看上去如此巧妙的技术方案，那么它有没有什么缺点呢？

有，缺点就是，ContentProvider会增加许多额外的耗时。

毕竟ContentProvider是Android四大组件之一，这个组件相对来说是比较重量级的。也就是说，本来我的初始化操作可能是一个非常轻量级的操作，依赖于ContentProvider之后就变成了一个重量级的操作了。

关于ContentProvider的耗时，Google官方也有给出一个测试结果：

这是在一台搭载Android 10系统的Pixel2手机上测试的情况。可以看到，一个空的ContentProvider大约会占用2ms的耗时，随着ContentProvider的增加，耗时也会跟着一起增加。如果你的应用程序中使用了50个ContentProvider，那么将会占用接近20ms的耗时。

注意这还只是空ContentProvider的耗时，并没有算上你在ContentProvider中执行逻辑的耗时。

这个测试结果告诉我们，虽然刚才所介绍的使用ContentProvider来进行初始化的设计方式很巧妙，但是如果每个第三方库都自己创建了一个ContentProvider，那么最终我们App的启动速度就会受到比较大的影响。

有没有办法解决这个问题呢？

有，就是使用我们今天要介绍的主题：App Startup。

我上面花了很长的篇幅来介绍App Startup具体是用来解决什么问题的，因为这部分内容才是App Startup库的核心，只有了解了它是用来解决什么问题的，才能快速掌握它的用法。不然就会像刚开始说的那样，学着学着怎么学到ContentProvider上面去了，一头雾水。

那么App Startup是如何解决这个问题的呢？它可以将所有用于初始化的ContentProvider合并成一个，从而使App的启动速度变得更快。

具体来讲，App Startup内部也创建了一个ContentProvider，并提供了一套用于初始化的标准。然后对于其他第三方库来说，你们就不需要再自己创建ContentProvider了，都按我的这套标准进行实现就行了，我可以保证你们的库在App启动之前都成功进行初始化。

了解了App Startup具体是用来解决什么问题的，以及它的实现原理，接下来我们开始学习它的用法，这部分就非常简单了。

首先要使用App Startup，我们要将这个库引入进来：

dependencies {
    implementation "androidx.startup:startup-runtime:1.0.0-alpha01"
}

接下来我们要定义一个用于执行初始化的Initializer，并实现App Startup库的Initializer接口，如下所示：

class LitePalInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        LitePal.initialize(context)
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf(OtherInitializer::class.java)
    }

}

实现Initializer接口要求重现两个方法，在create()方法中，我们去进行之前要进行的初始化操作就可以了，create()方法会把我们需要的Context参数传递进来。

dependencies()方法表示，当前的LitePalInitializer是否还依赖于其他的Initializer，如果有的话，就在这里进行配置，App Startup会保证先初始化依赖的Initializer，然后才会初始化当前的LitePalInitializer。

当然，绝大多数的情况下，我们的初始化操作都是不会依赖于其他Initializer的，所以通常直接返回一个emptyList()就可以了，如下所示：

class LitePalInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        LitePal.initialize(context)
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        return emptyList()
    }

}

定义好了Initializer之后，接下来还剩最后一步，将它配置到AndroidManifest.xml当中。但是注意，这里的配置是有比较严格的格式要求的，如下所示：

<application ...>

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

上述配置，我们能修改的地方并不多，只有meta-data中的android:name部分我们需要指定成我们自定义的Initializer的全路径类名，其他部分都是不能修改的，否则App Startup库可能会无法正常工作。

没错，App Startup库的用法就是这么简单，基本我将它总结成了三步走的操作。

引入App Startup的库。
自定义一个用于初始化的Initializer。
将自定义Initializer配置到AndroidManifest.xml当中。

这样，当App启动的时候会自动执行App Startup库中内置的ContentProvider，并在它的ContentProvider中会搜寻所有注册的Initializer，然后逐个调用它们的create()方法来进行初始化操作。

只用一个ContentProvider就可以让所有库都正常初始化，Everyone is happy。

其实到这里为止，App Startup库的知识就已经讲完了，最后再介绍一个不太常用的知识点吧：延迟初始化。

现在我们已经知道，所有的Initializer都会在App启动的时候自动执行初始化操作。但是如果我作为LitePal库的用户，就是不希望它在启动的时候自动初始化，而是想要在特定的时机手动初始化，这要怎么办呢？

首先，你得通过分析LitePal源码的方式，找到LitePal用于初始化的Initializer的全路径类名是什么，比如上述例子当中的com.example.LitePalInitializer（注意这里我只是为了讲解这个知识点而举的例子，实际上LitePal还并没有接入App Startup）。

然后，在你的项目的AndroidManifest.xml当中加入如下配置：

<application ...>

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

区别就在于，这里在LitePalInitializer的meta-data当中加入了一个tools:node="remove"的标记。

这个标记用于告诉manifest merger tool，在最后打包成APK时，将所有android:name是com.example.LitePalInitializer的meta-data节点全部删除。

这样，LitePal库在自己的AndroidManifest.xml中配置的Initializer也会被删除，既然删除了，App Startup在启动的时候肯定就无法初始化它了。

而在之后手动去初始化LitePal的代码也极其简单，如下所示：

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

将LitePalInitializer传入到initializeComponent()方法当中即可，App Startup库会按照同样的标准去调用其create()方法来执行初始化操作。

到这里为止，App Startup的功能基本就全部讲解完了。

最后如果让我总结一下的话，这个库的整体用法非常简单，但是可能并不适合所有人去使用。如果你是一个库开发者，并且使用了ContentProvider的方式来进行初始化操作，那么你应该接入App Startup，这样可以让接入你的库的App降低启动耗时。而如果你是一个App开发者，我认为使用ContentProvider来进行初始化操作的概率很低，所以可能App Startup对你来说用处并不大。

当然，考虑到业务逻辑分离的代码结构，App的开发者也可以考虑将一些原来放在Application中的初始化代码，移动到一个Initializer中去单独执行，或许可以让你的代码结构变得更加合理与清晰。

当前保存作为笔记原文地址

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 158,847评论 4赞 362
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,208评论 1赞 292
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 108,587评论 0赞 243
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,942评论 0赞 205
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,332评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,587评论 1赞 218
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,853评论 2赞 312
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,568评论 0赞 198
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,273评论 1赞 242
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2赞 246
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1赞 260
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,373评论 2赞 253
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,031评论 3赞 236
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0赞 195
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2赞 274
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2赞 269