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"]

这里写图片描述

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页