Gradle for Android 第三篇 (依赖管理)

原文地址 https://segmentfault.com/a/1190000004237922

依赖管理

这会是一个系列，所以如果你还没有看我之前的几篇文章，请先查看以下文章：

Gradle for Android 第一篇 (从 Gradle 和 AS 开始)
Gradle for Android 第二篇 (Build.gradle 入门)
Gradle for Android 第三篇 (依赖管理)
Gradle for Android 第四篇 (构建变体)
Gradle for Android 第五篇 (多模块构建)
Gradle for Android 第六篇 (测试)
Gradle for Android 第七篇 (Groovy 入门)

依赖管理是 Gradle 最闪耀的地方，最好的情景是，你仅仅只需添加一行代码在你的 build 文件，Gradle 会自动从远程仓库为你下载相关的 jar 包，并且保证你能够正确使用它们。Gradle 甚至可以为你做的更多，包括当你在你的工程里添加了多个相同的依赖，gradle 会为你排除掉相同的 jar 包。在这一章我们将学习以下内容：

• 仓库

• 本地依赖

• 详解依赖这一概念

仓库

当我们讨论依赖的时候，我们通常说的是远程仓库，就像那些依赖库专门用来提供给其他开发者使用的依赖库。手动管理依赖将会为你带来很大麻烦。你必须定位到该依赖文件位置，然后下载 jar 文件，复制该文件到你的项目，然后引用它们。通常这些 jar 文件还没有具体的版本号，所以你还必须去记忆它们的版本号，这样当需要更新的时候，你才会知道需要替换成哪个版本。你同时必须将该依赖包放在 svn 或者 git 上，这样你的其他同事才可以不用手动去下载这些依赖 jar。

使用远程仓库可以解决这些问题，一个仓库可以被视为一些文件的集合体。Gradle 不会默认为你的项目添加任何仓库。所以你需要把它们添加到 repositories 方法体内。如果是使用的是 Android studio，那么工具已经为你准备好了这一切：

repositories {
    jcenter()
}

Gradle 支持三种不同的仓库，分别是：Maven 和 Ivy 以及文件夹。依赖包会在你执行 build 构建的时候从这些远程仓库下载，当然 Gradle 会为你在本地保留缓存，所以一个特定版本的依赖包只需要下载一次。

一个依赖需要定义三个元素：group，name 和 version。group 意味着创建该 library 的组织名，通常这会是包名，name 是该 library 的唯一标示。version 是该 library 的版本号，我们来看看如何申明依赖：

dependencies {
       compile 'com.google.code.gson:gson:2.3'
       compile 'com.squareup.retrofit:retrofit:1.9.0'
}

上述的代码是基于 groovy 语法的，所以其完整的表述应该是这样的：

dependencies {
      compile group: 'com.google.code.gson', name: 'gson', version:'2.3'
      compile group: 'com.squareup.retrofit', name: 'retrofit'
           version: '1.9.0'
     }

为你的仓库预定义

为了方便，Gradle 会默认预定义三个 maven 仓库：Jcenter 和 mavenCentral 以及本地 maven 仓库。你可以同时申明它们：

repositories {
       mavenCentral()
       jcenter()
       mavenLocal()
   }

Maven 和 Jcenter 仓库是很出名的两大仓库。我们没必要同时使用他们，在这里我建议你们使用 jcenter，jcenter 是 maven 中心库的一个分支，这样你可以任意去切换这两个仓库。当然 jcenter 也支持了 https，而 maven 仓库并没有。

本地 maven 库是你曾使用过的所有依赖包的集合，当然你也可以添加自己的依赖包。默认情况下，你可以在你的 home 文件下找到. m2 的文件夹。除了这些仓库外，你还可以使用其他的公有的甚至是私有仓库。

远程仓库

有些组织，创建了一些有意思的插件或者 library, 他们更愿意把这些放在自己的 maven 库，而不是 maven 中心库或 jcenter。那么当你需要是要这些仓库的时候，你只需要在 maven 方法中加入 url 地址就好：

repositories {
       maven {
           url "http://repo.acmecorp.com/maven2"
       }
}

同样的，Ivy 仓库也可以这么做。Apache Ivy 在 ant 世界里是一个很出名的依赖管理工具。如果你的公司有自己的仓库，如果他们需要权限才能访问，你可以这么编写：

repositories {
       maven {
           url "http://repo.acmecorp.com/maven2"
           credentials {
               username 'user'
               password 'secretpassword'
           }
        } 
   }

注意：这不是一个好主意，最好的方式是把这些验证放在 Gradle properties 文件里，这些我们已经介绍过在第二章。

本地依赖

可能有些情况，你需要手动下载 jar 包，或者你想创建自己的 library，这样你就可以复用在不同的项目，而不必将该 library publish 到公有或者私有库。在上述情况下，可能你不需要网络资源，接下来我将介绍如何是使用这些 jar 依赖，以及如何导入 so 包，如何为你的项目添加依赖项目。

文件依赖

如果你想为你的工程添加 jar 文件作为依赖，你可以这样：

dependencies {
       compile files('libs/domoarigato.jar')
}

如果你这么做，那会很愚蠢，因为当你有很多这样的 jar 包时，你可以改写为：

dependencies {
       compile fileTree('libs')
 }

默认情况下，新建的 Android 项目会有一个 lib 文件夹，并且会在依赖中这么定义（即添加所有在 libs 文件夹中的 jar）：

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

这也意味着，在任何一个 Android 项目中，你都可以把一个 jar 文件放在到 libs 文件夹下，其会自动的将其添加到编译路径以及最后的 APK 文件。

native 包（so 包）

