Android 组件化架构下模块自加载方案

Posted 涂程

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android 组件化架构下模块自加载方案相关的知识,希望对你有一定的参考价值。

好文推荐:
作者:少冰半糖柠檬茶

背景

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

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

常见方案及优缺点

1、ContentProvider

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

优点: 模块间充分解耦,代码边界独立

弊端

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

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()
}

优点

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

弊端

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

3、App Startup

优点

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

弊端

  1. 使用时需要修改 AndroidManifest 文件,使用不够简洁;
  2. 子Module 功能比较独立,且很多情况不需要即时加载(不需要在应用启动就进行初始化的动作),如果使用延迟加载的话,又需要使用代码主动执行初始化操作,那么势就必存在对应的引用。而我们的 子Module 依赖其实是建议使用 runtimeonly ,减少代码上的直接依赖;
  3. 无法解决需要时加载这种需求;
  4. 加载时序是在 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
        }
    }

方案不足之处和优化点

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

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

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

以上是关于Android 组件化架构下模块自加载方案的主要内容,如果未能解决你的问题,请参考以下文章

导航架构组件 - 对话框片段

关于android导航架构组件的问题

如何在片段 xml 中使用自定义组件?

如何使用导航架构组件修复动态功能模块中片段的发布版本中的ClassNotFoundException?

Android组件化开发实践

使用导航架构组件添加(而不是替换)片段