Android依賴導入全攻略

在咱們開發安卓項目的時候，不會全部的功能都本身去造輪子，常常要使用到各類的其餘包，其中有谷歌給咱們提供的各類support包，也有各類第三方的功能庫，有時候咱們本身也會將一些功能封裝成包。這些包存在和導入的形式也多種多樣，有遠程倉庫的，有直接拷貝到本地的，jar包、aar包、so包等。所幸咱們均可以在主工程和各個Module的build.gradle裏進行統一管理。本文將在Android Studio3.0環境下來彙總下這些用法。

預備知識

先來看下Android Gradle plugin 3.0幾個引入依賴的方法：

Implementation

對於使用了該命令編譯的依賴，對該項目有依賴的項目將沒法訪問到使用該命令編譯的依賴中的任何程序，也就是將該依賴隱藏在內部，而不對外部公開。

使用implementation會使編譯速度有所增快：好比我在一個library中使用implementation依賴了gson庫，而後個人主項目依賴了library，那麼，個人主項目就沒法訪問gson庫中的方法。這樣的好處是編譯速度會加快，我換了一個版本的Gson庫，但只要library的代碼不改動，就不會從新編譯主項目的代碼。

api

等同於compile指令

compileOnly

等同於provided，只在編譯時有效，不會參與打包，不會包含到apk文件中。能夠用來解決重複導入庫的衝突（下文會提到）。

更多細節內容能夠看下這篇文章

遠程倉庫依賴

咱們先來看下主工程下的build.gradle文件

buildscript {
    ext.kotlin_version = '1.1.51'
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.1'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        jcenter()
    }
}
複製代碼

引入遠程倉庫依賴是很方便的，但在以前咱們須要聲明遠程倉庫的地址。上面有兩個倉庫地址的聲明，一個在buildscript {},另外一個在repositories {}。看代碼中系統給咱們的註釋就知道：前者是gradle腳本自身執行所需依賴（Gradle插件），後者是項目自己須要的依賴（普通代碼庫）。因此若是你沒有引入遠程的Gradle插件，那麼就不用在buildscript {}下的dependencies下添加依賴。

關於Gradle插件的開發能夠看下這篇文章：Gradle自定義插件

再來看下幾種遠程依賴的添加方式：

implementation 'commons-lang:commons-lang:2.6'
 
 implementation group: 'com.google.code.guice', name: 'guice', version: '1.0'
 
 implementation('org.hibernate:hibernate:3.1') {
        //不一樣版本同時被依賴時，那麼強制依賴這個版本的，默認false
        force = true
        //exclude能夠設置不編譯指定的模塊，有三種寫法:
        exclude module: 'cglib' 
        exclude group: 'org.jmock' 
        exclude group: 'org.unwanted', module: 'iAmBuggy' 
        //禁止依賴的傳遞，gradle自動添加子依賴項（依賴包所需的依賴），設置爲false，則須要手動添加每一個子依賴項，默認爲true。
        transitive = false
    }
複製代碼

一樣的配置下的版本衝突，會自動使用最新版；而不一樣配置下的版本衝突，gradle同步時會直接報錯。可以使用exclude、force解決衝突。 好比你同時依賴了兩個版本的v7包：

implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support:appcompat-v7:23.1.1'
複製代碼

最終只會使用26.1.0版本。可是如implementation 'com.android.support:appcompat-v7:23.1.1'，和androidTestImplementation 'com.android.support.test.espresso:espresso-core:2.1'，所依賴的com.android.support:support-annotations版本不一樣，就會致使衝突。除了能夠用exclude、force解決外，也能夠本身統一爲全部依賴指定support包的版本,不須要爲每一個依賴單獨排除了：

configurations.all {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        def requested = details.requested
        if (requested.group == 'com.android.support') {
            if (!requested.name.startsWith("multidex")) {
                details.useVersion '26.1.0'
            }
        }
    }
}
複製代碼

編譯期註解的依賴--annotationProcessor

用過butterknife或者Dagger的同窗可能對這種annotationProcessor引入方式有所印象，這種方式是隻在編譯的時候執行依賴的庫，可是庫最終不打包到apk中。結合編譯期註解的做用，他是用來生成代碼的，自己在運行時是不須要的。

本地依賴

jar包

jar包依賴的導入仍是比較簡單的：

• implementation files('hibernate.jar', 'libs/spring.jar')//列出每一個jar包的相對路徑
• implementation fileTree(dir: 'libs', include: ['*.jar'])//列出包含jar包的文件夾路徑

但和遠程倉庫依賴引入方式不一樣，若是本地同時存在兩個不一樣的jar包，或者本地已有jar包，再去遠程依賴不一樣版本的jar包，就會報錯。

解決方式：將其中的一個採用 compileOnly替換 implementation。顧名思義， compileOnly只在編譯時起做用，不會包含到APK裏面，在運行時也就避免找到重複的類了。

aar包

和jar包不一樣，aar包存放的路徑聲明和依賴引入是分開的：

repositories {
    flatDir {
        dir "../${project.name}/libs"
    }
}
dependencies {  
    implementation(name: 'aar名字', ext: 'aar')  
} 
複製代碼

若是aar包有不少，也能夠同樣象jar包統一添加一個文件夾下的全部包：

