一、不同類型的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倉庫既忆。通過這種方式依賴相比于前兩種方案都要更優(yōu)嗦玖，且配置靈活，可以根據實際需求調整
// 依賴明確的版本宇挫，標明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的改動導致編譯不過或者功能變更不
// 穩(wěn)定，因為每次都需要檢查是否有最新版本澈蟆，所以構建效率會低一些
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"]
總結如下：
二梁只、不同依賴配置方式的區(qū)別：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，差異主要在于構建內容和參與構建的時機苍蔬，多樣的配置方式滿足了開發(fā)者的花樣需求环形，具體區(qū)別如下：
1、implementation：
依賴包中依賴的library只能在依賴包內部使用格仲，主工程無法訪問依賴包依賴的library中的類和方法。使用場景：SDK開發(fā)中對第三方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的區(qū)別這篇文章寫得淺顯易懂囚痴，值得學習：Implementation Vs Api in Android Gradle plugin 3.0
