, 最终 B 依赖库会打包到 A 项目的 Apk 文件中 ;
如果 C 项目 依赖 A 项目 , 由于 compile 配置会 传递依赖 , C 项目也需要将 B 依赖库导入到自己的依赖中 , 这就使得...A 在 编译构建时需要 B 依赖库 , 最终 B 依赖库会打包到 A 项目的 Apk 文件中 ;
如果 C 项目 依赖 A 项目 , 由于 implementation 配置不会传递依赖 , C 项目是不知道...A 项目的 B 依赖库的 , 也无法访问 B 依赖库 ;
如果使用 compile 或者 api 添加依赖 , 则会有大量的依赖传递 , 构建效率 会 非常低 , 构建时会 不停的检查依赖树 , 发现依赖传递后...如果修改了这个依赖库 , 沿途所有依赖与该库的项目模块 , 都需要重新编译 , 会极大增加编译构建时间 , 能不用就不用 ;
推荐使用 implementation 依赖 代替 api 或 compile...;
compileOnly 依赖 的作用与 已废弃的 provided 依赖 类似 , 都是 将依赖库添加到编译路径中 ;
在 根目录的 build.gradle 顶层构建脚本 中的 buildScript