模块化架构下模块自加载方案

背景

在 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).navigation(context.applicationContext) as IPreloadProvider
    preloadProvider.preload()
}
复制代码

优点：

在多数场景下，我们都会使用 ARouter 来进行模块化设计，而ARouter天然支持这种路由调用的方法，简单好用；
代码边界独立，壳App 与子Modoule 间不需要代码上的直接依赖；

弊端：

壳App需要关心子Module 的业务，设计上有一定的耦合；
初始化的代码块容易膨胀，且各个子Module 的初始化代码均在一起，后续难以阅读和维护；

3、App Startup

优点：

App Startup 是为了解决因 App 启动时运行多个 ContentProvider 会增加 App 的启动时间的问题，使用了一个 InitializationProvider 管理多个依赖项，消除了每个库单独使用 ContentProvider 成本，减少初始化时间；
App Startup 可以自动初始化 AndroidManifest.xml 文件中 InitializationProvider 下面的声明要初始化的模块，并允许自定义模块初始化顺序；
App Startup 提供了一种延迟初始化模块的方法，减少 App 初始化时间；

弊端：

使用时需要修改 AndroidManifest 文件，使用不够简洁；
子Module 功能比较独立，且很多情况不需要即时加载（不需要在应用启动就进行初始化的动作），如果使用延迟加载的话，又需要使用代码主动执行初始化操作，那么势就必存在对应的引用。而我们的子Module 依赖其实是建议使用 runtimeonly ，减少代码上的直接依赖；
无法解决需要时加载这种需求；
加载时序是在 Application onCreate 之前，依赖的通用库此时可能并未被加载成功；

4、方案总结

所以，我们需要一个模块自加载方案，能够解决上面的问题，且能满足各种场景的需求：

代码简洁，使用方便，逻辑清晰；
子Module 的预加载或者预启动，由子Module 自身来管理，避免与其他模块的逻辑耦合；
加载时机可以控制，能做到即时加载或者懒加载，避免产生性能损耗；
不产生额外的性能损耗（可接受范围内）；

模块化自加载方案（ALoader）

方案： 每个子Module 都有自己的 ModuleApplication（虚拟Applicaiton），并定义启动模式，在应用 Application 启动时，会根据每个 ModuleApplication 的启动模式来择机调用其 onCreate() 函数，达到模块自加载的目的。

使用非常方便，仅需要在每个子Module 内创建 ModuleApplicaiton 类，继承自IModuleApplication，使用注解：ModuleApplication 定义 initMode 即可。

@ModuleApplication(initMode = InitMode.MAIN)
class LoginModuleApplication : IModuleApplication() {

    override fun onCreate(context: Context) {
        Log.v("ALoader", "Login Module onCreate")
    }
}
复制代码

InitMode：

HUNGRY： 饿汉式加载

主要用于加载时机较为严格的场景，即应用启动后，需要立刻加载该子Module 的相关配置。

IDLE： 空闲时加载

主要用于加载时机不那么严格的场景。即应用启动后，使用 idleHandler 进行初始化，达到空闲时加载的目的。

LAZY： 懒汉式加载

主要用于按需加载的场景。即应用启动后，不进行该子Module 的初始化操作，待该子Module 的 Activity 、 Service 或者相关逻辑执行时，才进行该子Module 的初始化工作，保证功能的正常运行。

自加载方案设计思路

借鉴了ARouter的实现原理，模块自加载方案的核心思想是：通过Apt技术，生成 InitMode(初始化时机) 和 被注解(@ModuleApplication)的组件类 的映射关系的类（ALoaderCore），利用这个保存了映射关系的类，ALoader根据 InitMode 寻找到目标类，执行其onCreate() 函数。该框架的核心是利用 apt 生成的映射关系。

1、如何提高ALoader的初始化速度

利用缓存和 Gradle 插件，来提升映射类的查找速度，实现高性能的初始化。

2、如何实现ALoader懒加载的效果

对于子Module 懒加载的实现，最重要的是如何识别到该子Module 开始启动，并在此之前进行初始化的操作。针对于多数的业务场景来讲，子Module 的启动通常是伴随着四大组件（Activity、Service、ContentProvider、BroadcastReceiver）的启动，而我们可以通过 Hook 技术来实现对四大组件启动的感知，通过包名的匹配来识别到是哪个子Module 开始启动。以 Activity 和 Service 为例：

    fun hookActivityThreadHHandler() {
        val aClass = Class.forName("android.app.ActivityThread")
        val sCurrentActivityThread: Field = aClass.getDeclaredField("sCurrentActivityThread")
        sCurrentActivityThread.isAccessible = true
        val activityThread = sCurrentActivityThread.get(aClass)

        val mHField: Field = aClass.getDeclaredField("mH")
        mHField.isAccessible = true
        val mh = mHField.get(activityThread) as Handler

        val handlerClass = Class.forName("android.os.Handler")
        val mCallbackField = handlerClass.getDeclaredField("mCallback")
        mCallbackField.isAccessible = true
        mCallbackField.set(mh, ProxyHandlerCallback())
    }

    class ProxyHandlerCallback : Handler.Callback {

        override fun handleMessage(msg: Message): Boolean {
            when (msg.what) {
                LAUNCH_ACTIVITY -> {
                    // TODO: 
                }
                EXECUTE_TRANSACTION -> {
                    // TODO: 
                }
                CREATE_SERVICE -> {
                    // TODO: 
                }
            }
            return false
        }
    }
复制代码

方案不足之处和优化点

该方案的最终目的是：通过最简单的方式，实现模块的按需自加载方案。但是依然还有可以优化的地方：

App Startup 可以自定义模块初始化顺序，在ALoader方案中，是否也需要集成？
通过 Hook 技术来判断子模块的启动，可能存在兼容性问题，是否还有更优雅的方式？
是否有其他更复杂的业务场景，还没考虑到呢？

当然，对于一般的业务场景，ALoader的实现已经足够满足需要。如果有其他更好的方案，我们也可以一起探讨。