Android 理解新的依赖方式

最新推荐文章于 2024-06-26 13:16:01 发布

zkbilian

最新推荐文章于 2024-06-26 13:16:01 发布

阅读量1.2k

点赞数

分类专栏： Android 我不是程序员文章标签：依赖 api implementation

本文链接：https://blog.csdn.net/m0_37711172/article/details/79893748

版权

本文详细介绍了在Android Studio 3.0环境下，如何管理依赖，包括Implementation、api、compileOnly等不同引入方式的特性，以及远程仓库、本地依赖（jar包、aar包、so文件）的处理方法，解决了资源文件重复、AndroidManifest合并错误等问题，并探讨了annotationProcessor与compileOnly的区别。

摘要由CSDN通过智能技术生成

在我们开发安卓项目的时候，不会所有的功能都自己去造轮子，经常要使用到各种的其他包，其中有谷歌给我们提供的各种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 {
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.0'
    }
}

allprojects {
    repositories {
        google()
        jcenter()
    }
}

引入远程仓库依赖是很方便的，但在之前我们需要声明远程仓库的地址。上面有两个仓库地址的声明，一个在buildscript {},另一个在repositories {}。看代码中系统给我们的注释就知道：前者是gradle脚本自身执行所需依赖（Gradle插件），后者是项目本身需要的依赖（普通代码库）。所以如果你没有引入远程的Gradle插件，那么就不用在buildscript {}下的dependencies下添加依赖。

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

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可以设置不编译指定