用 c 或者 c++ 写的 library 会被叫做 so 包，Android 插件默认情况下支持 native 包，你需要把. so 文件放在对应的文件夹中：

app
   ├── AndroidManifest.xml
   └── jniLibs
       ├── armeabi
       │   └── nativelib.so
       ├── armeabi-v7a
       │   └── nativelib.so
       ├── mips
       │   └── nativelib.so
       └── x86
           └── nativelib.so

aar 文件

如果你想分享一个 library, 该依赖包使用了 Android api，或者包含了 Android 资源文件，那么 aar 文件适合你。依赖库和应用工程是一样的，你可以使用相同的 tasks 来构建和测试你的依赖工程，当然他们也可以有不同的构建版本。应用工程和依赖工程的区别在于输出文件，应用工程会生成 APK 文件，并且其可以安装在 Android 设备上，而依赖工程会生成. aar 文件。该文件可以被 Android 应用工程当做依赖来使用。

创建和使用依赖工程模块

不同的是，你需要加不同的插件：

apply plugin: 'com.android.library'

我们有两种方式去使用一个依赖工程。一个就是在你的工程里面，直接将其作为一个模块，另外一个就是创建一个 aar 文件，这样其他的应用也就可以复用了。

如果你把其作为模块，那你需要在 settings.gradle 文件中添加其为模块：

include ':app', ':library'

在这里，我们就把它叫做 library 吧，如果你想使用该模块，你需要在你的依赖里面添加它，就像这样:

dependencies {
       compile project(':library')
  }

使用 aar 文件

如果你想复用你的 library，那么你就可以创建一个 aar 文件，并将其作为你的工程依赖。当你构建你的 library 项目，aar 文件将会在 build/output/aar / 下生成。把该文件作为你的依赖包，你需要创建一个文件夹来放置它，我们就叫它 aars 文件夹吧，然后把它拷贝到该文件夹里面，然后添加该文件夹作为依赖库：

repositories {
    flatDir {
        dirs 'aars' 
    }
}

这样你就可以把该文件夹下的所有 aar 文件作为依赖，同时你可以这么干：

dependencies {
       compile(name:'libraryname', ext:'aar')
}

这个会告诉 Gradle，在 aars 文件夹下，添加一个叫做 libraryname 的文件，且其后缀是 aar 的作为依赖。

依赖的概念

配置

有些时候，你可能需要和 sdk 协调工作。为了能顺利编译你的代码，你需要添加 SDK 到你的编译环境。你不需要将 sdk 包含在你的 APK 中，因为它早已经存在于设备中，所以配置来啦，我们会有 5 个不同的配置：

• compile

• apk

• provided

• testCompile

• androidTestCompile

compile 是默认的那个，其含义是包含所有的依赖包，即在 APK 里，compile 的依赖会存在。

apk 的意思是 apk 中存在，但是不会加入编译中，这个貌似用的比较少。

provided 的意思是提供编译支持，但是不会写入 apk。

testCompile 和 androidTestCompile 会添加额外的 library 支持针对测试。

这些配置将会被用在测试相关的 tasks 中，这会对添加测试框架例如 JUnit 或者 Espresso 非常有用，因为你只是想让这些框架们能够出现在测试 apk 中，而不是生产 apk 中。

除了这些特定的配置外，Android 插件还为每个构建变体提供了配置，这让 debugCompile 或者 releaseProvided 等配置成为可能。如果你想针对你的 debug 版本添加一个 logging 框架，这将很有用。这些内容的详细介绍，我会在下一个博客里详细介绍。

动态版本

在一些情形中，你可能想使用最新的依赖包在构建你的 app 或者 library 的时候。实现他的最好方式是使用动态版本。我现在给你们展示几种不同的动态控制版本方式：

dependencies {
       compile 'com.android.support:support-v4:22.2.+'
       compile 'com.android.support:appcompat-v7:22.2+'
       compile 'com.android.support:recyclerview-v7:+'
}

第一行，我们告诉 gradle, 得到最新的生产版本。第二行，我们告诉 gradle，我们想得到最新的 minor 版本，并且其最小的版本号是 2. 第三行，我们告诉 gradle, 得到最新的 library。

你应该小心去使用动态版本，如果当你允许 gradle 去挑选最新版本，可能导致挑选的依赖版本并不是稳定版，这将会对构建产生很多问题，更糟糕的是你可能在你的服务器和私人 pc 上得到不同的依赖版本，这直接导致你的应用不同步。

如果你在你的 build.gradle 中使用了动态版本，Android studio 将会警告你关于动态版本的潜在问题，就像你下面看到的这样：

Android studio UI 操作依赖库

在使用 Android studio 中，最简单的添加新依赖包的方法是使用工程结构弹框。从文件按钮中打开界面，导航到依赖包导航栏，然后你就可以看到你当前的依赖包了：

当你想添加新的依赖包的时候，可以点击绿色的小按钮，你可以添加其他模块，文件，甚至是上网搜索。

使用 Android studio 的界面让你能够很简单的浏览你项目中的所有依赖，并且添加新的依赖包。你不必在 build.gradle 中手动的添加代码了，并且你可以直接搜索 JCenter 库中的依赖资源。

总结

在这一章里，我们了解了多种方式添加依赖，我们学习了什么是仓库，以及如何使用他们，同时学习了如何在不使用仓库的情况下使用 jar 文件。

你现在知道了依赖包的属性配置，动态版本控制等。

我们也谈到了关于在多个环境下构建 app 变种，在下一章，我们将会学习到什么是构建变种，以及为什么他们很重要，构建变种将会使得开发测试以及分发 app 变得更加容易。理解变种的工作原理可以加快你的开发和分发效率。