当一个项目集成许多渠道时候，不知道你们有没有遇到，每上一个渠道的时候，往往需要完成渠道方的要求，比如说集成支付，账号，更改包名等等，如果你使用git分支的话，随着你的版本升级和渠道的增加，你维护的成本就会越来越高。
好在Android Studio使用Gradle构建项目，熟悉Android gradle DSL（领域定义语言）的话，Gradle实现多渠道打包，已经是信手拈来。这里提供一个场景，我们要使用Gradle构建来实现定制化渠道。
很多渠道方接入的需求：1.指定包名 2.指定图标 3.接入账号或支付（引入jar或工程方式） 4.指定界面和申请appkey（Manifest中处理） 等等...下面我们通过Gradle的构建，实现Build Variants，在一个工程中构建起来。
查看Android Studio 用户指南，这里面有关Gradle构建的文档，这里先设定好我们要接入的渠道名是special，这个渠道需要实现上面的需求，首先在主工程gradle中创建我们special的flavor
android {
...
defaultConfig {...}
buildTypes {...}
productFlavors {
normal {
applicationId "com.example.testdemo.normal"
versionName "1.0"
}
special {
applicationId "com.example.testdemo.special"
versionName "1.0"
}
}
}
我们修改了我们的包名，那么修改包名的需求就已经完成了。也许有些同学会问，我怎么知道哪些参数可以写呢？可以通过查看文档Android-gradle-DSL-ProductFlavor。DSL（领域特定语言）这种语言你必须要了解其定义你才知道怎么用，查看文档是少不了的了。
使用manifestPlaceholders，把我们flavors与渠道绑定。在使用友盟的话，可能在在manifest中有这样的定义
<meta-data
android:name="UMENG_CHANNEL"
android:value="{$CHANNEL}" />
然后在gradle中配置，这样渠道跟flavor就关联起来了
productFlavors {
normal {
applicationId "com.example.testdemo.normal"
versionName "1.0"
manifestPlaceholders = [ "CHANNEL": "normal"]
}
special {
applicationId "com.example.testdemo.special"
versionName "1.0"
manifestPlaceholders = [ "CHANNEL": "special"]
}
}
其实我们可以在gradle文件设置默认配置，这样flavor中没有配置的就会使用默认配置，配置了则会覆盖默认的
defaultConfig {
applicationId "com.example.testdemo.normal"
minSdkVersion 14
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
接下来，我的special渠道方要求我们导入一个special.jar的jar包，来接入他的账户系统或者支付，怎样做到渠道依赖独立呢？在gradle中我们可以通过flavorCompile的方式来进行渠道依赖
dependencies {
compile files('libs/commom.jar')
specialCompile('libs/special.jar')
}
注意：flavorCompile这个方式，在productFlavors的flavor必须首字母小写才能生效。例如flavor是Special的话SpecialCompile编译都过不了
选择自己想要flavor运行，打开Build，选择Selcet Build Variant
在Build Variant中有选择specialDebug，运行即是debug的special渠道包。
接入渠道方账号或者支付，就无法避免要引用到jar包的代码，这样就需要把代码也根据渠道来区分开来。我们可以创建flavor文件夹来区别渠道渠道独立的代码，在src创建flavor名字一直的文件夹，文件夹结构跟main的一致即可
这里需要注意的是，flavor跟main的文件是会合并的，合并存在一定的规则。
java中代码合并，如果有相同的文件是会报错重复错误的，所以main文件夹中，应该存放共有的代码，而flavor文件夹中存放自己所需要的独立的代码。
res中资源的合并，优先级是flavor高于main，即flavor中资源会加入或覆盖main中资源。如果special渠道要求指定的icon和appName，则在special中res中替换到默认的icon，在string.xml中改正相应的appName即可。
AndroidManifest.xml合并，其实也是增加和覆盖，但是往往我们合并的时候会遇到Merge failed的情况，例如：
这个是因为我在main的Manifest中MainActivity设置了竖屏，而在special的Manifest中设置了横屏，从而报错。那么遇到这种情况怎么处理呢？查看Android Studio 用户指南manifest-merge文段，我们可以使用manifest marker解决这个问题，在special的Manifest中使用tools:node="replace"就可以解决这个问题啦。
申请的appkey，如果在manifest中声明也会根据Manifest的规则合并进去。
总结一下，通过上面的方式，我们实现了应用包名不同，资源代码根据渠道分离。而且包体中不包含其他渠道所需的jar包，精简了包体大小，代码也是在同一的分支上，不需要切换分支和版本升级合并维护的繁琐。
Gradle功能强大，我目前对于gradle的语言的学习，也仅仅是查文档的阶段，发现Android Studio 用户指南 和 Android-gradle-DSL-Reference真的非常好用，熟悉这两个文档一般都可以完成项目的多渠道定制化需求。而关于Gradle 定制task，关于grovvy相关我自己还不是很清楚，以后学习了有机会再分享给大家。
关于Gradle认知，这篇文章很全面，有时间一定多看几遍Gradle详解
参考：
https://developer.android.com/studio/build/index.html
http://google.github.io/android-gradle-dsl/current/index.html
http://www.infoq.com/cn/articles/android-in-depth-gradle/
