Tidyvo 与 Clean / PDF / Recover 竞品保活、拉活及通知最终对比#

报告日期：2026-08-31
对比范围：Clean 7 个 APK、PDF 6 个 APK、Recover 1 个 APK，另含 Ora 1 个仅公开资料样本；与 Tidyvo v1.0.6 通知专项 PRD、v1.1.0 正式 PRD、Tidyvo 正式 Android 工程当前代码快照对比。
重点：后台保活与恢复、通知触发、频控、远程调控、通知文案、点击路由、实现差距。
不包含：各产品可见功能盘点、竞品线上投放效果推测、Tidyvo 业务代码改造。
重要边界：本文是最终分析报告；v1.1.0 是当前正式 PRD 真源，第 10 章的 Tidyvo 改造参数是待确认建议，未自动改写 v1.0.6 或 v1.1.0 PRD，也不代表已经开发上线。

1. 三分钟读懂报告#

1.1 最终结论#

1. 竞品不是靠一条“神奇保活链路”，而是靠多入口恢复。 成熟样本把 Foreground Service（前台服务）、短 Job、周期 Job、WorkManager、Alarm、Boot 和 FCM 汇入一个恢复入口；目标是提高恢复概率，不是保证永久存活。
2. Force Stop（用户在系统设置中强制停止）是共同硬边界。 本次已动态测试的 Clean、PDF、Recover 样本都没有可靠证据能绕过强停。
3. Boot 恢复是否成功，关键不只是有没有 Boot Receiver。 Android 16 上，CleanMas、CleanLoom、BlazeClean、AuraClean 利用开机临时白名单内的短 Job 成功建立 FGS；Clean Sweep Master、NeatPulse、Flare 的本轮结果不同。
4. 通知成熟度最高的共同点不是“发得多”，而是先产生候选，再经过多层门控。 常见门控包括 App 后台、设备解锁、屏幕状态、安装首延迟、全局冷却、场景冷却、单模板上限、每日总上限和时间窗口。
5. 2 分钟轮询只应理解为“每 2 分钟检查一次”，不能理解为“每 2 分钟发一条”。 是否展示必须由真实场景、权限、频控和单轮最多一条共同决定。
6. Tidyvo v1.0.6 的候选生成与单轮一条设计是清楚的，但全局防轰炸层偏弱。 它对 13 个周期/状态 ID 分别设置每日 5 次、间隔 15 分钟；数学上允许周期类最多 65 条/日，4 个事件 ID 又只有同 ID 60 秒间隔，没有全局每日总上限和全局冷却。
7. v1.1.0 没有重新定义通知频控，而是要求沿用既有发送时机、频控和授权，只调整通知点击路由。 因此 v1.0.6 仍是通知机制参考，但 v1.1.0 对页面和功能的删除会覆盖旧路由。
8. v1.0.6 的 17 个通知 ID 不能原样进入 v1.1.0。 To clean、Records 和独立 Large files 已删除；Notification Cleaner 被限定为一次性手动清理，不做后台持续监听。因此 ID 11、15、8、17 以及 ID 18 的大文件分支存在直接冲突。
9. 竞品常用远程配置控制开关、频率、模板和灰度；Tidyvo v1.0.6 目前中台只控制受众三态。 这让客户端简单，但上线后无法快速降低频率、关闭单场景或调整时间窗口。
10. Tidyvo 的文案真实性明显优于多数激进竞品。 通知专项要求动态数值必须来自本机真实数据，不使用固定 GB、固定提速比例或虚构风险；v1.1.0 也要求页面、Widget 和通知任务只使用真实本机数据，这点应保留。
11. Tidyvo 正式工程当前并未实现 v1.0.6 的完整通知与恢复系统，也未实现 v1.1.0 的完整产品范围。 当前代码可确认的是通知权限和充电场景的本地通知；Manifest 中未见自定义 FGS、Boot Receiver、JobService、FCM Service 或 NotificationListenerService，依赖中也未接 Firebase Messaging。
12. 推荐方向不是推翻现有“轮询＋事件”，而是在 v1.1.0 先完成 ID 清理和路由重映射，再补统一闸门。 保留合格的 2 分钟候选检查和主动事件；停用失效 ID，并增加全局冷却、全局日上限、时间窗口、单场景远程开关和一条可见业务通知槽位。

