主流 SDK 类型与应用场景：支付、社交、地图、推送等 SDK 的分类与选型
要说 SDK 接入，我个人的习惯是——在项目初期就把这一块梳理清楚。为什么呢？因为 SDK 选型一旦定下来，后面想换，代价非常大。你想想看，支付、社交、地图、推送，这些都是 App 的“基础设施”，选错了等于地基没打好。
这一章我们聊聊主流 SDK 的分类标准，以及在不同场景下到底该怎么选。我不喜欢讲大道理，直接上干货。
SDK 四大金刚：支付、社交、地图、推送
移动端开发绕不开这四个方向。我把它们称作“四大金刚”，因为绝大多数 App 至少会用到其中两三个。
| SDK 类型 | 核心能力 | 典型场景 | 代表厂商 |
|---|---|---|---|
| 支付 SDK | 交易、对账、回调处理 | 电商、会员充值、打赏 | 支付宝、微信支付 |
| 社交 SDK | 分享、登录、消息推送 | 内容 App、社区、游戏 | 微信开放平台、QQ 互联 |
| 地图 SDK | 定位、导航、POI 检索 | 出行、外卖、物流 | 高德、百度、腾讯地图 |
| 推送 SDK | 消息送达、厂商通道、标签 | 新闻、资讯、社交 | 极光、个推、友盟+ |
我的建议：不要为了省事一股脑全选同一家。支付场景下支付宝+微信几乎是标配，但地图就得看你的核心诉求。我曾经在物流 App 里只用了一家地图 SDK，结果偏远地区定位精度不够，被迫紧急接入另一家的兜底方案。
支付 SDK：选型看这三个维度
支付 SDK 的接入，表面上只是调一个支付接口，实际上坑很深。
- 费率与结算周期：支付宝通常支持 T+1 结算，微信支付个人商户可能 T+7。如果你们的 App 需要快速回笼资金，这个差异就应该考虑进来。
- 回调机制：异步通知丢失的风险是真实存在的。我在项目中就碰到过微信支付回调因网络闪断没收到，最后靠服务端轮询对账才修复的。
- 聚合支付 vs 单一支付：接入两家 SDK 工作量翻倍，但聚合支付 SDK（如 Ping++）会多一层依赖，且有额外抽成。我个人倾向在创业初期用聚合支付，用户量上来后再按支付渠道拆分。
避坑指南：我曾经在回调处理上掉过坑——支付成功后没及时回调，用户反复点击“购买”按钮，结果生成了多笔订单。解决办法是在回调处理前加一个“幂等性校验”，用订单号去服务端查是否已经支付成功。
社交 SDK：登录、分享、关系链
社交 SDK 的核心是解决“用户之间的连接”。不过说实话，很多时候我们只是想要一个“微信登录”和“分享到朋友圈”的功能。
- 授权登录：微信、QQ、微博是主流。要注意的是微信授权登录已经改为“静默授权 + 用户确认”两段式，直接拿用户信息没那么容易了。
- 分享能力：分享图片到朋友圈，分享链接到聊天窗口，这些都是高频场景。但 iOS 端微信分享有 Universal Link 的要求，Android 端有包名签名校验。这些细节一个没对上，分享就会失败。
- 消息推送 vs 社交 SDK：很多开发者会把推送 SDK 和社交 SDK 的聊天能力混淆。如果是做即时通讯 App，需要接入的是 IM SDK（比如腾讯云 IM、环信），而不是社交 SDK。
注意：社交 SDK 的包体积普遍偏大。微信 SDK 的 .aar 文件就有 2MB 左右，如果你只需要登录功能，可以考虑用微信开放平台提供的“精简版 SDK”。我之前的项目因为包体积超了 150MB 被商店警告，后来砍掉了很多不必要的社交模块才解决。
地图 SDK：精度、耗电 & 离线能力
地图 SDK 的选型说白了就是一个“精度 vs 耗电”的权衡。开发者容易忽视的是：地图 SDK 定位频率设置不当会导致 App 在后台疯狂定位，电池消耗直接翻倍。
- 定位精度：高德和百度在大多数城市精度一致，但在偏远地区或室内，百度地图的“室内定位”和“5G 辅助定位”可能有优势。我的经验是，线下测试不能只看公司附近 5 公里，要去郊区、地下室、电梯里测一遍。
- 离线地图：如果你的 App 要覆盖高铁、地下车库或国外用户，离线地图就很重要。百度地图的离线包更新频率比高德略高，但包体也更大。你可以根据场景规划：只下载城市级离线包，还是全量下载？
- 各平台对比：腾讯地图的定位接口对 iOS 适配比较好，高德的文档最全，百度地图的 POI 检索数据最新。没有完美的选项，只有最适合你场景的那个。
推送 SDK：厂商通道 vs 第三方通道
推送 SDK 这几年变化很大。国内安卓厂商已经逐步收紧了推送通道权限，如果不用厂商通道（比如华为 push、小米 push），App 在后台会被直接杀掉，推送收不到。
- 厂商通道：华为、小米、OPPO、vivo 都有自己的推送 SDK。你需要分别接入它们。好消息是，第三方推送 SDK（极光、个推、友盟+）都已经做了封装，你只需要集成它们的 SDK，它们会帮你适配各厂商通道。
- iOS 推送：走 APNs（苹果推送通知服务），不用管厂商通道。但 iOS 端推送的“通知扩展”和“快捷回复”功能需要额外配置。
- 标签系统：推送 SDK 的标签功能可以帮你做精细化运营，比如给“北京+活跃用户”打标签，推送优惠券。大部分第三方 SDK 都支持多标签组合，但数量有限制（通常最多 10 个标签）。
我的经验：推送 SDK 不光是发消息，它还是个很好的“用户体验度量工具”。你可以通过推送到达率、点击率来反推 App 的保活能力。如果发现推送到达率低于 80%，大概率是后台进程被系统清理了，这时候就需要接入厂商通道。
选型决策：一张表搞定
我把选型要点整理成一个简单的决策矩阵，你直接对着看就行：
| 需求 | 第一梯队 | 备选 | 注意点 |
|---|---|---|---|
| 支付 | 支付宝 + 微信支付 | 银联、PayPal | 必须有回调幂等性处理 |
| 登录/分享 | 微信 + QQ | 微博、Apple 登录 | 注意签名包名校验 |
| 地图 | 高德 / 百度 | 腾讯地图 | 定位频率可以按场景动态调整 |
| 推送 | 极光 / 个推 | 友盟+、华为 Push | 厂商通道是必选项 |
核心逻辑图：从需求到选型
下面这张图展示了 SDK 选型的完整链路。从业务需求出发，到分类评估，再到最终决策。你可以在项目启动阶段把它打印出来贴在工位上。
看到这个流程你可能会问：“那在实际项目中，我应该先看什么？” 我个人习惯是先从 稳定性 和 社区活跃度 入手。一个 SDK 如果连基本的 issue 回复都要等三天，那它的稳定性大概率也不靠谱。搞技术的你想想看，SDK 出问题的时候，开发时间最宝贵。
为什么我不建议盲从大厂
很多团队选 SDK 就认准“BAT 出品，必属精品”。现实往往不是这样。我遇到过一些大厂 SDK 的接入文档写得非常简略，甚至 API 注释都是空的。反倒是像极光、个推这样的专业 SDK 服务商，文档详细到每个接口的参数边界值都列出来了。
选型的本质是 匹配：你们的 App 在哪个阶段？有多少开发资源？对包体积的容忍度是多少？把这些想清楚了，选 SDK 就不会纠结。
一个小技巧：你可以在 GitHub 上搜对应 SDK 的 issues 和 releases，看看修复 bug 的频率如何。如果上次 release 是半年前，那就要小心了。我曾经因为图省事选了一个快三年没更新的地图 SDK，结果 iOS 13 发布后定位直接失效——那种感觉，真难受。
好了，关于 SDK 的分类和选型，先讲到这里。实践出真知，后面几章我们会手把手过一遍接入流程，到时候你就知道这些理论知识怎么用了。