报告口径本页直接渲染本地报告真源；静态能力、动态观察、推断和线上未验证项不得互相替代。
三款清理类竞品深度横向分析#
文档日期：2026-10-12
分析日期：2026-09-30
对象：Pure Clean Master、Swift Clean-Phone Manager Pro、CleanTool：file manager
口径：D1=本轮真机直接证据；S1=当前 APK/反编译直接证据；I=基于多项证据的合理推断；U=未验证。
重要边界：本文只代表本轮提取的 APK 与一次 Pixel 6a / Android 16 测试，不把 APK 内置能力等同于线上当前策略，也不把 12 秒存活外推为长期保活。
1. 结论先行#
- 三款产品本质上都是“清理工具箱 + 高强度广告 + 通知召回 + 后台常驻”的同类模型，不是单一垃圾清理器。文件清理只是入口，真实产品骨架还包含图片、App、流量、RAM、设备信息、通知清理等重复使用工具。（S1/D1）
- 广告介入早于核心价值交付。三款在首次通知授权后都立即出现全屏广告；Pure Clean 在首轮引导后又进入 AppLovin 全屏广告，Swift Clean 和 CleanTool 在首个 CTA 后出现第二个 Mintegral 全屏广告。（D1）
- 通知权限不只是提醒权限，也是后台装配门槛。三款均把通知授权与前台服务（Foreground Service，FGS）、周期 Job/Work、Alarm 及召回模块强绑定；拒绝后后台链路会明显收缩。（S1）
- 后台链路高度相似：初始化 Provider/Application → FGS → 启动失败时 JobService 兜底 → 自有周期 Job + WorkManager → 每日唤醒型 Alarm → 开机/升级/系统事件/FCM 重新装配 →
onTaskRemoved()再次尝试启动。（S1） - 这套链路能抵抗普通 Home 退后台和最近任务划除，但不能突破系统强停。三款在本机退后台或划卡 12 秒后仍有进程和 FGS；执行系统强停后，进程、活动 Service、活动通知与活动 Job 均消失，Alarm 被取消。（D1）
- 通知模块不是普通“定时提醒”，而是增长路由层。它同时接入文件变化、截图、安装/卸载、网络变化、电池、解锁/最近任务、通知累计、广告外跳、自动策略和 FCM，并通过 Action 直达具体工具页。（S1）
- Pure Clean 与 CleanTool 高概率属于同一产品族/共享代码基线：两者 Play 开发者相同、签名证书相同，
com.ai.smart目录 Pure 的 11 个类路径全部在 CleanTool 中命中，业务a/ac目录 41 个路径中有 40 个共同路径；前台服务、Alarm、Job、通知 ID 和大部分产品结构也一致。（S1/I） - Swift Clean 的代码命名空间和签名不同，但其商业化、权限、保活和通知召回结构与另外两款高度同构，更像另一套实现相同增长模型的代码基线。（S1/I）
- 最值得借鉴的是“事件—Action—功能落地”的统一路由、“场景门禁 + 冷却”的集中策略和可审计多语言资源；不建议照搬取消第三方通知、4 秒左右连续提醒、广告误触召回、未经实时测量的风险文案，以及无清晰用户价值的
specialUseFGS。（S1/I）
2. 样本身份与纠错#
| 用户提供入口 | 实际产品 | 当前样本 | minSdk / targetSdk | 身份结论 |
|---|---|---|---|---|
com.pureclean.smartfile.master |
Pure Clean Master | 1.1.8 (19) |
32 / 37 |
本机 Play 样本；公开页曾显示 1.1.2，本文以 APK 为准 |
Com.swift clean.phone.managepro |
Swift Clean-Phone Manager Pro | 1.0.9 (11) |
26 / 36 |
原字符串不是有效包名；实际为 com.swiftclean.phone.managerpro |
com.brisksignal.easyproxyapp |
CleanTool：file manager | 2.3.1 (231) |
32 / 36 |
商店产品不是 Proxy/VPN，而是清理/文件工具 |
三款均为 Google Play split APK，分析输入包含 base、arm64-v8a 与 xxhdpi。各文件 SHA-256、签名与反编译完整度见单包《样本与证据索引》；商店页只用于身份辅助，不覆盖 APK 真值。
3. 产品定位与功能覆盖#
3.1 功能矩阵#
| 功能 | Pure Clean | Swift Clean | CleanTool | 实现/验证边界 |
|---|---|---|---|---|
| Cache Clean（缓存清理） | ✓ | ✓ | ✓ | 依赖所有文件访问/Usage Access；本轮未授权真实清理 |
| Large Files（大文件） | ✓ | ✓ | ✓ | 有扫描、选择、删除链；删除准确率未验证 |
| Screenshot Cleaner（截图清理） | ✓ | ✓ | ✓ | 页面、文件监听及通知触发存在 |
| Similar Photos（相似照片） | ✓ | ✓ | ✓ | 页面和算法入口存在；聚类质量未验证 |
| App Manager（应用管理） | ✓ | ✓ | ✓ | 卸载最终走系统确认，不是静默卸载 |
| Network Traffic（流量） | ✓ | ✓ | ✓ | 依赖 Usage Access 与系统统计口径 |
| Speed Test（网速测试） | 未见核心入口 | ✓ | ✓ | 口径/准确率未抓包验证 |
| RAM / Memory（内存状态） | ✓ | ✓ | ✓ | 主要是状态展示和流程包装；未证明可强停其他 App |
| Device Info（设备信息） | ✓ | ✓ | ✓ | 展示系统/硬件/存储信息，不等于“修复设备” |
| Notification Clean（通知清理） | ✓ | ✓ | ✓ | 需 Notification access；代码会取消并保存第三方通知 |
| Desktop Widget（桌面小组件） | 非核心/待核 | ✓ | ✓ | OEM 桌面支持和实际使用率未验证 |
3.2 共同产品漏斗#
首次启动
→ 立即请求通知权限
→ 全屏广告
→ 设备/清理引导
→ 再次广告或高权限引导
→ 工具箱首页
→ 扫描/结果/清理页
→ 插屏/原生/横幅广告
→ 常驻通知、事件通知、FCM 再召回
→ 按 Action 回到具体工具页
这个结构的关键不是“功能多”，而是同一套功能页面同时承担自然使用、广告承载和通知回流三种角色。（I）
3.3 功能价值判断#
- 文件枚举、用户选择删除、系统卸载 Intent、UsageStats/NetworkStats、NotificationListener 等都有真实 Android 能力支撑。（S1）
- “RAM 加速”“一键优化”“后台应用拖慢手机”等表达不能仅凭 Activity/动画成立。当前证据能证明读取内存状态与展示清理流程，不能证明普通 App 能统一结束其他进程或稳定改善性能。（S1/U）
- 三款通知清理都会处理第三方通知：过滤自身/ongoing 等条件后，读取包名、标题、正文与时间，调用系统取消接口并写入本地数据库或计数。这比“整理通知”更具侵入性。（S1）
4. 广告与商业化深拆#
4.1 广告架构对比#
| 项目 | Pure Clean | Swift Clean | CleanTool |
|---|---|---|---|
| 主要聚合/加载层 | Google Mobile Ads + AppLovin MAX | TradPlus | Google Mobile Ads + AppLovin MAX |
| 启动位 | newcleanStart |
swiftcleanStart |
newcleanStart |
| 扫描位 | newcleanScan |
swiftcleanScan1、swiftcleanScan |
newcleanScan |
| 完成位 | newcleanFinish |
由扫描位/页面链承接 | newcleanFinish |
| 首页位 | newcleanHome Native/Banner |
RC 控制 Native/Banner | newcleanHome Native/Banner |
| 额外返回位 | extra |
广告生命周期回跳链 | extra |
| 配置分层 | D0–D3 本地 JSON + Remote Config | max0–max3 + Remote Config |
D0–D3 本地 JSON + Remote Config |
| 本轮首启实见 | Mintegral → AppLovin | Mintegral → Mintegral | Mintegral → Mintegral |
Manifest 中存在更多广告适配器，只能证明 SDK footprint（打包足迹），不能认定它们都在当前线上 waterfall/bidding（瀑布流/竞价）中请求或填充。实际广告网络、价格、地域和频率仍需抓包或后台数据。（S1/U）
4.2 首次用户价值与广告顺序#
| 产品 | 首次关键顺序 | 产品判断 |
|---|---|---|
| Pure Clean | 通知权限 → Mintegral → 引导 → Start to Use → AppLovin → 首页 |
两次商业节点早于一次完整清理价值交付 |
| Swift Clean | 通知权限 → Mintegral → “快速清理” → Mintegral → 所有文件访问引导 | CTA 文案是功能承诺，实际先进入第二次广告 |
| CleanTool | 通知权限 → Mintegral → 引导 → Start to Use → Mintegral → 首页权限提示 |
首轮广告素材使用“内存已满”，第二轮使用“PDF 失效”风险叙事 |
上述广告素材由网络实时返回，只证明本轮展示实例；是否由 App 方直接配置、是否长期使用、是否构成政策违规，需要结合广告来源和投放后台专项核验。（D1/U）
4.3 远端控制能力#
- Pure Clean / CleanTool：按安装第 0、1、2、3+ 天加载不同本地配置，Firebase Remote Config 可替换广告组合及部分通知频控。（S1）
- Swift Clean：Remote Config 可替换
max0–max3整套广告位配置，并控制展示/点击上限、广告 ID 黑名单、加载实验和首页 Native/Banner。（S1） - APK 中的默认值只是 fallback（兜底值），不是生产环境当前值；本文没有登录 Firebase、TradPlus、MAX 或投放后台。（U）
5. 权限调用与产品绑定#
5.1 高影响权限矩阵#
| 能力/权限 | 三款共同状态 | 主要用途 | 风险与边界 |
|---|---|---|---|
POST_NOTIFICATIONS |
Manifest + 首启请求 | 常驻 FGS、场景召回、FCM | 被用作后台链总开关，不只是普通提醒 |
MANAGE_EXTERNAL_STORAGE |
Manifest + 系统设置跳转 | 全盘文件扫描/删除 | Google Play 高敏权限；本轮未授予 |
PACKAGE_USAGE_STATS / Usage Access |
设置页引导 | App 缓存、最后使用、流量 | 特殊访问；未授权时数据不完整 |
| Notification Listener Access | 自有 Service | 读取、取消、保存第三方通知 | 可能影响消息可达性和隐私；本轮未授予 |
FOREGROUND_SERVICE |
使用中 | 常驻进程与通知 | 必须有持续、用户可理解的前台用途 |
FOREGROUND_SERVICE_SPECIAL_USE |
声明 | 后台常驻链 | 需准确 subtype/用途和 Play 审核依据 |
RECEIVE_BOOT_COMPLETED |
声明 + Receiver | 开机重装配 | 不能据此声称“强停后复活” |
WAKE_LOCK |
声明/依赖 | 后台任务/SDK | 自有直接持锁范围需进一步运行时确认 |
REQUEST_DELETE_PACKAGES |
声明 | 跳系统卸载页 | 不等于静默卸载 |
| Advertising ID/AdServices | SDK/声明 | 广告与归因 | 需与 Consent、Data Safety、隐私政策对账 |
5.2 实际授权结果#
本轮只授予通知运行时权限；所有文件访问、Notification access、Usage access 均保持关闭。已验证权限提示和设置跳转，未验证全盘删除、第三方通知取消和按 App 流量的真实结果。（D1）
6. 保活与拉活机制#
6.1 共同链路#
Provider / Application / 首个页面
└─ 通知权限与策略门禁
├─ startForegroundService()
│ └─ 自定义 RemoteViews 常驻通知
├─ 启动异常 → JobService fallback（Pure/CleanTool 3857；Swift 22002）
├─ 自有周期 Job（Pure/CleanTool 3432；Swift 20）
├─ WorkManager（约 15 分钟级）
├─ AlarmManager.set(ELAPSED_REALTIME_WAKEUP, 约 24 小时)
├─ Boot / Package replaced / 系统事件 Receiver
├─ FCM Service
└─ onTaskRemoved()/onDestroy() 再次调度
AlarmManager 的 type 2 是 ELAPSED_REALTIME_WAKEUP（唤醒型），但调用的是非 exact 的 set()；系统仍可能合批、漂移或延迟，不能写成精确定时。（S1）
6.2 单包关键参数#
| 参数 | Pure Clean | Swift Clean | CleanTool |
|---|---|---|---|
| FGS Service | com.ai.smart.gXXfik |
crown.arithmetic.floor.mowxgu |
com.ai.smart.gXXfik |
| FGS 通知 ID | 1 |
20 |
1 |
| FGS Channel | channel_id_resident |
crown_floor |
channel_id_resident |
| Job fallback | 3857 |
22002 |
3857 |
| 自有周期 Job | 3432 |
20 |
3432 |
| Alarm Receiver | com.ai.smart.BpFZcYhmZ |
crown.arithmetic.floor.kQuACgQQ |
com.ai.smart.BpFZcYhmZ |
| Alarm 类型 | ELAPSED_REALTIME_WAKEUP |
ELAPSED_REALTIME_WAKEUP |
ELAPSED_REALTIME_WAKEUP |
6.3 动态存活结果#
| 测试动作 | Pure Clean | Swift Clean | CleanTool | 可下结论 |
|---|---|---|---|---|
| Home 后 12 秒 | 进程/FGS 在 | 进程/FGS 在 | 进程/FGS 在 | 短窗口后台存活成功（D1） |
| 最近任务划除后 12 秒 | 进程/FGS/Job 在 | 进程/FGS/Job 在 | 进程/FGS/Job 在 | 抗普通划卡链路生效（D1） |
| 系统强停后 3 秒 | 均消失 | 均消失 | 均消失 | 不能突破 Android 强停边界（D1） |
未做重启、升级、Doze、后台受限、低电量、断网数小时和多 OEM 长窗口测试，因此“长期保活率”“日级到达率”均为 U。
7. 通知召回系统#
7.1 规模与基础参数#
| 维度 | Pure Clean | Swift Clean | CleanTool |
|---|---|---|---|
| 场景/Action 规模 | 15 个场景、4 个优先级池 | 23 个 Action 家族；FCM 分支含 10 组本地模板 | 15 个主要场景，另有 FCM 模板 |
| 普通通知 ID | 8194 |
21 |
8194 |
| 常驻通知 ID | 1 |
20 |
1 |
| Channel 数 | 3 | 3 | 3 |
| 内置语言 | 6 | 8 | 6 |
| 文案资源规模 | 22 个英语模板/动态变体 + 六语全表 | 8 语种 × 89 个 tongzhi_* 字段 |
40 个直接通知 key 六语全表 + 10 个 FCM 随机模板 |
| 连续提醒 | 首条后约 4 秒，Samsung 1 次/其他 3 次 | 首条后约 3.5 秒更新同一 ID | 首条后约 4 秒连续替换 |
完整标题、正文、按钮、变量、语言、触发、频控、Action 和落地页不在横向表中删减，分别见三包《拉活通知规则与文案全量报告》；本文只做机制对照。
Swift Clean 源码共出现 24 个相关 notify_* 标识，但 notify_highpriority_ 只是内部 builder name 前缀，不是独立点击路由；因此产品口径按 23 个 Action 家族计算。（S1）
7.2 共同触发类别#
| 触发类别 | 典型事件 | 目标落地 |
|---|---|---|
| 文件/存储 | 大文件、截图变化、存储不足、缓存 | Cache / Large File / Screenshot |
| 图片 | 新截图、相似照片候选 | Screenshot / Similar Photo |
| App | 安装、卸载、最近任务/后台应用 | App Manager / RAM |
| 网络 | Wi-Fi/网络切换、流量、测速 | Network Traffic / Speed Test |
| 电池/系统 | 充电、断电、低电量、解锁、开机 | Device Info / RAM / 首页 |
| 通知累计 | 拦截/累计达到阈值（常见 20 条） | Notification Clean |
| 广告离开 | 广告点击或 AppLovin 外跳 | 返回原 App/恢复任务 |
| 自动/定时 | 池策略、周期 Worker/Job/Alarm | 对应清理功能 |
| 远端 | FCM payload/action | 本地 Action 路由 |
7.3 总门禁与频控#
三款实现名不同，但共同门禁大致包含：
- 通知总开关与系统通知权限；
- App 当前前后台状态；
- 屏幕、横屏、通话/特殊页面等阻断条件；
- 全局或 type/pool 级最短间隔；
- scene（场景）级冷却；
- 单日次数、连续未点击上限或特殊场景每日一次；
- 设备/系统分支（例如 Samsung 连续提醒次数不同）；
- Remote Config 开关与频次覆盖；
- 同一通知 ID 的覆盖、取消和重新发布。
这说明通知系统是集中式策略引擎，而不是各页面零散 notify()。（S1）
7.4 Swift Clean 动态通知直证#
本轮 Swift Clean 实际发布：
| 字段 | 动态值 |
|---|---|
| ID | 21 |
| effective Channel | event_recall_channel_v2 |
| Channel name | EnMusic 提醒 |
| Importance | 4（HIGH） |
| 标题 | 背景應用正在拖慢手機 |
| 正文 | 太多應用在背景執行。一鍵釋放記憶體。 |
| flags | `ONGOING_EVENT |
Channel name 与清理产品语义不一致，属于合规和可解释性风险。该通知证明拉活模块在当前环境实际运行，不只是“APK 里有代码”。（D1）
7.5 主要通知风险#
- NotificationListener 取消其他 App 的非 ongoing 通知并保存包名、标题、正文和时间，可能影响用户收件可达性并处理敏感文本。（S1）
- 约 3.5–4 秒的连续提醒、High importance、高振动/灯光和 ongoing 属性会提高打扰度。（S1/I）
- “设备变慢、存储不足、内存过高、发现垃圾”等状态若没有实时可信测量，容易形成虚假紧迫感。（S1/I）
- 广告外跳召回把商业事件包装成系统提醒，用户可能误解为设备问题或必要任务。（S1/I）
- FCM 的受众、频率、payload 和线上文案不在 APK 中完整可见；仅有 Service/解析代码不等于线上正在发送。（S1/U）
8. 代码族群与复用判断#
8.1 Pure Clean 与 CleanTool#
| 证据 | 结果 | 判断 |
|---|---|---|
| Google Play 开发者 | 同为 Prosperous Connection Studio | 同一发布主体（S1） |
| 签名证书 SHA-256 | 完全相同 | 同一签名控制链（S1） |
com.ai.smart |
Pure 11 个路径，11 个均在 CleanTool 命中 | 后台模块高度同源（S1） |
a/ac 业务路径 |
Pure 41 个，40 个与 CleanTool 共同 | 产品主架构高度同源（S1） |
| FGS/Alarm/Job/通知 ID | 核心标识与参数相同 | 共享框架或分支演进（S1/I） |
| 差异 | CleanTool 多测速、Widget、更多通知/页面细节 | CleanTool 更像扩展分支（I） |
8.2 Swift Clean#
Swift Clean 签名不同，自有命名空间为 crown.arithmetic.floor 等，不能归入同一签名产品族。但其“通知权限 → FGS/Job/Alarm/Work → 事件通知/FCM → Action 功能路由 → 广告变现”与另外两款结构高度相似。当前证据支持“同策略模型、不同代码基线”，不支持认定为同一开发者或同一源码分支。（S1/I）
9. 风险优先级#
| 优先级 | 风险 | 影响 | 建议验证 |
|---|---|---|---|
| P0 | NotificationListener 取消并落库第三方通知 | 用户漏读、敏感内容处理、隐私披露不一致 | 授权后用脱敏测试通知核对过滤、数据库、删除和备份规则 |
| P0 | All files access 与清理承诺 | Play 审核、误删、数据安全 | 最小范围、删除确认、回收/恢复路径、Data Safety 对账 |
| P0 | SDK/日志中设备标识与广告数据 | 隐私与合规 | Consent 前后抓包、SDK 数据清单、日志脱敏、地区矩阵 |
| P1 | 特殊用途 FGS 与高频后台重装配 | Play 政策、耗电、系统限制 | 对照当前 FGS 声明、Battery Historian、Doze/OEM 长测 |
| P1 | 3.5–4 秒连续 High 通知 | 打扰、投诉、通知权限关闭 | 单日/单周上限、静默窗口、未点击熔断、远端 kill switch |
| P1 | 广告误触/风险叙事通知 | 误导、信任与政策风险 | 文案审计、广告来源归因、禁止伪系统态表达 |
| P2 | Remote Config 可大范围改频次/广告 | APK 审核看不到线上策略 | 参数白名单、服务端边界、变更审计、回滚 |
| P2 | 强停能力误表述 | 开发预期错误 | 明确区分划卡、进程回收、强停三种状态 |
10. 给我方产品与开发的建议#
10.1 可以借鉴#
- 建立统一
NotificationScenario（通知场景）模型：事件、资格判断、频控、文案 key、Action、路由、埋点集中管理。 - 通知 Action 直达功能页，但落地前重新校验权限和数据，失效时降级到安全页面。
- 文案使用可审计资源表，变量只来自真实系统/业务数据；标题、正文、CTA、无障碍文本和多语言一起验收。
- 使用全局 kill switch、场景开关、单日/单周上限、静默时段、连续未点击熔断和版本级回滚。
- 把 Home、划卡、系统回收、强停、重启、Doze、后台受限、低电量、断网拆成独立验收场景。
- 广告返回可恢复原任务，但优先用应用内状态恢复；只有用户明确同意且确有价值时才使用系统通知。
10.2 不建议照搬#
- 不取消或保存第三方通知正文，除非这是明确核心功能、用户主动开启且有严格最小化/删除/备份隔离。
- 不使用 3.5–4 秒连续提醒或 High importance 轰炸；不要用同一 ID 高频覆盖制造持续可见。
- 不用未经检测的“内存已满、手机变慢、发现大量垃圾”等结论制造紧迫感。
- 不把广告点击、广告误触或外跳伪装为设备风险通知。
- 不为了“保活”单独声明
specialUseFGS；先证明持续用户可见价值和政策资格。 - 不把 APK fallback、Remote Config 能力或一次真机成功写成生产到达率、长期保活率或实际线上策略。
10.3 开发落地前必须确认#
- 每个后台组件的用户价值、启动条件、停止条件和系统版本差异；
- 通知权限拒绝/撤销后的功能降级；
- FGS type、Channel、常驻卡片与 Play 声明一致性；
- Alarm 是否真的需要 wakeup，是否能改为 WorkManager；
- Action 是否可被伪造，导出 Activity/Receiver 是否有保护；
- PendingIntent mutability、唯一 requestCode、参数校验；
- FCM 只接受白名单 action，不信任任意服务端字段；
- Remote Config 的允许范围、默认值、过期、回滚和审计；
- 通知/Usage/文件数据是否进入备份、日志、分析和第三方 SDK；
- 文案变量是否来自实时可信数据，并能解释测量口径。
11. 证据入口#
| 对象 | 样本/证据 | 产品与广告 | 权限/后台 | 通知规则与全文 | 代码册 |
|---|---|---|---|---|---|
| Pure Clean | 索引 | 报告 | 报告 | 全量报告 | 代码册 |
| Swift Clean | 索引 | 报告 | 报告 | 全量报告 | 代码册 |
| CleanTool | 索引 | 报告 | 报告 | 全量报告 | 代码册 |
动态流程、后台存活、强停和实际通知见《真机动态验证与后台存活报告》。精确代码以每包完整 jadx/ 与代码册中的文件/行号为准；JADX 失败的方法以定点恢复产物或 smali 交叉复核。
原提示词的逐项完成性、当前测试机版本/权限/FGS/Job/Alarm 状态及文档安全门禁见《交付验收清单》（本地证据路径：交付验收清单.md）。
12. 未验证项#
- 未授予所有文件访问、Notification access、Usage access，未验证真实删除、通知拦截和按 App 流量结果。
- 未登录生产 Remote Config、FCM、TradPlus、MAX、Adjust 或广告后台，线上参数/受众/文案/频次未知。
- 未抓包，不能确认每个 SDK 的真实请求、字段、地域 Consent 和当前填充网络。
- 未完成 Android 8–16、多 OEM、Doze、后台受限、电量和日级长窗口矩阵。
- 未验证 Google Play 当前 AAB 与本机样本是否完全同源。
- 未对广告素材责任、商店政策和法律合规作正式法律结论。