2. SDK基础概念
好，咱们直接进入正题。SDK 的架构设计，说白了就是决定你的套件能活多久、能走多远。我见过太多 SDK，功能倒是挺全，但用起来像一团乱麻——改一个地方崩一片，升级版本用户得哭爹喊娘。这章我就把这几年的实战经验掰开揉碎，跟你聊聊怎么搭一个「耐造」的架构。
2.1 模块化设计原则：别让所有代码挤在一间屋子里
模块化不是什么新鲜概念，但在 SDK 里，它直接决定了你的用户能不能「按需取用」。我个人习惯把 SDK 拆成三层：核心层、功能层和适配层。
核心原则：高内聚、低耦合。每个模块只干一件事，并且干好。
举个例子，你做一个支付 SDK，别把「网络请求」「数据加密」「UI 弹窗」全塞一个类里。拆开：
- 网络模块：只负责发请求、收响应。
- 加密模块：只处理签名、验签。
- UI 模块：只展示支付页面。
- 业务模块：串联上面三个，对外暴露接口。
这样做的好处是什么？用户如果只需要「无 UI 后台支付」，直接跳过 UI 模块，依赖体积瞬间小一半。我在项目中遇到过，有个客户硬要把所有功能打包成一个 jar，结果集成后包体积暴涨 3MB，直接被对方技术负责人骂回来了。嗯，从那以后我再也不敢偷懒了。
2.2 接口设计规范：对外要「抠门」，对内要「大方」
接口设计是我认为 SDK 里最见功力的地方。说白了，你对外暴露的 API 越少，用户越不容易用错。我建议遵循「最小暴露原则」：
- 公开接口：只暴露用户真正需要的。比如
init()、pay()、onResult()。 - 内部接口：用
@hide或internal修饰，坚决不对外开放。 - 废弃接口：用
@Deprecated标注，并注明替代方案。
小技巧：接口命名要「自解释」。别搞什么 doSomething()，直接叫 startPayment()。用户看名字就知道怎么用，文档都省一半。
我曾经接手过一个老 SDK，里面有个 processData() 方法，传什么参数、返回什么结果，全靠猜。后来我重构时，直接把它拆成 encryptData() 和 sendData()，用户反馈瞬间好了很多。你想想看，接口就是你和用户之间的契约，契约写得模糊，后面全是扯皮。
2.3 依赖管理：别让你的 SDK 变成「依赖地狱」
依赖管理是 SDK 开发里最容易踩坑的地方。我见过最离谱的情况：一个 SDK 依赖了 20 多个第三方库，结果和宿主 App 的版本冲突，编译都过不去。
我的建议是：能不用就不用，非用不可就「隔离」。
| 依赖类型 | 处理方式 | 示例 |
|---|---|---|
| 基础工具库（如 Gson） | 尽量用宿主自带的，或提供「无依赖版本」 | 提供 sdk-core 和 sdk-with-gson 两个变体 |
| 网络库（如 OkHttp） | 声明为 provided 或 compileOnly |
让宿主自己决定版本 |
| UI 库（如 Glide） | 内部封装，不暴露给外部 | 用 internal 修饰图片加载类 |
避坑指南：千万不要在 SDK 里直接依赖一个固定版本的第三方库。我曾经因为依赖了某个旧版 OkHttp，导致宿主升级后网络请求全部报错。后来我改用「依赖注入」的方式，让宿主自己传进来，问题才彻底解决。
2.4 版本号语义化：让用户一眼看懂你的版本策略
版本号这东西，看似简单，但用错了能坑死用户。我强烈推荐 语义化版本控制（SemVer），格式是 主版本号.次版本号.修订号。
- 主版本号：不兼容的 API 修改。比如从 v1 升到 v2，用户必须改代码。
- 次版本号：向下兼容的功能新增。比如 v1.1 升到 v1.2，加了个新接口，旧接口照常工作。
- 修订号：向下兼容的问题修复。比如 v1.1.0 升到 v1.1.1，修了个 bug，用户无感升级。
核心原则：版本号不是随便写的，它是你和用户之间的「信任信号」。乱改主版本号，用户会怀疑你的稳定性；从不改主版本号，用户会怀疑你根本没在维护。
我记得有一次，团队里有人把一个小 bug 修复直接升了主版本号，结果用户以为 API 全变了，吓得不敢升级。后来我们定了个规矩：每次发版前，对照 SemVer 规范逐条检查，谁违规谁请下午茶。嗯，效果立竿见影。
2.5 架构总览：一张图看懂 SDK 设计
说了这么多，咱们用一张图把整个架构串起来。下面这张 SVG 图展示了 SDK 的模块划分、接口暴露范围和依赖关系。
这张图其实就概括了咱们这章的核心思想：分层清晰、接口克制、依赖可控、版本可追溯。你照着这个思路去搭 SDK，至少能保证三年内不用大重构。
2.6 小结：架构设计没有银弹，但有套路
说了这么多，其实就四个字：克制 + 规范。克制是指别什么都往 SDK 里塞，规范是指接口、依赖、版本都得有章可循。我见过太多 SDK 死在「功能膨胀」和「版本混乱」上，说白了就是一开始没想清楚。
嗯，这章就到这儿。记住，架构设计不是一蹴而就的，它需要你在每个版本迭代中不断打磨。但只要你把模块化、接口规范、依赖管理和版本语义化这四件事做扎实了，后面的路会顺很多。