混淆后的代码为什么难读ProGuard/R8 混淆后，类名方法名全变成 a.b.c、a.a.a——不同类同名、同类不同方法同名，全局搜索基本报废。但混淆只改名字，改不了结构：字符串常量、API 调用关系、继承体系都还在。反混淆的核心思路就是用结构特征替代名字特征。技巧一：字符串是永不混淆的路标无论怎么混淆，字符串常量必须保留（运行时要真用）。逆向第一步永远是搜字符串：# 在 jadx 里全局搜（Text search） "sign" → 找签名相关 "token" → 找鉴权相关 "AES/CBC/PKCS5Padding" → 直接定位加密代码 "/api/" → 找接口定义 "deviceId" → 找设备指纹搜到字符串后按 X（交叉引用）查谁在用——使用点往往就是业务逻辑所在，类名再混淆也无所谓。技巧二：从入口顺藤摸瓜混淆改不了 AndroidManifest.xml（系统要按原名找组件）。从 Manifest 里的入口 Activity 开始：Manifest 找到主 Activity（即使类名混淆，路径是明确的）进 onCreate 看它初始化了什么网络层、加密层都会在启动链上露面四大组件、Application 入口都是同理——Manifest 是混淆代码的地图。技巧三：批量重命名，自己建立秩序jadx 支持重命名（N 键），且重命名会保存到项目文件。分析时养成习惯：认出 a.b.c 是签名工具类 → 重命名 SignUtils认出 a.a(String) 是 md5 → 重命名 md5半小时后，你面对的就不再是乱码而是自己命名的清晰结构。重命名的另一个好处：交叉引用会跟着更新，越分析越清晰。技巧四：用 API 调用反查业务类想找"谁在做网络请求"，别搜类名，搜 API：# 搜 OkHttp 的使用 okhttp3.Request.Builder → 查这个类的交叉引用 → 所有构造请求的地方 # 搜加解密 API javax.crypto.Cipher → 交叉引用 → 所有加解密点 # 搜 SharedPreferences getSharedPreferences → 找本地存储的 token/配置系统 API 类名不会被混淆，它们是锚点，业务类是挂在锚点上的藤蔓。技巧五：对付 R8 的激进优化R8 比 ProGuard 更狠：内联短方法、删除未用代码、合并类。表现为：方法找不到：可能被内联了。搜方法内的特征字符串，在调用方里找展开的逻辑类消失了：可能被合并。看继承关系，找"胖得异常"的类switch 变 if：枚举/常量的 switch 被优化。jadx 的 deobf 模式（Preferences → Deobfuscation）能缓解一部分技巧六：jadx 命令行批量导出GUI 适合交互分析，批量处理用命令行：# 导出全部源码供 grep jadx -d out_dir target.apk # 然后上 ripgrep rg -l "Cipher.getInstance" out_dir/ rg "getSign|makeSign|calcSign" out_dir/ -A 3配合脚本批量分析几十个 APK 时，这条流水线比 GUI 点来点去快一百倍。精髓：反混淆的心法名字是假的，结构是真的——字符串、API 调用、Manifest 入口永不混淆先找锚点再顺藤摸瓜，别试图通读代码边分析边重命名，分析成果即时固化GUI 交互 + 命令行批量，按场景选工具总结字符串搜索 + 交叉引用是第一板斧Manifest 入口是混淆代码的地图系统 API 是锚点，业务类挂在其上重命名建立秩序，R8 优化用特征字符串破解交流微信：run1255