关于android:我为何弃用Jetpack的App-Startup

前言

最近 Jetpack 又增加了新成员App Startup，官网申明这是一个在 Android 利用启动时，针对初始化组件进行优化的依赖库。自己第一次听到后非常高兴，因为本人负责的我的项目在启动时须要初始化的货色切实是太多，而且有点横七竖八，都耦合在一起了。对于能够异步初始化的组件也没有进行异步解决，而对于曾经解决过的异步组件它们之间的依赖关系或者多个异步之后的对立逻辑解决也没有一个很好的对立标准。所以针对这种状况早就想找个计划来优化了，这次终于等到了App Startup。

然而，当我元气满满的去查看官网文档时，并没有找到料想中的后果。官网文档中只提到了能够通过一个 ContentProvider 来对立治理须要初始化的组件，同时通过 dependencies() 办法解决组件间初始化的依赖程序，而后呢？没了？等等官网你是不是漏了什么？

异步解决呢？尽管咱们能够在 create() 办法中手动创立子线程进行异步工作，但一个异步工作依赖另一个异步工作又该如何解决呢？多个异步工作实现之后，对立逻辑解决又在哪里呢？依赖工作实现后的回调又在哪里？亦或者是依赖工作实现后的告诉？

我有点不置信，所以又去查看了 App Startup 的源码，源码很简略，也就几个文件，最初发现的确只反对下面的那几个性能。

如果你的我的项目都是同步初始化的话，并且应用到了多个 ContentProvider，App Startup 可能有肯定的优化空间，毕竟对立到了一个 ContentProvider 中，同时反对了简略的程序依赖。

值得一提的是，App Startup中只提供了应用反射来获取初始化的组件实例，这对于一些没有过多依赖的初始化我的项目来说，自觉应用 App Startup 来优化是否会对启动速度进一步造成影响呢？

所以细想了一下，不禁让我想起了三国时的一个名词：鸡肋。食之无味，弃之可惜。

但最终我还是决定放弃应用它。

放弃之后有点不甘心，可能更多的是它没有解决我以后的我的项目场景。都剖析了这么多，源码都看了，总不能大功告成吧，所以本人咬咬牙再补充一点呗。

所以保持一下，就有了上面这个库，App Startup的进阶版Android Startup。

Android Startup

Android Startup 提供一种在利用启动时可能更加简略、高效的形式来初始化组件。开发人员能够应用 Android Startup 来简化启动序列，并显式地设置初始化程序与组件之间的依赖关系。
与此同时，Android Startup反对 同步与异步期待，并通过有向无环图拓扑排序的形式来保障外部依赖组件的初始化程序。

因为 Android Startup 是基于 App Startup 进行的扩大，所以它的应用形式与 App Startup 有点相似，该有的性能基本上都有，同时额定还附加其它性能。

上面是一张与 google 的 App Startup 性能比照的表格。

上面简略介绍一下 Android Startup 的应用。

增加依赖

将上面的依赖增加到 build.gradle 文件中:

dependencies {implementation 'com.rousetime.android:android-startup:1.0.1'}

依赖版本的更新信息: Release

疾速应用

android-startup 提供了两种应用形式，在应用之前须要先定义初始化的组件。

定义初始化的组件

每一个初始化的组件都须要实现 AndroidStartup<T> 抽象类，它实现了 Startup<T> 接口，它次要有以下四个形象办法：

• callCreateOnMainThread(): Boolean用来管制 create() 办法调时所在的线程，返回 true 代表在主线程执行。
• waitOnMainThread(): Boolean用来管制以后初始化的组件是否须要在主线程进行期待其实现。如果返回 true，将在主线程期待，并且阻塞主线程。
• create(): T?组件初始化办法，执行须要解决的初始化逻辑，反对返回一个 T 类型的实例。
• dependencies(): List<Class<out Startup<*>>>?返回 Startup<*> 类型的 list 汇合。用来示意以后组件在执行之前须要依赖的组件。

例如，上面定义一个 SampleFirstStartup 类来实现 AndroidStartup<String> 抽象类:

class SampleFirstStartup : AndroidStartup<String>() {override fun callCreateOnMainThread(): Boolean = true
 
    override fun waitOnMainThread(): Boolean = false
 
    override fun create(context: Context): String? {
        // todo something
        return this.javaClass.simpleName
    }
 
    override fun dependencies(): List<Class<out Startup<*>>>? {return null}
 
}

因为 SampleFirstStartup 在执行之前不须要依赖其它组件，所以它的 dependencies() 办法能够返回空，同时它会在主线程中执行。

留神：️尽管 waitOnMainThread() 返回了 false，但因为它是在主线程中执行，而主线程默认是阻塞的，所以callCreateOnMainThread() 返回 true 时，该办法设置将生效。

假如你还须要定义 SampleSecondStartup，它依赖于SampleFirstStartup。这意味着在执行SampleSecondStartup 之前 SampleFirstStartup 必须先执行结束。

class SampleSecondStartup : AndroidStartup<Boolean>() {override fun callCreateOnMainThread(): Boolean = false
 
    override fun waitOnMainThread(): Boolean = true
 
    override fun create(context: Context): Boolean {
        // 模拟执行耗时
        Thread.sleep(5000)
        return true
    }
 
    override fun dependencies(): List<Class<out Startup<*>>>? {return listOf(SampleFirstStartup::class.java)
    }
 
}

