一、依赖管理基础：什么是依赖管理，为什么SDK需要依赖管理，依赖地狱的概念

1.1 依赖管理到底是什么？

说白了，依赖管理就是帮你管好「你的代码用了别人的什么代码」。

我刚开始做SDK开发那会儿，还没意识到这事儿有多重要。那时候项目小，依赖就那么三五个，手动下载jar包扔进lib目录就完事了。直到有一次，我花了一整天排查一个诡异的NullPointerException，最后发现是A库依赖了B库的1.0版本，而C库依赖了B库的2.0版本——两个版本不兼容，运行时直接炸了。

嗯，从那以后，我再也不敢手动管依赖了。

依赖管理的核心任务其实就三件事：

• 声明：告诉构建工具，你的项目需要哪些库、什么版本
• 解析：自动下载这些库，以及这些库依赖的其他库（传递依赖）
• 冲突解决：当多个依赖要求同一个库的不同版本时，决定用哪个

你想想看，一个中型SDK项目，依赖的库可能有几十个。每个库又有自己的依赖。这些依赖层层嵌套，最终形成一个巨大的依赖树。手动管理？不现实。

1.2 为什么SDK需要依赖管理？

这个问题我问过不少刚入行的同学。他们的第一反应往往是：「为了省事儿啊。」

对，但不全对。

SDK和普通应用不一样。普通应用只管自己跑起来就行，但SDK是要给别人用的。这意味着：

1. 你的依赖会传染给使用者——用户集成你的SDK，就等于集成了你所有的依赖
2. 版本冲突会加倍——用户的项目可能已经用了某个库的不同版本
3. 包体积敏感——多一个依赖，用户的APK就大一圈

我在项目中遇到过最典型的场景：我们发布了一个支付SDK，内部依赖了OkHttp 3.12。结果用户的项目里用了OkHttp 4.0，两个版本在类加载时发生了冲突。用户花了三天排查，最后发现是我们SDK的问题。那感觉，嗯，挺尴尬的。

1.3 依赖地狱——每个SDK开发者的噩梦

「依赖地狱」这个词，我第一次听到是在一次技术分享会上。当时一位老前辈说：「你们迟早会遇到的，躲不掉。」

他说得对。

依赖地狱，指的是依赖管理失控后的一系列问题。常见症状包括：

症状	表现	后果
版本冲突	两个依赖需要同一个库的不同版本	运行时异常、编译失败
传递依赖过多	A依赖B，B依赖C，C依赖D...	包体积膨胀、启动变慢
循环依赖	A依赖B，B又依赖A	构建死循环、无法编译
隐式依赖	依赖了某个库的内部实现	升级后直接崩溃

我曾经接手过一个遗留SDK项目，它的依赖图长这样：

com.example:core:1.0
  └── com.example:utils:1.0
       └── com.example:core:1.0  (循环依赖！)
  └── com.google:gson:2.8
  └── com.squareup:okhttp:3.10
       └── com.squareup:okio:1.15
com.example:payment:1.0
  └── com.example:core:1.0
  └── com.google:gson:2.9  (版本冲突！)
  └── com.squareup:okhttp:4.0  (版本冲突！)

你看，光是列出来就够头疼的了。更别说实际排查的时候，你根本不知道哪个版本被最终采用了。

1.4 依赖管理的核心知识体系

为了让你更直观地理解依赖管理的全貌，我画了一张图：

这张图把依赖管理分成了三个层次：声明、解析、冲突解决。底层是依赖地狱的各种问题，顶层是最佳实践。说白了，依赖管理就是一场「从混乱到有序」的博弈。

1.5 小结

依赖管理不是锦上添花，而是SDK开发的必修课。你想想看，一个连自己依赖都管不好的SDK，用户怎么敢用？

我个人习惯在项目初期就把依赖管理规范定好。比如：

• 所有依赖必须显式声明版本号
• 禁止使用「+」号通配版本
• 定期执行依赖审计，清理无用依赖
• 每次发布前做一次完整的依赖树检查

这些习惯帮我避免了很多坑。嗯，希望也能帮到你。

可可精品资料库