简介这是面向安卓开发学习者的一套仓库管理系统源码围绕商品入库、出库、库存盘点与信息查询等业务展开适合在校学生完成课程设计或毕业设计也能帮助新手理解完整安卓工程的组织方式。整个资源包共189个文件压缩后仅3.49MB其中100个class与34个java文件构成核心代码28个xml负责界面布局与配置jpg/png图片为界面元素docx/doc文档提供说明两个apk可安装体验再加上properties、project、db、cfg等工程级文件目录结构清晰方便按模块查阅。该资源在CSDN已有306人浏览学习有一定参考价值。通过这套源码读者能掌握仓库管理APP中SQLite数据库增删改查、ListView与适配器绑定、Activity间数据传递等关键编码方法并可借助附带APK在真机或模拟器上运行验证边运行边对比源码理解交互过程。资源来源于合法渠道收集整理仅供学习交流使用请尊重原著版权也可作为二次开发的基础工程整体对提升编码和调试能力有明显助益。1. 仓库管理“小程序”源码包里面装的其实是 Android APK 与反编译产物搜“小程序 仓库管理系统源码”的人大多是冲着课程设计或毕设快速落地一个仓管 Demo 来的。解压这份 .rar 之后你会看到里面不是微信小程序代码而是两个 Android 安装包biyesheji.apk、仓库管理系统.apk、一个 resources.ap_ 资源归档、一份 proguard.cfg 混淆配置以及一组 .class 字节码——典型的从 APK 反编译提取的 Android 项目产物。这类包解决的核心问题是不用从零搭界面和数据层直接基于已有仓管 App 的结构去改功能、换字段、重打包。适合想搞懂 Android 仓管应用页面跳转和数据流转的学习者也适合需要“能跑起来”的仓库管理课程设计的同学。纯新手建议先看第 3 章的工程重建直接硬啃 .class 是没有意义的。2. 先拆包看货APK、.class 与 proguard.cfg 的文件角色和技术栈推断2.1 从文件清单推断项目状态与技术选型拿到 .rar 别急着解压反编译先把清单过一遍。这份包里每个文件都不是乱放的能直接告诉你项目大概长什么样文件名文件类型在项目里的角色resources.ap_aapt 编译后的资源归档存放已编译的 layout、drawable、string 资源biyesheji.apkAndroid 安装包打包好的原始项目biyesheji 是“毕业设计”拼音说明是课程设计产物仓库管理系统.apkAndroid 安装包同一项目的成品包或改名打包proguard.cfg混淆配置文件构建时的 ProGuard/R8 配置MenuDemo.classJava 字节码主菜单入口类负责页面跳转Tianjiar.class / Tianjiac.classJava 字节码“添加”相关业务类拼音缩写命名Xiugair1.class / Xiugaic1.class / Xiugaig1.classJava 字节码“修改”相关业务类后缀 r1/c1/g1 区分不同实体注意 class 文件名是可读的拼音加缩写这本身就是一条重要线索ProGuard 如果开了混淆类名会被改成 a、b、c 这种无意义名字。现在能看到 MenuDemo、Tianjiar 这种名字说明项目要么没开混淆要么只开了压缩和优化成员变量被混淆但类名被 keep 住了。这种情况在课程设计项目里很常见作者用 Android Studio 直接 Build APK没做额外的加固配置。技术栈方面从文件组成看是原生 Android Java 项目没有看到 RN、Flutter 或 Kotlin 的痕迹反编译成本相对低。resources.ap_ 的存在说明资源是经过 aapt 编译的不是散装 res 目录这会在后面重建工程时带来 R 文件对齐的坑第 5 章会专门讲。另一个值得注意的点是包里有biyesheji.apk和仓库管理系统.apk两个安装包。常见做法是先用拼音名打包一次最后改了应用名再打一次。这两个包差异不大反编译时优先用“仓库管理系统.apk”因为它的资源表更接近最终版本。2.2 proguard.cfg 能读出混淆开关和保留规则打开 proguard.cfg 看前半部分通常能看到这样的配置# 本项目使用的混淆配置节选 -dontusemixedcaseclassnames -dontskipnonpubliclibraryclasses -keepattributes *Annotation* -keep public class * extends android.app.Activity -keepclassmembers class * { native methods; }逐行说下我关心什么。-keep public class * extends android.app.Activity表示所有 Activity 子类类名会被保留这就是为什么 MenuDemo、Tianjiar 这些类名还在。-keepclassmembers ... native methods说明项目里可能有 JNI 调用或加密逻辑如果某个类反编译出来是空的但有一堆 native 方法声明那逻辑在 .so 里.class 只是壳。如果 cfg 里有-dontobfuscate那成员变量名和本地变量名基本都保留反编译出来能直接读如果没有变量名就会变成 a、b、c 这种。这套项目里 class 名可读但变量名未必反编译时要做好“类名能懂、方法内逻辑要猜”的心理准备。还有一种情况cfg 里如果写了-keep class com.example.warehouse.** { *; }这种包级 keep 规则那整个业务包的类都不会被混淆对复原来说是最理想的状态。判断方法很简单反编译后随便打开一个类看方法名是不是 setData、getStock 这种可读名字如果是说明混淆基本没影响到业务层。3. 从字节码到可用工程反编译工具选型与导入重建3.1 先用 jadx 做整体预览看结构再动手反编译工具我一般分两步走先用 jadx 打开 APK 看整体结构再用 CFR 对个别 .class 单独反编译。jadx 对 APK 整体处理能力强能把 resources、manifest、Java 源码一次性导出jadx -d ./warehouse_src 仓库管理系统.apk --show-bad-code-d指定输出目录--show-bad-code让 jadx 把无法完整还原的方法体也留下来而不是直接丢弃。第一次跑完先看warehouse_src/sources下的包结构再打开resources/AndroidManifest.xml确认入口 Activity。正常解码后 manifest 里能看到activity android:name.MenuDemo这类声明这就能确认第 4 章要分析的调用链起点。如果 jadx 报错说资源表解析失败常见的做法是换个参数再跑一次jadx -d ./warehouse_src 仓库管理系统.apk --show-bad-code --deobf--deobf会尝试用启发式规则给混淆类重命名虽然名字不一定准确但能让你先分清哪个类是 Activity、哪个是普通工具类。注意这个选项只在类名被混淆时才需要这套项目里类名可读可以不开启。3.2 用 CFR 单独反编译 .class 文件jadx 对 APK 级反编译很顺手但碰到单个 .class 或方法体报错的情况CFR 更稳。CFR 是命令行工具适合对指定类文件做精确反编译java -jar cfr_0.152.jar MenuDemo.class --outputdir ./src_menu--outputdir指定输出目录如果不加CFR 会把反编译结果直接打到终端。对 .rar 里的 .class 文件我通常先全部复制到一个目录然后批量反编译mkdir -p ./classes_decompiled for f in *.class; do java -jar cfr_0.152.jar $f --outputdir ./classes_decompiled done批量跑完后在classes_decompiled里就能看到对应 .java 文件。这里有个经验CFR 对泛型和 switch 语句还原比 jadx 好但对 lambda 和匿名内部类还原一般如果你看到-$$Lambda$这种类名说明原代码用了 lambda逻辑在包装类里别删。3.3 重建 Android 工程目录结构反编译输出的是源码碎片不是完整工程需要手动搭一个 Android Studio 工程骨架把源码和资源搬进去mkdir -p WarehouseApp/app/src/main/java mkdir -p WarehouseApp/app/src/main/res cp -r warehouse_src/sources/* WarehouseApp/app/src/main/java/ cp -r warehouse_src/resources/res/* WarehouseApp/app/src/main/res/warehouse_src/sources下是 jadx 输出的 Java 源码warehouse_src/resources/res是解码后的资源文件。拷贝完后还要改AndroidManifest.xml重点确认三处package 名和应用 ID、入口 Activity 声明、用到的权限。反编译出来的 manifest 里 package 名可能和实际不匹配常见做法是改成你自己的包名然后把所有源码里的 import 同步改掉。这一步最容易翻车的是资源目录结构。jadx 导出的res里可能包含res/values、res/layout、res/drawable等目录但 APK 内的资源文件是编译过的二进制格式jadx 虽然会解码成 xml 文本但有些二进制资源比如 9-patch 图可能解不干净。我一般会优先保留resources.ap_里的原始资源用 apktool 单独解一次包apktool d 仓库管理系统.apk -o ./apktool_outapktool 解出来的 res 目录更完整把apktool_out/res和 jadx 输出的 res 合并用 apktool 的版本作为主资源Java 源码用 jadx 的版本这样重建出来的工程资源缺失率最低。4. 业务逻辑复原MenuDemo 入口与增删改查四类的方法调用链4.1 MenuDemo 主菜单从按钮监听反推页面跳转反编译后的 MenuDemo 反编译出来一般是这样的结构public class MenuDemo extends Activity { protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.menu_demo); Button btnAdd (Button) findViewById(R.id.btn_add_r); btnAdd.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { startActivity(new Intent(MenuDemo.this, Tianjiar.class)); } }); } }这段代码说明了三件事MenuDemo 是启动入口布局文件是menu_demo.xml点击按钮跳转到Tianjiar这个 Activity。复原时最实用的动作是先把menu_demo.xml里所有按钮的 id 和跳转目标整理成一张对照表比如btn_add_r对应 Tianjiar、btn_add_c对应 Tianjiac、btn_edit_r1对应 Xiugair1。有了这张表整个 App 的功能分区就出来了。注意反编译出来的代码里findViewById可能带着类型强转的泛型丢失问题jadx 经常输出成(Button) findViewById(...)或者直接是findViewById(...)这不影响逻辑但导入 Android Studio 后会报 unchecked 警告不用管能编译就行。4.2 四个业务类从命名反推数据实体Tianjiar、Tianjiac、Xiugair1、Xiugaic1、Xiugaig1 这五个类乍一看像乱码按拼音拆一下就很清楚Tianjia 是“添加”Xiugai 是“修改”后缀 r、c、g 大概率是不同数据实体的首字母。以 Tianjiar 为例复原出来的核心逻辑类似public class Tianjiar extends Activity { private DBHelper dbHelper; protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_tianjiar); dbHelper new DBHelper(this); Button btnSave (Button) findViewById(R.id.btn_save_r); btnSave.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { saveRecord(); } }); } private void saveRecord() { String name ((EditText) findViewById(R.id.edit_name)).getText().toString(); String stock ((EditText) findViewById(R.id.edit_stock)).getText().toString(); ContentValues cv new ContentValues(); cv.put(name, name); cv.put(stock, Integer.parseInt(stock)); dbHelper.getWritableDatabase().insert(goods, null, cv); Toast.makeText(this, 添加成功, Toast.LENGTH_SHORT).show(); } }这段代码是我按该类在仓管系统里最常见写法补全的示意重点看两点。第一保存动作是直接往 SQLite 里insert没有走网络层说明这个项目是纯本地数据存储复原时不需要搭服务端。第二ContentValues里 key 是name、stock对应库表字段名这些字符串是后续恢复数据库表结构的关键线索。Xiugair1 的逻辑和 Tianjiar 几乎对称先从列表页拿到记录的 id然后getWritableDatabase().update(goods, values, id?, new String[]{id})。复原时可以直接复制 Tianjiar 的代码改改 SQL 语句不用重新设计。4.3 本地数据层SQLite 表结构修复与数据流打通这类仓管 App 的 DBHelper 基本长一个样反编译后建表语句可能在onCreate里直接可见CREATE TABLE goods ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, stock INTEGER DEFAULT 0, price REAL DEFAULT 0, update_time TEXT );这里有个容易踩的坑反编译DBHelper.class时建表 SQL 经常被混淆成字符串拼凑比如CREATE TABLE TABLE_NAME ( ...这种写法。如果字符串常量被拆开直接看代码可能看不出完整表结构。我一般会先用strings命令提取 .class 里的字符串常量strings Tianjiar.class | grep -i create table\|insert\|update\|select这会输出.class里所有可读字符串建表语句、字段名、SQL 关键字都能看到。如果strings也看不到完整 SQL那就拿 APK 装到模拟器里跑一遍然后在/data/data/包名/databases/目录下把数据库文件拉出来adb shell run-as package_name cat /data/data/package_name/databases/goods.db goods.db用 SQLite 工具打开这个文件表结构直接看到比反编译代码来得快。复原数据流时记住一条主线界面拿输入 → 组装 ContentValues → insert/update 到 SQLite → 列表页用 Cursor 查出来填到 ListView 或 RecyclerView。这条链路通了这个项目就算真的“活着”了。5. 反编译源码的避坑清单四个必踩的坑与排查路径5.1 坑一导入 Android Studio 后 R 文件一片红现象把反编译出来的源码导入新工程所有R.id.xxx、R.layout.xxx都标红build 报cannot find symbol R。原因反编译 APK 时 jadx 会自动生成一个 R.java它的资源 ID 来自 APK 的资源表。但你把资源文件拷进新工程后Android Studio 会根据当前 res 目录重新生成 R 类资源项顺序和 ID 都变了两套 R 冲突或者某些资源根本不在反编译结果里。解决把反编译自动生成的 R.java 全部删掉让 Android Studio 基于 res 目录重新生成。具体操作是搜索整个工程里的R.java文件删除然后 sync。如果删完还报错说明 res 目录缺资源回到resources.ap_里找对应文件补上或者用 layout 里引用的资源名反查缺失项。从那以后我每次重建都先删 R.java 再 sync基本不会再卡在这。5.2 坑二混淆后变量名全是 a、b、c逻辑读不懂现象打开反编译出的方法体局部变量清一色叫a、b、c方法名是a()、b()完全看不出业务含义。原因proguard.cfg 里没有-dontobfuscateProGuard 对方法体和字段做了混淆重命名。但类名能被保留说明配置里 keep 了 Activity所以整体还能救。解决个别变量名混淆不影响编译运行不用逐个改名。读逻辑时先看方法调用的对象类型比如a.getWritableDatabase().insert(...)通过类型就能推断a是 DBHelper。想进一步还原可以用 jadx-gui 的“重命名”功能手动把关键变量改成可读名改完哪里引用了会同步更新比纯文本编辑高效。改到能看懂业务逻辑为止不需要全部变量都有名字。5.3 坑三一运行就 ClassNotFoundError 或 NoClassDefFoundError现象App 安装成功点击入口 Activity 直接闪退logcat 报ClassNotFoundException或NoClassDefFoundError指向某个不存在的类。原因常见有两种。一是 ProGuard 压缩阶段把代码里看起来没引用的类删掉了但代码里有反射调用删除时就漏了二是从两个版本 APK 里交叉拼代码biyesheji.apk的代码引用了仓库管理系统.apk里没有的类。解决先看 crash 日志里缺失的类名去原 APK 的 dex 里确认它是否存在jadx -d ./dex_check 仓库管理系统.apk grep -r 缺失类名 ./dex_check/sources如果原 APK 里有、你重建的工程里没有说明源码拷贝时漏了文件把对应 .class 反编译出来补进去。如果原 APK 里也没有那就是两个包版本不一致导致的统一用同一个 APK 的源码作为基线别再混用。反编译项目最怕混版本一份 rar 里两个 apk 本身就是一个警示信号。5.4 坑四第三方库缺失导致构建失败现象编译时提示程序包android.support.v4.app不存在或程序包org.apache.http不存在。原因原项目用了老版本依赖库但反编译产物里不带 jar/aar你新建的工程也没声明这些依赖。解决看 import 语句把缺的库逐个补回 build.gradle。如果是android.support.*加implementation com.android.support:appcompat-v7:28.0.0如果是org.apache.http需要单独引入org.apache.http.legacy。还有一类是项目自带 jar 包被 ProGuard 优化掉了但代码里还在用去 libs 目录找一遍有没有遗漏的 .jar 文件。补依赖的原则是“能不换就不换”保持和老代码同版本换大版本经常引发 API 兼容问题。6. 进阶技巧没有 mapping 文件时用调用关系把混淆类名反推出来ProGuard 的 mapping 文件是混淆前后名字对照的“后悔药”但这个 rar 里没有。没有 mapping 时一个可行办法是从字节码里提取类之间的调用关系按出现频次反推哪个类才是核心入口。先把所有 .class 用 javap 打成可读文本javap -c -p ./*.class all_output.txt然后写个小脚本统计每个类被引用的次数#!/usr/bin/env python3 import re import sys text open(sys.argv[1], encodingutf-8, errorsignore).read() # 匹配 javap 输出中的 Method/class 引用尾部例如 # // Method com.example.warehouse.Tianjiar.onCreate(android.os.Bundle)V calls re.findall(r// (?:Method|class|interface) ([\w$.]), text) stats {} for name in calls: stats[name] stats.get(name, 0) 1 for name, count in sorted(stats.items(), keylambda x: -x[1]): print(f{count:5d} {name})用法python3 parse_calls.py all_output.txt | head -40输出里被引用次数最多的几个类就是入口 Activity 和数据操作核心类。这个思路的原理是即使混淆把方法名改掉了类之间的 new、invoke 关系改不了谁被 new 的次数多谁就是逻辑枢纽。结合第 4 章的 MenuDemo 分析很快就能定位谁是主界面、谁是数据层。如果连类名也被混淆成a、b那就先用strings把 dex 里的字符串常量导出来strings 仓库管理系统.apk | grep -i create table\|select .* from\|insert intoSQL 语句里的表名和字段名是字符串混淆不会动它们。从小程序仓库管理这个场景来说拿到表结构等于拿到了数据字典剩下的类名映射只是体力活。从那以后我每次拿到反编译项目第一件事就是跑一遍调用关系统计再决定从哪里下手改业务改之前也建议你把原 APK 装到模拟器里跑一遍把操作过程录个屏改完对照录屏验证功能希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/22 14:43:25 · 阅读 1.2k 反编译Android APK：仓库管理系统源码解析与重建
简介这是面向安卓开发学习者的一套仓库管理系统源码围绕商品入库、出库、库存盘点与信息查询等业务展开适合在校学生完成课程设计或毕业设计也能帮助新手理解完整安卓工程的组织方式。整个资源包共189个文件压缩后仅3.49MB其中100个class与34个java文件构成核心代码28个xml负责界面布局与配置jpg/png图片为界面元素docx/doc文档提供说明两个apk可安装体验再加上properties、project、db、cfg等工程级文件目录结构清晰方便按模块查阅。该资源在CSDN已有306人浏览学习有一定参考价值。通过这套源码读者能掌握仓库管理APP中SQLite数据库增删改查、ListView与适配器绑定、Activity间数据传递等关键编码方法并可借助附带APK在真机或模拟器上运行验证边运行边对比源码理解交互过程。资源来源于合法渠道收集整理仅供学习交流使用请尊重原著版权也可作为二次开发的基础工程整体对提升编码和调试能力有明显助益。1. 仓库管理“小程序”源码包里面装的其实是 Android APK 与反编译产物搜“小程序 仓库管理系统源码”的人大多是冲着课程设计或毕设快速落地一个仓管 Demo 来的。解压这份 .rar 之后你会看到里面不是微信小程序代码而是两个 Android 安装包biyesheji.apk、仓库管理系统.apk、一个 resources.ap_ 资源归档、一份 proguard.cfg 混淆配置以及一组 .class 字节码——典型的从 APK 反编译提取的 Android 项目产物。这类包解决的核心问题是不用从零搭界面和数据层直接基于已有仓管 App 的结构去改功能、换字段、重打包。适合想搞懂 Android 仓管应用页面跳转和数据流转的学习者也适合需要“能跑起来”的仓库管理课程设计的同学。纯新手建议先看第 3 章的工程重建直接硬啃 .class 是没有意义的。2. 先拆包看货APK、.class 与 proguard.cfg 的文件角色和技术栈推断2.1 从文件清单推断项目状态与技术选型拿到 .rar 别急着解压反编译先把清单过一遍。这份包里每个文件都不是乱放的能直接告诉你项目大概长什么样文件名文件类型在项目里的角色resources.ap_aapt 编译后的资源归档存放已编译的 layout、drawable、string 资源biyesheji.apkAndroid 安装包打包好的原始项目biyesheji 是“毕业设计”拼音说明是课程设计产物仓库管理系统.apkAndroid 安装包同一项目的成品包或改名打包proguard.cfg混淆配置文件构建时的 ProGuard/R8 配置MenuDemo.classJava 字节码主菜单入口类负责页面跳转Tianjiar.class / Tianjiac.classJava 字节码“添加”相关业务类拼音缩写命名Xiugair1.class / Xiugaic1.class / Xiugaig1.classJava 字节码“修改”相关业务类后缀 r1/c1/g1 区分不同实体注意 class 文件名是可读的拼音加缩写这本身就是一条重要线索ProGuard 如果开了混淆类名会被改成 a、b、c 这种无意义名字。现在能看到 MenuDemo、Tianjiar 这种名字说明项目要么没开混淆要么只开了压缩和优化成员变量被混淆但类名被 keep 住了。这种情况在课程设计项目里很常见作者用 Android Studio 直接 Build APK没做额外的加固配置。技术栈方面从文件组成看是原生 Android Java 项目没有看到 RN、Flutter 或 Kotlin 的痕迹反编译成本相对低。resources.ap_ 的存在说明资源是经过 aapt 编译的不是散装 res 目录这会在后面重建工程时带来 R 文件对齐的坑第 5 章会专门讲。另一个值得注意的点是包里有biyesheji.apk和仓库管理系统.apk两个安装包。常见做法是先用拼音名打包一次最后改了应用名再打一次。这两个包差异不大反编译时优先用“仓库管理系统.apk”因为它的资源表更接近最终版本。2.2 proguard.cfg 能读出混淆开关和保留规则打开 proguard.cfg 看前半部分通常能看到这样的配置# 本项目使用的混淆配置节选 -dontusemixedcaseclassnames -dontskipnonpubliclibraryclasses -keepattributes *Annotation* -keep public class * extends android.app.Activity -keepclassmembers class * { native methods; }逐行说下我关心什么。-keep public class * extends android.app.Activity表示所有 Activity 子类类名会被保留这就是为什么 MenuDemo、Tianjiar 这些类名还在。-keepclassmembers ... native methods说明项目里可能有 JNI 调用或加密逻辑如果某个类反编译出来是空的但有一堆 native 方法声明那逻辑在 .so 里.class 只是壳。如果 cfg 里有-dontobfuscate那成员变量名和本地变量名基本都保留反编译出来能直接读如果没有变量名就会变成 a、b、c 这种。这套项目里 class 名可读但变量名未必反编译时要做好“类名能懂、方法内逻辑要猜”的心理准备。还有一种情况cfg 里如果写了-keep class com.example.warehouse.** { *; }这种包级 keep 规则那整个业务包的类都不会被混淆对复原来说是最理想的状态。判断方法很简单反编译后随便打开一个类看方法名是不是 setData、getStock 这种可读名字如果是说明混淆基本没影响到业务层。3. 从字节码到可用工程反编译工具选型与导入重建3.1 先用 jadx 做整体预览看结构再动手反编译工具我一般分两步走先用 jadx 打开 APK 看整体结构再用 CFR 对个别 .class 单独反编译。jadx 对 APK 整体处理能力强能把 resources、manifest、Java 源码一次性导出jadx -d ./warehouse_src 仓库管理系统.apk --show-bad-code-d指定输出目录--show-bad-code让 jadx 把无法完整还原的方法体也留下来而不是直接丢弃。第一次跑完先看warehouse_src/sources下的包结构再打开resources/AndroidManifest.xml确认入口 Activity。正常解码后 manifest 里能看到activity android:name.MenuDemo这类声明这就能确认第 4 章要分析的调用链起点。如果 jadx 报错说资源表解析失败常见的做法是换个参数再跑一次jadx -d ./warehouse_src 仓库管理系统.apk --show-bad-code --deobf--deobf会尝试用启发式规则给混淆类重命名虽然名字不一定准确但能让你先分清哪个类是 Activity、哪个是普通工具类。注意这个选项只在类名被混淆时才需要这套项目里类名可读可以不开启。3.2 用 CFR 单独反编译 .class 文件jadx 对 APK 级反编译很顺手但碰到单个 .class 或方法体报错的情况CFR 更稳。CFR 是命令行工具适合对指定类文件做精确反编译java -jar cfr_0.152.jar MenuDemo.class --outputdir ./src_menu--outputdir指定输出目录如果不加CFR 会把反编译结果直接打到终端。对 .rar 里的 .class 文件我通常先全部复制到一个目录然后批量反编译mkdir -p ./classes_decompiled for f in *.class; do java -jar cfr_0.152.jar $f --outputdir ./classes_decompiled done批量跑完后在classes_decompiled里就能看到对应 .java 文件。这里有个经验CFR 对泛型和 switch 语句还原比 jadx 好但对 lambda 和匿名内部类还原一般如果你看到-$$Lambda$这种类名说明原代码用了 lambda逻辑在包装类里别删。3.3 重建 Android 工程目录结构反编译输出的是源码碎片不是完整工程需要手动搭一个 Android Studio 工程骨架把源码和资源搬进去mkdir -p WarehouseApp/app/src/main/java mkdir -p WarehouseApp/app/src/main/res cp -r warehouse_src/sources/* WarehouseApp/app/src/main/java/ cp -r warehouse_src/resources/res/* WarehouseApp/app/src/main/res/warehouse_src/sources下是 jadx 输出的 Java 源码warehouse_src/resources/res是解码后的资源文件。拷贝完后还要改AndroidManifest.xml重点确认三处package 名和应用 ID、入口 Activity 声明、用到的权限。反编译出来的 manifest 里 package 名可能和实际不匹配常见做法是改成你自己的包名然后把所有源码里的 import 同步改掉。这一步最容易翻车的是资源目录结构。jadx 导出的res里可能包含res/values、res/layout、res/drawable等目录但 APK 内的资源文件是编译过的二进制格式jadx 虽然会解码成 xml 文本但有些二进制资源比如 9-patch 图可能解不干净。我一般会优先保留resources.ap_里的原始资源用 apktool 单独解一次包apktool d 仓库管理系统.apk -o ./apktool_outapktool 解出来的 res 目录更完整把apktool_out/res和 jadx 输出的 res 合并用 apktool 的版本作为主资源Java 源码用 jadx 的版本这样重建出来的工程资源缺失率最低。4. 业务逻辑复原MenuDemo 入口与增删改查四类的方法调用链4.1 MenuDemo 主菜单从按钮监听反推页面跳转反编译后的 MenuDemo 反编译出来一般是这样的结构public class MenuDemo extends Activity { protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.menu_demo); Button btnAdd (Button) findViewById(R.id.btn_add_r); btnAdd.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { startActivity(new Intent(MenuDemo.this, Tianjiar.class)); } }); } }这段代码说明了三件事MenuDemo 是启动入口布局文件是menu_demo.xml点击按钮跳转到Tianjiar这个 Activity。复原时最实用的动作是先把menu_demo.xml里所有按钮的 id 和跳转目标整理成一张对照表比如btn_add_r对应 Tianjiar、btn_add_c对应 Tianjiac、btn_edit_r1对应 Xiugair1。有了这张表整个 App 的功能分区就出来了。注意反编译出来的代码里findViewById可能带着类型强转的泛型丢失问题jadx 经常输出成(Button) findViewById(...)或者直接是findViewById(...)这不影响逻辑但导入 Android Studio 后会报 unchecked 警告不用管能编译就行。4.2 四个业务类从命名反推数据实体Tianjiar、Tianjiac、Xiugair1、Xiugaic1、Xiugaig1 这五个类乍一看像乱码按拼音拆一下就很清楚Tianjia 是“添加”Xiugai 是“修改”后缀 r、c、g 大概率是不同数据实体的首字母。以 Tianjiar 为例复原出来的核心逻辑类似public class Tianjiar extends Activity { private DBHelper dbHelper; protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_tianjiar); dbHelper new DBHelper(this); Button btnSave (Button) findViewById(R.id.btn_save_r); btnSave.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { saveRecord(); } }); } private void saveRecord() { String name ((EditText) findViewById(R.id.edit_name)).getText().toString(); String stock ((EditText) findViewById(R.id.edit_stock)).getText().toString(); ContentValues cv new ContentValues(); cv.put(name, name); cv.put(stock, Integer.parseInt(stock)); dbHelper.getWritableDatabase().insert(goods, null, cv); Toast.makeText(this, 添加成功, Toast.LENGTH_SHORT).show(); } }这段代码是我按该类在仓管系统里最常见写法补全的示意重点看两点。第一保存动作是直接往 SQLite 里insert没有走网络层说明这个项目是纯本地数据存储复原时不需要搭服务端。第二ContentValues里 key 是name、stock对应库表字段名这些字符串是后续恢复数据库表结构的关键线索。Xiugair1 的逻辑和 Tianjiar 几乎对称先从列表页拿到记录的 id然后getWritableDatabase().update(goods, values, id?, new String[]{id})。复原时可以直接复制 Tianjiar 的代码改改 SQL 语句不用重新设计。4.3 本地数据层SQLite 表结构修复与数据流打通这类仓管 App 的 DBHelper 基本长一个样反编译后建表语句可能在onCreate里直接可见CREATE TABLE goods ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, stock INTEGER DEFAULT 0, price REAL DEFAULT 0, update_time TEXT );这里有个容易踩的坑反编译DBHelper.class时建表 SQL 经常被混淆成字符串拼凑比如CREATE TABLE TABLE_NAME ( ...这种写法。如果字符串常量被拆开直接看代码可能看不出完整表结构。我一般会先用strings命令提取 .class 里的字符串常量strings Tianjiar.class | grep -i create table\|insert\|update\|select这会输出.class里所有可读字符串建表语句、字段名、SQL 关键字都能看到。如果strings也看不到完整 SQL那就拿 APK 装到模拟器里跑一遍然后在/data/data/包名/databases/目录下把数据库文件拉出来adb shell run-as package_name cat /data/data/package_name/databases/goods.db goods.db用 SQLite 工具打开这个文件表结构直接看到比反编译代码来得快。复原数据流时记住一条主线界面拿输入 → 组装 ContentValues → insert/update 到 SQLite → 列表页用 Cursor 查出来填到 ListView 或 RecyclerView。这条链路通了这个项目就算真的“活着”了。5. 反编译源码的避坑清单四个必踩的坑与排查路径5.1 坑一导入 Android Studio 后 R 文件一片红现象把反编译出来的源码导入新工程所有R.id.xxx、R.layout.xxx都标红build 报cannot find symbol R。原因反编译 APK 时 jadx 会自动生成一个 R.java它的资源 ID 来自 APK 的资源表。但你把资源文件拷进新工程后Android Studio 会根据当前 res 目录重新生成 R 类资源项顺序和 ID 都变了两套 R 冲突或者某些资源根本不在反编译结果里。解决把反编译自动生成的 R.java 全部删掉让 Android Studio 基于 res 目录重新生成。具体操作是搜索整个工程里的R.java文件删除然后 sync。如果删完还报错说明 res 目录缺资源回到resources.ap_里找对应文件补上或者用 layout 里引用的资源名反查缺失项。从那以后我每次重建都先删 R.java 再 sync基本不会再卡在这。5.2 坑二混淆后变量名全是 a、b、c逻辑读不懂现象打开反编译出的方法体局部变量清一色叫a、b、c方法名是a()、b()完全看不出业务含义。原因proguard.cfg 里没有-dontobfuscateProGuard 对方法体和字段做了混淆重命名。但类名能被保留说明配置里 keep 了 Activity所以整体还能救。解决个别变量名混淆不影响编译运行不用逐个改名。读逻辑时先看方法调用的对象类型比如a.getWritableDatabase().insert(...)通过类型就能推断a是 DBHelper。想进一步还原可以用 jadx-gui 的“重命名”功能手动把关键变量改成可读名改完哪里引用了会同步更新比纯文本编辑高效。改到能看懂业务逻辑为止不需要全部变量都有名字。5.3 坑三一运行就 ClassNotFoundError 或 NoClassDefFoundError现象App 安装成功点击入口 Activity 直接闪退logcat 报ClassNotFoundException或NoClassDefFoundError指向某个不存在的类。原因常见有两种。一是 ProGuard 压缩阶段把代码里看起来没引用的类删掉了但代码里有反射调用删除时就漏了二是从两个版本 APK 里交叉拼代码biyesheji.apk的代码引用了仓库管理系统.apk里没有的类。解决先看 crash 日志里缺失的类名去原 APK 的 dex 里确认它是否存在jadx -d ./dex_check 仓库管理系统.apk grep -r 缺失类名 ./dex_check/sources如果原 APK 里有、你重建的工程里没有说明源码拷贝时漏了文件把对应 .class 反编译出来补进去。如果原 APK 里也没有那就是两个包版本不一致导致的统一用同一个 APK 的源码作为基线别再混用。反编译项目最怕混版本一份 rar 里两个 apk 本身就是一个警示信号。5.4 坑四第三方库缺失导致构建失败现象编译时提示程序包android.support.v4.app不存在或程序包org.apache.http不存在。原因原项目用了老版本依赖库但反编译产物里不带 jar/aar你新建的工程也没声明这些依赖。解决看 import 语句把缺的库逐个补回 build.gradle。如果是android.support.*加implementation com.android.support:appcompat-v7:28.0.0如果是org.apache.http需要单独引入org.apache.http.legacy。还有一类是项目自带 jar 包被 ProGuard 优化掉了但代码里还在用去 libs 目录找一遍有没有遗漏的 .jar 文件。补依赖的原则是“能不换就不换”保持和老代码同版本换大版本经常引发 API 兼容问题。6. 进阶技巧没有 mapping 文件时用调用关系把混淆类名反推出来ProGuard 的 mapping 文件是混淆前后名字对照的“后悔药”但这个 rar 里没有。没有 mapping 时一个可行办法是从字节码里提取类之间的调用关系按出现频次反推哪个类才是核心入口。先把所有 .class 用 javap 打成可读文本javap -c -p ./*.class all_output.txt然后写个小脚本统计每个类被引用的次数#!/usr/bin/env python3 import re import sys text open(sys.argv[1], encodingutf-8, errorsignore).read() # 匹配 javap 输出中的 Method/class 引用尾部例如 # // Method com.example.warehouse.Tianjiar.onCreate(android.os.Bundle)V calls re.findall(r// (?:Method|class|interface) ([\w$.]), text) stats {} for name in calls: stats[name] stats.get(name, 0) 1 for name, count in sorted(stats.items(), keylambda x: -x[1]): print(f{count:5d} {name})用法python3 parse_calls.py all_output.txt | head -40输出里被引用次数最多的几个类就是入口 Activity 和数据操作核心类。这个思路的原理是即使混淆把方法名改掉了类之间的 new、invoke 关系改不了谁被 new 的次数多谁就是逻辑枢纽。结合第 4 章的 MenuDemo 分析很快就能定位谁是主界面、谁是数据层。如果连类名也被混淆成a、b那就先用strings把 dex 里的字符串常量导出来strings 仓库管理系统.apk | grep -i create table\|select .* from\|insert intoSQL 语句里的表名和字段名是字符串混淆不会动它们。从小程序仓库管理这个场景来说拿到表结构等于拿到了数据字典剩下的类名映射只是体力活。从那以后我每次拿到反编译项目第一件事就是跑一遍调用关系统计再决定从哪里下手改业务改之前也建议你把原 APK 装到模拟器里跑一遍把操作过程录个屏改完对照录屏验证功能希望帮到你。本文还有配套的精品资源点击获取