Tidyvo 基于线上 v1.0.5 的竞品同构通知系统具体执行方案#

产品：Tidyvo: Deep Storage Cleaner（桌面名称：Tidyvo Cleaner）
包名：com.tidyvo.cleaner
当前线上基线：v1.0.5；本方案不擅自指定下一 App 版本号，正式启动新版本时再写入对应 PRD
方案日期：2026-08-13
竞品基线：Photo Recovery V1.0.3
配置真源：Tidyvo 自有中台；FCM 负责消息送达与配置刷新
产品现状：Notification Cleaner 已在上一线上版本加入，本方案按现有能力继续配置，不重复定义为新增功能 协作边界：本文只定义产品需求、中台规则、通知文案和验收口径，不代表实现状态；Codex 不开发业务代码，具体实现由开发团队基于线上 v1.0.5 代码完成

1. 执行结论#

Tidyvo 按竞品相同的系统结构执行：

自有中台下发策略、素材和灰度
→ 客户端保存 Offline_A / Online_B 或远程策略组
→ Service / Job / WorkManager / Alarm / FCM 维持调度和恢复入口
→ 时间窗口内按全局间隔循环尝试
→ 检查全局上限、通知栏数量和单素材频控
→ 从当前可用场景中选择通知
→ 本地通知或 FCM 展示
→ 统一跳板记录点击并进入 Tidyvo 对应功能
→ 在启动、功能完成和退出节点承接现有广告链路

“全盘复刻竞品”指：完整保留竞品已确认的调度模型、两套策略、17 个通知 ID、四类通知、特殊通知属性、后台恢复链、Notification Cleaner 和广告转化结构。

结合 Tidyvo 产品时，只做必要的业务语义替换：竞品的照片/视频/文档“恢复”场景，映射为 Tidyvo 已具备的照片整理、视频压缩、私密空间、联系人、To clean 和通知清理场景；不下发 Tidyvo 实际无法承接的恢复承诺。

1.1 先看懂竞品方案里的三个概念#

例如：Tidyvo 发出“发现 20 张重复照片”属于通知触达；Tidyvo 把其他 App 的普通通知隐藏并放进通知历史，属于 Notification Cleaner。两套能力互相联动，但不是一回事。

2. 当前能力基线#

3. 后台策略组#

3.1 竞品同构基线#

Offline_A（竞品较低频策略）和Online_B（竞品高频策略）是竞品 APK 中内置的两套兜底参数，不是联网/离线状态。中台把某个用户分到哪组，客户端就按哪组参数执行。

未确认值不得编造成竞品事实。Tidyvo 后台字段保留 null，由远程策略显式填写；不因为未确认而删除能力。

3.2 Tidyvo 首次发布配置#

首次发布必须同时建立 Offline_A 和 Online_B，两组均可直接分配用户。中台必须支持按以下条件分组：

• 首个支持本方案的 App 版本及以上；具体版本号在常老大正式启动下一版本时写入对应 PRD；
• 国家/地区；
• App 当前语言；
• Android 版本；
• 厂商；
• 安装时长；
• 最后活跃时间；
• Notification Cleaner 授权状态；
• 远程百分比。

发布配置：

3.3 竞品开关是怎样一层层控制的#

Tidyvo 中台 master_switch（整套系统总开关）/ emergency_stop（紧急停发）
→ 竞品 normal_enabled（普通通知总开关）
→ 场景 enabled（单个通知 ID 开关）
→ 模板 enabled（单句通知文案开关）

竞品已确认的是“普通通知总开关＋单素材开关”两层控制；master_switch 和 emergency_stop 是 Tidyvo 为方便中台统一控制而增加的最上层开关。

上面的层级以普通通知为例；ad_ntf（广告/运营通知）、res_ntf（大样式通知）、filter_ntf（常驻通知）按竞品结构分别保留自己的类型开关。

4. 统一落地页契约#

中台对外使用以下产品级枚举；开发团队负责映射到线上 v1.0.5 的真实内部路由。本文不以本地 v1.0.0 代码中的路由名称判断线上实现。未知值、参数缺失、当前页面不存在或权限不足时回退 Home。

5. 17 个通知 ID 的 Tidyvo 具体配置#

5.1 总表#

5.2 选择顺序#

每次循环只选择当前优先级最高的一条合格素材：

ID 18 空间/大文件
→ ID 15 删除后仍有待处理
→ ID 11 To clean
→ ID 17 Notification Cleaner
→ ID 13 长时间未清理
→ ID 16 新截图
→ ID 9 Smart Clean
→ ID 14 新增媒体
→ ID 6 截图
→ ID 10 模糊照片
→ ID 2 重复/相似照片
→ ID 3 大视频/压缩
→ ID 12 长时间未扫描
→ ID 7 联系人
→ ID 5 私密空间
→ ID 8 Records
→ ID 1 首页综合召回