1.2 一页决策表#

白话结论： Tidyvo 现有方向的主要问题不是“2 分钟检查太频繁”，而是检查通过以后缺少一个能统管所有场景的总闸门。

2. 样本、证据和概念口径#

2.1 样本范围#

逆向 APK 合计 14 个；Ora 只有 Google Play 公开资料，不能当作 APK 逆向结论。

2.2 证据标签#

2.3 六个容易混淆的词#

3. 三类竞品的总体架构#

成熟样本大致都能归纳成下面这条链路：

Boot / FCM / Activity / Job / Work / Alarm / 本地事件
                         ↓
                    统一恢复入口
                         ↓
                确保调度器与状态可用
                         ↓
         周期轮询或事件回调生成通知候选
                         ↓
     权限 → 后台 → 设备状态 → 时间 → 冷却 → 上限
                         ↓
               本轮选 0 或 1 条模板
                         ↓
        发布通知 → 点击跳板 → 目标页 → 埋点

白话结论： 竞品的真正共同点是“入口多，但最终必须汇到同一套规则”，不是每个入口各发一条通知。

4. 保活、拉活与恢复能力对比#

4.1 组件覆盖#

4.2 Boot 为什么有的成功、有的失败#

Android 16 上四个成功白标包的动态顺序是：

直接从普通后台态请求主 FGS → 系统拒绝
收到 BOOT_COMPLETED 临时白名单 → 启动短 JobService
短 JobService 在允许窗口内进入前台 → 再请求主 FGS → 成功

关键不是“短 Job 能绕过系统”，而是它在 Boot 场景的临时合法窗口内完成了前台桥接。Receiver 到达晚、Job 执行时机错过、FGS 类型或通知权限不满足，都可能失败。

4.3 Tidyvo 与竞品的真实差异#

白话结论： Tidyvo 的方案图和成熟竞品相似，但当前代码还没有搭出这张网；不能用“依赖里有 WorkManager”代替实际恢复能力。

5. 通知触发与候选机制对比#

5.1 触发来源#

5.2 候选不是通知#

以 Tidyvo 2 分钟轮询为例：

第 1 轮：检查 13 个 ID → 都没有真实数据 → 0 条
第 2 轮：截图场景合格，但全局冷却未结束 → 0 条
第 3 轮：模糊照片和截图都合格 → 只选游标遇到的第 1 个 → 1 条
第 4 轮：其他场景仍合格，但全局冷却 → 0 条

所以“每天 720 次轮询”只代表最多 720 次候选检查。真正风险在于：如果没有全局冷却和全局总量，多个 ID 可以轮流绕开各自的 15 分钟间隔。

5.3 设备与页面门控#

白话结论： “已解锁、亮屏、竖屏”不是所有竞品统一的 Android 规定，而是部分高频竞品为了隐私、时机和自定义布局主动加的产品门槛。

6. 频控规则对比#

6.1 Clean 的高频多层控制#

6.2 PDF 的低频与覆盖控制#

6.3 Recover 与 Tidyvo#

6.4 Tidyvo 当前规则的数学风险#

• 2 分钟轮询：一天最多进入 720 轮候选检查。
• 13 个 POLLING / STATE ID：每 ID 5 次/日，理论产品上限为 65 条/日，即使每个 ID 自己都没有超限。
• 4 个 EVENT ID：只限制同 ID 成功展示后 60 秒，不设置每日上限，也不计入周期 ID 上限。
• 常驻通知、Notification Cleaner 汇总通知、运营 FCM 定时通知又不纳入本地普通通知频控。

这不是说 Tidyvo 一定会发到这个数量，而是说现有规则没有一条硬门槛能证明它绝不会发生。

7. 通知文案、真实性与路由对比#

7.1 文案主题#

7.2 Tidyvo 文案相对竞品的优势#

