Android Studio添加依赖的几种方式(转)

时间:2024-03-21 17:55:20

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

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

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

1、库依赖(library)

2、模块依赖(module)

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

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

Android Studio添加依赖的几种方式(转)

Android Studio添加依赖的几种方式(转)

一种一种来,先说库依赖

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了。