本文探讨了如何利用整洁架构（Clean Architecture）的设计原则优化 Android 项目中的 Gradle Module 划分与依赖管理。文章详细阐述了 Module 粒度划分的三大原则（REP、CCP、CRP）以及依赖关系的三大原则（ADP、SDP、SAP），并通过不稳定度公式和抽象度公式量化评估组件健康度。文中结合短视频应用案例，演示了如何通过调整模块结构、引入抽象层及中间件来解决循环依赖和稳定性问题，并提供了 Gradle 可视化工具及 CI 集成等实践建议，旨在帮助开发者构建高内聚、低耦合、易维护的工程架构。
现代 Android 项目通常构建在 Gradle 工程之上，开发者习惯于使用 Gradle Module 来划分和组织代码。然而，随着 Module 数量的增加（几十甚至上百个），如果模块间的依赖关系不合理，会严重拖慢工程的编译速度。如何更科学地组织 Gradle Module 是 Android 开发领域的普遍需求。
整洁架构（Clean Architecture）由 Robert C. Martin 提出，Google 推荐将其用于 MVVM 的分层优化。除了业务架构，其组件设计原则同样适用于优化 Gradle 的工程架构。本文将讨论如何基于整洁架构中的设计原则来设计和治理 Gradle Module。
参考 Clean Architecture 中对组件的定义：组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。在 Android 中，Gradle Module 是发布 JAR 或 AAR 的基本单元，因此 Module 可视为一个组件。在 Module 粒度划分上，我们套用书中关于组件划分的三个原则：复用发布等价原则（REP）、共同封闭原则（CCP）、共同复用原则（CRP）。
软件复用的最小粒度应等同于其发布的最小粒度。
REP 告诉我们 Module 划分的一个基本原则是代码的可复用性。当一些代码有被复用的价值时，它们就应该被考虑拆分为 Module，以便独立发布。此外，REP 还要求我们注意 Module 不能拆分过度。当我们发布 AAR 时都需要为其设定发布版本号，如果不设定版本号就无法保证组件之间能够彼此兼容。这在 androidx 系列组件中尤为突出，我们经常遇到因为版本不一致造成的运行时问题，产生这种不一致的一个重要原因就是组件的拆分过度。
如果两个可以独立发布的组件，它们总是作为一个整体被复用，就会出现可复用的粒度大于可发布粒度的问题，增大了版本冲突的概率。此时可以考虑将它们合二为一，同时发布以避免版本不一致。在小团队中这个问题不突出，因为通过人为约定可以保证所有组件同时发布；但在跨团队的大型项目中，如果一个功能的升级总是要多个团队一起配合，沟通成本是难以忍受的。
组件中的所有类对于同一种性质的变化应该是共同封闭的，即一个变化的影响应该尽量局限在单个组件内部，而避免同时影响多个组件。我们应该将那些会因为相同目的而同时修改的类放到同一个组件中，而将不会为了相同目的同时修改的那些类放到不同的组件中。
相对于 REP 关注的可复用性，CCP 强调的是可维护性。很多场景下可维护性相对于可复用性更加重要。CCP 要求我们将所有可能被一起修改的类集中在一起，两个总是被一起修改的类应该放入同一组件。这和大家熟知的 SOLID 设计原则中的 SRP（单一职责）很类似，SRP 要求总是一起修改的函数应该放在同一个类，CCP 可以看作是组件版本的 SRP。
有的人在 Android 项目中喜欢按照代码的功能属性划分 Module，比如一个 MVVM 架构的工程，目录可能如下划分：
+ UI
+ Logic
+ Repository
+ API
+ DB
但实际开发中，很少只修改 UI 或者只修改 Logic，大多是围绕某个 Feature 进行垂直修改。这种跨 Module 修改显然违反了 CCP 原则，因此以业务属性为单位来进行 Module 划分可能更加合理。例如一个短视频应用的目录结构应该是：
+ VideoPlay
+ ui
+ data
+ ...
+ VideoCreation
+ Account
+ ...
这样，我们的修改可以在单个组件中闭环完成，在 Gradle 编译中减少受影响的模块，提升编译速度。
组件中的类应该同时被复用，即组件中不要依赖不参与复用的类。
REP 要求我们将紧密相关的类放在一个组件中一同发布，而 CRP 要求我们强调的是不要把不相关的类放进来，要用大家就一起用。要注意所谓'共同'复用并不意味着所有的类都能被外部访问，有些类可能是服务于内部其他类的，但也是必不可少的。我们虽然不希望组件过度拆分，但是同时要求组件的类不能过度冗余，不应该出现别人只需要依赖它的某几个类而不需要其他类的情况。
例如 VideoCreation 承载了短视频创作相关的功能，短视频创作链路分为拍摄和编辑两部分。某些场景下用户通过相册选取素材后直接进入编辑，此时可能不需要拍摄模块，所以拍摄和编辑两个模块共存一个组件不符合 CRP 原则。当拍摄部分代码发生变动时，会连累那些只依赖编辑模块的组件一同参与编译。此时应该考虑拆分 VideoCreation 为 VideoRecord 和 VideoEdit 两个 Module。
CRP 与 SOLID 的 ISP（接口隔离原则）有点像，ISP 指的是对外不暴露不需要的接口，从这点来看，CRP 可以称为组件版的 ISP。
上述三个原则有着互斥关系，REP 和 CCP 是粘合性原则，告诉我们哪些类要放在一起，这会让组件变得更大。CRP 是排除性原则，不需要的类要从组件中移除出去，这会使组件变小。组件设计的重要任务就是在这三个原则之间做出均衡。
REP、CCP、CRP 的中心思想都是追求组件内部合理的内聚性，但是它们的侧重点不同，三者很难同时兼顾。如果只遵守 REP、CCP 而忽略 CRP，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；遵守 REP、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改 n 个组件，带来的成本也是巨大的；如果只遵守 CCP 和 CRP 而忽略 REP，可能因为组件的能力太过于垂直而牺牲了底层能力的可复用性。
Gradle Module 粒度如何划分很难找到一个普适的结论，应该综合项目类型、项目阶段等各种因素，在三原则中做出取舍和权衡。例如在项目早期我们更加关注业务开发和维护效率，所以 CCP 比 REP 更重要；但随着项目的发展，可能就要考虑底层能力的可复用性，REP 变得重要起来；随着项目的持续迭代，组件能力越发臃肿，此时需要借助 CRP 对组件进行合理的拆分和重构。
在粒度划分上我们追求的是组件如何保持合理的内聚性，组件间依赖关系的梳理有助于更好地维持外部的耦合。Clean Architecture 中关于组件耦合设计也有三个原则：无环依赖原则（ADP）、稳定依赖原则（SDP）、稳定抽象原则（SAP）。
组件依赖关系图中不应该出现环，关系图必须是一个有向无环图（DAG）。Module 之间出现环形依赖会扩大组件变更带来的影响范围，增加整体编译成本。
比如 A -> B -> C -> A 这样的环形依赖中，由于 C 依赖了 A，B 又依赖了 C，A 的变化对 B、C 都会带来影响，依赖环中的任何一点发生变更都会影响环上的其他节点。设想一下如果没有 C -> A 的依赖，C 的变化只会影响 B，B 只会影响 A，A 的变化将不再影响任何人。
所幸我们不必担心 Gradle 中出现环形依赖的 Module。Gradle 需要根据 Module 依赖关系决策编译顺序，如果 Module 之间有环存在，Gradle 在编译期会报错提醒。因此我们需要关心的是发现环形依赖后该如何解决，消除环形依赖一般有两种方法：
当然，这种方式如果滥用会导致工程的组件膨胀，所以是否真的要从 A 中下沉一个 D 组件，还要结合前文介绍的 REP 和 CCP 原则综合考虑。
依赖关系要趋于稳定的方向，例如 A 依赖 B，则被依赖方 B 应该比依赖方 A 更稳定。
SDP 原则很好理解，如果 A 是一个公共组件需要保持较高稳定度，而它如果依赖一个经常变更的组件 B，则会因为 B 的变更变得不稳定。若要保证 A 的稳定，B 的修改就会变得畏手畏脚，难以进行。一个预期会经常变更的组件是一个不稳定的组件，这个定义过于主观，如何客观衡量一个组件的稳定性呢？
稳定度的衡量方式可以看一个组件依赖了多少组件（入向依赖度）和被多少组件所依赖（出向依赖度）这两个指标：
这个值越小，说明这个组件越稳定：
仍然以短视频应用的工程结构为例：
+ app #宿主
+ play #视频播放
+ ui
+ data
+ creation #视频创作
+ ui
+ data
+ common #公共能力
+ db
+ net
+ camera
+ cache
+ infra #基础框架等
infra 的不稳定度
infra 是一个极为稳定的 Module，它不能擅自改动。app 的不稳定度
app 是一个极度不稳定的 Module，任何一个 Module 的变动都会影响它。一个相对健康的工程结构，箭头的走势一定是符合 SDP 的原则，从不稳定的组件流向稳定的组件。从 Module 内部来看 :ui 的不稳定度高于 :data 也符合 UI 侧需求更容易变更的客观现实。
再分析一下 VideoPlay 和 VideoCreation 这两个 Module 的依赖关系，假设此应用为了鼓励用户创作在视频播放时增加了创作入口，所以 VideoPlay 对 VideoCreation 产生依赖：
VideoPlay 不稳定度
VideoCreation 不稳定度
VideoCreation 的不稳定度反而略高于 VideoPlay，这是与 SDP 原则相违背的。在产品层面为了迎合需求我们让 VideoPlay 直接依赖了 VideoCreation，但是在工程层面这并非一个好设计，关于解决方案可以参考后文内容。
一个组件的抽象化程度应该与其稳定性保持一致，越稳定的组件应该越抽象。
SOLID 中最核心的当属开闭原则（OCP）：代码应该对扩展开放，对修改关闭。我们常常通过面向抽象类/接口编程的方法去实践 OCP，即用抽象构建框架，用实现扩展细节。抽象层包含程序的基础协议和顶层设计等，这些代码不应该经常变更，所以应该放在稳定组件（I=0）中，而不稳定组件（I=1）中适合放那些能够快速和方便修改的实现部分。
SAP 为组件的稳定性和抽象化程度建立了一种关联，稳定组件需要变更时应该避免修改自己，而是通过其派生类的扩展来实现变更，这就要求稳定组件具备良好的抽象能力。而至于抽象类的实现部分，应该从稳定组件中剥离，放到不稳定组件中，这样可以无压力的对其代码进行修改而不必担心影响他人。
A 的取值范围从 0 到 1，值越大表示组件内的抽象化程度越高，0 代表组件中没有任何抽象类，1 代表组件只有抽象没有任何实现。
如上所述，由于 infra 处于极度稳定状态，它应该有与之匹配的抽象化程度。以数据层的能力为例，我们将 infra 中所有的关于数据层的实现抽离到 Common，只留下抽象接口，其他 Module 的 :data 只依赖稳定的 infra，而 app 负责全局注入 db、net、cache 等具体实现。
此外，由于 VideoCreation 中没有剥离抽象和实现，对 VideoCreation 实现的修改可能会破坏其应有的稳定性。基于 SAP 原则，我们新增一个高度抽象化的 creation:api，它具有高稳定性和高抽象度，而 VideoCreation 的稳定性降低，负责同时为 api 提供具体实现。
组件的不稳定度（I）和抽象度（A）关系可见下图：纵轴为 A 值（数值越大越抽象），横轴为 I 值（数值越大越不稳定）。基于 SAP 原则，一个健康的组件应该尽量靠近主序列（Main Sequence），我们用 Distance from the Main Sequence (D) 来评价组件的抽象度与稳定性之间的平衡关系：D = abs((A+I) - 1)。这个值越小，说明这个组件的抽象度与稳定性是越平衡的。位于（A = 1, I = 0）的组件是极度稳定并完全抽象，位于（A = 0，I = 1）的组件是完全具象且极度不稳定的组件。
位于坐标左下角的组件由于其稳定性要求高不能被随意修改，但是由于其代码抽象度很低又无法通过扩展进行修改，一旦有升级要求只能修改自身。这种既需要修改又不能修改的矛盾使得这个区域被称为痛苦区（Zone Of Pain）。
比如之前例子中的 Common 部分，如果作为公共模块被直接依赖、需要具备极高的稳定性，但是由于其内部充满具体实现，当我们要升级 db 或者 net 等公共库时由于影响范围太大往往需要对程序进行全面回归测试。所以我们不允许 Common 被过多地依赖，降低其稳定性，也降低了其发生变更时的负担，当发生变更时，只要针对其依赖的 infra 接口完成单元测试即可，避免了回归测试成本。
位于坐标右上角的组件，不稳定度很高意味着没有被其他组件依赖，所以在这部分做任何抽象都是无意义的，因此也被称为无用区（Zone Of Useless）。一般这种代码都是历史原因造成的，例如我们经常看到某个角落里遗留了一些没有被实现的抽象类，像这样的无用代码应该被移除。
一个健康的组件应该尽量远离痛苦区和无用区，并尽量靠近主序列。
理论原则需要落地到具体的工程实践中才能发挥作用。在 Gradle 环境中，我们可以通过以下方式辅助实施上述原则：
dependency-graph 或 gradle-dependency-tree 生成依赖树图，直观检查是否存在环形依赖或违反 SDP/SAP 的箭头走向。CI 流水线中可以集成此类检查脚本，自动阻断违规构建。settings.gradle.kts 中明确定义子模块路径，配合 build.gradle.kts 中的 api 与 implementation 依赖声明区分。确保公共接口模块使用 api 传递依赖，而具体实现模块使用 implementation 隐藏依赖细节。infra），建立严格的单元测试和集成测试套件。当修改涉及抽象层时，确保所有下游消费者模块的测试用例均能通过，防止破坏性变更。最终总结之前，再看一下我们这个短视频应用经过整洁架构优化之后的效果。除了前文叙述过的通过新增 creation:api，让 VideoPlay 的稳定性和抽象度趋于一致以外，我们还对 camera 的位置做了调整。调整前的 camera 处于 Common 中，但它的修改比较独立且仅仅被 VideoCreation 所依赖，首先这不符合 CRP 原则，其次 camera 经常伴随 VideoCreation 的需求而升级，也不符合 CCP 的要求，因此我们把 camera 从 Common 抽出并移动到 VideoCreation。
最后我们还新增了一个 creation:common。由于 VideoCreation 中有多处对 infra 的依赖，虽然 infra 是极度稳定的组件，但是作为外部组件仍然不可信赖，一旦 infra 发生变动对 VideoCreation 的稳定性造成影响，我们新增 creation:common 收敛对 infra 的依赖，提升 VideoCreation 的稳定性。优化之后各组件的不稳定度如下表：
不稳定度（I）逐层递减，抽象度也随之逐渐递增。文章中的例子十分简单，肯定有人会觉得这种程度的优化仅凭直觉就可完成，没必要套用公式。但是实际项目往往要复杂得多，了解这些公式能够在复杂场景中发挥引导作用，避免我们迷失方向。
最后做一个总结，Gradle Module 作为 Android 工程的组件单元，我们可以基于整洁架构中关于组件设计的原则对其进行治理：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online