1. 动态变量无可靠值时，模板不进入随机池。
2. 文案、CTA、UI 和固定路由作为一整套随机，不交叉拼接。
3. 点击进入对应工具，不把所有通知都丢回首页。
4. 不使用固定虚假 GB、App 数量、提速比例和未经检测的“紧急/损坏/过期”。
5. 事件候选被拦截后不排队、不补发，避免过时通知。

7.3 仍需注意的 Tidyvo 文案风险#

白话结论： 最值得学习的是“场景、文案、数据和落地页一致”；最不该学习的是“用固定数字制造紧迫感”。

8. 远程调控能力对比#

8.1 竞品如何配置#

8.2 Tidyvo 当前中台边界#

Tidyvo v1.0.6 PRD 只允许一个字段：

优点是简单、客户端规则稳定；缺点是上线后如果单场景异常、频率过高或夜间投诉，只能整体关闭或发新版。

8.3 建议的最小远程配置（待确认）#

不建议把 43 套文案和复杂规则全部搬到中台。建议只增加 7 个运营安全字段：

不放中台： 文案正文、文件名、文件 URI、联系人、通知正文、FCM Token、任意新路由、超过客户端硬上限的频率。

9. Tidyvo v1.1.0 需求叠加对比#

9.1 两份 PRD 的关系#

因此，不能简单说“v1.1.0 完整继承 v1.0.6 的 17 个 ID”。准确口径是：

v1.0.6 提供通知机制和旧场景表
              +
v1.1.0 提供当前产品结构、权限、数据和路由真源
              ↓
逐 ID 做兼容性复核后，才能形成 v1.1.0 实际通知清单

9.2 v1.1.0 对通知直接产生的变化#

9.3 v1.0.6 场景 ID 对 v1.1.0 的兼容性#

9.4 v1.1.0 下的通知数量不是“13＋4”#

在未做新的产品决策前，v1.1.0 最保守的兼容集合是：

• 可直接保留：ID 12、9、5、7。
• 改路由后可保留：ID 10、2、6。
• 需要重新确认条件/数据：ID 13、1、3、18-A、14、16。
• 应停用：ID 11、8、18-B、18-C、15、17。

这是一份兼容性结论，不是已经改写后的最终 ID 表。尤其是 ID 13 的内部基线、ID 3 的视频阈值、ID 14/16 的“完整列表落页”体验，需要常老大另行确认后才能回写正式 PRD。

9.5 v1.1.0 与竞品对比后的新增判断#

1. v1.1.0 的任务直达和失效回 Home，接近 Recover 的统一跳板思路，比竞品“全部回 launcher”更清楚。
2. 图片/视频通知进入完整复核列表，不筛选新内容，降低了过期目标和深链失败风险，但文案必须避免承诺“点开只看刚新增项”。
3. Notification Cleaner 采用一次性手动处理，比 Photo Recovery 的后台监听和自动取消更收敛，权限解释和隐私风险更低。
4. 删除 To clean、Records 和 Large files 后，旧通知 ID 数量自然减少；这反而有利于降低 2 分钟轮询的候选密度。
5. v1.1.0 没有新增通知频控，所以第 6 章指出的全局冷却和总量缺口依然存在，但任何调整都属于新产品决策，不能冒充 v1.1.0 已有需求。

白话结论： v1.1.0 不是给旧通知系统再加一批功能，而是把旧通知必须落到的产品地基换了；先删掉没有落脚点的通知，再谈频率优化。

10. 适合 Tidyvo 的最终改造建议（待确认，不是现行 PRD）#

10.1 总体原则#

保留现有“轮询 + 主动事件 + 多入口恢复”，只改造成：

恢复入口层：Activity / Boot / FCM / Job / Work / Alarm
                         ↓
统一调度层：合并并发恢复，只维护一套调度器
                         ↓
候选层：2 分钟周期 ID + 即时事件 ID
                         ↓
统一闸门：受众 / 权限 / 后台 / 设备 / 时间 / 冷却 / 总量
                         ↓
选择层：单轮最多 1 条，事件不排队，周期游标继续
                         ↓
展示层：一个普通业务通知槽位 + 独立常驻/通知清理槽位
                         ↓
路由与记录：点击跳板 → 目标页；记录展示/点击/忽略/原因

