【开源】AdPurge3.0性能攻坚版成品与源码

阿力

上一篇帖子在这里【三改开源】APK去广告编辑器优化版2.0与项目源码
5.0最终开源版
今天就不说废话了，但得说点不是废话的话

首先在分享最终成品与源码之前，我得感谢二开作者@霄云 把他优化改进的最新版本源码开源分享出来了，我下载体验了一下发现他这个版本处理效率要比我发的2.0快了很多，详细对比请看下方
指标           v2.0 初版        二改作者        v3.0
DEX 修补   147.3s        59.99s               51.2s ✅
打包+签名  9.1s                13.66s               6.9s ✅
总耗时            161.3s        82.9s               62.3s ✅
处理后体积50.7MB        50.5MB              49.5MB ✅

测试时广告商选项为全选具体可看分享链接中的处理报告.md

于是我又下载了他的源码参考了一下技术原理，在2.0的基础上再次优化了一下，最终测试处理50mb的文件，dex文件数为10个，得出的总耗时为62.3s，相当于一分钟一个包，我觉得如果dex文件数量少会更快，这个要你们去自己体验了解，这里就不说了，此最终版本只是在我这里是最终，但在各位圈友手里就未必了，还是那句话一山更比一山高，希望有兴趣的圈友能够参与
优化改进并且分享出来，我很期待更好的版本！

以下是我改进的一些地方

经圈友反馈以下功能有些问题，现已直接采用二开作者最新版本更新的内容，一键功能全部勾选实测73s，不勾选这两个选项差不多少个10s，链接内容已更新请自行提取

## v3.0.1 (2026-08-13)

> Bug 修复 + 功能对齐版：修复「勾选 VPN 去除 / 虚拟机检测后处理的包闪退」问题，并采纳同类工具（二改作者 0813 版）实测稳定的两个功能。

###  修复

**修复勾选 VPN 去除 / 虚拟机检测后处理的包闪退**：根因是检测方法仅按方法名包含匹配（contains），业务方法只要名字带 vpn/emulator 字样就被置为 return false，导致调用方初始化/分支逻辑断裂。现对齐同类工具实测稳定方案

**方法体证据检查**：方法体内指令必须实际引用网络接口、系统属性、模拟器特征路径等检测证据字符串才判定为检测方法，且仅处理 boolean 返回类型的方法，不再误伤业务方法

### 新增功能（采纳同类工具实测稳定特性）

- **开屏广告倒计时缩短**：类名含 splash 的类中，追踪常量写入寄存器的值，命中 `Handler.postDelayed` / `sendEmptyMessageDelayed` / `sendMessageDelayed` / `CountDownTimer` 且延迟 ≥1000ms 时把延迟常量置 0，开屏广告倒计时立即结束、直接进入主界面（同类工具实测单 APK 306~483 处命中）

- **签名校验扫描提示**：16 个签名校验特征关键词扫描全部 DEX，处理前若检测到签名校验逻辑即弹出警告，提示「处理后重新签名可能导致应用校验失败闪退」，避免用户误认为是去广告修补本身的问题，用户可选择取消或继续处理

---

## v3.0 (2026-08-13)

> 性能攻坚版：以同类工具（二改作者 0813 版）为基准逐项实测对比，深挖出「debug 构建性能降级」「dexlib2 懒解析重复兑现」「debug_info 状态机编码」三大隐藏瓶颈并逐一击破。
> 同一 51.8MB / 9 DEX 测试 APK 实测（12 家厂商全开）：**总耗时 161.3s → 62.3s（快 2.6 倍），比同类工具（82.9s）快 25%**。

###  性能提升（v3.0 核心亮点）

**总耗时 161.3s → 62.3s**：DEX 修补 147.3s → 51.2s，打包签名 9.1s → 6.9s，处理后 APK 从 50.7MB 缩至 49.5MB
- **Release 构建**：debuggable 应用 ART 执行性能降级（解释执行为主），改 Release 构建后整体快 2 倍以上

**方法级深拷贝预解析（关键优化）**：dexlib2 的 dex-backed 对象是懒解析的，写盘时 DexWriter 遍历全部指令多遍（字符串池/类型池/编码），每遍都重新解析字节流 → N 遍遍历 = N 次全量解析 + GC 风暴。提前在扫描期把方法解析成 Immutable 对象，写盘时零解析：单 DEX 写回由 8~19.5s 降至 2.9~7.1s

**丢弃 debug_info**：写回时不再重编码调试信息（行号表/局部变量表的状态机编码），写回更快且 DEX 体积缩小 16%（未压缩 106.1MB → 89.8MB）；不影响 APK 运行，仅处理后 APK 的崩溃日志不显示源码行号

- **写盘前释放原始 DEX 树**：扫描完成后释放 dex-backed 对象树，写盘前堆占用由 362MB 降至 200MB 以内，大 APK 不再有内存不足风险

- **方法级零拷贝**：被修改类中未修改的方法直接复用原始引用，仅重建被修改的方法

- **取消资源引用二次全量加载**：assets 资源引用在 DEX 修补遍历时顺手收集，无需修补完成后再把全部 DEX 重新加载扫描一遍

- **每个 DEX 处理后无条件 GC**：下一个 DEX 的加载与写回在干净的堆上进行

游客，如果您要查看本帖隐藏内容请回复

喜破解

沙发又来

道无相

如果用c语言写的话性能会更强

bairm888

看看

阿力

道无相 发表于 2026-8-13 21:10
如果用c语言写的话性能会更强

这个项目他们一开始就是用的kotlin，想着项目已经成型了就按照原作最初意愿走了

韩日梦

看看有啥变化

小白菜学习菜

看看

忏彻

感谢分享

Motivar

感谢分享

Deelok

看看

laiwen666

感谢分享

cxp521

感谢分享 都是优秀的

opugtd

看看有没有

阿力

cxp521 发表于 2 分钟前
感谢分享 都是优秀的

这话说的过于漂亮

道无相

阿力 发表于 2026-8-13 21:13
这个项目他们一开始就是用的kotlin，想着项目已经成型了就按照原作最初意愿走了 ...

或许可以考虑让ai照着源码重写一套C语言的