Android 组件化案例

2019-04-30 本文已影响4人 Android高级开发

为什么组件化
随着移动互联网的发展，或许中小型项目还可以用单工程+MVC/MVP/MVVM的架构来完成，但当项目到了一定程度之后，编译时间原来越长，测试或者开发任何一个模块功能都需要整个项目重启运行。

常规单工程+MVC/MVP/MVVM项目：

image

乍一看，这样的结构只要咱们模块分层明确，是不存在大问题的，但是随着业务的快速迭代，面临以下问题：

1.需求疯狂变化，上周刚讨论出一套方案，你花了两天搞定，这个时候PM告诉你，这个咱们修改或者不要了，是否想抓狂呢。

2.所有业务都在一个项目，不管基于什么原因，有时候咱们为了快速完成一个功能，或多或少存在耦合，任何改动都可能显的比较吃力，解决了一个BUG又出现另外一个BUG。

3.团队人数达到一定程度后，并行开发过程中，如果某个成员不小心犯错并且提交了代码，可能导致项目暂时无法运行，不得不停下来协同查找问题，严重影响开发效率

4.业务越来越多，项目越来越大，编译运行一次要10秒…20秒…1分钟…5分钟…累计几个月下来的时间说不得抽出来都可以去找个女朋友了…

基于以上问题，咱们的组件化应运而生。

组件化结构图

image

对比上张图，这里的APP主要由业务组件构成，严格来说这5个业务组件也可以是5个App,当实现以上架构图，看看组件化的优缺点：

组件化优点

业务组件可以单独分配并行开发
单个组件业务可以由开发者自行决定采取MVC/MVP/MVVM架构而不影响整体大局
新人接手项目分配任务可单独分配某一个模块任务，不必关心整个项目
开发效率提升，开发过程仅仅需要维护开发自己的组件内容
若公司有多个团队，优秀代码组件可快速移植复用
积累个人的组件仓库，摆脱粘贴复制的“搬砖工”身份
测试可单独测试某个模块

组件化的坑

组件与组件之间的调用，数据等交互
多个组件，在使用application的时候怎办
多个组件资源命名重复
多个组件引用不同版本的相同的库

了解了优缺点，咱们进入正式的组件化开发集成，后续将会描述如何解决组件化的一些坑。

前文说过，咱们的5个组件可以理解为5个app，下面开始集成。

先看看咱们的组件化效果，手机展示效果，

image

image
1：首先统一组件之间的版本以及第三方库版本
利用Gradle统一版本号，可参考 android使用Gradle统一配置依赖版本

2:咱们的组件又是Lib，又是application，如何控制调试，如何在主APP选择

在config.build处新增一个布尔isBuildApp作为标志判断依赖，true表示作为application存在，false表示lib存在

ext {
    isBuildApp=false;//false:作为Lib组件存在， true:作为application存在
    ...
}

在每个组件的build根据isBuildApp来选择依赖

if(rootProject.ext.isBuildApp){
    apply plugin: "com.android.application"
}else{
    apply plugin: 'com.android.library'

}
android{
...
 defaultConfig {
        if(rootProject.ext.isBuildApp){
            applicationId "com.allure.shop"
        }
        ...
    }
}

ibrary与application运行时需要manifest,依然根据isBuildApp判断

   sourceSets {
        main {
            if (rootProject.ext.isBuildApp) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/release/AndroidManifest.xml'
                java {
                    exclude 'debug/**'
                }
            }
        }
    }

资源的命名为了避免重复，建议按照组件名开头，如Login组件，命名login_xxx，BaiDuMap组件命bd_map_xxx
可用gradle进行强制检测

resourcePrefix "login_"

主项目的引用

 if (rootProject.ext.isBuildApp) {
        compile project(':modulebase')
    } else {
        compile project(':modulecore:moduleLogin')
        compile project(':modulecore:moduleShop')
    }

解决组件与组件的交互：
方案1：可采用建立中间件的方式来统一管理组件之间的交互,如电影组件与首页组件需要跳转传值等可采用开源的ActivityRouter，EventBus来完成

image

方案2：在主项目APP建立统一的入口类，针对组件与组件的交互建立方法，实现接口等，但此方式有一定沟通成本，组件与组件之间的交互维护可能需要一份文档来约束。

application的使用：
方案1：统一使用基础库的单例BaseApplication
方案2：反射ActivityThread

Lib与Application的切换
修改config.build里的isBuildApp属性并且重新sync

项目结构图：
作为组件Lib

image

作为单独的application

image

总结

组件化技术难度不大，难点在于业务的解耦。具体是否选择组件化方式还是要根据项目大小来确定。当然采取了组件化是极好的。

Android 组件化案例

总结

猜你喜欢

热点阅读