def dir = new File('app/libs')
    dir.traverse(
            nameFilter: ~/.*\.aar/
    ) { file ->
        def name = file.getName().replace('.aar', '')
        implementation(name: name, ext: 'aar')
    }
複製代碼

當一個library類型的module須要引用aar文件時，也要在所在模塊的build.gradle文件中加入上面的話，可是當其餘 Module引用此library的module時，也須要在他的build.gradle中加入以下配置，不然會提示找不到文件：

repositories {  
    flatDir {  
        dirs 'libs', '../包含aar包的模塊名/libs'  
    }  
}  
複製代碼

即若是當前Module須要一個aar包內容，不論aar包是否是在當前Module中，都須要在build.gradle中聲明它所在的路徑。若是項目中這樣的Module比較多，每一個都須要聲明路徑，不便於管理的話，推薦在項目的根build.gradle中統一添加,將全部包含aar包的模塊名列出，這樣不管是本Module或其餘Module都不須要單獨配置路徑了：

allprojects {
    repositories {
        jcenter()
        google()
        flatDir {
             dirs "../moudle-A/libs,../moudle-B/libs,../moudle-C/libs".split(",")
        }
    }
}
複製代碼

so文件

這個和jar包差很少，聲明下so文件的存放路徑就好了：

sourceSets {
        main {
            jniLibs.srcDirs = ['libs']
        }
    }
複製代碼

或者直接在main目錄下新建jniLibs目錄，這是so文件默認的放置目錄，不過不經常使用。值得一提的是aar包裏面也能夠包含so文件，但依賴這種包含so文件的aar包時不須要作特定的配置，編譯時so文件會自動包含到引用AAR壓縮包的APK中。

但比較特殊的一點是，so文件須要放到具體的ABI目錄下，不能直接放libs目錄下因此你見到的結果多是這樣的：

全部的x86/x86_64/armeabi-v7a/arm64-v8a設備都支持armeabi架構的so文件。因此爲了減少包體積，爲了減少 apk 體積，能夠只保留 armeabi 一個文件夾。但若是你想引入多個平臺的，那麼須要保持 so 文件的數量一致，就是說 armeabi 文件下的每一個so文件都要在armeabi-v7a下找到對應的so文件，但這樣apk包的體積就會增大。

還有一種作法是生成指定ABI版本的APK，而後按需上傳到應用商店，讓用戶本身選擇下載適合本身手機的版本，這個可能更多的用在安卓遊戲APP上，build.gradle配置以下：

android {
    ... 
    splits {
        abi {
            enable true  //啓用ABI拆分機制
            reset()  //重置ABI列表爲只包含一個空字符串
            include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //與include一塊兒使用來能夠表示要使用哪個ABI
             universalApk
             true//是否打包一個通用版本（包含全部的ABI）。默認值爲 false。
        }
    }
 
    // ABI的code碼
    project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]
 
    android.applicationVariants.all { variant ->
        // 最終標記
        variant.outputs.each { output ->
            output.versionCodeOverride =
                    project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode
        }
    }
 }
複製代碼

問題和小結

1.aar包中的資源文件重複了

1.aar包中的資源文件重複了

資源文件重複了，主工程的資源文件會直接覆蓋aar包中的文件，而且不會有任何報錯或者提示，最終aar包中也會直接用主工程的資源文件，因此須要注意命名方式。暫時沒有更好的解決方法。

2.AndroidManifest合併錯誤

一樣也是發生在aar包上， Android Studio 項目每一個module中均可以有一個AndroidManifest.xml文件，但最終的APK 文件只能包含一個 AndroidManifest.xml 文件。在構建應用時，Gradle 構建會將全部清單文件合併到一個封裝到 APK 的清單文件中。aar包的清單文件和咱們的app清單文件屬性衝突時：用tools:replace="屬性名"解決。

3.annotationProcessor與compileOnly的區別

上文說了annotationProcessor與compileOnly都是隻編譯並不打入apk中，他倆到底有什麼區別呢？扮演的角色不同，annotationProcessor做用是編譯時生成代碼，編譯完真的就不須要了，compileOnly是有重複的庫，爲的是剃除只保留一個庫，最終仍是須要的。

4.模塊的依賴分析

上面說了若是咱們的項目若是間接依賴了相同庫的不一樣版本，在編譯時就直接會報錯：

項目依賴以下：

解決方法很簡單，用exclude就好了，但咱們並不知道哪兩個依賴他們依賴了相同庫的不一樣版本，該把exclude放到哪裏呢？這就能夠用到一個命令：

./gradlew -q <模塊名>:dependencies
複製代碼

就能打印出該模塊全部的依賴樹信息：

能夠看到com.android.support.test:runner:1.0.2和com.android.support:appcompat-v7:26.1.0依賴的庫版本不一樣致使的，而com.android.support.test.espresso:espresso-core:3.0.2又依賴了前者，因此把這兩個庫的衝突的依賴排除掉就好了：

androidTestImplementation('com.android.support.test:runner:1.0.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    androidTestImplementation('com.android.support.test.espresso:espresso-core:3.0.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })

複製代碼

或者：

implementation ('com.android.support:appcompat-v7:26.1.0', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
複製代碼

二者二選一，衝突就解決啦。