2. SDK 分类：原生SDK、Web SDK、混合SDK 的区别与选型
做 SDK 集成这几年，我踩过最大的坑就是——选错了 SDK 类型。你想想看，一个原生 SDK 硬塞进 WebView，或者一个纯 Web SDK 去调设备的蓝牙——根本跑不起来。说白了，搞清这三种分类，是技术选型的第一步。
我习惯把 SDK 分成三类：原生 SDK、Web SDK 和 混合 SDK。这三者不只是在代码层面不同，连集成流程、性能表现、更新策略都差很多。
一句话概括：
- 原生 SDK：用目标平台语言写，直接调用系统 API。
- Web SDK：前端 JavaScript，跑在浏览器或 WebView 里。
- 混合 SDK：封装了一层桥接，让 Web 代码能调用原生能力。
2.1 原生 SDK
原生 SDK，就是直接用 Android 的 Java/Kotlin、iOS 的 Objective-C/Swift 写的库。它直接编译进应用，能访问所有系统接口——蓝牙、摄像头、指纹、陀螺仪，统统不在话下。性能也是最好的，因为不需要中间层转译。
特点：
- 安装即用，集成后打包进 app 包体。
- 平台相关，Android 和 iOS 各有一套代码。
- 更新需要发版，用户下载新版本。
- 性能无额外损耗。
我在项目中遇到过一个问题：一个图片处理库，用原生 C++ 写的，在 Android 上比 Java 版快了将近 3 倍。但如果拿 Web 方式去调用，相同操作会慢得让人崩溃。所以但凡涉及高性能计算、硬件交互、大量本地数据，原生 SDK 是唯一选择。
选型提示：如果你的 app 需要扫描二维码、人脸识别、推送通知——别犹豫，直接上原生 SDK。
2.2 Web SDK
Web SDK 就是嵌入到网页里的 JS 代码。最常见的就是各种统计分析、客服聊天、支付 H5 页面。它不依赖平台，<script> 标签一插就能跑。但受限也明显：无法直接获取设备硬件信息，必须通过浏览器 API 兜着。
特点：
- 跨平台，一套代码覆盖桌面、移动端。
- 无需打包，随时热更新。
- 性能受浏览器限制，不能做密集计算。
- 依赖网络，断网就罢工。
我记得有次客户要在他们的微信公众号里接入第三方登录。用原生 SDK 必须打包发版，而 Web SDK 改一行 redirect_uri 就能上线。最后我们选择了 Web SDK，半小时搞定。但注意——如果你的用户经常在弱网环境，就别指望 Web SDK 能稳定通信了。
警告：别试图用 Web SDK 调用设备的 NFC、指纹、蓝牙。浏览器压根不给这些权限。除非你走 WebUSB 或 WebBluetooth，但那又是另一套安全策略了。
2.3 混合 SDK
混合 SDK 有点「两头都占」的意思。它通常是一个 JS 库 + 一个原生桥模块。JS 部分负责业务逻辑，原生桥负责跟系统打交道。比如移动端常见的 React Native 插件、Flutter package，或者某些支付 SDK 里同时提供的 Cordova 插件。
我特别喜欢混合 SDK 的一点：业务逻辑可以写一次，桥接层适配不同平台。但代价是调试起来麻烦。曾经我遇到一个 ScrollView 里嵌 WebView 再调混合 SDK 的拍照功能，结果触摸事件被吞了——这种跨层面的 BUG 极难排查。
特点：
- 有一定跨平台能力，但核心原生功能仍需分别实现。
- 集成复杂度高，需要同时管理 JS 和原生两层。
- 性能介于原生和 Web 之间，桥接通信有开销。
- 更新灵活：JS 部分可热更，原生部分仍需发版。
2.4 三类 SDK 核心对比
下面这张表我建议你存下来。每次做选型时，对着它打勾就行。
| 对比维度 | 原生 SDK | Web SDK | 混合 SDK |
|---|---|---|---|
| 运行环境 | App 进程内（Android/iOS 内核） | 浏览器 / WebView | 主 App JS 引擎 + 原生桥 |
| 集成方式 | Gradle / CocoaPods / 手动添加库 | 加载 JS 文件或 npm 包 | 同时引入 JS 层和原生模块 |
| 性能 | 最高（无中间层） | 较低（渲染+JS 解释） | 中等（桥接损耗平均 5~20ms） |
| 平台依赖 | 强（各平台分开维护） | 弱（一套代码全平台） | 中等（业务统一，桥接分开） |
| 更新方式 | 发版 + 用户下载 | 热更新（刷新页面即可） | JS 热更，原生部分发版 |
| 典型场景 | 推送、支付、摄像头、图形处理 | 统计、客服、第三方登录、广告 | 跨平台插件、高频功能与 UI 混合 |
2.5 选型实战建议
我个人的选型步骤其实很简单，就三步：
- 先列功能清单：把所有必须调用的系统 API（相机、蓝牙、本地存储）写下来。如果能用浏览器 API 解决，就归到 Web 侧；否则划入原生或混合。
- 评估迭代频率：如果功能需要每周改，原生发版成本太高，果断上 Web 或混合。
- 看团队技术栈：团队都是前端？那优先 Web SDK，混合次之，原生最后考虑。
我曾经踩过的坑：有一次为了省事，把一个支付 SDK 的混合版本用在纯原生项目中。结果桥接层在 Android 低版本上崩溃，用户一支付就闪退。后来全部换成纯原生 SDK 才稳定。所以——如果没有跨平台需求，别为了「万一以后要用」而选择混合方案。
很多新人会纠结：到底哪种 SDK 最好？其实没有「最好」，只有「最合适」。你想想看，一个广告统计库用原生写，性能和混合/Web 几乎没差别，但维护成本却高出一倍——这就不划算。反过来，一个人脸识别 SDK 用 Web 去包，延迟大到用户骂娘。所以，回到业务本身，把上面的表格和图多看几遍，选型自然清晰。