10.2 推荐执行规则#

10.3 候选优先级#

不建议用“谁先被轮询到就永远优先”的单一顺序。可以保持游标公平性，同时按价值分三层：

同层继续使用游标避免固定场景长期霸占；跨层仍受全局冷却和每日总量约束。

10.4 哪些现有规则应保留#

• 每轮/每事件最多展示一条。
• 候选未展示不计次数和冷却。
• 已通过 v1.1.0 兼容性确认的事件被拦截即结束，不排队、不补发。
• 动态模板必须取得真实变量。
• 文案、UI、CTA 和路由整套绑定。
• FCM Topic 空数据消息只恢复调度，不直接展示通知。
• 所有恢复入口只进入统一调度器。
• Force Stop、系统拒绝和权限关闭写成真实边界。

10.5 哪些现有规则建议调整#

11. 数据口径与上线验证#

11.1 必须记录的决策日志#

不得上传文件名、URI、联系人、其他 App 通知正文、FCM Token 或真实个人内容。

11.2 能证明与不能证明#

11.3 验收矩阵#

12. Tidyvo 当前实现差距#

当前核对基线：/Users/fangbing/Desktop/龙虾/Deep Cleaner/，分支 main，提交 605eb22，工作区存在用户未提交改动；本报告只读检查，没有修改该工程。

13. 最终推荐结论#

13.1 产品结论#

1. Tidyvo 不需要照抄任何一个竞品的整套参数；三类竞品最值得组合的是：Clean 的多层门控、PDF 的低频/覆盖/忽略退避、Recover 的统一调度与路由。
2. v1.1.0 开发前应先完成通知 ID 收口：停用 ID 11、8、18-B、18-C、15、17；其余按第 9.3 节逐项改路由或确认数据条件。该结论尚未回写正式 PRD。
3. ID 收口后继续使用“2 分钟轮询 + 主动事件”没有问题，但轮询只能产生候选，所有候选必须经过跨 ID 的全局冷却和日总量。
4. 下一次通知需求确认最应该补的是：全局 60 分钟冷却、全局默认 6 条/日、08:00–22:00、事件计入总量、单场景远程开关；这些目前都不是 v1.1.0 已确认需求。
5. 保活侧先把统一恢复入口、Boot 时序和系统拒绝原因做成可验证能力，再讨论恢复率；不要以 specialUse 声明代替产品正当性。
6. 文案继续坚持真实数据和直接路由，不采用固定数字、虚假提速、文件损坏/过期等无证据恐吓话术；图片/视频通知必须遵守 v1.1.0 的完整列表落页规则。

13.2 开发顺序建议#

14. 证据入口#

14.1 Clean#

• Cleaner 7 包保活恢复与产品族群横向总览
• Cleaner 7 包通知场景、文案与规则全量摘录

14.2 PDF#

• PDF 竞品逆向分析统一总览
• PDF 竞品通知场景与规则全量摘录

14.3 Recover#

• Photo Recovery V1.0.3 竞品逆向分析统一总览（本地证据路径：../Recover/Photo_Recovery_V1.0.3_竞品逆向分析统一总览.md）
• Photo Recovery V1.0.3 独立复核报告（本地证据路径：../Recover/Photo_Recovery_V1.0.3_独立复核报告.md）

14.4 Tidyvo#

• ../../Deep Cleaner/01-产品需求/Tidyvo-PRD-v1.0.6.md：Tidyvo v1.0.6 通知需求真源；本报告没有修改。
• /Users/fangbing/Desktop/龙虾/Deep Cleaner/01-产品需求/Deep Cleaner-PRD-v1.1.0-阅读优化版.md：v1.1.0 线上与线下唯一正式 PRD 真源；本报告只读核对，没有修改。
• /Users/fangbing/Desktop/龙虾/Deep Cleaner/：Tidyvo 正式 Android 工程当前实现真源；本报告只读核对。

最终证据边界： 竞品 APK 中有组件、模板或远端字段，只能证明客户端具备该能力；当前线上配置、长期成功率、展示率、点击率和增量收益仍需远端响应、真机长测和对照实验验证。