Gradle for Android 脚本编写总结

build.gradle的配置文件
基于grade构建的项目通常至少有一个build.gradle，那么我们来看看Android的build.gradle：

buildscript {   repositories {        jcenter()   }   dependencies {       classpath 'com.android.tools.build:gradle:1.2.3'  } }

这个就是实际构建开始的地方，在仓库地址中，我们使用了JCenter，JCenter类似maven库，不需要任何额外的配置，grade还支持其他几个仓库，不论是远程还是本地仓库。

构建脚本也定义了一个Android构建工具，这个就是Android plugin的来源之处。Android plugin提供了所有需要去构建和测试的应用。每个Android应用都需要这么一个插件：

apply plugin: 'com.android.application'

理解Gradle脚本
当然我们现在讨论的所有内容都是基于Android studio的，所以请先行下载相关工具。当我们创建一个新的工程，Android studio会默认为我们创建三个gradle文件，两个build.gradle，一个settings.gradle，build.gradle分别放在了根目录和moudle目录下，下面是gradle文件的构成图：

 MyApp   ├── build.gradle   ├── settings.gradle   └── app       └── build.gradle

setting.gradle解析
当你的app只有一个模块的时候，你的setting.gradle将会是这样子的：

include ':app'

模块内的build.gradle
模块内的gradle文件只对该模块起作用，而且其可以重写任何的参数来自于根目录下的gradle文件。该模块文件应该是这样：

 apply plugin: 'com.android.application'   android {       compileSdkVersion 22       buildToolsVersion "22.0.1"       defaultConfig {           applicationId "com.gradleforandroid.gettingstarted"           minSdkVersion 14           targetSdkVersion 22           versionCode 1           versionName "1.0"            //解决Dex 文件方法数超过了最大值65535的上限            multiDexEnabled true           //Manifest 替换字符           manifestPlaceholders = [                            JPUSH_PKGNAME: applicationId,                            JPUSH_APPKEY : "cfdf4a312958c47d85c37443",                            JPUSH_CHANNEL: "developer-default",                    ]       }       buildTypes {           release {                zipAlignEnabled true                minifyEnabled true                shrinkResources true                proguardFiles getDefaultProguardFile                ('proguard-android.txt'), 'proguard-rules.pro'           }        }      //忽略lint错误   lintOptions {        abortOnError false    }    //dex method过多， 配置    dexOptions {        //incremental true        javaMaxHeapSize "4g"    }    // If you need to add more flavors, consider using flavor dimensions.    productFlavors {        mock {            applicationIdSuffix = ".mock"             manifestPlaceholders = [UMENG_CHANNEL_VALUE: "Umeng"]        }        prod {        }    }    // Remove mockRelease as it's not needed.    android.variantFilter { variant ->        if(variant.buildType.name.equals('release')                && variant.getFlavors().get(0).name.equals('mock')) {            variant.setIgnore(true);        }    }    }    dependencies {       compile fileTree(dir: 'libs', include: ['*.jar'])       compile 'com.android.support:appcompat-v7:22.2.0'     }

BuildConfig和resources

android {    buildTypes {        debug {            buildConfigField "String", "API_URL",               "\"http://test.example.com/api\""               buildConfigField "boolean", "LOG_HTTP_CALLS", "true"     }       release {            buildConfigField "String", "API_URL",                "\"http://example.com/api\""               buildConfigField "boolean", "LOG_HTTP_CALLS","false"     }  }

类似这些定义的常量，当定义了这些属性后，你完全可以在代码中使用：BuildConfig.API_URL和BuildConfig.LOG_HTTP

最近，Android tools team也让其里面定义string变为可能：

android {       buildTypes {           debug {               resValue "string", "app_name", "Example DEBUG"           }           release {               resValue "string", "app_name", "Example"            }        }}

你可以在代码中使用这些string。其中“”不是必须得。

全局设置
如果你有很多模块在一个工程下，你可以这么定义你的project文件。

allprojects {       apply plugin: 'com.android.application'       android {           compileSdkVersion 22           buildToolsVersion "22.0.1"       } }

这只会在你的所有模块都是Android app应用的时候有效。你需要添加Android 插件才能访问Android的tasks。更好的做法是你在全局的gradle文件中定义一些属性，然后再模块中运用它们。比如你可以在根目录下这么定义：

 ext {       compileSdkVersion = 22       buildToolsVersion = "22.0.1"}

那么你在子模块中就可以使用这些属性了：

android {       compileSdkVersion rootProject.ext.compileSdkVersion       buildToolsVersion rootProject.ext.buildToolsVersion }

Project properties文件
上述方法是一种办法，当然还有很多办法：

列表内容
ext方法 gradle.properties文件
-p参数

ext {     local = 'Hello from build.gradle'}   task printProperties << {     println local        // Local extra property     println propertiesFile        // Property from file     if (project.hasProperty('cmd')) {       println cmd        // Command line property     }}

当然你可以在gradle.properties中定义：

propertiesFile = Hello from gradle.properties
你也可以输入命令行：

$ gradlew printProperties -Pcmd=’Hello from the command line’
:printProperties
Hello from build.gradle
Hello from gradle.properties
Hello from the command line

签名配置
在你发布你的应用之前，你需要为你的app私钥签名。如果你有付费版和免费版，你需要有不同的key去签名不同的变体。这就是配置签名的好处。配置签名可以这样定义：

   android {       signingConfigs {           staging.initWith(signingConfigs.debug)           release {               storeFile file("release.keystore")               storePassword"secretpassword"               keyAlias "gradleforandroid"               keyPassword "secretpassword"           }      }}

在这个例子中，我们创建了2个不同的签名配置。debug配置是as默认的，其使用了公共的keystore和password，所以没有必要为debug版本创建签名配置了。staging配置使用了initWith()方法，其会复制其他的签名配置。这意味着staging和debug的key是一样的。

release配置使用了storeFile，定义了key alias和密码。当然这不是一个好的选择，你需要在 Gradle properties文件中配置。

当你定义了签名配置后，你需要应用它们。构建版本都有一个属性叫做signingConfig，你可以这么干：

android {       buildTypes {           release {               signingConfig signingConfigs.release           }        }}

上例使用了buildTypes，但是你可能需要对每个版本生成不同的验证，你可以这么定义：

android {       productFlavors {           blue {               signingConfig signingConfigs.release           }       }}

当然，你在flavor中定义这些，最好会被重写，所以最好的做法是：

android {       buildTypes {           release {               productFlavors.red.signingConfig signingConfigs.red               productFlavors.blue.signingConfig signingConfigs.blue           }       }}

多模块构建的结构
这是最简单最直接的方式来创建你的多模块项目了。setting.gradle文件申明了该项目下的所有模块，它应该是这样：

include ':app', ':library'

这保证了app和library模块都会包含在构建配置中。你需要做的仅仅只是为你的模块添加子文件夹。

为了在你的app模块中添加library模块做为其依赖包，你需要在app的build.gradle文件中添加以下内容：

dependencies {      compile project(':library') }

为了给app添加一个模块作为依赖，你需要使用project()方法，该方法的参数为模块路径。

如果在你的模块中还包含了子模块，gradle可以满足你得要求。举个栗子，你可以把你的目录结构定义为这样：

project├─── setting.gradle├─── build.grade├─── app│    └─── build.gradle└─── libraries     ├─── library1     │    └─── build.gradle     └─── library2          └─── build.gradle

该app模块依然位于根目录，但是现在项目有2个不同的依赖包。这些依赖模块不位于项目的根目录，而是在特定的依赖文件夹内。根据这一结构，你需要在settings.xml中这么定义：

include ':app', ':libraries:library1', ':libraries:library2'

你会注意到在子目录下申明模块也非常的容易。所有的路径都是围绕着根目录，即当你添加一个位于子文件夹下的模块作为另外一个模块的依赖包得实惠，你应该将路径定为根目录。这意味着如果在上例中app模块想要依赖library1,build.gradle文件需要这么申明：

dependencies {       compile project(':libraries:library1')}

添加Java依赖库

当你新建了一个Java模块，build.grade文件会是这样：

apply plugin: 'java'   dependencies {       compile fileTree(dir: 'libs', include: ['*.jar'])}

Java模块使用了Java插件，这意味着很多Android特性在这儿不能使用，因为你不需要。

build文件也有基本的库管理，你可以添加jar文件在libs文件夹下。你可以添加更多的依赖库，根据第三章的内容。

给你的app模块添加Java模块，这很简单，不是吗？

dependencies {       compile project(':javalib')}

这告诉了gradle去引入一个叫做javelin的模块吧，如果你为你的app模块添加了这个依赖，那么javalib模块将会总是在你的app模块构建之前构建。

参考资料：
https://segmentfault.com/a/1190000004247809

更多相关文章

随机推荐