项目刚起步时所有代码塞进一个app模块完全没问题。但随着功能越来越多你会发现改一行代码要全量编译几分钟、不同团队改同一个模块频繁冲突、想复用某块功能却发现它和一堆东西耦合在一起拆不出来。这时就该上多模块化Modularization把一个巨大的app拆成多个职责清晰、可独立编译、可复用的 module就像把一栋大楼分成若干独立单元。本文讲清为什么拆、怎么拆、模块间如何通信。一、为什么要多模块化收益说明编译更快只重新编译改动的模块增量编译 并行职责清晰每个模块边界明确强制解耦可复用通用模块可被多个 App / feature 复用团队协作不同团队负责不同模块减少冲突按需交付配合 Dynamic Feature 实现功能动态下发经验信号当全量编译超过几分钟、或多人频繁在同一文件冲突时就该考虑拆模块了。二、常见的分层模块策略一种被广泛采用的分层参考官方 Now in Android 架构:app 应用入口组装各 feature ├── :feature:home 功能模块首页 ├── :feature:profile 功能模块个人中心 ├── :core:ui 通用 UI 组件、主题 ├── :core:data Repository、数据源整合 ├── :core:network 网络层Retrofit/OkHttp ├── :core:database 数据库层Room ├── :core:model 纯数据模型无依赖 └── :core:common 工具类、扩展函数依赖方向规则关键app ── feature ── core永远是上层依赖下层下层绝不反向依赖上层feature 模块之间也不互相依赖。三、模块类型类型Gradle 插件用途应用模块com.android.application最终 App只能有一个入口 app库模块com.android.libraryfeature/core 模块产出 aar纯 Kotlin 模块org.jetbrains.kotlin.jvm无 Android 依赖的逻辑/模型层Dynamic Featurecom.android.dynamic-feature按需下载的功能模块:core:model、:core:common这类不依赖 Android API 的模块尽量做成纯 Kotlin 模块编译更快、也能被测试直接用。四、模块间通信与解耦模块拆开后怎么让:feature:home用到:feature:profile的能力又不直接依赖它接口下沉把公共接口放到下层:core模块feature 依赖接口而非实现。依赖注入用 Hilt 在 app 层组装实现feature 只声明需要什么。导航解耦用 Navigation 的 deep link 跨模块跳转避免直接引用对方 Activity/Fragment 类。五、用 Version Catalog 统一依赖多模块下最怕各模块依赖版本不一致。用gradle/libs.versions.tomlVersion Catalog集中管理[versions] retrofit 2.11.0 [libraries] retrofit { module com.squareup.retrofit2:retrofit, version.ref retrofit }// 任意模块dependencies{implementation(libs.retrofit)}再配合convention plugins约定插件把各模块重复的构建配置抽出来避免每个build.gradle复制粘贴。六、apivsimplementation关键字依赖是否传递给上游implementation不传递默认首选编译更快api传递上游也能用到这个依赖默认用implementation。滥用api会让依赖穿透多层模块破坏封装还会拖慢编译——改一个底层依赖导致一大片模块重编。