为了解相关资料，在网上找了很久才找到相关资料。记录一下，防止忘记。
参考资料：http://blog.csdn.net/zhaoyanjun6/article/details/77678577
背景
由于同一个项目需要提供给不同的客户，同时不同的客户又有各自定制的功能。即一个项目，多个不同的定制版本的模式。因此引发了多个版本管理的问题。如果每个定制版本都一份代码，对于代码的维护将会非常困难，因此共用一份代码是必须的。
最开始，由于定制版本不多，差异也不大，所以通过设定一个静态值来表示不同的定制版，再由运行时决定功能逻辑。后来，随着定制版本增多、各版本之间的逻辑差异加大，导致版本判断的代码越来越多，逻辑越来越复杂。由于冗余代码的增加，维护也越来越困难。因此，代码的管理方案也需要相应的改变。首先想到的是通过SVN等版本管理工具进行管理，将基础版本作为主干，各定制版本在分支上开发。在一个分支上添加了公共功能或者是修复了公共功能部分的BUG时，再将代码合并到主干，其它分支再到主干上同步。这是一个优秀的解决方案，但是在公共部分的代码更新频繁的情况下，这个方案会导致频繁的分支同步与合并。虽然在改动量小的时候，及时更新同步可以有效解决合并困难的问题。不过对于开发人员并不集中且无法利用网络的情况下，需要有一种新的代码管理方案来解决。
新的方案就是利用Gradle的差异化构建来进行管理。这个方案将差异化的代码，即各定制版本不同逻辑的部分分布到各版本中，而将共同的部分集中在一起，所以不需要同步，也不需要在运行时进行逻辑判断，因为在编译时已经进行过了统一的判断了。但是在各定制功能存在组合时，这个方案的问题也非常大，这里暂时不讨论。
使用步骤
第一步 创建一个编译版本
创建一个命名为custom1的Build Type。根据需要改变其它的配置。
第二步 指定编译版本
打开Build Variants，并将目标Module的Build Variant选择刚才创建的编译版本。然后运行。
结果，如图所示，无法运行。提示 Error : the apk for your currently selected variant(app-custom1-unsigned.apk)is not signed.Please specity a signing configuration for this variant(custom1)。（这是故意留着的，因为在发现这个问题后，上网找，发现资料不多）。
问题原因是没有指定签名文件，所以无法生成签名的安装包，而生成的未签名的安装包是无法运行的。解决方案是：点击Fix，然后创建签名配置
如上图所示，这里创建了一个名为normal的配置，Normal.jks签名文件是前面已经创建好的。然后在custom1中指定Signing Config为刚刚创建的normal。至此，就已经完成了定制版本的配置。接下来将添加定制版本的代码。
第三步 添加定制版本代码
在Project结构下，在src目录下创建一个与步骤一创建的build type同名的文件夹custom1，并在文件夹下创建名为java的文件夹，与名为res的文件夹，分别用于存放代码与资源文件。
可以看到现在custom1的目录结构与main的目录结构一致了。main目录表示的是各build type共用的代码，custom1目录表示的是当build variant设置为custom1时使用的代码。
第四步 定制逻辑
重复第一到第三步，再创建一个定制版custom2。然后再在两个定制版本中添加相同的包名以及类文件。以供main目录下的公共代码使用，公共代码没有使用到的可以自由定义。完成代码后就可以通过更改build variant的设置选择不同的定制逻辑了。
从以上两图可以清晰的看出，当且仅当build variant选定的build type对应的代码会回到编译中去。
如果没有时间从实践一遍，或者对实际效果不了解，可以直接下载源代码：https://gitee.com/IndoorsNum31/GradleDifferentiatedBuild
