SDK 基础概念：定义、组成与生命周期
咱们做双人审批集成，第一步得把 SDK 摸透。
说实话，我刚开始接触 SDK 时，也以为它就是个代码包。后来踩了几次坑，才明白这东西远没那么简单。这一章，咱们就把 SDK 的定义、组成和生命周期彻底讲清楚。
什么是 SDK？不止是代码集合
SDK，全称 Software Development Kit，中文叫“软件开发工具包”。
维基百科上说它是“用于创建特定软件包、软件框架、硬件平台、操作系统的一整套开发工具”。听起来有点绕。我自己的理解更直白：你拿到一个 SDK，就等于拿到了一整套“能和某个系统对话”的能力。
你想想看，你要集成一个支付功能，难道要从头写一套加密、通信、回调处理？不用。SDK 把这些最麻烦的底层细节都封装好了。你调几个接口，传几个参数，功能就跑起来了。
但这里有个关键区分：SDK 不是 API。不少人会把这两个搞混。
| 维度 | SDK | API |
|---|---|---|
| 本质 | 可下载、可运行的代码包 | 一组接口定义（协议/端点） |
| 集成方式 | 嵌入到项目代码中 | 通过网络请求调用 |
| 依赖关系 | SDK 内部可能包含 API 调用 | API 本身不提供运行代码 |
| 典型例子 | 微信支付 SDK、Firebase SDK | GitHub REST API、Stripe API |
一个小建议：在双人审批集成中，如果第三方提供了 SDK，尽量优先用 SDK，而不是直接调 API。为什么？因为 SDK 内部已经处理好了重试、签名、错误码映射这些脏活累活。我见过太多项目因为直接用 API 没处理限流，线上挂了两次才换 SDK。
SDK 的组成：拆开看看里面有什么
一个标准的 SDK 包，打开后通常包含这几部分：
- 核心库（Core Library）——最底层的代码，通常是编译好的二进制文件或 jar/aar 包。你几乎不需要动它，但所有功能都依赖它。
- API 接口层（Interface Layer）——提供给你调用的类、方法、协议。这是你唯一需要“阅读文档”的部分。
- 资源文件（Assets）——图标、字符串、本地化配置。比如支付 SDK 里的银联 logo 或微信支付按钮。
- 配置文件（Config File）——appId、密钥、环境地址这类初始化参数。这部分千万别硬编码到代码里，我之前就因为这个吃过亏。
- 文档与示例（Docs & Samples）——好的 SDK 会带一份 sample 工程和一个 README。我个人的习惯是：先跑通 sample，再读文档。很多坑在文档里看不出来，跑一遍代码全清楚了。
我一般会把 SDK 里的这些组件按“使用频率”画张表，方便团队理解优先级。
| 组件 | 使用频率 | 修改频次 | 典型文件 |
|---|---|---|---|
| 核心库 | 低 | 几乎不 | sdk-core.aar, sdk-core.jar |
| API 接口层 | 高 | 每次接入 | PayService.java, PaymentProtocol.swift |
| 资源文件 | 中 | 较少修改 | drawable/, strings.xml |
| 配置文件 | 高 | 每次初始化 | config.json, SDKConfig.plist |
| 文档与示例 | 极高（前 3 天） | 参考用 | README.md, SampleApp/ |
重点提示：双人审批场景里，有一类“配置文件”特别容易被忽略——就是控制审批流程是否开启的功能开关。如果 SDK 把这个开关写死在配置文件里，那上线后想动态调整就很麻烦。我建议你选 SDK 时，注意看它是否支持运行时动态配置开关。
SDK 的生命周期：从出生到退役
很多人以为 SDK 下载下来就能一直用。这是最大的误区。SDK 是有生命周期的，而且这个周期直接影响到你项目的维护成本。
我把它分成 6 个阶段：
- 创建与开发——第三方开发团队设计 SDK 架构、写完代码、内部测试。
- 发布与集成——你下载 SDK，把它嵌入到你的项目里，打通双人审批流程。
- 集成测试——在测试环境验证 SDK 功能是否符合需求。这一步我建议写单独的集成测试用例，别跟业务逻辑混在一起。
- 上线与运行——SDK 在生产环境干活。这时候你主要关注：崩溃率、性能影响、兼容性。
- 维护与升级——第三方发布新版本（修复 bug、加功能）。你需要评估要不要升级，怎么升级。我经历过最惨的一次：升级一个支付 SDK 时，忘了做灰度，导致部分用户无法完成支付。从那以后，我定了个铁律：SDK 升级必须走双人审批。
- 废弃与归档——旧版本不再维护，必须迁移。如果你还在用 SDK 1.0 的接口，而对方已经发到 5.0 了……嗯，那你的技术债会越滚越大。
避坑指南：我曾经接过一个项目，团队用了个 SDK 的 1.0 版本，所有接口都是同步的。两年后，第三方发布了 2.0，改成了异步回调模式。项目里几百处调用点，全部要重写。为什么会这样？因为当初选型时只关注了“能不能用”，忽略了“这个 SDK 的版本演进策略”。如果 SDK 的升级是破坏性变更，那你在接入时就要做好隔离层——比如用个 adapter 包装一下，别让业务代码直接依赖 SDK 的具体版本。
总结一下这一章的核心：SDK 不是一块大砖头，它是精密的工具箱。了解它的定义避免你用错概念，掌握它的组成帮你快速上手，理解它的生命周期让你在后续的升级维护中少走弯路。这些基础打牢了，咱们才能开始讲双人审批要改造的那些具体细节。