多Module构建
通常一个多Module的工程会有一个根目录,而它的子目录下包含了所有的Module。为了告诉Gradle这个Project的结构,这个目录下包含了所有要构建的Modules,并且会有一个settings.gradle
文件放在这个Project的根目录下。每一个Module都可以提供它自己的build.gradle
文件。
一个多Module的Project目录结构如下:
代码语言:javascript复制project
├─── setting.gradle
├─── build.gradle
├─── app
│ └─── build.gradle
└─── library
└─── build.gradle
这是一个最简单最直接多Module工程的配置。settings.gradle
文件声明了在这个工程中的所有Module:
include ':app', ':library'
它保证了app
和library
模块都包含在了Build配置中。我们所需要做的就是把模块的路径和名称添加到这个文件中即可。
如果需要把library
模块作为依赖,包含到app
模块的话,需要在app
这个模块的build.gradle
中添加以下代码:
dependencies {
compile project(':library')
}
为了在一个Module中添加一个依赖Lib,需要使用project()
这个函数,并且将该Lib的路径作为参数。如果想要使用子目录来组成Module的话,Gradle也可以进行配置,例如下面的工程结构:
project
├─── setting.gradle
├─── build.gradle
├─── app
│ └─── build.gradle
└─── libraries
├─── library1
│ └─── build.gradle
└─── library2
└─── build.gradle
在这种情况下app
模块仍然在根目录下,但是Project会有两个不同的Library,并且这些Library没有在根目录下,而是在一个子目录libraries
下。像这种目录结构,我们可以在settings.gradle
中使用以下声明:
include ':app', ':libraries:library1', ':libraries:library2'
所有的路径都是相对于根目录而言的,而根目录的定义也就是settings.gradle
文件所在的地方。
当添加一个子目录的Module作为另一个Module的依赖关系的话,你应该相对于根目录来引用它。也就意味着,假如上述例子中,app
模块依赖于library1
,那么在app
模块中的build.gradle
文件如下:
dependencies {
compile project(':libraries:library1')
}
如果你声明了子目录的依赖关系,所有的Path都应该相对于根目录。因为Gradle创建所有工程的依赖模型都是从Project的根目录开始的。
The build lifecycle revisited
了解构建过程模型会有助于理解多Module工程的打包。
在第一个阶段,也就是initialization
阶段,Gradle会找到settings.gradle
文件。如果这个文件不存在的话,那么Gradle会认为你只有一个单独的Module需要构建。如果有多个Module的话,那么这个settings.gradle
文件就是可以定义子Module的地方。
如果这些子目录都有自己的build.gradle
文件,那么Gradle就会处理这些,并且把他们添加到构建过程的Model中。这也就是为什么你应该在Module中使用相对于根目录的路径进行依赖。Gradle总是会根据根目录来配置依赖关系。
一旦你知道了构建过程Model是如何把他们放到一起的时候,我们也就知道了配置多Module的构建配置。我们可以在根目录的build.gradle
中配置给所有的Module中使用的属性和设置。这样有助于我们可以得到整个Build Configuration的预览,不过可能会比较复杂,尤其是当你有很多不同的plugins的时候。
另一方面,每个模块都有单独的build.gradle
文件,这种策略可以保证各个模块间不会那么紧密,并且它也可以更好的跟踪Build的修改,因为日志中就会打印出来它归属于哪个Module。
你可以在根目录下拥有一个Build文件,来定义一些通用的属性,让所有的Module都可以读取,而且每一个模块的配置都只在自己的模块内部生效,所以Android Studio在根目录创建了一个build.gradle
文件,并且在Module中同样也有build.gradle
文件。
Module tasks
当你已经拥有了多模块的工程后,你需要在执行任务之前思考一下。
当使用命令行在Project的根目录下执行一个Task的时候,Gradle会检查出哪个模块有这个名字的Task,然后为每个模块执行这个任务
例如,有一个Mobile APP模块,还有一个Android Wear模块,当执行
gradlew assembleDebug
的时候,就会构建Debug版本的Mobile App和Android Wear模块。当你修改路径到一个特殊的Module时,Gradle将只会执行单独的模块,即使你在Project的根目录下使用Gradle Wrapper的时候也一样。例如,执行../gradlew assembleDebug
在Android Wear模块的目录下,将只会构建Android Wear模块。
改变目录,然后执行module中指定的任务来构建单独的模块会比较麻烦。我们可以配置Module名字以及Task名字,然后执行,就只会在特殊的Module中执行指定Task。例如,为了只构建Android Wear模块,我们可以使用gradlew :wear:assembleDebug
命令来单独构建该模块。
Adding a Java library
当添加一个新的Java Library Module的话,Android Studio生成出来的build.gradle
会跟下面的一样:
apply plugin: 'java'
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
}
Java Library Module会使用java
插件,而不是使用Android Plugin。这也意味着很多Android特殊的属性和任务都不可用,不过在一个Java Library也不需要那些。
build.gradle
也有基本的依赖管理,所以我们可以在libs
目录下添加Jar文件,而不需要特殊的配置。如果需要添加一个Java Library Module名为javalib
作为你App的依赖的话,需要添加这一行:
dependencies {
compile project(':javalib')
}
这也告诉Gradle去引入一个名为javalib
的模块。如果添加了这个依赖的话,那么javalib
这个模块总会在App模块构建前完成构建。
Adding an Android library
生成一个Android Library,默认的build.gradle
文件会以如下开始:
apply plugin: 'com.android.library'
添加其他工程的依赖于Java Library相同:
代码语言:javascript复制dependencies {
compile project(':androidlib')
}
一个Android Library不仅仅只包含Java代码,还有Android的资源,比如说Strings,layouts,Manifest等。在引用了Android Library之后,我们可以使用Library的类以及资源。
Analyzing the build file
build.gradle
文件比较大,所以只看一下一些比较重要的部分:
buildscript {
dependencies {
classpath 'com.google.appengine:gradle-appengine-plugin:1.9.18'
}
}
App Engine Plugin需要在构建脚本中添加classpath
。
我们在添加Android Plugin的时候见到过,而在这个地方,我们可以再添加其他的两个插件:
代码语言:javascript复制 apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'appengine'
java
插件主要用来生成Jar包。而war
插件是后端运行和分发的重要的插件,这个插件会生成一个War文件,可以在Java Web应用中被应用。最后appengine
插件可以加载一系列构建的Task,执行并且部署后端。
下一个比较重要的代码块定义了App Engine模块的依赖:
代码语言:javascript复制dependencies {
appengineSdk 'com.google.appengine:appengine-java-sdk:1.9.18'
compile 'com.google.appengine:appengine-endpoints:1.9.18'
compile 'com.google.appengine:appengine-endpoints-deps:1.9.18'
compile 'javax.servlet:servlet-api:2.5'
}
第一个依赖使用了appengineSdk
,指定了这个Module使用的SDK。endpoints``这个依赖是Cloud Enpoints工作所必须依赖的库,只有当你选择使用了Cloud Endpoints才需要被添加。而
servlet```则是为了一些Google App Engine模块所使用的。
在appengine
代码块中指定App Engine特殊的配置:
appengine {
downloadSdk = true
appcfg {
oauth2 = true
}
endpoints {
getClientLibsOnBuild = true
getDiscoveryDocsOnBuild = true
}
}
downloadSdk
属性可以改变本地开发环境是否下载SDK。如果你已经在设备上安装了Google App Engine SDK的话,你可以设置downloadSdk
属性为false。
appcfg
代码块用来配置App Engine SDK,在一个典型的Google App Engine的安装过程中,你可能手动的在命令行配置一些参数。而使用appcfg
代码块后,可以使用它来替代命令行参数。
endpoints
代码块包含了一些Cloud Endpoints特殊的配置。
Using the backend in an app
当创建了一个App Engine模块的时候,Android Studio会自动的在build.gradle
文件中添加依赖。
dependencies {
compile project(path: ':backend', configuration: 'android-endpoints')
}
Speeding up multimodule builds
当构建一个多Module的工程时候,Gradle处理会线性的处理所有Module。随着电脑的核越来越多,我们可以让构建的过程并行处理。该特性已经在Gradle中存在了,但是默认是不可用的。如果你想在工程中应用的话,需要在gradle.properties
中添加配置:
org.gradle.parallel=true
Module coupling
当你有多Module的工程的话,你可以使用allprojects
在任何模块中用到这些属性。Gradle可以让一个模块去引用另外一个模块的属性,这样会使得多模块的构建变得简单一些,但是会让模块间变得耦合。
两个模块间当要访问对方Task或者Properties的时候,就会变得耦合。