项目里的build.gradle导了很多包,在依赖dependencies里有很多不同的关键字,在此分别记录一下。
dependencies闭包的整体功能是指定当前项目所有依赖关系:本地依赖、库依赖及远程依赖。
本地依赖:可以对本地Jar包或者目录添加依赖关系
库依赖:可以对项目中的库模块添加依赖关系
远程依赖:可以对jcenter库上的开源项目添加依赖,标准的远程依赖格式是:域名:组织名:版本号
implementation fileTree(dir: 'libs', include: ['*.jar']) // 本地依赖 implementation 'com.android.support:appcompat-v7:26.1.0'//远程依赖 implementation 'com.android.support:appcompat-v7:26.1.0'//远程依赖,com.android.support是域名部分,appcompat-v7是组名称,26.1.0是版本号 implementation project(':hello') // 库依赖 testImplementation 'junit:junit:4.12' // 声明测试用列库 androidTestImplementation 'com.android.support.test:runner:1.0.1' androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1' 在gadle3.0之后,默认的依赖由之前的compile更改为implementation
对比一下:
Android Studio 2.X | Android Studio 3.X |
apk | runtimeOnly |
provided | compileOnly |
compile | api |
没有对应 | implementation |
debugCompile | debugImplementation |
releaseCompile | releaseImplementation |
androidTestCompile | androidTestImplementation |
debugImplementation(debugCompile) 只在debug模式的编译和最终的debug apk打包时有效。
releaseImplementation(releaseCompile)仅仅针对release 模式的编译和最终的release apk打包。
androidTestImplementation(androidTestCompile) 只在单元测试代码的编译以及最终打包测试apk时有效。
freeddddffdfsdsfsImplementation(freeddddffdfsdsfsCompile)只有freeddddffdfsdsfs 模式下才有效
api (compile)
依赖向上传递
若A api B, B api C,C module对A module可见
对于各个渠道还可以单独依赖属于渠道特有的包,通过渠道名+api/compile指定,比如debugApi、releaseApi、testApi
implementation (新指令: 具备依赖可见性)
依赖不向上传递
若A implementation B, B implementation C,C module对A module不可见
若A implementation B, B api C,C module对A module可见
功能同api,区别仅仅是增加了依赖可见性
对于各个渠道还可以单独依赖属于渠道特有的包,通过渠道名+implementation指定,
比如debugImplementation、releaseImplementation、testImplementation。
compileOnly(provided)
只在编译时有效,不会参与打包
主要是为了方便程序编译通过的,不会打包到apk中,使用场景:android系统有这个API,但编译时需要引入才能构建通过,比如系统的APK依赖framework.jar、gson库等
若A implementation C,打包后apk(A + C);
而A compileOnly C,打包后apk(A);
该指令实质:A module假装依赖了C module通过欺骗编译器编译时检测以避免java.lang.ClassNotFoundException编译报错
使用情形
A implementation C,B implementation C,打包时A module生成aar(A + C),B module生成aar(B + C)
若改成A implementation C,B compileOnlyC,打包时A module生成aar(A + C),B module生成aar(B)
最终apk包(A + B + C),结果一致
虽然aar(B)不真实依赖C module,但B module确实用到了C module的api。
没有运行时错误的原因:aar(A + C)与aar(B)合并生成apk,B module运行时找到并调用aar(A + C)中的C module
runtimeOnly(apk)
只在生成apk的时候参与打包,编译时不会参与,很少用。不能在代码中直接调用依赖包的代码,否则会在编译时出错。