干货---从智行-Android-项目看组件化架构实践

#####2.1 组件化调整的原因和目标

如前面提到的，在调整之前，项目是单一工程的架构模式，这也是常见的 Android 项目架构模式，但是一旦项目整体业务增多，扩张出相对较为独立的业务模块，这种架构就会带来一些问题，例如：

• 业务间代码层面耦合太重，业务之间隔离不明确：由于各业务间代码存在较多的耦合，经常出现某个业务线功能开发迭代影响其他业务线，出现代码冲突，影响其他业务功能。

• 项目整体源码较多，编译耗时久：各业务开发人员主要开发各自业务线需求，但是需要编译整个项目，耗时较多，影响开发效率。

• 多应用差异化适配方案不完善：在业务扩张过程中，还衍生出一些独立应用，例如智行旗下的订票助手、智行机票等应用，实际是使用同一个项目打包，更改一些主题配色和首页入口，进行差异化的编译打包。之前使用的多应用打包方案存在一些的问题，逐渐无法满足实际需求。

参考技术社区的 Android 架构方案，以及结合项目实际情况和业务场景，我们选择了组件化方案来进行架构的调整。

Android 项目组件化，最早是冯森林老师在 2016 年 MDCC 大会上的《回归初心，从容器化到组件化》演讲中提出来的，当时该方案刚提出，实际应用到项目中的还是比较少得，毕竟一般的公司项目业务不是很复杂，项目结构也是较为单一，没有使用组件化的必要。

但对于此时的智行 Android 项目而言，正是组件化架构最适合实践的项目，多个业务线，项目整体比较庞大，业务间不必要的耦合过多，因此组件化架构的调整方案也就应运而生。

在进行调整之前，团队也定下了调整预期的目标：

1）业务解耦，使得各业务模块可以独立运行，同时可以组合编译打包
2）拆分基础组件，抽离出基础组件 Library
3）各业务间通信和业务交叉调用的实现
4）实现多应用差异化适配打包

以上大的目标点主要是来解决之前遇到的问题，也是项目架构调整的首要目的。

2.2 组件化架构调整的整体规划

2.2.1 基础组件的拆分

智行 Android 项目的基础组件主要分为业务基础组件和功能基础组件，其中业务基础组件包含登录组件、自定义 View 组件、项目网络层组件等，这些和业务有关联，提供给各业务模块的基础组件，根据具体情况拆分成 aar 或者 library，像登录，基础网络层这样较为稳定的组件，一般直接打包成 aar，减少编译耗时。而像自定义 View 组件，由于随着版本迭代会有较多变化，就直接以源码形式抽离成 Library。

基础组件的调整相对较为简单，主要就是按照功能或者业务拆分成 Library ，处理好之前的引用的地方即可，但是对于拆分出来的 Library 的质量和后续维护工作是要求相对较高的，作为基础的组件，是需要为各业务模块提供基础的功能的，重要性是相对较高的。

基础组件库的编译版本设置一般是和主工程同步的，为了方便后续升级和维护配置，可以使用如下的方式来实现 library 使用同一份配置：

ext.libDefaultConfig = {
minSdkVersion 19
targetSdkVersion 25
javaCompileOptions {
annotationProcessorOptions {
includeCompileClasspath = true
}
}
}

定义一个通用的 DefaultConfig 配置，设置统一的 SDK 版本信息和编译选项，在 Library 的 build.gralde 文件中使用如下方式即可应用到配置：

android {
…
defaultConfig libDefaultConfig
}

这样既可以保证基础组件库的编译配置统一，也方便后期统一修改和升级。

对于再基础点的组件，例如 Support Library、json 库等，绝大多数基础组件都会使用到。为了避免每个独立基础组件都去引入对应的依赖，还要尽可能得保证版本的统一，我们使用了一个空壳 Library 来一次性引入这些基础的依赖组件。

这个 Library 叫做 BaseDependencies，然后其他的基础组件去依赖 BaseDependencies，这样就可以保证基础组件对这些基础的依赖版本做到一致，后续的升级改动位置也相对较为集中。如此调整后的依赖如下图所示：

当然这样的也有一定的弊端，就是每个基础组件都可能存在引入冗余的依赖，对于后续可能需要提供给第三方的基础组件，还需要进行改动才可以独立出来。

2.2.2 业务模块的拆分和配置

业务模块的调整是组件化中最重要的，这里的模块也是组件，对于这类组件的调整目标就是做到能够独立运行。业务模块的调整主要分两步：

1）业务模块的拆分独立
2）业务模块的配置

由于之前各业务的代码以不同包名来进行区分，各业务代码也是比较集中的，拆分出来还是相对较为容易的。遇到两个业务模块都会使用到的类的话，就将对应的类下沉到 Base Module，当然这种情况也是尽可能去避免，否则 Base Module 会越来越臃肿，如果不加以控制，那么业务模块就变成了一个空壳，失去了组件化原本的意义。

拆分成独立模块业务，彼此之间是平级的关系，无依赖关系，从而从结构层面达成了分离的目的，避免了之前一不小心就出现的类相互引用，耦合严重的问题。

业务模块拆分成独立的 Library 以后，就是对其进行配置，这也是组件化的关键步骤，既要使得各个业务模块可以独立运行，又要保证各个模块作为整体 App 的一部分，关键就在于不同场景下给每个业务模块应用不同的插件类型。

独立运行时，需要使用：

apply plugin: ‘com.android.application’

而分独立运行时，则需要使用：

apply plugin: ‘com.android.library’

为了方便业务模块的在这两种模式下的快速切换和统一调整，我们使用了以下的设置方式：

// 项目的 build.gradle 中配置模块是否独立运行
def isSingleCompile = false
ext.isSingleCompile = isSingleCompile

if (isSingleCompile) {
ext.COMPLIEMODE = ‘com.android.application’
} else {
ext.COMPLIEMODE = ‘com.android.library’
}

// 业务模块的 build.gradle 中应用

这样在切换时，只需要修改 isSingleCompile 的值，就可以在独立运行和作为模块运行之间切换。

当业务模块独立运行时，还需要配置独立的 Application 和启动页，以及一些特殊的资源文件，这里同样是根据 isSingleCompile 的值来配置 sourceSets 中的属性：

sourceSets {
main {
manifest.srcFile MANIFEST_FILE
res.srcDirs = RESOURCES
java.srcDirs = JAVA_SOURCES
…
}
}

这里配置内容不再赘述，可以参考 Android 官网的说明进行设置，主要是针对独立运行时配置 Manifest 文件和添加入口页面的调整。

2.2.3 业务间的通信

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

写在最后

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从哪里入手去学习，对此我整理了一些资料，需要的可以免费分享给大家

我的【Github】会分享一些关于Android进阶方面的知识，也会分享一下最新的面试题~

如果你熟练掌握GitHub中列出的知识点，相信将会大大增加你通过前两轮技术面试的几率！这些内容都供大家参考，互相学习。

①「Android面试真题解析大全」PDF完整高清版+②「Android面试知识体系」学习思维导图压缩包——————可以在我的【Github】阅读下载，最后觉得有帮助、有需要的朋友可以点个赞

ps://bbs.csdn.net/topics/618156601)阅读下载**，最后觉得有帮助、有需要的朋友可以点个赞

[外链图片转存中…(img-WXOxgenP-1710698815231)]

[外链图片转存中…(img-NYJHbfm9-1710698815232)]