多模块Android项目导入库最佳实践：Retrofit依赖方案选择

毫无疑问，方案一是更贴合Android模块化最佳实践的选择，具体原因如下：

• 严格的依赖隔离，保障模块纯净性
  既然Retrofit仅在feature1和feature2中使用，那我们就该让这个依赖的作用范围精准匹配使用场景。方案一中，在feature1和feature2的gradle文件里分别用implementation 'com.squareup.retrofit2:retrofit:2.4.0'导入，能让编译器严格限制Retrofit的可访问性——feature3的代码里如果尝试使用Retrofit，直接就会编译失败，从根源上避免了无用依赖的滥用，确保每个feature模块只承载自己需要的能力，职责边界清晰。

• 避免无意义的依赖传递
  方案二中用api在common模块导入Retrofit，会把这个库传递给所有依赖common的模块（包括feature3和app），哪怕这些模块完全用不上Retrofit。这不仅会增加这些模块的编译classpath体积，拖慢构建速度，还会埋下版本冲突的隐患——后续如果某个模块需要引入不同版本的Retrofit，处理依赖冲突的成本会高很多。

• 代码重复的问题可轻松解决
  你提到方案二代码量更少，但其实方案一的重复问题有很简单的解决办法：在项目根目录的build.gradle里统一定义依赖常量，比如：

  ext {
      dependencyVersions = [
          retrofit: "2.4.0"
      ]
      libraries = [
          retrofit: "com.squareup.retrofit2:retrofit:${dependencyVersions.retrofit}"
      ]
  }
  

  之后在feature1和feature2的gradle里只需要写implementation libraries.retrofit即可，既保证了版本统一，又几乎没有额外的代码冗余，完美兼顾了可控性和简洁性。

内容的提问来源于stack exchange，提问作者Piotr Aleksander Chmielowski