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{
    dir'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:'con.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"]