1. 移动端 SDK 适配概述

做移动端开发的，几乎天天跟 SDK 打交道。不管是第三方登录、支付推送，还是地图、直播，都得接 SDK。但接进来只是第一步，真正头疼的是不断迭代的系统版本跟 SDK 版本之间「打架」。说白了，SDK 适配 就是让你的 SDK 能在不同 Android 版本、不同 iOS 系统、甚至不同屏幕尺寸上稳定跑起来，不出 crash，不丢功能。

1.1 什么是 SDK 适配

SDK 适配，不是简单地把编译版本改一下。它包含三件事：

• API 兼容 —— SDK 调用的系统 API 在新版本里有没有被废弃、改名或者行为变化。
• 权限模型适配 —— Android 运行时权限、iOS 隐私权限，每年都可能收紧。
• 行为差异对齐 —— 同一段代码在 Android 13 和 Android 14 上跑，结果可能完全不一样。

我在项目里碰过一个真实案例：接了一家第三方的崩溃上报 SDK，在 Android 12 上一直好好的，上了 Android 13 直接闪退。查了半天，是 SDK 内部用了 PendingIntent.getActivity()，而 Android 13 强制要求必须指定 FLAG_IMMUTABLE。这就是典型的 API 兼容问题，不针对新系统做适配就会崩。

1.2 为什么需要适配

你想想看，现在 Android 系统版本从 5.0 到 14 都有不小的用户量，iOS 从 12 到 17 也不断有设备在跑。如果 SDK 不针对这些版本做适配，会发生什么？

• 用户手机上直接闪退，体验断崖式下跌。
• 功能异常，比如摄像头打不开、本地推送不触发。
• 被应用商店拒审（尤其是 iOS，隐私 API 使用合规要求极严）。
• 甚至被系统直接杀掉进程，连日志都抓不到。

我记得有一次，一个广告 SDK 在 iOS 14+ 上拿不到 IDFA，结果整个变现策略直接崩掉。后来才去适配 AppTrackingTransparency，但已经跑了一个多月空数据。嗯，适配这件事，晚一步就是真金白银的损失。

1.3 Android 与 iOS 生态差异总结

做双端适配，得先搞清楚这对「冤家」的根本差异。下面这张表是我根据多年踩坑经验整理的，覆盖了最影响 SDK 兼容性的几个维度。

维度	Android	iOS
系统碎片化	严重，厂商定制 + 版本分散	较轻，主要受旧设备硬件制约
权限模型	运行时权限（用户可随时拒绝）	隐私权限（需 info.plist 声明 + 首次授权弹框）
后台限制	各厂商加码，如华为/MIUI 对后台唤醒限制严格	iOS 统一管控，BGTaskScheduler 有限窗口
API 废弃策略	通常保留兼容性（但 targetSdkVersion 强制升级）	标记 deprecated 后很快就会硬移除
编译与运行	存在即时编译（JIT/AOT 混合）行为差异	纯 AOT，编译时固化大部分行为
隐私声明	政策宽松但 Google Play 审核渐严	App Store 审核严格，未声明即可能被拒

简单来说，Android 适配的难点在于「猜不透厂商」，同一个 Android 版本，不同厂商的定制 ROM 行为可能天差地别。iOS 适配的难点在于「规则变化快」，每年 WWDC 都会推出新的隐私或 API 限制，不跟进就等着被拒。

1.4 知识体系总览

下面我用一张流程图把 SDK 适配的核心要素串起来，你看一眼就能理清思路。

这张图把适配拆成四大块：系统 API 兼容、权限模型适配、行为差异对齐、隐私与审核合规。每个子节点对应具体的工作项。说实话，很多团队第一次接 SDK 时只关注了第一项，结果后面三项暴雷了才回头补，浪费大量时间。