Android依赖导入全攻略

时间 2019-11-15

原文原文链接

在咱们开发安卓项目的时候，不会全部的功能都本身去造轮子，常常要使用到各类的其余包，其中有谷歌给咱们提供的各类support包，也有各类第三方的功能库，有时候咱们本身也会将一些功能封装成包。这些包存在和导入的形式也多种多样，有远程仓库的，有直接拷贝到本地的，jar包、aar包、so包等。所幸咱们均可以在主工程和各个Module的build.gradle里进行统一管理。本文将在Android Studio3.0环境下来汇总下这些用法。android

预备知识

先来看下Android Gradle plugin 3.0几个引入依赖的方法：git

Implementation

对于使用了该命令编译的依赖，对该项目有依赖的项目将没法访问到使用该命令编译的依赖中的任何程序，也就是将该依赖隐藏在内部，而不对外部公开。github

使用implementation会使编译速度有所增快：好比我在一个library中使用implementation依赖了gson库，而后个人主项目依赖了library，那么，个人主项目就没法访问gson库中的方法。这样的好处是编译速度会加快，我换了一个版本的Gson库，但只要library的代码不改动，就不会从新编译主项目的代码。spring

api

等同于compile指令api

compileOnly

等同于provided，只在编译时有效，不会参与打包，不会包含到apk文件中。能够用来解决重复导入库的冲突（下文会提到）。bash

更多细节内容能够看下这篇文章架构

远程仓库依赖

咱们先来看下主工程下的build.gradle文件app

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下添加依赖。eclipse

关于Gradle插件的开发能够看下这篇文章：Gradle自定义插件 ide

再来看下几种远程依赖的添加方式：

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包中的资源文件重复了

资源文件重复了，主工程的资源文件会直接覆盖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'
    })
复制代码

二者二选一，冲突就解决啦。