分享Android Studio中Gradle依赖

一、不同类型的library引入方案：

1、本地Module library依赖：

通过这种方式依赖的弊端是每次都需要构建module，当module比较多时构建非常耗时，建议控制module的依赖数量，避免构建耗时

//module需要在项目根目录下的settings.gradle中通过include引入
implementation project(':librarydict')

2、本地二进制library依赖：jar和aar：

本地的jar和aar需要放在module的libs文件夹下，通过这种方式依赖的弊端是不知道jar和aar的版本号，如果要按照这种方式依赖，建议将jar/aar的名字加上版本信息，方便确认版本
依赖jar:

// 可以一条依赖引入libs下所有的jar
                  implementation fileTree(dir: 'libs', include: ['*.jar'])

// 也可以指定依赖某一个或几个jar
                 implementation files('libs/dict-v120.jar', 'libs/download-v151.jar')

依赖aar：

// 在module的build.gradle中增加如下语句：    
repositories {
    flatDir {
        dirs 'libs'
    }
}

// 可以一条依赖引入libs下所有的aar
implementation fileTree(dir: 'libs', include: ['*.aar'])

// 也可以指定依赖某一个aar
implementation (name: 'library-download', ext: 'aar')

3、远程二进制library依赖：

为了安全起见，建议搭建公司内部的私有maven仓库，统一管理依赖的library，公司内部的公共library不要使用公共的maven仓库。通过这种方式依赖相比于前两种方案都要更优，且配置灵活，可以根据实际需求调整

// 依赖明确的版本，标明group、name和version
implementation group: 'com.android.demo', name: 'library-dict', version: '1.2.0'

// 通常按照如下方式简写即可
implementation 'com.android.demo:library-dict:1.2.0'

// 也可以不指定版本，将version改为"+"，当远程仓库有更新的版本后，构建时会拉取最新的版本。
// 好处是可以始终依赖最新的library；弊端是有可能library的改动导致编译不过或者功能变更不
// 稳定，因为每次都需要检查是否有最新版本，所以构建效率会低一些
implementation 'com.android.demo:library-dict:+'

 

// 对于有多个APP，依赖内部统一SDK的情况时，可以将gradle文件放在服务器，远程控制统一依
// 赖版本，避免因为各个APP依赖的SDK版本不统一导致很难管理和维护
// 远程http://172.28.2.93/remote/library-config.gradle：
ext.libraryBuildConfig = [
    deps: [
        "dict-library"                 : 'com.android.demo:library-dict:1.2.0',
        "download-library"             : 'com.android.demo:library-download:1.5.1',
    ]
]

// 项目根目录下的build.gradle全局引入：
apply "http://172.28.2.93/remote/library-config.gradle"

ext {
    dependencies = [
        "dict-library"     : libraryBuildConfig.deps.'dict-library',
        "download-library" : libraryBuildConfig.deps.'download-library',
    ]
}

// 在module的build.gradle中依赖：
implementation rootProject.ext.dependencies["dict-library"]
implementation rootProject.ext.dependencies["download-library"]

总结如下：

二、不同依赖配置方式的区别：compile、implementation、api
从Android Gradle plugin 3.0开始，对于依赖包的配置方式，引入了implementation和api，使用Android Studio新建项目时，原来用compile的地方全部默认被替换成了implementation 比如：

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:27.1.1'
    compile 'com.android.support.constraint:constraint-layout:1.1.3'
}

变成下面的样子：

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:appcompat-v7:27.1.1'
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'
}

网上查资料时，依赖配置方式还有：provided、api、apk、compileOnly、runtimeOnly、渠道名+Compile，差异主要在于构建内容和参与构建的时机，多样的配置方式满足了开发者的花样需求，具体区别如下：

1、implementation：

依赖包中依赖的library只能在依赖包内部使用，主工程无法访问依赖包依赖的library中的类和方法。使用场景：SDK开发中对第三方library有依赖，希望控制SDK的大小、不想因为和宿主工程引用的同一个依赖包版本不同导致编译冲突时特别适合。

因为当依赖包依赖的library有改动时，只会重新编译library和依赖包，不需要重新编译宿主，所以构建速度会快一些。

对于各个渠道还可以单独依赖属于渠道特有的包，通过渠道名+implementation指定，比如debugImplementation、releaseImplementation、testImplementation。

2、api(原compile)：

会将依赖包中依赖的其它library一同编译和打包到apk中，宿主工程可以使用依赖包中依赖的其它library的类和方法

对于各个渠道还可以单独依赖属于渠道特有的包，通过渠道名+api/compile指定，比如debugApi、releaseApi、testApi

3、compileOnly(provided)：

主要是为了方便程序编译通过的，不会打包到apk中，使用场景：android系统有这个API，但编译时需要引入才能构建通过，比如系统的APK依赖framework.jar、gson库等

4、runtimeOnly(原apk)：

只是打包到apk中，不参与编译，不能在代码中直接调用依赖包的代码，否则会在编译时出错。一般很少使用

关于implementation和compile的区别这篇文章写得浅显易懂，值得学习：Implementation Vs Api in Android Gradle plugin 3.0