📚 课程目录第2章共享SDK基础与架构

共享SDK基础与架构

做SDK开发这么多年，我见过太多团队上来就写代码，结果后面集成的时候各种翻车。说白了，SDK的架构设计决定了它的生命力。这一章咱们就聊聊最基础的东西——SDK到底是什么、有哪些分类、常见的架构模型长什么样。先把地基打牢，后面讲动态授权策略才不会懵。

SDK，全称Software Development Kit，软件开发工具包。它不是一个单一的文件，而是一套工具、接口、文档和示例的集合。你可以把它理解成一个“半成品工具箱”——别人拿过去，按你的规则把业务逻辑填进去，就能快速集成到自己的App里。

我个人习惯这样区分：SDK是给开发者用的，它不是直接给终端用户看的。比如你调用微信支付的SDK，你写的是WXPay.request(params, callback)，用户根本不知道背后有SDK的存在。

一个小概念：SDK和库（Library）有区别。库通常是单一的二进制或源码文件，SDK还包含了配置文件、示例代码甚至模拟器。我早年做个推流SDK，连编译脚本和测试用例都打包进去了，那才叫完整的SDK。

嗯，分类方式有很多种。我从两个维度来划分，这样后面聊隐私增强时好对应。

你想想看，一个广告SDK如果想把用户浏览记录发给广告平台，没有动态授权机制，那基本就是裸奔。所以分类的意义在于：不同的SDK对隐私输出的敏感度不同，架构设计时就要考虑授权粒度。

避坑提醒：我曾经见过一个团队把基础日志SDK和广告SDK混在一起打包，结果日志里不小心传了手机号，被审计直接抓包。SDK分类一定要清晰，权限边界要独立。

这块是重点。不同的架构模型直接影响动态授权的实现难度。我挑四个主流的说说。

所有功能打成一个包，提供统一的入口。好处是集成简单，调用方只需要引入一个aar就行。但问题是：所有代码跑在同一个进程空间，隐私数据控制全靠开发者自觉。 我在直播项目里吃过亏——单体SDK里拿到的摄像头数据，一不小心就被其他模块拷贝了。

按职责分成接口层、核心层、数据层。接口层只暴露公共API，核心层处理业务逻辑，数据层管理本地存储。分层的好处是能拦截数据流出——你可以在数据层加授权检查，只有通过策略的数据才允许传出。

我建议做隐私增强时优先考虑分层架构。我在一个金融SDK里就用分层方案，把隐私敏感的操作都锁在数据层，上层想拿数据必须走授权通道。

主SDK只提供调度框架，具体功能由插件动态加载。权限管理可以做成一个独立的插件，这样切换策略时不需要更新主SDK。缺点是多了一个插件加载的复杂度，集成方得处理插件冲突。

近几年比较火。核心极小，只负责进程通信和权限校验，所有业务模块都是独立进程。每个模块申请数据时都要经过微内核的授权服务。说白了，授权成了SDK的“门卫”。这种架构天然适合动态授权，不过对系统资源要求高，移动端用得少一些。

为了方便对比，我整理了个表格：

架构模型	集成复杂度	隐私可管控性	典型场景
单体	低	低	简单工具类SDK
分层	中	中高	广告、支付
插件	中高	高	需要热更新策略的SDK
微内核	高	极高	安全沙箱、物联网

我的个人建议：如果你的SDK需要动态调整数据输出策略，至少用到分层架构。微内核虽然完美，但移动端启动耗时和内存占用会让你头疼。权衡之下，我倾向“分层+插件”的混合方案——分层保证数据隔离，插件保证策略热更新。

下面这张图把几个架构模型和隐私关注点的关系画出来，你一看就明白：

最后再补充一点：不管选哪种架构，隐私输出的控制策略都要落在架构的“边界”上。单体架构的边界是进程出口，分层架构的边界是层间通信，微内核的边界就是微内核自身。我们后面课程讲动态授权时，你会发现授权点就是这些边界。

实战小技巧：我习惯在SDK的架构图上标出所有数据流出点，用红色箭头表示。这样一眼就能看出哪些地方需要加授权检查。推荐你也试试。

好，这一章的内容差不多就这些。记住：SDK定义、分类、架构模型，是后面所有策略设计的基础。有空你可以拿出自己项目里的SDK，对照着表格分析一下它属于哪种架构，隐私隔离效果怎么样。