compile
在Gradle升级到4.+版本的时候,已经会提示compile被废弃掉了,替换它的是api指令
Implementation
“访问隔离”作用于编译器,好处是,编译速度快,比如,我在一个library中使用implementation依赖了gson库,然后我的主项目依赖了library,那么,我的主项目就无法访问gson库中的方法。我换了一个版本的Gson库,但只要library的代码不改动,就不会重新编译主项目的代码。
坏处是,我们可能要写更多的implementation,但是阅读性更好,同时如果我们的library依赖了Gson的1.0版本,同时主工程依赖了Gson的2.0版本,但最终打到apk中的是2.0版本(通过依赖树可看到)。所以对运行并不影响。
compileOnly
等同于provided,只在编译时有效,不会参与打包,不会包含到apk文件中。可以用来解决重复导入库的冲突
annotationProcessor
编译期注解的依赖
用过butterknife或者Dagger的同学可能对这种annotationProcessor引入方式有所印象,这种方式是只在编译的时候执行依赖的库,但是库最终不打包到apk中。结合编译期注解的作用,他是用来生成代码的,本身在运行时是不需要的。
apk(runtimeOnly)
只在生成apk的时候参与打包,编译时不会参与,很少用。
testCompile(testImplementation)
testCompile 只在单元测试代码的编译以及最终打包测试apk时有效。
debugCompile(debugImplementation)
debugCompile 只在debug模式的编译和最终的debug apk打包时有效
releaseCompile(releaseImplementation)
Release compile 仅仅针对Release 模式的编译和最终的Release 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包依赖
生成aar包,rebuild一下就可以的,生成目录在library工程的build->outputs->aar下。aar和jar不同的地方在于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
}
}
}
参考:https://juejin.im/post/5acd6daaf265da238a30ca73
对于gradle一些语法不是很了解的可以看下《实战Gradle》