gradle variants 认识

• 认识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

1. free-beijing-debug

1. free-shanghai-release
2. paid-beijing-debug
3. paid-shanghai-release
4. free-beijing-debug
5. free-shanghai-release
6. paid-beijing-debug
7. 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里面吧，后者至少用到了抽象。虽然都是很糟糕。
为什么代码设计可以提高代码质量？
它提供了一个审视代码的高角度，你在代码设计的时候不需要纠结具体的实现。
设计的时候就决定好大概有哪些类，每个类的职责是什么，并将重要的方法定义好。
这样，就可以看清楚类之间的关系以及它的作用是什么。这时候各种设计模式就走用武之地了，怎么继承，怎么组合，就有个数了。
不过这只是涉及代码结构优化，算法的精良化就无能为力了。