Android模块化架构下，子模块自加载方案

Android模块化架构下，子模块自加载方案！

背景

在 Android 模块化架构中后，子Module 间相互解耦，作为独立的模块运行。如果 子Module 也需要进初始化的操作，那么该如何做呢？可能你会说，直接在 壳App Application的onCreate函数进行初始化就可以了，但这样会带来一些新的问题：

• 我们并不需要 壳App 去关注模块内部的业务，所以每个模块的初始化应该由自身管理；
• 并不是所有子模块的初始化，都需要在 Application onCreate() 时去进行加载，这样会极大影响应用的启动速度。所以每个模块的初始化应该按需加载；

常见方案及优缺点

1、ContentProvider

实现原理：每个 子Module 内部自定义 ContentProvider ，在应用 Application 的 onCreate 函数执行前，系统就会自动的顺序调用 子Module 的 ContentProvider 的 onCreate 函数，也就实现了 子Module 的自加载功能。例如 WorkManager 也是根据这个原理，其内部声明了 ContentProvider 来实现这种自加载方案。

优点：

• 模块间充分解耦，代码边界独立

弊端：

• ContentProvider 的启动是有性能损耗的，在子模块较多（业务逻辑较多的 App，可能会有几十个 子Module ）的情况下，有一定的性能损耗；
• 需要继承 ContentProvider 类并在 AndroidManifes 中声明，代码不够简洁和优雅；
• 无法控制初始化的时机，在应用启动时就会初始化所有的子模块，而初始化本身可能就是一件比较重的业务逻辑；

2、ARouter

实现原理：通过路由的方式，实现子Module的初始化。

定义通用IPreloadProvider接口

interface IPreloadProvider: IProvider {
   
    fun preload()
}

在主module中进行初始化调用

fun ARouter.preload(context: Context, path: String) {
   
    val preloadProvider = this.build(path