在 dependencies() 办法中返回了 SampleFirstStartup，所以它能保障SampleFirstStartup 优先执行结束。
它会在子线程中执行，但因为 waitOnMainThread() 返回了true，所以主线程会阻塞期待直到它执行结束。

例如，你还定义了 SampleThirdStartup 与 SampleFourthStartup

Manifest 中主动配置

第一种初始化办法是在 Manifest 中进行主动配置。

在 Android Startup 中提供了 StartupProvider 类，它是一个非凡的 content provider，提供自动识别在 manifest 中配置的初始化组件。
为了让其可能自动识别，须要在 StartupProvider 中定义 <meta-data> 标签。其中的 name 为定义的组件类，value的值对应为android.startup。

<provider
    android:name="com.rousetime.android_startup.provider.StartupProvider"
    android:authorities="${applicationId}.android_startup"
    android:exported="false">
 
    <meta-data
         android:name="com.rousetime.sample.startup.SampleFourthStartup"
        android:value="android.startup" />
 
</provider>

你不须要将 SampleFirstStartup、SampleSecondStartup 与SampleThirdStartup增加到 <meta-data> 标签中。这是因为在 SampleFourthStartup 中，它的 dependencies() 中依赖了这些组件。StartupProvider会自动识别曾经申明的组件中依赖的其它组件。

Application 中手动配置

第二种初始化办法是在 Application 进行手动配置。

手动初始化须要应用到StartupManager.Builder()。

例如，如下代码应用 StartupManager.Builder() 进行初始化配置。

class SampleApplication : Application() {override fun onCreate() {super.onCreate()
        StartupManager.Builder()
            .addStartup(SampleFirstStartup())
            .addStartup(SampleSecondStartup())
            .addStartup(SampleThirdStartup())
            .addStartup(SampleFourthStartup())
            .build(this)
            .start()
            .await()}
}

如果你开启了日志输入，而后运行我的项目之后，将会在控制台中输入通过拓扑排序优化之后的初始化组件的执行程序。

 D/StartupTrack: TopologySort result: 
    ================================================ ordering start ================================================
    order [0] Class: SampleFirstStartup => Dependencies size: 0 => callCreateOnMainThread: true => waitOnMainThread: false
    order [1] Class: SampleSecondStartup => Dependencies size: 1 => callCreateOnMainThread: false => waitOnMainThread: true
    order [2] Class: SampleThirdStartup => Dependencies size: 2 => callCreateOnMainThread: false => waitOnMainThread: false
    order [3] Class: SampleFourthStartup => Dependencies size: 3 => callCreateOnMainThread: false => waitOnMainThread: false
    ================================================ ordering end ================================================

残缺的代码实例，你能够通过查看 app 获取。

更多

可选配置

• LoggerLevel: 管制 Android Startup 中的日志输入，可选值包含LoggerLevel.NONE, LoggerLevel.ERROR and LoggerLevel.DEBUG。
• AwaitTimeout: 管制 Android Startup 中主线程的超时等待时间，即阻塞的最长工夫。

Manifest 中配置

应用这些配置，你须要定义一个类去实现 StartupProviderConfig 接口，并且实现它的对应办法。

class SampleStartupProviderConfig : StartupProviderConfig {override fun getConfig(): StartupConfig =
        StartupConfig.Builder()
            .setLoggerLevel(LoggerLevel.DEBUG)
            .setAwaitTimeout(12000L)
            .build()}

与此同时，你还须要在 manifest 中进行配置StartupProviderConfig。

<provider
     android:name="com.rousetime.android_startup.provider.StartupProvider"
    android:authorities="${applicationId}.android_startup"
    android:exported="false">
 
    <meta-data
         android:name="com.rousetime.sample.startup.SampleStartupProviderConfig"
         android:value="android.startup.provider.config" />
 
</provider>

通过下面的配置，StartupProvider会主动解析SampleStartupProviderConfig。

Application 中配置

在 Application 须要借助 StartupManager.Builder() 进行配置。

override fun onCreate() {super.onCreate()
 
    val config = StartupConfig.Builder()
        .setLoggerLevel(LoggerLevel.DEBUG)
        .setAwaitTimeout(12000L)
        .build()
 
    StartupManager.Builder()
        .setConfig(config)
        ...
        .build(this)
        .start()
        .await()}

办法

AndroidStartup

• createExecutor(): Executor: 如果定义的组件没有运行在主线程，那么能够通过该办法进行管制运行的子线程。
• onDependenciesCompleted(startup: Startup<*>, result: Any?): 该办法会在每一个依赖执行结束之后进行回调。

实战测试

AwesomeGithub 中应用了 Android Startup，优化配置的初始化工夫与组件化开发的配置注入机会，应用前与应用后工夫比照:

AwesomeGithub

AwesomeGithub 是基于 Github 的客户端，纯练习我的项目，反对组件化开发，反对账户明码与认证登陆。应用 Kotlin 语言进行开发，我的项目架构是基于 JetPack&DataBinding 的 MVVM；我的项目中应用了 Arouter、Retrofit、Coroutine、Glide、Dagger 与 Hilt 等风行开源技术。

除了 Android 原生版本，还有基于 Flutter 的跨平台版本 flutter_github。

如果你喜爱我的文章，你能够关注我的微信公众号：【Android 补给站】或者扫描下方二维码进行关注，当然你也能够间接关注以后网站的帐号。次要区别就是微信可能更办法互动。

公众号更新不会很频繁，但一旦更新必然是纯干货。