AndroidStudio的几种依赖方式

纯粹按照个人理解进行总结的，非官方提供

前置知识点：AndroidStudio中项目组织方式，最高层为Project（虽然结构层次和Eclipse里的workplace有些相似，但还是有很大区别的），下面可以包括很多module，每个module可完全独立作为一个项目，运行处一个APK。（这在结构层次上又相当于eclipse里的project）

经过实践总结，以gradle为构建工具的AndroidStudio在依赖方面可以分为

1、库依赖（library）

2、模块依赖（module）

简单区分，模块就是源代码模块，库依赖就打包好的jar、aar文件

以上两种每种又可以分为内部和外部。

一种一种来，先说库依赖

A、内部库

这个应该是从eclipse那边延续过来的，算是对eclipse的兼容，指位于/Project/module/libs/下的jar、aar文件

使用方法：这种依赖比较简单，直接放在指定目录就好了，在模块配置/Project/module/build.gradle中的dependencies标签下加入

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

compile(name: 'FileSelector-release', ext: 'aar')

androidstudio会自动加载指定目录下的依赖库

B、外部库

这个是gradle的标准依赖方式，导入、管理、升级等都非常便捷

使用方法：在项目配置文件（顶级gradle文件/Project/build.gradle）中声明中心仓库，自动生成的项目中，AS会默认配置好，默认中心仓库为jcenter，也可以使用maven。

在module配置文件里（/Project/module/build.gradle）的dependencies标签下有类似

compile 'com.google.code.gson:gson:2.4'

AS会从中心仓库下载相应版本的库文件，实际文件一般在/用户文件夹/.gradle\caches\modules-2\files-2.1

并在工程结构的ExternalLibraries中列出，这也就是为什么叫这种为“外部库”

这里的引入配置代码需要库的提供方提供，一般gitbug的项目如果同时支持gradle构建方式引用，会在readme里面说明，如果没在github上，可以去中央仓库去搜，中央仓库的位置是可以从配置文件里追溯源码追到的。jcenter:

https://jcenter.bintray.com/

C、内部模块

前面说了，一个Project下面可以包括很多Module，这些module可以是相互完全独立的，也可以是被依赖的。

使用方法：

如果希望一个module被一个或者多个其他的Module依赖，那么，需要在该module的build.gradle文件把当前模块声明为Library

即不能用

apply plugin: 'com.android.application'

要用

apply plugin: 'com.android.library'

好吧，这个又类似于eclipse里面设置某个eclipse工程“Is Library”
在顶层工程目录下的settings.gradle中include模块名

include ':app',':module-name'

D、外部模块（这种方式，是我自己YY出来，经过验证可行的）
前面说，AndroidStudio组织结构顶层是一个Project，如果这么说，理解起来，其实在同一个项目里，
不应该有与project同级的模块存在，但实际并不绝对
例如工程A、B分别各自包含两个module，其中一个模块另一个是library模块，也即上面提到的C内部模块。
此时，A工程是可以依赖B工程中的library模块的。
使用方法：和内部模块类似，在settings.gradle中include 后面加上模块名，这里的模块名需要自己定义

include ':app', ':module-name'

include ':external-module-name'
project(':external-module-name').projectDir = new File(rootDir, '../../Example/sdkexample')

意思比较明显，声明一个模块，指定一下这个模块的地址。把这个include到工程中。比较讲究的是那个地址的写法，要切记不能写错了，写错了找不到，在AS的工程结构中，这种外部模块的依赖，是不能组织在工程内部的，实际上会合工程顶层，以及ExternalLibraries处于同一级如图，那个sdkexample是另一个工程中的内部模块。最后说一下，为什么会有这篇文章，我也不想搞这么复杂啊，又是这样依赖那样依赖的，其实都是项目需要被逼的了。要是所有依赖的代码都可以用第二种方式使用外部依赖。尤其是D这种外部模块依赖，很奇葩的，大家要是仔细理解D的这种方式其实应该不难想到，这是为了解决联合开发的问题而被逼出来的想法。

适用场景如下：

双方协作开发，一方依赖另一方的代码，被依赖方代码也正在开发过程中，随时会变化。关键双方不是基于同一个git仓库开发，各自有各自的，自然本地目录也不是同一个了。这样形式的依赖，可以使双方各自独立开发，依赖方在本地clone两个仓库，一个依赖另一个，各自还可以独立开发，依赖方只需要在必要的时候pull代码就OK了。