使用 buildTypes 进行特殊处理

• 项目使用神策进行埋点，神策在 init()的时候，如果是神策的 debug 的话支持实时查看埋点，每次写完业务代码在测试的时候需要测试新功能在神策上的埋点。
  而业务对于神策有3种处理方式，release环境，debug 环境，因为 debug 环境是不上报神策的，隐藏增加神策 debug，即release 上报，debug 上报，不上报。
  而一切业务功能又区分渠道，比如外内外渠道的支付 google play 或者是微信。

• 一番思考后，决定在 release,debug两种buildTypes后增加一种sensors，这个模式下打开神策的 debug，release下神策采用 release，debug下关闭神策的上报。

• gradle 3.0以上，如果在 app 增加 buildTypes 而 library 没有对应的，会报错，因此第一步要解决这个问题

sensors {
    }
//对所有的子项目的 buildType 采取回退策略，即如果找不到对应的 buildTypes，
//则按照 matchingFallbacks 进行匹配
 buildTypes.all { type ->
    type.matchingFallbacks = ['debug']
  }

在 AndroidManifest 增加 meta-data作为是否打开神策 debug 的开关

<meta-data
        android:name="sensors"
        android:value="${sensors}"/>

对各 buildTypes 中的 snesors 字段进行配置

buildTypes {
    release {
      addManifestPlaceholders([sensors: false])
    }

    debug {
      addManifestPlaceholders([sensors: false])
    }

    //gradle 3.0后，如果 app 中的版本没有再子项目定义，会报错
    sensors {
      addManifestPlaceholders([sensors: true])
    }
  }

因此，在代码中有了release/debug;sensors=true/false 的四种情况

if(sensors==true){
  //神策debug 模式
}else{
  if(release){
  //开启神策正常上报模式
  }else{
  //关闭神策统计
  }
}

Android Studio 使用 Gradle 进行自动化构建，而android{}是'com.android.application'的插件,因此学习 Gradle 与'com.android.application'插件非常有必要，而以上的思路也是通过学习 Android Gradle 想到说增加 buildTypes来优化实际业务需求的