gradle 的琐碎知识

废话：今天看了很多关于gradle的文章，终于知道它大概是干啥的了，就是一个帮助项目构建的工具（自己理解），比如项目依赖哪些子模块，以及gradle中都有什么tast(这些子模块和任务都会按照一定的顺序和依赖关系被加载和执行)

1：manifestPlaceholders

有时候会有这样的需求，根据不同的情况生成不同的值（测试环境使用测试环境的服务器url,发布服务器使用发布线上服务器的url.）

androidManifest.xml中会有data属性进行配置，这个时候可以进行value的动态获取如下

<meta-data
   


   android:name="umeng_app_key"


   android:value="${umeng_app_key}" />


这个name会在应用中进行获取使用，这里的value是动态进行获取的。

manifestPlaceholders = [umeng_app_key: "你替代的内容"]

这句话可以在不同的编译版本中赋不同的值，例如可以在buildType为debug的时候可以赋值value1,在release模式中可以赋值value2,这样就可以根据不同的编译类型进行获取不同的值了。

2:buildConfigField

这个值用来定义全局的变量，在java类中可以通过 buildConfig.YOUR_KEY 来获取在gradle中的配置，并且有一个好处就是可以根据不同的编译类型赋不同的值。具体demo如下

buildConfigField "String", "YOUR_KEY", "\"1234567890\""

3：productFlavors（不同定制的产品）

一个product flavor定义了从项目中构建了一个应用的自定义版本。一个单一的项目可以同时定义多个不同的flavor来改变应用的输出。
这个新的设计概念是为了解决不同的版本之间的差异非常小的情况。虽然最项目终生成了多个定制的版本，但是它们本质上都是同一个应用，那么这种做法可能是比使用库项目更好的实现方式。

每一个flavor都是通过闭包来配置的。

demo1:

productFlavors {
  

   name1 {
       

      applicationId “包名1”
    }


   name2 {
       

      applicationId “包名2”
    }


}

demo2:

productFlavors { 
        flavor1 { 
            packageName "com.example.flavor1" 
            versionCode 20 
        } 
 
        flavor2 { 
            packageName "com.example.flavor2" 
            minSdkVersion 14 
        } 
 }

Build Type  + Product Flavor = Build Variant（构建类型+定制产品=构建变种版本）。

每一个Build Type都会生成一个新的APK。Product Flavor同样也会做这些事情。项目的输出将会拼接所有可能的Build Type和Product Flavor（如果有Flavor定义存在的话）的组合。每一种组合（包含Build Type和Product Flavor）就是一个Build Variant（构建变种版本）。

例如上面声明的demo2 和 debug、release结合就会生成4个版本。

flavor1-debug、flavor1-release、flavor2-debug、flavor2-release

注意ProductFlavor类型的 Android.productFlavors.* 对象与 android.defaultConfig 对象的类型是相同的。这意味着它们共享相同的属性。

通常情况下，Build Type的配置会覆盖其它的配置。例如，Build Type的packageNameSuffix会被追加到Product Flavor的packageName上面。

参考：http://blog.youkuaiyun.com/qinxiandiqi/article/details/37906449