Android组件化框架实践

2021-10-18 本文已影响0人 Henryzhu

前言

之前考虑到后续可能会参与到小包项目的开发中，因此希望利用平时的时间形成2套框架，后续新项目立项后可立即投入使用，快速上线。本文说明的是一套基于jetpack+coroutines基础上形成的一套组件化框架，本文主要描述组件化项目的通用配置和关键技术点的解决方案。

为什么要组件化

大家知道，随着项目的业务逐渐发展，业务功能越来越多，参与的开发人员也可能变更，修改合并代码容易出现冲突，于是在出现了模块化的概念，即把同一个业务板块的内容单独抽取一个module去实现，做到代码隔离。但是模块化也会带来一些新的问题，不同的模块之间为了实现数据跳转，依赖关系错综复杂，代码耦合性很强。而且最致命的是，项目迭代到一定程度，由于项目本身比较大，全量编译耗时往往非常巨大，因此引入组件化。

总结下来组件化有如下2个优点：

加快编译速度。在开发阶段，业务模块(module_xxx)可以作为application独立编译，编译速度明显加快；
明确开发人员彼此职责。明确开发人员维护模块，只需要管理和熟悉相应的module，彼此互不打扰，公共基础功能根据是否是业务相关，降级到Common层或core层，或单独封装成lib调用；
更合规。相比插件化的解决方案，组件化并没有引入动态加载Apk的功能，保证在google play等商店上线时不会出现合规性问题；

项目架构图

架构图

以上架构图是目前我完成的项目中的模块依赖关系图，各个模块承载功能说明如下：

App壳module中没有任何业务代码，只有全局Application对象的代码，和全局主题、logo等配置；
Module_main、Module_sample、Module_A、Module_B为4个业务模块，后续可根据项目中真实的模块做修改；
lib_download代表下载功能，是一个library，某个业务模块如需要直接依赖即可；
lib_common作为项目业务模块的业务公共组件，包括所有和项目界面相关的组件或基类；
lib_core代表所有与项目界面无关的组件和类库及资源，包括基类、图片加载、日志、网络请求、基础Util等
lib_fileprovider代表fileprovider的公共定义处理，common库直接依赖即可；
lib_webview代表webview页面的模块，由于业务模块基本都会跳转webview，所以直接common库去依赖；

组件化配置

在项目中的gradle.properties中添加组件化控制开关
```
#当前是否是组件化模块，false表示整体编译，true表示分模块编译
isComponentMode=false
```
在开发阶段，将此参数调整为true，即可单个模块编译打包，合并打包测试或发布时，将此参数修改为false

新增模块调试入口启动类

在module_XXX等业务模块下新建Debug包，并新增DebugActivity和XXXApplication作为组件化状态下，模块调试的入口类和Application对象，如下
debug

新增模块编译时的Manifest文件

在module_XXX等业务模块下新建module_manifest文件夹，提供AndroidManifest文件，此Manifest文件包含上面的DebugActivity文件作为App启动入口，及其他当前模块的所有Activity
manifest
抽取module_main、module_A、module_B等业务模块的build.gradle文件中公共内容，形成一个模块通用的build.gradle文件，样例如下

if (Boolean.parseBoolean(isComponentMode)) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-kapt'


