第1章：双端SDK概览
大家好，欢迎来到这门课。我个人习惯把双端SDK理解成一座桥——连接你的App和第三方服务的桥。说白了，就是一组写好的代码库，让你不用从零造轮子。
但问题来了。一座桥如果一边是Android，一边是iOS，那桥墩的结构可能完全不一样。这就是我们今天要聊的核心：双端SDK适配。
1.1 什么是双端SDK？
SDK全称是Software Development Kit。双端SDK呢，指的就是同一套业务逻辑，在Android和iOS两个平台上都要能跑起来。
举个例子。你要在App里接微信登录。Android那边有一套接入流程，iOS那边又是另一套。如果你维护两套代码，写法不同，API不同，回调机制也不同。双端SDK的目的，就是把这些差异封装起来，对外提供统一的接口。
嗯，这里要注意一点。很多人以为双端SDK就是一套代码两个平台通用。这个想法不全对。真正的双端SDK，通常是在上层暴露统一的API，底层用条件编译或者桥接模式去调用各平台的原生能力。
1.2 为什么需要双端适配？
你可能要问：我直接写两套不就行了？为什么非要搞适配？
我在项目中遇到过好几次这种情况：产品说“加个分享功能”，Android那边调个微信SDK很快就好了，iOS那边同样的事要折腾半天——因为回调机制、线程模型、内存管理全都不一样。运维两套代码的后果是：
- 开发成本翻倍：每个功能要写两次，测试也要测两次。
- Bug不一致：同样一套逻辑，Android没问题，iOS闪退。排查起来很痛苦。
- 维护噩梦：版本迭代时，改一个地方要同步改两个文件，漏一个就出问题。
说白了一个道理：双端适配不是为了炫技，而是为了让你把精力放在业务上，而不是平台差异上。
1.3 常见的双端SDK类型
市面上常见的双端SDK，我可以给你列个清单。你想想看，你接触过哪些？
| SDK类型 | Android端关键差异 | iOS端关键差异 | 适配难点 |
|---|---|---|---|
| 支付SDK | 微信/支付宝使用intent回调 | 使用URL Scheme或Universal Link | 回调路径不同，结果状态同步 |
| 推送SDK | 依赖Google Play Services或厂商通道 | 使用APNs（Apple Push Notification Service） | 设备获取方式不同，推送到达率差异大 |
| 登录SDK | 通常使用Activity结果回调 | 使用ASWebAuthenticationSession | WebView与系统浏览器切换的体验差异 |
| 分享SDK | Intent机制分发 | UIActivityViewController | 分享渠道列表和返回结果格式不同 |
| 统计SDK | Activity生命周期监听 | UIViewController生命周期监听 | 页面埋点时机不同，数据对齐困难 |
你看这张表格。每个类型都有它自己的坑。我记得有一次做支付适配，Android那边调起支付宝后什么都不用管，结果iOS那边必须处理URL Scheme的返回数据。如果没处理好，用户的支付状态永远是“处理中”。
1.4 双端SDK的本质矛盾
双端适配搞多了你会发现，本质矛盾就三个：
- 异步模型差异：Android用Handler、回调、协程；iOS用闭包、Delegate、Combine/RxSwift。同一套业务逻辑，写出来的回调风格完全不同。
- 生命周期差异：Activity和UIViewController的创建、销毁、恢复、暂停时机不一致。SDK里如果持有了Context或者强引用，很容易内存泄漏。
- 线程模型差异：Android主线程不能做网络请求；iOS要求UI操作必须在主线程。SDK内部如果线程切不对，要么ANR，要么崩溃。
1.5 双端SDK适配全景图
为了让你有个整体认识，我把适配的完整过程画成了一张图。从原生SDK开始，经过抽象层，最终变成双端统一的接口。
从这张图你能看出来。适配中间层是核心。它做的事情很简单：把Android和iOS原生SDK的差异消化掉，暴露一个清爽的接口让业务方调用。我做过好几个项目，中间层的设计直接决定了后面维护起来到底是天堂还是地狱。
1.6 一个小总结
这一章我们聊了双端SDK是什么、为什么需要适配、常见类型有哪些。说白了就一个中心思想：不要重复造轮子，但也不要用一个轮子硬塞两辆车。