这个顺序是 Tidyvo 的业务映射规则，不声称是竞品代码已确认的选择顺序；它只负责在竞品同构调度器中决定 Tidyvo 场景优先级。

5.3 逐 ID 执行规则#

5.4 统计周期和过期规则#

5.5 广告承接规则#

5.6 每轮决策顺序#

客户端每次被任一调度入口唤起后，按固定顺序判断：

读取最后一份校验通过的中台配置
→ 检查 master_switch / emergency_stop
→ 检查当前 App 版本是否命中发布范围
→ 选择用户所属策略组
→ 普通通知检查 normal_enabled（普通通知总开关）
→ 检查当地时间窗口
→ 检查 POST_NOTIFICATIONS
→ 检查安装时长门槛
→ 检查全局 upper_limit 与 interval_time
→ 检查当前活动通知数
→ 收集当前合格的17个ID候选
→ 按第5.2节优先级排序
→ 检查候选ID的 upper_limit / interval
→ 检查模板语言、enabled、weight、repetitions
→ 校验动态变量；无效时切换同ID无变量模板
→ 生成对应 normal/ad/res/filter 通知
→ 保存通知ID、模板、策略组、展示时间和次数

任一步不满足时记录抑制原因；轮询通知等待下一循环，事件通知在有效期内等待下一可执行机会。

5.7 本地与服务端职责#

6. 英文生产文案池#

英文为 fallback_locale，所有其他语言缺失或解析失败时使用本表。fixed_claim=true 的素材按竞品固定宣称方式保留，不要求本地实时扫描值。

7. 文案选择和变量规则#

7.1 文案选择#

1. 先按 App 当前语言筛选模板；没有对应语言时使用英语。
2. 同一 ID 中只选择 enabled=true 且未超过自身频控的模板。
3. 按 weight 加权随机；首次录入时同一 ID 各模板权重平均。
4. repetitions 控制同一模板可连续出现次数；超过后必须换该 ID 的其他模板。
5. 模板全部冷却时跳过该 ID，继续选择下一优先级场景。

7.2 变量#

fixed_claim=true 不读取本地变量，直接展示素材中固定数字。

8. Notification Cleaner（通知清理功能）联动#

Notification Cleaner 是“管理其他 App 通知”的功能，不是 Tidyvo 给用户发送通知的开关。该功能已上线，本方案只补齐它与竞品同构通知系统的联动。

Notification access（通知使用权）是系统授权，允许 Tidyvo 查看和管理其他 App 的通知；ongoing（持续通知）是音乐播放、导航、前台服务等持续存在的通知，竞品不会清除这类通知。

8.1 权限需求#

权限状态只决定能否执行对应能力，不改变 Offline_A / Online_B、17个ID和文案池的建档范围。

9. FCM Token 与中台联动#

FCM（Firebase 云消息服务）负责把服务端消息送到指定手机；Token（设备推送标识）相当于这台设备在 FCM 中的收件地址。FCM 是发送通道，不是普通通知、广告通知等通知类型。

9.1 Token 注册#

App 首次获取或刷新 Token 后上传：

{
  "installation_id": "install_uuid",
  "fcm_token": "token",
  "app_version": "{current_app_version}",
  "platform": "android",
  "locale": "en",
  "country": "US",
  "timezone": "America/New_York",
  "notification_permission": true,
  "notification_access": true,
  "strategy_group": "Online_B"
}

9.2 两类消息#

即时通知：中台筛选 Token 后通过 FCM HTTP v1 发送完整通知和路由。

配置刷新：

{
  "type": "config_refresh",
  "config_version": "tidyvo-ntf-001"
}

客户端比较版本后从中台拉取完整配置，校验、保存并重新安排本地任务。

9.3 统一 payload#

{
  "message_id": "msg_uuid",
  "campaign_id": "campaign_id",
  "notification_id": "9",
  "template_id": "TIDY_09_D",
  "type": "ad_ntf",
  "route": "smart_clean",
  "config_version": "tidyvo-ntf-001",
  "expire_at": "1786636800000"
}

服务账号和 HTTP v1 凭证只存在服务端，不进入 APK、中台前端、Git 或配置 payload。

10. 四类通知与特殊属性#

ntf 是 notification（通知）的缩写。竞品把通知分成以下四类，每类分别配置开关、频道、频率和展示属性：

例如，同一句“发现大文件”可以按普通样式做成 normal_ntf，也可以按竞品大版式做成 res_ntf；通知类型决定它怎么展示和受哪套配置控制。

特殊属性：

11. 后台维持和恢复链#

