CleanTool v2.3.1 产品功能与商业化分析#
文档日期：2026-10-12
1. 结论#
CleanTool 不是单一文件管理器，而是以“清理/设备工具”为壳、以高频通知召回和广告变现为核心的工具集合。S1 证据显示它把缓存、大文件、截图、相似照片、应用管理、RAM、流量、网速、设备信息、通知清理和桌面小组件做成统一入口，并在启动、扫描、结果、首页及大量次级页面嵌入 App Open、Interstitial、Native、Banner 广告。
商业化采用 AppLovin MAX 为主要聚合层，同时代码支持直接 AdMob；广告位按安装天数 D0/D1/D2/D3 使用本地 JSON，并可由 Firebase Remote Config 远程替换。通知侧又存在“广告外跳后提醒用户返回”的独立召回场景，说明广告曝光与回流被设计成同一闭环。
2. 产品功能地图#
| 功能域 | 能力 | 静态实现证据 | 必要条件/边界 | 等级 |
|---|---|---|---|---|
| 缓存清理 | 扫描缓存、列表选择、清理动画/完成页 | CacheScanningActivity、CacheDataActivity、CacheCleanAnimationActivity |
Android 11+ 主要依赖 All files access；部分系统缓存只能跳系统设置 | S1 |
| 大文件 | 扫描、按文件选择、删除、动画 | LargeCleanScanActivity、LargeFileCleanDataActivity、LargeFileCleanAnimationActivity |
依赖文件访问权限 | S1 |
| 截图清理 | 扫描截图、预览、选择删除 | ScreenShotScanningActivity、ScreenShotCleanDataActivity、PhotoViewActivity |
依赖文件访问权限 | S1 |
| 相似照片 | 扫描相似图、分组选择、删除 | SimilarPhotoScanningActivity、SimilarPhotoDataActivity |
相似度算法效果未动态验证 | S1/U |
| 应用管理 | 扫描安装包、查看版本/体积/最后使用时间、触发卸载 | AppManageScanActivity、AppManageInfoActivity |
最后使用时间需 Usage Access；卸载仍由系统确认 | S1 |
| RAM 工具 | RAM 扫描、展示内存占用、引导管理 | RamScanActivity、RamCleanActivity |
Android 无法由普通 App 真正“一键结束所有后台”；效果未验证 | S1/U |
| 网络流量 | 按应用/周期查询流量使用 | NetworkTrafficScanningActivity、NetworkTrafficInfoActivity |
依赖 Usage Access 与系统统计可用性 | S1 |
| 网速测试 | 测试页、结果页；常驻通知显示实时速度 | SpeedTestingActivity、SpeedTestOkActivity、m71.c() |
测速口径和准确性未抓包验证 | S1/U |
| 设备信息 | 扫描和展示设备状态 | DeviceScanActivity、DeviceInfoActivity |
展示字段未逐项动态核验 | S1 |
| 通知清理 | NotificationListener 拦截其他 App 非 ongoing 通知并入库/计数 | NotificationListener.java:62-115 |
必须用户手动授予 Notification access | S1 |
| 桌面小组件 | 缓存清理、通知清理、网络三类 Widget | StorageCWidget、NotificationCleanWidget、NetworkWidget |
系统桌面支持情况依 OEM | S1 |
| 多语言 | 英/德/西/法/葡/日 6 种 | xy1.java:15-29、i7.java:117 |
其他系统语言回退英语 | S1 |
2.1 核心流程#
- Splash/首次引导读取隐私、语言与权限状态。
- 首页以功能卡片进入扫描页。
- 扫描页加载
newcleanScan插屏候选；完成或清理后进入结果页并加载newcleanFinish。 - 首页使用
newcleanHome原生/横幅广告；启动使用newcleanStartApp Open/插屏。 - 结果页继续推荐下一工具，形成“扫描—广告—结果—下一工具”循环。
以上第 3-5 点由广告位枚举与调用点拼接得到；精确展示时机、是否每次展示及失败降级属于 I/U。
3. 广告架构#
3.1 广告格式与加载栈#
u6.java 根据 ad unit id 是否以 ca-app-pub 开头选择实现：
- 以
ca-app-pub开头：直接使用 Google Mobile Ads（AdMob）AppOpenAd、InterstitialAd、NativeAd、AdView。 - 其他 ID：使用 AppLovin MAX 的
MaxAppOpenAd、MaxInterstitialAd、MaxNativeAdLoader、MaxAdView。
| format | 代码含义 | 典型页面 | S1 证据 |
|---|---|---|---|
open |
App Open（开屏广告） | 启动/回前台 | u6.java:270-291 |
int |
Interstitial（插屏广告） | 扫描、完成、extra | u6.java:183-205 |
nav |
Native（原生广告） | 首页信息流 | u6.java:207-268 |
ban |
Banner（横幅广告） | 首页/容器 | u6.java:151-181 |
Manifest 与类库还包含 Google/AdMob、AppLovin/MAX、Meta Audience Network、Unity Ads、Vungle、ironSource/LevelPlay、BIGO、Fyber/Inneractive、Mintegral/MBridge 等适配器。S1 仅证明 SDK 被打包；某一网络在真实请求中出价/填充属于 U。
3.2 广告位#
| 广告位 | 支持格式 | 本地开关 | 产品位置 | 等级 |
|---|---|---|---|---|
newcleanStart |
open, int |
true | 启动与回前台 | S1/I |
newcleanScan |
int |
true | 各工具扫描页 | S1 |
newcleanFinish |
int |
true | 扫描/清理完成 | S1 |
newcleanHome |
nav, ban |
true | 首页 | S1 |
extra |
int |
代码定义、未出现在 D0-D3 JSON | 多个次级页退出/返回 | S1/U |
大量 Activity 在创建时调用 u6.k(..., s6.g, ...)；这表明存在 extra 插屏展示尝试，但参数掩码和触发时点受混淆影响，不能据此声称“每个页面必弹”。
3.3 D0-D3 配置#
d0_config.json 至 d3_config.json 均包含上述四个主广告位。D0、D1、D2/3 使用不同 ad unit；D2 与 D3 当前本地配置相同。每个 AdInfo.value 在当前代码被传入缓存对象/回调，但其完整业务含义未由静态代码唯一确定，记为 U，不把它外推成“展示次数”或“权重”。
Remote Config 可下发 day0_ad、day1_ad、day2_ad、day3_ad 字符串并覆盖内部文件，因此 APK JSON 只是 fallback，不等于线上当前投放配置。
3.4 广告退出召回#
当广告 Activity 使 App 进入后台，且生命周期状态标记 u6.f21074c=true，进程后台回调延迟 1 秒执行 g(case 4)，尝试发出：
- 文案：
Oops! looks like you tapped an ad. Tap to go back! - 按钮：
Back - action：
notify_ad_retrieve - 图标：
ic_nt_10 - 场景冷却：10 分钟；仍受通知总门禁约束。
证据：kf.java:103-110、g.java:116-143。这是静态确定的产品意图；实际广告 SDK 生命周期回调和系统通知展示仍需真机验证。
4. Remote Config 与策略开关#
| Key | 本地默认/初始值 | 用途 | 证据等级 |
|---|---|---|---|
openTime |
10 | 开屏相关时长（代码日志为“启动页时长”） | S1 |
notifyCoolTime |
900 秒 | type 1 通知全局冷却，拉取后乘 1000 | S1 |
day0_ad...day3_ad |
本地 JSON fallback | 分安装天数广告配置 | S1 |
ban_ad_with_vpn |
true | 检测 VPN 时不加载广告 | S1 |
notify_interval_10m |
false/0 | 通知 AB 开关；开启后改用场景冷却并放宽时间/横屏门禁 | S1/I |
证据：yi2.java:18-32,115-145、u32.java:50-157。线上值与用户分组均为 U。
5. 数据与归因组件#
- Firebase Analytics：产品事件。
- Adjust：归因、广告收入事件、FCM token 传递。
- Meta/Facebook App Events：部分事件上报。
- Firebase Crashlytics / Performance / Sessions：稳定性与性能。
- Install Referrer、Google Advertising ID、Privacy Sandbox AdServices：广告归因与广告能力。
- 广告收入累计达到 0.01、0.02、0.04、0.06、0.08、0.1、0.2、0.3、0.4、0.6、0.8、1、2 等阈值时触发相应 ROAS 事件；见
u6.java:294-313。
静态代码不证明每项数据在所有地区、同意状态和会话中都实际上传；需 CMP/Consent、网络请求和 Data safety 对账。
6. 竞品判断#
6.1 优势（I）#
- 工具覆盖面广，任何一个通知入口都能路由到对应功能，缩短回流后的操作路径。
- D0-D3 广告配置与远端覆盖，使新用户和成熟用户可使用不同变现组合。
- 通知、Widget、前台常驻栏、FCM 与系统事件共同形成多入口召回。
- 本地 6 语种通知文案完整，召回体验在主要目标语言中一致。
6.2 风险（S1/I）#
- NotificationListener 会直接取消其他 App 的非 ongoing 通知；这不是普通“通知整理”，对用户信息可达性影响很大。
MANAGE_EXTERNAL_STORAGE、Usage Access、Notification Access、开机启动、特殊用途 FGS 等权限组合敏感，上架合规与用户信任成本高。- 非静默提醒使用高重要性 Channel，且普通提醒后还设计 4 秒间隔的连续替换提醒；存在打扰和投诉风险。
- 广告外跳召回通知把商业事件转成系统通知，可能被用户理解为诱导回流。
allowBackup=true、明文流量允许、外部存储根目录 FileProvider 等配置需安全审计。- Google Play Data safety、商店描述和隐私政策产品名/文件处理口径不完全一致。
7. 对我方的可借鉴与不可照搬#
可借鉴的是“通知 action 与具体功能一一对应”“统一场景门禁”“文案资源多语言化”“远端只控频次/开关、内置文案可审计”。不建议照搬的是：取消其他 App 通知、4 秒连续提醒、广告外跳召回、无明确用户价值的特殊用途 FGS，以及把大文件/内存/电量判断写成未经验证的夸张效果。
8. 未验证项#
- 广告真实 waterfall/bidding、填充网络、单用户展示频次与收入。
- Remote Config 线上当前值、AB 分组和地域策略。
- 清理、RAM、测速、相似照片算法的准确性与真实效果。
- 权限拒绝/撤销后的降级体验。
- Google Play 当前 AAB 是否与本地 APK 完全同源。