10、用户同意管理平台（CMP）集成：同意弹窗SDK选型、同意状态存储与同步、撤销同意机制实现
用户同意管理，说白了就是整个隐私合规体系的“守门员”。
我见过太多团队，功能做得花里胡哨，结果弹窗没做好，直接被应用商店下架。嗯，这章我们就来聊聊CMP（Consent Management Platform）怎么落地。
10.1 同意弹窗SDK选型：别只看名气
选SDK这件事，我个人习惯先看三点：合规覆盖度、性能开销、定制灵活性。
市面上主流的CMP SDK就那么几家：Google的UMP（User Messaging Platform）、OneTrust、ConsentManager.net，还有国内一些厂商自研的方案。
我建议你做个表格对比一下：
| SDK名称 | GDPR支持 | 国内法规支持 | 包体积增量 | 定制化程度 |
|---|---|---|---|---|
| Google UMP | ✅ 原生支持 | ❌ 需二次开发 | ~200KB | 低（样式受限） |
| OneTrust | ✅ 完整 | ✅ 支持 | ~500KB | 高（UI可深度定制） |
| ConsentManager | ✅ 完整 | ⚠️ 部分支持 | ~300KB | 中 |
| 自研方案 | 需自行实现 | 需自行实现 | 可控 | 最高 |
我在项目中遇到过一个问题：选了某大厂的CMP SDK，结果它在低端机上弹窗卡顿，用户点“同意”要等3秒。你想想看，这种体验用户能忍吗？
10.2 同意状态存储与同步：别让用户点两次
同意状态存哪里？这是个老生常谈的问题。
我个人习惯用SharedPreferences + 加密。为什么？因为简单、可靠。但要注意，别把同意状态和普通配置混在一起存。
// 我习惯这样存同意状态
class ConsentStorage(context: Context) {
private val prefs = context.getSharedPreferences(
"consent_prefs",
Context.MODE_PRIVATE
)
fun saveConsent(consent: ConsentResult) {
prefs.edit().putString("consent_data",
Gson().toJson(consent)).apply()
}
fun getConsent(): ConsentResult? {
val json = prefs.getString("consent_data", null)
return if (json != null) Gson().fromJson(json, ConsentResult::class.java) else null
}
}
这里有个坑：多进程同步问题。如果你的App有多个进程，SharedPreferences默认是不支持跨进程同步的。我曾经因为这个踩过雷——用户在A进程撤销了同意，B进程还在继续采集数据。
再说说跨设备同步。用户可能在手机上撤销了同意，但平板上的App还在用旧状态。怎么办？
我建议的做法是：
- 每次启动App时，从服务端拉取最新的同意状态
- 本地状态和服务端状态做合并，以服务端为准
- 用户每次操作同意/撤销，立即同步到服务端
说白了，就是服务端作为权威源，本地只做缓存。
10.3 撤销同意机制实现：给用户一个“后悔药”
GDPR明确要求，用户撤回同意应当和给予同意一样容易。这句话翻译成技术语言就是：撤销按钮不能藏得太深。
我见过有些App，同意弹窗做得贼大，撤销入口放在“设置-隐私-高级-管理同意”里。嗯，这种设计基本等于没有。
正确的做法是：
- 在App的隐私设置页面，放一个显眼的“管理同意”入口
- 点击后展示当前所有已授权的数据处理目的
- 用户关闭某个开关，立即停止对应的数据采集
代码实现上，我习惯用观察者模式：
// 撤销同意的核心逻辑
class ConsentManager {
private val listeners = mutableListOf<ConsentChangeListener>()
fun revokeConsent(purpose: DataPurpose) {
// 1. 更新本地状态
consentStorage.revoke(purpose)
// 2. 通知所有监听者
listeners.forEach { it.onConsentRevoked(purpose) }
// 3. 同步到服务端
syncToServer()
}
}
interface ConsentChangeListener {
fun onConsentRevoked(purpose: DataPurpose)
fun onConsentGranted(purpose: DataPurpose)
}
这里要注意的是，撤销同意后，要立即停止数据采集，不能等下次启动再生效。我曾经在审计时发现，某个SDK在用户撤销后还在继续上报数据，原因是它只检查了启动时的状态，没有监听实时变化。
10.4 整体架构：一张图说清楚
说了这么多，我们来看看CMP的整体架构。我画了一张图，帮你理清各模块的关系：
这张图展示了核心流程：用户点击弹窗 → 状态存储 → 通知下游模块。说白了，就是一条链，任何一个环节断了，合规就出问题。
10.5 实战中的几个坑
最后，分享几个我踩过的坑：
- 弹窗时机不对：别在App启动时立刻弹，用户还没看清界面就被吓跑了。我建议延迟1-2秒，或者等用户完成第一个操作后再弹。
- 状态丢失：用户清缓存后，同意状态没了，又弹一次。解决方案是把同意状态同时存到服务端。
- 第三方SDK不配合：有些SDK不提供动态开关数据采集的接口。遇到这种情况，我一般会加一层代理，在SDK外部拦截数据上报。
嗯，CMP集成这块就聊这么多。记住一句话：用户同意管理不是UI问题，是架构问题。弹窗只是表象，背后的状态管理和同步机制才是核心。