竞品不是只靠一个后台 Service，而是准备多条恢复入口：某一条被系统延迟或回收时，其他入口再次检查并补齐任务。

Android 及厂商系统可能延迟或限制这些能力；测试报告记录实际结果，但不删除对应实现。

12. 中台字段#

字段类型白话说明：boolean（开关，只有 true/false）、integer（整数）、string（文本）、enum（只能从规定选项中选择）、null（当前没有确认值，由后台另行填写）。

12.1 全局字段#

12.2 场景字段#

12.3 模板字段#

13. 埋点#

Notification Cleaner 内容只在本机处理；埋点不上传通知标题、正文、发送者、验证码、图片或原始 PendingIntent。

14. 中台配置示例#

{
  "config_version": "tidyvo-ntf-001",
  "master_switch": true,
  "emergency_stop": false,
  "strategy_groups": {
    "Offline_A": {
      "normal_enabled": true,
      "upper_limit": 5,
      "interval_time_minutes": 30,
      "repetitions": 1,
      "ad_ntf_upper_limit": -1
    },
    "Online_B": {
      "normal_enabled": true,
      "upper_limit": 99,
      "interval_time_minutes": 2,
      "repetitions": 3,
      "continuous_ntf_num": 12,
      "ntf_cooling_time_minutes": 2,
      "max_visible_ntf": 5,
      "android_16_max_visible": 1,
      "ad_ntf_upper_limit": -1
    }
  },
  "assignment": {
    "strategy_group": "Online_B",
    "app_version_scope": "{feature_enabled_app_version}",
    "percentage": 100
  },
  "global_rule": {
    "start_time": "08:00",
    "end_time": "21:30",
    "timezone_mode": "device_local",
    "min_install_age_minutes": 5,
    "future_when_days": 365
  },
  "scenes": [
    {
      "notification_id": 17,
      "enabled": true,
      "trigger_type": "interval",
      "condition": {
        "notification_access": true,
        "notification_cleaner_enabled": true
      },
      "upper_limit": 2,
      "interval_minutes": 15,
      "priority": 88,
      "route": "notification_cleaner",
      "template_pool_id": "POOL_TIDY_17",
      "notification_type": "normal_ntf"
    }
  ]
}

15. 开发交付需求顺序#

本章只规定需求交付顺序，不执行开发。

1. 开发团队以线上 v1.0.5 代码为唯一实现基线，不使用本地 v1.0.0 覆盖线上功能。
2. 开发团队回填线上 Notification Cleaner 的真实内部路由、白名单、数据库和权限链映射；产品验收按本文行为，不按类名或代码结构验收。
3. 中台提供策略、场景、模板、语言、灰度和回滚配置能力。
4. 客户端支持配置解析、版本校验、本地缓存和失败兜底。
5. 中台建立17个通知 ID及完整生产素材，并按确定语言范围导入多语言。
6. 客户端提供统一通知跳板，并只接受第4章产品级落地页枚举。
7. 完成 FCM Token 注册、配置刷新和即时通知需求。
8. 完成 Service、Job、WorkManager、Alarm、开机/升级与 FCM 恢复链需求。
9. 完成四类通知和特殊通知属性需求。
10. 测试团队逐 ID、逐策略、逐语言和逐 ROM 验收。

16. 验收清单#

• 开发团队确认实现基线为线上 v1.0.5，Notification Cleaner 现有能力未被旧代码覆盖。
• Offline_A 和 Online_B 参数可由中台直接分配。
• 17 个通知 ID 全部建档且各有 Tidyvo 场景、条件、路由和英文素材。
• ID 14、15、16 能按 Tidyvo 等价本地事件触发。
• App 12种现有语言均可选到对应文案，缺失时回退英语。
• 全局、场景、素材、通知栏数量和重复次数同时生效。
• Online_B 2分钟间隔、99条上限和广告 -1 能力可验证。
• 统一跳板拒绝未知路由并回退 Home。
• Notification Cleaner 权限、隐藏、历史、ID 17 和常驻服务形成闭环。
• com.tidyvo.cleaner 运行时强制加入白名单，Tidyvo 自身普通通知和常驻通知均不会被 Notification Cleaner 清除或写入清理历史。
• Service、快速 Job、18分钟 Work、24分钟 Job、8小时 Alarm、开机/升级和 FCM 均有测试结果。
• 非小米未来365天时间戳和删除通知恢复服务按设备记录结果。
• Token 刷新、解绑和失效清理可验证，APK及日志不暴露服务端凭证。
• 每个 ID 验证展示、点击、落地、广告请求和埋点链路。
• Pixel、Samsung、Xiaomi 至少各一台记录实际系统表现；未测设备明确标记未验证。