android {
    compileSdkVersion configs.android.compileSdkVersion
    buildToolsVersion configs.android.buildToolsVersion

    defaultConfig {
        minSdkVersion configs.android.minSdkVersion
        targetSdkVersion configs.android.targetSdkVersion
        versionCode configs.android.versionCode
        versionName configs.android.versionName

        multiDexEnabled true

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        consumerProguardFiles "consumer-rules.pro"

        kapt {
            arguments {
                arg("AROUTER_MODULE_NAME", project.getName())
            }
        }
    }

    sourceSets {
        main {
            jniLibs.srcDirs = ['libs']
            if (Boolean.parseBoolean(isComponentMode)) {
                //模块化，作为独立App应用运行
                manifest.srcFile 'src/main/module_manifest/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/AndroidManifest.xml'
                resources {
                    //合并打包版本时，排除debug文件夹下所有文件
                    exclude '*/debug/*'
                }
            }
        }
    }

    buildTypes {
        debug {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = '1.8'
    }

    buildFeatures {
        viewBinding true
    }
}

注意点：

此文件顶部的module类型配置，通过步骤一中的参数动态改变模块的module类型
sourceSets中通过步骤一的参数动态获取AndroidManifest文件

然后在对应的module_xxx中的build.gradle顶部添加此公共文件的依赖，样例如下：

apply from: "../module.build.gradle"

android {
    defaultConfig {
        if (Boolean.parseBoolean(isComponentMode)) {
            //Module作为独立App应用运行，需配置包名
            applicationId "com.zhl.module_main"
        }
    }
}

dependencies {
    implementation project(path: ':lib_common')
    //ARouter注解处理器
    kapt deps.arouter.arouter_compiler
}

壳工程依赖。设置在非组件化模式下，依赖各个业务模块合并编译

   dependencies {
       implementation fileTree(dir: "libs", include: ["*.jar"])
   
       if (!Boolean.parseBoolean(isComponentMode)) {
           //非组件化模式下，依赖各个模块
           implementation project(path: ':module_main')
           implementation project(path: ':module_sample')
           implementation project(path: ':module_a')
           implementation project(path: ':module_b')
       }
   
   }

页面跳转

组件化的第一目标就是业务模块间解耦，不相互依赖，如模块A的的一个Activity需要跳转模块B的一个Activity，在没有相互依赖的情况下，我们采用阿里的路由解决方案-ARouter，ARouter的配置过程参照官方文档，需要注意的点是kapt相关的依赖配置需要在各个业务模块module去添加，代码参考如下：

dependencies {
    implementation project(path: ':lib_common')
    //ARouter注解处理器
    kapt deps.arouter.arouter_compiler
}

defaultConfig {
        minSdkVersion configs.android.minSdkVersion
        targetSdkVersion configs.android.targetSdkVersion
        versionCode configs.android.versionCode
        versionName configs.android.versionName

        multiDexEnabled true

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        consumerProguardFiles "consumer-rules.pro"

        kapt {
            arguments {
                arg("AROUTER_MODULE_NAME", project.getName())
            }
        }
    }

然后在各个模块的Activity或Fragment上配置对应的path，则可实现跨模块跳转；

至此，可在修改isComponentMode参数不同的状态下实现分模块组件化编译运行或合并编译运行！

框架组件化技术点分析

通过上面的步骤相信你可以很快实现一个组件化框架的通用配置，但是如果你进一步深入组件化的使用后，会出现如下几个问题：

问题一：组件间数据传递

组件间的数据传递又分为两种情况：

1.页面主动跳转携带数据

组件化项目在业务开发过程中会出现如下问题：module_A和module_B之间要进行跳转，要使用一个共同的model，此时需要把该model对象放在Base中，但是随着业务的不断迭代，各个模块跳转之间跳转的业务会越来越多，导致model对象在base中越来越多，这部分内容严格来说是隶属于业务代码，因此在base模块和业务模块之间新增lib_common模块，统一管理Model实体类、图片资源、Strings等内容

2.模块数据被动拉取

例如：在module_main模块需要获取到module_user模块的用户信息去做显示。此场景使用ARouter的依赖注入进行处理

先在lib_common模块建立一个获取user信息的接口

interface IUserProvider : IProvider {

    /**
     * 提供User模块的数据
     *
     * @param s
     */
    fun getUserData(): String
}

然后在module_user模块实现

@Route(path = ARouterConstant.USER.USER_DATA_PROVIDER)
class UserProvider : IUserProvider {

    override fun getUserData(): String {
        return "这个是User模块的数据"
    }

    override fun init(context: Context?) {

    }
}

再module_main模块获取数据

val iSampleProvider = ARouter.getInstance()
                .build(ARouterConstant.SAMPLE.SAMPLE_DATA_PROVIDER).navigation() as ISampleProvider
Log.d("TAG值",iSampleProvider.getSampleData())

问题二： Application生命周期处理

Application作为程序启动的入口，其中的onCreate()方法经常做一些初始化相关工作，这些初始化的代码中，又包含2类，其中一类是所有模块都要用到的全局配置，如ARouter初始化、网络请求头配置、刷新样式、日志打印配置等。另外一类是某个模块特定的初始化配置。目前在组件化框架中有如下三种实现方式

方式一：统一处理

将全局配置代码统一全部放在Common层的Application的基类中，某个模块特定的初始化配置代码放在app壳module的Application配置

优点：处理简单，逻辑清晰

缺点：模块特定的初始化代码需要在其他module中调用，无法实现代码隔离

方式二：反射处理

在lib_common模块中定义ICommonApplication

interface ICommonApplication {

    fun onCreate()

}

定义业务module配置类

object ModuleApplicationConfig {

    private const val MODULE_MAIN = "com.zhl.module_main.MainApplication"
    private const val MODULE_SAMPLE = "com.zhl.module_sample.SampleApplication"
    private const val MODULE_A = "com.zhl.module_a.AApplication"
    private const val MODULE_B = "com.zhl.module_b.BApplication"

    val modules = mutableListOf<String>(MODULE_MAIN, MODULE_SAMPLE, MODULE_A, MODULE_B)
    
}

在每个业务模块中定义Application回调接收

class MainApplication : ICommonApplication {
    
    override fun onCreate() {
        Log.d("Application生命周期", "MainApplication执行onCreate!!")
        //todo 执行Main_module模块需要特定执行的代码 
    }
    
}

在CommonApplication类的OnCreate()方法中通过反射各个业务module的Application实例，然后执行相关初始化代码

open class CommonApplication : BaseApplication() {

    override fun onCreate() {
        super.onCreate()

        initComponent()
    }

    private fun initComponent() {
        ModuleApplicationConfig.modules.forEach {
            val clazz = Class.forName(it)
            val instance = clazz.newInstance() as ICommonApplication
            instance.onCreate()
        }
    }
}

优点：可实现代码隔离，逻辑清晰

缺点：通过反射实现，有性能问题，新增模块是需要修改module配置类

方式三：APT处理

此方法引入一个新的AppLifeCycle插件，他可以无侵入的获取到Application的生命周期，具体使用步骤如下：

lib_common模块依赖applifecycle-api依赖

//AppLifecycle
api 'com.github.hufeiyang.Android-AppLifecycleMgr:applifecycle-api:1.0.4'

各个业务模块module_xxx添加applifecycle-compiler注解处理器依赖(注意：java请用annotationProcessor关键字)
```
kapt 'com.github.hufeiyang.Android-AppLifecycleMgr:applifecycle-compiler:1.0.4'
```

新建各个业务模块的Application，用于接受主Application的生命周期事件分发，以module_main模块的MainApplication为例：

@AppLifecycle
class MainApplication : IApplicationLifecycleCallbacks {

    /**
     * 设置优先级
     *
     * @return
     */
    override fun getPriority(): Int {
        return NORM_PRIORITY
    }

    override fun onCreate(context: Context?) {
        Log.d("Application生命周期", "MainApplication执行onCreate!!")
    }

    override fun onTerminate() {

    }

    override fun onLowMemory() {

    }

    override fun onTrimMemory(level: Int) {

    }


}

壳工程添加AppLifecycle插件配置，并注册生命周期事件

项目build.gradle修改如下：

buildscript {
    ext.kotlin_version = "1.5.21"
    repositories {
        google()
        mavenCentral()
        //applifecycle插件仓也是jitpack
        maven { url 'https://jitpack.io' }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:7.0.3'
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.31'

        //加载插件applifecycle
        classpath 'com.github.hufeiyang.Android-AppLifecycleMgr:applifecycle-plugin:1.0.3'
    }
}

app模块build.gradle修改如下：

//使用插件applifecycle
apply plugin: 'com.hm.plugin.lifecycle'

优点：实现代码隔离，通过APT插件模式处理，编译阶段完成引用，无性能问题

缺点：代码逻辑调用无直接关联，要引入三方库

结论：目前项目经过评估引入方式三处理

其他

具体代码见：https://github.com/henryzhu-dev/AppArchitectureApplication

目前还在持续不断完善中，力求可以覆盖更多场景，实现最终快速实现业务，高质量交付的目的！

参考资料：

https://juejin.cn/post/6881116198889586701

https://juejin.cn/post/6844904147641171981

https://juejin.cn/post/6844904147641171981#heading-6

https://zhuanlan.zhihu.com/p/333887361

Android组件化框架实践

前言

为什么要组件化

项目架构图

组件化配置

框架组件化技术点分析

问题一：组件间数据传递

1.页面主动跳转携带数据

2.模块数据被动拉取

问题二： Application生命周期处理

方式一：统一处理

方式二：反射处理

方式三：APT处理

其他

参考资料：

猜你喜欢

热点阅读

Android组件化框架实践

前言

为什么要组件化

项目架构图

组件化配置

框架组件化技术点分析

问题一：组件间数据传递

1.页面主动跳转携带数据

2.模块数据被动拉取

问题二： Application生命周期处理

方式一：统一处理

方式二： 反射处理

方式三：APT处理

其他

参考资料：

猜你喜欢

热点阅读

方式二：反射处理