源码依赖 vs 二进制依赖：优缺点、选择策略
说起依赖集成，我见过不少团队在这里栽过跟头。
一个常见的场景：项目跑得好好的，突然有人改了底层库的某个头文件，结果整个团队都在等重新编译。而另一边，有人只是更新了一个 .jar 文件，五分钟就搞定了。
这两种方式——源码依赖和二进制依赖，其实各有各的脾气。选对了，开发效率翻倍；选错了，你会不断在「改一行代码等半小时编译」的焦虑中度过。
什么是源码依赖？什么是二进制依赖？
先明确一下概念。
- 源码依赖：你把 SDK 的源代码直接引入项目，和自己的代码一起编译。比如用 Git Submodule、CocoaPods 指定本地路径，或者安卓端的 `include ':library'`。
- 二进制依赖：你只拿到编译好的产物——像 .a、.so、.jar、.framework——直接链接进去，不关心它的源代码。比如通过 Maven Central、CocoaPods Specs 拉取预编译包。
说白了，一个是你亲眼看着它怎么被「做」出来的，另一个是别人做好了你直接用。
源码依赖的优缺点
先说说源码依赖。我个人非常喜欢用来做底层核心库的开发阶段。
✅ 优点
- 调试无障碍：你可以直接跳进 SDK 内部，加断点、看变量值、单步跟踪。我记得有次排查一个内存泄漏，问题根源藏在一个 C 层的回调里。如果不是源码依赖，我根本看不到那个函数参数是空的。
- 定制灵活：想改 SDK 的某个行为？直接改源码就行。比如修改一个网络请求的 header 拼接逻辑，不用等官方发新版本。
- 平台适配更彻底：某些 SDK 在 iOS 模拟器上跑，在真机上却崩溃。如果是源码依赖，你可以针对不同架构写条件编译。
- 无黑盒信任问题：代码完全透明，你知道它里面有没有偷偷采集数据。
❌ 缺点
- 编译时间爆炸：这是最痛的。我曾在一个项目中引入了三个源码级 SDK，加上主工程，一次增量编译需要 15 分钟。全量编译？至少 40 分钟。团队的咖啡机都够被我们喝坏了。
- 依赖冲突增多：多个源码库可能用了同一份底层代码的不同版本。你不得不去手动解决链接时符号重复的问题。
- 版本管理麻烦：你用 tag 还是 branch？别人更新了子模块但没 push，你拉了老代码，编译报错，查半天才发现是版本不匹配。
- 产物体积不可控：源码依赖通常会引入更多未使用的代码，因为编译器分不清哪些是你真正需要的。
二进制依赖的优缺点
那二进制依赖呢？它刚好是另一个极端。
✅ 优点
- 编译速度快：这是它最吸引人的地方。链接一个 .framework 的时间，比编译同样体量的源码至少快 10 倍。你想想看，项目大了以后，每次改一行代码等 5 分钟和等 30 秒，体验天差地别。
- 集成简单：一行 podfile 或者一个 gradle 声明就搞定了。不需要管它内部依赖什么，也不需要应对它的构建配置。
- 版本锁定清晰：二进制依赖一旦指定版本号，就是那个版本。不会出现「拉下来编译不过」的情况。
- 体积容易优化：你可以选择只包含 arm64 架构的 fat binary，把模拟器切片去掉，包体更小。
❌ 缺点
- 调试受限：你只能看到接口声明，看不到实现。我遇到过一个问题：二进制 SDK 里某个回调始终不触发，我没办法定位是因为我传参错了还是 SDK 内部挂了。最后只能绕弯子加一层中间层来验证猜测。
- 定制门槛高：无法改 SDK 内部逻辑。除非你联系厂商定制版本，但周期长、成本高。
- 隐蔽的兼容性问题：二进制包可能是在 Xcode 13 下编译的，而你用的是 Xcode 15，某些系统 API 行为发生了变化，但包里的代码不会自动适配。
- 安全隐患：你无法确认.dylib 或 .aar 里到底有没有后门代码。除非你主动做逆向分析。
选择策略：什么时候用源码，什么时候用二进制？
我通常遵循一个原则：核心可变的用源码，成熟稳定的用二进制。
| 维度 | 推荐方式 | 原因 |
|---|---|---|
| 团队内部核心模块 | 源码依赖 | 方便快速迭代、修复 Bug、预研新特性 |
| 第三方稳定 SDK（如支付、推送） | 二进制依赖 | 极少修改，集成快速，版本控制清晰 |
| 需要频繁调试的库 | 源码依赖 | 断点跟进去看实现逻辑，定位问题效率高 |
| 大型项目的基础库 | 二进制依赖 | 避免每次微调都引发全量编译，缩短 CI 时间 |
| 跨平台共享代码（如 C++ core） | 源码依赖 + 条件编译 | 保持代码统一，不同平台用不同编译器参数 |
| 闭源商业 SDK | 二进制依赖 | 无源码可选，只看接口声明 |
💡 一个实用混合策略
我做过一个 Android + iOS 的跨平台项目。做法是：
- 把最常改动的网络层和存储层作为 源码模块 引入。
- 把 UI 组件库、日志工具等 打包成二进制框架，通过 CI 在每次发布后自动生成并上传到内部仓库。
- 开发人员只在需要修改源码模块时才拉取完整的仓库，平时编译直接依赖二进制版本。
这样一来，大部分情况下的改动只影响二进制依赖层面，编译飞快。
我曾经踩过的坑与避坑指南
说到底，没有的好与坏，只有合适不合适。我把我以前踩过的一些坑总结成一条检查清单，你下次做决策时可以对照一下。
💣 遇过的问题清单
- 「二进制包里的符号与系统库冲突」：用
nm -gUj xxx.framework/xxx提前检查暴露符号，避免二次链接失效。 - 「源码依赖下的头文件路径失效」：养成用
HEADER_SEARCH_PATHS或者include_dirs做相对路径定位，别写死路径。 - 「混合方式时出现重复符号」：对源码模块启用
-fvisibility=hidden，只暴露 API 接口，内部符号不对外暴露。 - 「二进制依赖在模拟器上闪退」：检查 binary 是否包含 x86_64 切片。没有的话，只能切换到源码版本做本地开发测试。
可视化决策流程
下面这张简单的决策图，可以帮你快速判断在某个具体场景下该用哪种依赖形式。
嗯，从上图你能看到：核心决策点就一个——你是不是需要经常去改这个库的代码？是，就走源码依赖；不是，就走二进制依赖。如果大部分场景都是「否」，但某个特定模块偶尔需要看实现逻辑，那就走混合方式，把那个模块临时切到源码。
到现在为止，我经手的项目里真正只用一种方式的很少。大多数情况都是混合策略。关键不是你选择了什么，而是你能不能想清楚——这行代码，我今天到底需不需要碰它？