-
认识gradle编译工具
buildVariants = productFlavors * buildType
也就是，如果 buildType=2个 , productFlavors=3个 ,就会有 2 * 3 = 6 个buildVariants。buildType 跟 productFlavors 可以独立增加。另外，默认就会有2个buildType，分别是 release与debug。
这个看起来有点多，但 buildVariants 是可以过滤的
如果不嫌多，还可以增加维度
// 这里增加了2个维度'version','area'
flavorDimensions 'version', 'area'
productFlavors {
beijing{
dimension 'area'
}
shanghai{
dimension 'area'
}
free{
dimension 'version'
}
paid{
dimension 'version'
}
}
那么，productFlavors 就有 [free,paid]+[beijing,shanghai]=4 个，组合上默认的2个 buildTypes，就有 8 个 buildVariants
- free-beijing-debug
- free-shanghai-release
- paid-beijing-debug
- paid-shanghai-release
- free-beijing-debug
- free-shanghai-release
- paid-beijing-debug
- paid-shanghai-release
过滤 buildVariants
android {
productFlavors {
realData
fakeData
}
variantFilter { variant ->
def names = variant.flavors*.name
if (names.contains("fakeData") && variant.buildType.name == "release") {
variant.ignore = true
}
// 甚至可以在这里写一些通用配置
if (names.contains("fakeData")) {
variant.buildConfigField "String", "CHANNEL", "google play"
}
}}
可以在 buildType或productFlavor中添加一些属性buildConfigField，用来提供不同版本的参数，在代码中可以通过 buildConfig 静态类获得这些变量
同样地，也可以增加提供给androidManifest使用的参数，ManifestPlaceholders。gradle guide
-
一个思考
看到别人写的代码有时候会很惊艳：构思精密，实现优雅。为什么这样的代码我就写不出来呢？
结论是，我没有做代码设计。
虽然软件工程里面有代码设计这一步，但是不知道有多少个开发组的开发流程中包含了这一块。
有的只是紧跟着每一个需求，从头到尾开始写代码。遇到有重复的地方？拷贝，或者抽取出来放到Utils里面吧，后者至少用到了抽象。虽然都是很糟糕。
为什么代码设计可以提高代码质量？
它提供了一个审视代码的高角度，你在代码设计的时候不需要纠结具体的实现。
设计的时候就决定好大概有哪些类，每个类的职责是什么，并将重要的方法定义好。
这样，就可以看清楚类之间的关系以及它的作用是什么。这时候各种设计模式就走用武之地了，怎么继承，怎么组合，就有个数了。
不过这只是涉及代码结构优化，算法的精良化就无能为力了。
