Android库传递依赖处理及Gradle依赖可见性相关技术问询

你对Gradle传递依赖可见性的理解完全正确：

• 若库B用api声明依赖C，依赖B的项目A在编译期和运行期都能访问C的API；
• 若B用implementation声明依赖C，C仅对B内部可见，A在编译期无法访问C的API，仅运行期会被打包进APK。

一、为什么无需显式引入core-ktx就能使用？ #

没错，这说明你项目中的某个直接依赖（比如androidx.appcompat:appcompat、com.google.android.material:material这类常用库）通过api关键字声明了对core-ktx的依赖。

比如androidx.appcompat:appcompat本身就以api方式依赖core-ktx——因为AppCompat的很多核心功能基于core-ktx实现，必须把这些API暴露给上层开发者，所以用api保证传递依赖的可见性。只要你在项目里引入了appcompat，就自动能使用core-ktx的所有功能。

二、material库对cardview、recyclerview、constraintlayout的依赖情况 #

1. cardview与recyclerview：material库确实通过api声明了这两个库的依赖。因为Material Design的很多组件（比如MaterialCardView、带Material样式的RecyclerView）是直接基于这两个库扩展的，必须把它们的API暴露给开发者，所以用api确保传递可见性。这意味着你只要引入了material库，就无需单独再声明cardview和recyclerview的依赖，直接就能使用它们的API。

2. constraintlayout：material库并没有直接依赖constraintlayout，如果你需要使用ConstraintLayout的布局功能，还是得单独在build.gradle中显式声明依赖。

三、关于依赖管理的建议 #

虽然传递依赖能省去部分显式声明，但建议显式声明你直接使用的依赖及其版本：

• 避免因传递依赖的版本自动更新导致的兼容性问题；
• 让项目的依赖结构更清晰，其他开发者能快速识别你用到的核心库。

内容的提问来源于stack exchange，提问作者pnkj