SDK 选型：功能需求评估、兼容性检查、许可证与费用
做集成之前，选对 SDK 是头等大事。我见过不少团队，功能开发到一半才发现 SDK 授权过期，或者底层依赖跟现有环境打架——那叫一个狼狈。所以今天咱们聊聊选型时的三个关键维度：功能需求、兼容性、还有钱和许可证。
1. 功能需求评估
选 SDK 第一步：清点自己的功能清单。
记得我之前做过一个支付项目，团队接了个第三方钱包 SDK，结果集成到一半发现它不支持银联。排查时间花了三天，最后还是换方案。所以我的习惯是：先列一个“必须支持”列表，跟 SDK 的文档逐条比对。
怎么评估？我总结了三步：
- 罗列业务场景 —— 你的 App/系统到底需要 SDK 做什么？比如人脸识别、推送、地图、支付…
- 筛选核心 API —— SDK 的接口是否能覆盖你的关键逻辑？注意看是否有 deprecated 的方法。
- 验证扩展性 —— 如果你的业务将来要升级，SDK 是否提供自定义 hook 或回调？
小技巧：看 SDK 的 ChangeLog。如果最近半年频繁修 Bug，要么他们很活跃，要么代码质量堪忧。我个人选 SDK 会优先看“近期稳定版 v2.x”而非刚发布的 v3.0 beta。
另外，别只看表面功能。有些 SDK 宣传支持“直播推流”，但实际上只支持 RTMP 协议，而你后端只接 HLS，那就麻烦了。所以要深入看文档里的技术细节。
| 评估维度 | 检查项 | 常见坑 |
|---|---|---|
| 主功能 | 是否包含你需要的核心能力？ | SDK 只提供基础版，高级功能需额外付费 |
| API 设计 | 接口是否简洁？是否有异步/同步两种模式？ | 大量同步阻塞调用，导致 UI 卡顿 |
| 文档质量 | Demo 是否完整？是否有常见问题？ | 文档全是 Java，但项目是用 Kotlin 的 |
| 社区活跃度 | GitHub 上 Issue 响应时间？是否有官方技术支持？ | 最后一次更新在一年前 |
2. 兼容性检查
功能没问题，不代表就能直接跑起来。兼容性问题是我在实际项目里遇到最多的坑。
想起来有一次，我们把一个 SDK 从 Android Q 升级到 Android R，结果某家厂商的底层库签名算法变了——SDK 里硬编码的 libcrypto 版本太低，直接崩溃。查了两天才找到原因。
所以兼容性检查要覆盖这几个方面：
- 操作系统 & 版本：最低支持版本是否覆盖你的用户群体？比如你的 App 还在支持 Android 6.0，但 SDK 要求最低 8.0。
- 架构 & ABI：是否提供 arm64-v8a、armeabi-v7a、x86_64 的 native 库？很多国产手机厂商的模拟器可能是 x86。
- 第三方依赖：SDK 里是否带了 OkHttp、Gson、或者某个版本的 protobuf？会不会和你项目已有的版本冲突？
- 硬件 & 权限：比如人脸识别 SDK 是否需要前置摄像头权限？定位 SDK 是否需要后台定位权限？
⚠️ 特别注意：SDK 里如果包含了 .so 文件，一定要确认它是否使用了 System.loadLibrary 方式加载。我曾经踩过一个坑：某个 SDK 把两个不同版本的 libc++_shared.so 打包进去，导致应用启动时直接 crash。
怎么做兼容性预检？我的做法是：
- 在项目的多台不同配置的真机上跑一遍 SDK 的 Demo（至少要覆盖高低版本 + 不同SoC）。
- 用
gradle dependencies查看是否有依赖冲突。 - 针对 proguard 混淆做测试——很多 SDK 的反射调用在混淆后直接失效。
| 类型 | 典型问题 | 处理方式 |
|---|---|---|
| OS 版本 | Android 14 下某些权限被限制，SDK 未适配 | 找 SDK 方索取适配版本，或使用兼容性包装 |
| CPU 架构 | 只提供了 x86_64 的库，但用户有大量 arm 设备 | 尽快切换支持全架构的 SDK |
| 依赖冲突 | SDK 使用了不兼容的 Kotlin 1.5 协程 | 使用 exclude 或 force 版本，但需测试 |
| 混淆配置 | SDK 中的类被 ProGuard 混淆后无法反射 | 添加 -keep 规则 |
3. 许可证与费用
说白了，免费的不一定最便宜，收费的不一定最贵。我见过太多小团队用了 MIT 许可证的 SDK，结果商业闭源后被告——许可证里明确写了“任何派生作品也必须开源”。
所以选型时一定要把法务和财务因素算进来。我一般按下面几个维度去查：
- 开源许可证：MIT、Apache 2.0、GPL、LGPL、AGPL…… 每个对商业使用的限制不同。如果你做的是闭源商业 App，GPL 基本就排除了（除非你能把 SDK 作为独立进程调用）。
- 商业授权：有些 SDK 开源版功能有限制，比如只能免费调用 100 次/天，商用需要购买 License。一定要看 Clear Terms。
- 定价模型：按调用次数、按设备数、按年订阅、还是买断？我曾经优化过一个项目，选了一个按设备计费的 SDK，结果用户量上来后费用直接翻了好几倍——早期完全没算到。
- 隐藏成本：比如 SDK 的服务器端 API 是否需要额外付费？某些云服务商的 SDK 只包含客户端，服务端联网费用另算。
我的建议：在技术选型文档里，专门写一节“许可证与成本评估”，列出所有候选 SDK 的许可证类型、价格参考和风险点。这样产品/法务在 review 时能一眼看懂，省得后续扯皮。
下面是我常用的一张对比表，供你参考：
| SDK 示例 | 许可证 | 免费模式 | 商用费用 | 备注 |
|---|---|---|---|---|
| Glide（图片加载） | Apache 2.0 | 完全免费 | 无 | 放心用 |
| 百度人脸识别 | 商业授权 | 免费 100 次/天 | 按 QPS / 调用量阶梯付费 | 每日超量自动停机 |
| ZXing 二维码 | Apache 2.0 | 完全免费 | 无 | 但需要自行处理部分兼容问题 |
| 某个支付 SDK | 专有授权 | 仅测试可用 | 年费 + 交易手续费 | 某些公司还要求押金 |
另外，还有一个容易被忽略的点：许可证的传染性。比如你用了 GPL 的 SDK，你的整个项目都可能被要求开源。嗯，这可不是小事。我有个朋友的公司就因为这样被迫换了个 SDK，重构了三个月。
一个小工具：用 License Checker Gradle Plugin（com.jaredsburrows.license）可以自动扫描项目里所有依赖的许可证类型，生成报告。我每次新项目都会在 CI 里加这个步骤。
最后总结一下：选 SDK 就像找队友，功能、兼容、成本三者缺一不可。别急着开始写代码，花一两天把这三件事做扎实，后面可以省下几周的时间救火。