Gradle妙用,真正的统一化自动依赖管理

*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布

目录

Gradle妙用,真正的统一化自动依赖管理

重要性

项目结构

第一种:直接在app-module的src下建立对应的flavor名相同的文件夹,并创建相应的java/res文件即可.

第二种:将Flavor作为module来处理

大功臣Groovy

拿到currentFlavor

动态配置项目参数

动态化依赖 Flavor

动态化签名文件配置

三方依赖的特殊处理

创建Flavor的AppConfig文件

Tip

---

如果你也在做着同一套代码,构建多个项目的需求,那么一定要浏览下,或许会带给你启发.清晰化的目录结构,统一化的自动依赖管理.

入坑以来一直和variant打着交道,最初15年还是eclipse开发,那是还没variant概念.当时的项目是企业级app开发,简而言之就是一套代码针对不同企业构建其对应请求地址的包,当然不同企业也会有差异化的需求但大致的业务流程都差不多.(ps:如果是你,你会怎么做?一家企业一套代码?这种想法最初就被否了,因为企业多了,以后增加/修改公共需求都是问题,绝对让你崩溃!).所以当时的处理只是从代码层面来区分的,当然劣势也有,可能会增加包的大小.再往后推,谷歌爸爸退出了AS正式版,果断拥抱.再后来,了解到了Gradle的Flavor配置.可以根据Flavor从项目结构上选择依赖文件.这不就完美从项目配置上满足了我的需求么.随后就是更改重构的过程~以下只是我的经验心得,献给可能需要的你.

重要性

无论是从项目的健壮性还是可维护性来说好的开发工具搭配项目架构能让你事半功倍

统一化管理:我一直有统一配置的习惯,无论是代码的配置还是gradle的依赖.这样在项目变动的时候,更改一处即可.想想,假如不这么做,漏该了一处,什么结果...

项目结构

productFlavors:相信大家都了解,用于构建变体.我们可以用来打多渠道包,也可以做一些资源/代码差异化变更.这里我们将充分的依靠它完成后续工作!

差异化的实现有两种方式

首先我创建了两个Flavor:

  productFlavors {
      variant_a {
          applicationId "com.joe.variant_a"
      }
      variant_b {
          applicationId "com.joe.variant_b"
      }
  }

第一种:直接在app-module的src下建立对应的flavor名相同的文件夹,并创建相应的java/res文件即可.

如图: 

    

这种是常见的目录结构.也满足了大多的需求,差异化的主题色/代码等都满足了.但是对于想大做文章的就不一定满足需求了,比如:

依赖性差异: 项目A需要添加实现一个扫码功能,而B则不需要.见多识广的可能说,创建扫码的module可以用aImplementation来选择性依赖,不错可以解决.起初我也这么做的.那么问题又来了: B需要依赖支付组件而A又不需要,行呗,接着bImplementation呗.有没有想过如果你的Flavor不止这两个有N多个,而差异化的依赖又有N项...再这么在dependencies {...}中写下去,看着多痛苦啊.

业务性差异: