android studio的构建系统Gradle处理依赖的方式

Android Studio的构建系统Gradle处理依赖的方式

经过 2 年时间的研发，Google 在2014年12月8日正式发布了面向 Android 开发者的集成开发环境 Android Studio 1.0（第一个稳定版）。

Android Studio 是 Google 开发的一款面向 Android 开发者的 IDE，支持

Windows、Mac、Linux 等操作系统，基于流行的 Java 语言集成开发环境 IntelliJ

搭建而成。

Android Studio基于Gradle来构建项目。Gradle是一个新的构建工具，自Studio亮相之处就支持Gradle。Gradle集合了Ant和Maven的优点，不管是配置、编译、打包都非常棒。

一个典型的android项目的Gradle脚本如下：

buildscript {

repositories {

mavenCentral()

}

dependencies {

classpath ':gradle:0.4'

}

}

apply plugin: 'android'

android {

compileSdkVersion 17

}

其中的各个条目解释如下：

buildscript{}设置脚本的运行环境。

repositories{}支持java依赖库管理（maven/ivy）,用于项目的依赖。

dependencies{}依赖包的定义。支持maven/ivy，远程，本地库，也支持单文件。如果前面定义了repositories{}maven 库，则使用maven的依赖库，使用时只需要按照用类似于:gradle:0.4，gradle 就会自动的往远程库下载相应的依赖。

apply plugin:声明构建的项目类型。

android{}设置编译android项目的参数，构建android项目的所有配置都写在这里。

下面重点介绍Gradle中关于依赖库的管理。

1.本地依赖

gradle作为构建工具，能够很方便的使用本地jar包，以下为使用的构建脚本关于依赖库的代码部分：

dependencies {

//单文件依赖

compile files('libs/')

//某个文件夹下面全部依赖

compile fileTree(dir: 'libs', include: '*.jar')

}

2.远程依赖

gradle同时支持maven，ivy，以maven作为例子：

repositories {

//从中央库里面获取依赖

mavenCentral()

//或者使用指定的本地maven 库

maven{

url "file://F:/githubrepo/releases"

}

//或者使用指定的远程maven库

maven{

url "/youxiachai/youxiachai-mvn-repo/raw/master/releases"

}

}

dependencies {

//应用格式: packageName:artifactId:version

compile 'd:support-v4:r13'

}

d library的依赖

对于项目依赖 android library的话，在这里需要使用gradle mulit project机制。

Mulit project设置是gradle约定的一种格式，如果需要编译某个项目之前，要先编译另外一个项目的时候，就需要用到。结构如下（来自于官方文档）：

MyProject/

|

+ app/

|

+ libraries/

+ lib1/

|

+ lib2/

|

需要在workplace目录下面创建 的文件，然后在里面写上：

include ':app', ':libraries:lib1', ':libraries:lib2'

如此，gradle mutil project 就设置完毕。

对于app project如果需要应用libraries目录下的 lib1，只需要在app project的文件里的依赖中这么写：

compile project(':libraries:lib1')

即可完成，写完以后可以用gradle AndroidDependencies可以检查依赖状况。

《附录》

《附1：Apach maven工具》

Maven是一个项目管理和构建自动化工具。但是对于程序员来说，最关心的是它的项目构建功能。

maven的配置文件==>

一个使用Maven进行构建的项目会包含一个POM文件，其中保存所有的配置：定义项目的类型、名字，管理依赖关系，定制插件的行为等等。比如说，可以配置compiler插件让它使用java 1.5来编译等。

一个典型的pom文件列出如下：

Xml 代码

xmlns:xsi="/2001/XMLSchema-instance"

xsi:schemaLocation="/POM/4.0.0

/xsd/">

4.0.0

orld

helloworld

1.0-SNAPSHOT

jar

helloworld

UTF-8

junit

junit

3.8.1

test

在 POM 中，groupId, artifactId, packaging, version 叫作 maven 坐标，它能唯一的确定一个项目。有了 maven 坐标，我们就可以用它来指定我们的项目所依赖的其他项目，插件，或者父项目。

maven解析项目依赖关系==>

Maven坐标能够确定一个项目。换句话说，我们可以用它来解决依赖关系。在POM中，依赖关系是在 dependencies 部分中定义的。在上面的 POM 例子中，我们用 dependencies 定义了对于 junit 的依赖：

Xml 代码

junit

junit

3.8.1

test

这个例子很简单，但是实际开发中我们会有复杂得多的依赖关系，因为被依赖的

jar 文件会有自己的依赖关系。那么我们是不是需要把那些间接依赖的 jar 文件也都定义在POM中呢？答案是不需要，因为 maven 提供了传递依赖的特性。

所谓传递依赖是指 maven 会检查被依赖的 jar 文件，把它的依赖关系纳入最终解决的依赖关系链中。针对上面的 junit 依赖关系，如果你看一下 maven 的本地库（下面会介绍maven库的概念）~/.m2/repository/junit/junit/3.8.1/ ，就会发现 maven 不但下载了 ，还下载了它的 POM 文件。这样 maven 就能检查 junit 的依赖关系，把它所需要的依赖也包括进来。

在 POM 的 dependencies 部分中，scope 字段决定了依赖关系的适用范围。我们的例子中 junit 的 scope 是 test，那么它只会在执行 compiler:testCompile and

surefire:test 目标的时候才会被加到 classpath 中，在执行 compiler:compile 目标时是拿不到 junit 的。

我们还可以指定 scope 为 provided，意思是 JDK 或者容器会提供所需的jar文件。比如说在做web应用开发的时候，我们在编译的时候需要 servlet API jar 文件，但是在打包的时候不需要把这个 jar 文件打在 WAR 中，因为servlet容器或者应用服务器会提供的。

scope 的默认值是 compile，即任何时候都会被包含在 classpath 中，在打包的时候也会被包括进去。

Maven 库==>

当第一次运行 maven 命令的时候，需要 Internet 连接，因为它要从网上下载一些文件。那么它从哪里下载呢？它是从 maven 默认的远程库(/maven2) 下载的。这个远程库有 maven 的核心插件和可供下载的 jar 文件。

但是不是所有的 jar 文件都是可以从默认的远程库下载的，比如说我们自己开发的项目。这个时候，有两个选择：要么在公司内部设置定制库，要么手动下载和安装所需的jar文件到本地库。

本地库是指 maven 下载了插件或者 jar 文件后存放在本地机器上的拷贝。在

Linux 上，它的位置在 ~/.m2/repository，在 Windows XP 上，在 C:Documents

and Settingsusername.m2repository ，在 Windows 7 上，在

C:Usersusername.m2repository。当 maven 查找需要的 jar 文件时，它会先在本地库中寻找，只有在找不到的情况下，才会去远程库中找。

运行下面的命令能把我们自己的项目（例如helloworld）安装到本地库：

$mvn install

一旦一个项目被安装到了本地库后，别的项目就可以通过 maven 坐标和这个项

目建立依赖关系。比如如果我现在有一个新项目需要用到 helloworld，那么在运行了上面的 mvn install 命令后，我就可以如下所示来建立依赖关系：

Xml 代码

orld

helloworld

1.0-SNAPSHOT

《附2：Java虚拟机》

Java虚拟机（Java Virtual Machine，JVM）是软件模拟的计算机，它可以在任何处理器上（无论是在计算机中还是在其他电子设备中）安全兼容地执行保存在.class文件中的字节码。Java虚拟机的“机器码”保存在.class文件中，有时也可以称之为字节码文件。

Java程序的跨平台特性主要是指字节码文件可以在任何具有Java虚拟机的计算机或者电子设备上运行，Java虚拟机中的Java解释器负责将字节码文件解释成为特定的机器码进行运行。因此在运行时，Java源程序需要通过编译器编译成为.class文件。

Java虚拟机的建立需要针对不同的软硬件平台来实现，既要考虑处理器的型号，也要考虑操作系统的种类。由此在SPARC结构、X86结构、MIPS和PPC等嵌入式处理芯片上，在UNIX、Linux、Windows和部分实时操作系统上都可实现Java虚拟机。

几乎所有的语言都需要通过编译或者解释才可以被计算机执行，但是Java有一点不同，它同时需要这两个过程。其实，也正是因为这个原因才使Java这种语言具有了平台无关性。当完成一个Java源程序后，首先，通过Java翻译程序将它编译成一种叫做字节码的中间代码，然后再由Java平台的解释器将它转换成为机器语言来执行，这一平台的核心就是JVM。

Java的编译过程与其他的语言不同。像C++这样的语言，在编译时它是与计算机的硬件平台信息密不可分的。编译程序通过查表将所有指令的操作数和操作码等转换成内存的偏移量，即程序运行时的内存分配方式，目的是保证程序正常运行。而Java却是将指令转换成为一种.class的文件，这种文件不包含硬件的信息，需要执行时只要经过安装有JVM的机器进行解释，创建内存分配后再通过查表来确定一条指令所在的地址。这样就有效地保证了Java的可移植性和安全性。