开屏关闭键、摇一摇阈值与续费前提醒：把三条要求翻成控件与状态｜洹拓科技
一、先把条文摊平成一张参数对照表
工业和信息化部《关于进一步提升移动互联网应用服务能力的通知》（工信部信管函〔2023〕26 号）是移动端交付里反复要引用的一份文件，它依据《个人信息保护法》《电信条例》等法律法规规章印发，管的是开屏与弹窗的关闭、频繁打扰、诱导误触、自动续费、下载安装、后台唤醒这几段用户体验。文件已经在施行。
这类条文最容易被读成态度：评审会上说一句“我们注意体验”，然后没有任何人能对“注意”给出可核对的值。我们的做法是把每一条要求先翻译一次，反复问同一个问题——这句话在界面上对应哪个控件，在代码里对应哪个参数，在测试里对应哪条用例。翻译不出来，就等于还没自查。下面是我们内部版本评审必带的对照表。
| 条文要求 | 对应的前端对象 | 必须写得出的参数 |
|---|---|---|
| 开屏与弹窗信息窗口提供清晰有效的关闭按钮 | 广告容器内的关闭控件 | 可点击区尺寸档位、与内容区的安全间距、出现时机与倒计时的关系 |
| 不得频繁弹窗干扰正常使用 | 会话级弹窗调度器 | 单会话次数上限、同内容重复间隔、跨渠道合并计数 |
| 不得用全屏热力图、高灵敏度摇一摇诱导误触 | 传感器触发层与整页点击热区 | 默认开关状态、引导文案与图标、触发下限档位、一键关闭路径 |
| 自动续费须征得同意、不得默认勾选、到期前显著提醒 | 续费状态机与提醒链路 | 六个状态各自的文案与可执行动作、提醒事件字段 |
| 推荐下载不得偷梁换柱、强制捆绑、静默下载 | 按钮与跳转目标的对照表 | 按钮文案、实际目标、下载是否需要显式确认 |
| 非服务必需不得自启动、关联启动或唤醒调用更新 | 后台唤醒场景清单 | 每个场景的业务理由、能否被策略关闭 |
| 处理规则要简洁告知、敏感项突出显示、建立已收集清单 | 告知页与清单导出链路 | 突出显示的层级、清单的生成来源与更新频率 |
这张表的价值不在整齐，在于它把“我们合规吗”这种无法回答的问题，换成了“这一格填不填得出”。填不出来的格子就是待办。
二、关闭键是控件参数，频繁是累加计数
“清晰有效的关闭按钮”这句话里，“清晰”和“有效”各自都能量化。有效指的是点得到：关闭控件的可点击区域要按我们自己的最小热区档位设定，不能等于图标的视觉尺寸——图标看着大、真正可点的只有中间一小块，是投诉里最常见的形态之一。清晰指的是看得见：关闭区与广告内容区之间要留出安全间距，避免手指落在广告边缘却被算成点击内容；深色主题和小屏机型上还要单独核对对比度，同一套资源在深色底上容易糊成一片。时机同样是要害——关闭按钮什么时候出现、倒计时期间能不能提前点、跳过和关闭是不是同一个控件，这三条要写进控件设计说明，而不是留给实现时随手决定。
关闭之后还有一条常被漏掉的规则：同一条内容不得因为用户点了关闭就换个入口再弹一次。这要求广告容器与弹窗调度器共用一个内容标识，关闭动作落到标识上，而不是只把当前视图隐藏。
频繁是累加出来的，不是单点决定的。开屏一次、插屏一次、悬浮窗再一次、首页气泡补一下，单看哪一处都不算多，用户感受到的是四次。所以我们把弹窗预算做成三个计数，并在同一个调度器里合并：同一会话内的弹窗总次数上限、同一内容标识的重复间隔、跨渠道的合并计数。跨渠道合并最容易漏，因为开屏归广告组件、插屏归业务代码、悬浮窗归运营位，三方各自记账就没人看总数。落地方式是让所有弹出请求都走同一个入口函数，由它返回允许或拒绝，并把拒绝原因写进日志。这样“一个会话里到底弹了几次”是可查询的事实，不是感觉。
留证的办法很朴素：发布前按机型分档截图，覆盖小屏、大屏、深色模式与系统字体放大四种条件，把关闭控件和各弹窗在第一屏的状态留档。真机上才看得见的东西，构建产物检查不到。
三、摇一摇：默认关闭、有引导、有下限、可关
条文点名了两类易造成误触发的方式，一类是把整屏做成点击热区的“全屏热力图”，一类是高灵敏度的“摇一摇”。我们的实现纪律是三条：不得默认开启；进入该交互必须有明确的文字与图标引导；触发阈值不得低于公开的实践指南给出的参考下限，且要能一键关闭。
公开的实践指南对摇动类触发给出的参考阈值是三项：加速度、转动角度与操作时长。这三项要写成产品配置里的三个参数，由设计评审确认后进入实现。这里要把话说准：它们是实践指南给出的参考阈值，不是条文里的强制数值，所以我们把它们作为下限使用，同时保留按机型与场景调高的余地。手持行走时的自然晃动、手机放在桌面上被震动传导，都可能落进低灵敏度的触发区间；用户不会把这理解成“我摇到了”，只会理解成应用乱跳转，这也是这类交互在应用商店评论里集中挨骂的原因。
还有两条要补。一是触发与落地之间要留一次可取消的过渡：摇动只应把候选动作摆到用户面前，跳转最好再由用户确认一下。二是引导的可发现性：提示文案要出现在触发之前，而不是触发之后补一句“下次不再提示”，事后告知不构成事前同意。全屏热图同理——页面上任意一点都会跳转的实现要禁用，广告区域与非广告区域的边界要写进组件约束，而不是靠视觉对齐碰运气。
四、自动续费做成六态状态机
续费问题的核心是一条状态链路，不是一句提示文案。我们把它固定成六个状态：未同意、已同意、即将到期、已扣费、已退订、争议中。每个状态必须同时定义两件事：用户在这一态看到什么文案，以及在这一态可以做什么动作。
| 状态 | 展示要点 | 该状态下必须可用的动作 |
|---|---|---|
| 未同意 | 功能权益与资费说清，勾选框的默认状态 | 主动勾选同意 |
| 已同意 | 续费周期、下一次扣费时间、退订入口 | 退订、更换支付方式 |
| 即将到期 | 到期时间、扣费金额、提醒是否已发送 | 退订、暂缓 |
| 已扣费 | 扣费时间与金额、本期服务已提供 | 索取凭证、退订后续周期 |
| 已退订 | 生效时间、剩余权益截止日期 | 重新订阅需再次明确同意 |
| 争议中 | 争议原因与处理进度 | 补充材料、撤回争议 |
同意这一环的要求很具体：不得默认勾选、不得强制捆绑开通。落到界面上就是勾选状态只能由用户产生，任何“为了少一步”而预置的选中都要下线；把会员与别的服务打包成一个开关的写法也要拆开。提醒这一环，条文要求以短信、消息推送等显著方式在续期前五天提醒，这个数字是政策口径，我们要做的是把它变成一条可审计的事件：发送渠道、内容版本、目标用户、发送时间与送达结果全部落库。做到这一步，“我们提醒过了”才有证据，否则只能靠一句“应该都发过了”。争议中这一态在实践中常被省掉，而恰恰是扣费争议最需要位置：它决定客服看到的是同一个状态，还是只能靠聊天记录重建现场。
退订的“便捷”我们也定了几条判据：路径不超过两步；不得要求用户联系人工客服才能取消；不得在退订路径上反复插入挽留页；退订后立即生效并把状态回显给用户。挽留可以有，但不能把取消动作藏在第三层。
五、下载三红线与后台唤醒的评审项
推荐下载的三处红线是：不得静默下载；不得把按钮伪装成别的功能；跳转目标必须与按钮文案一致。前两条靠实现约束，第三条靠对照表——每个下载或打开入口的按钮文案与实际目标成对登记，评审时逐条看。文案写“查看详情”而目标是安装包装机、文案写“继续”而跳到第三方应用市场，在这张表里会直接暴露。未经用户同意或主动选择，不得自动或强制下载；以折叠显示、主动弹窗、频繁提示的方式逼人打开，属于同一类问题。
自启动与关联启动没有界面，因此最容易变成债务。我们的做法是维护一份后台唤醒场景清单，每个场景写四项：被谁唤醒、唤醒后做什么、业务理由、能否关闭。写不出业务理由的关掉。更关键的是把这条要求在评审阶段就拦住——任何需要后台常驻、开机自启、被别的进程带起来的新功能，方案评审表里要有一栏，问的是“非服务所必需或无合理场景下不得自启动、关联启动或唤醒调用更新，本功能为何属于必需”。这一栏填不满，功能就不进版本。
六、告知、清单与一张上线自检表
个人信息处理规则要以简洁清晰易懂的方式告知，处理敏感个人信息的目的、方式、范围要突出显示。这里的“突出显示”我们不接受加粗一行这种实现：要么单独一屏，要么独立可展开区块，进入前给摘要，展开后能看到具体目的与范围。同时要建立已收集个人信息清单，而清单必须从实际存储与埋点导出，不能手抄一份文档交上去。我们把它做成构建期脚本的产物：从数据模型与埋点定义生成清单文件，随版本更新，并提供可下载的机器可读格式。手工维护的清单一定会漂移，只有可重新生成的清单才可信。
服务事项与资费这一条要在开通之前显著提示：存在会员开通、收费等附加条件的场景，提示位置不能塞进协议链接里，功能权益与资费是同一个页面上必须同时被看到的东西。
最后把上面这些收拢成一张上线前用户感知合规自检表。洹拓把它放在发布流程的最后一个卡点，七项内容分别对应关闭控件、弹窗合并计数、摇动类触发、续费六态与提醒留证、退订路径、下载文案对照、后台唤醒清单。每一项都要填结论并附证据链接或截图留档路径，由不在该项目里的人复核。这份表平时是自查工具，出问题时就是定位材料——它能直接回答“哪一条要求由哪个控件实现、证据在哪里”。反过来，如果一格只写了“已确认无问题”而没有任何证据指向，那一格就是没做。