企业官网建设流程全解析

HBuilder uni-app 混淆，对 Native 代码与资源进行混淆处理

如果你用 uni-app 做过商业项目，就会知道一个尴尬的事实：我们在 HBuilder 里写得开开心心的业务代码，打包成 App 装到用户手机上之后，基本等于把源码摊开给人家看。我早年接过一个外包项目，上线没两周就被同行“参考”了核心逻辑，后来复盘时发现，对方反编译 APK 拿到的不是 Java 层代码，而是assets/apps下连注释都没删干净的 JS 文件。从那以后我养成了一个习惯：只要是人货分离的项目，发布前必须做混淆处理。这篇文章就专门聊聊，在 HBuilder + uni-app 这套技术栈下，对 JS 业务代码、Native 字节码和静态资源分别怎么做混淆，以及每一步背后真正要解决的问题是什么。

我知道很多人一听“混淆”第一反应是“加个配置就行”，真去做的时候才发现坑一大堆：js 混淆完项目白屏、Android 那边 R8 把 uni-app 的反射类冲掉了、资源混淆之后 plus.android 动态获取 ID 失败……所以我不会只贴配置，我会把判断逻辑、工具选型、以及我踩过的坑一并写出来，希望能帮你在发布前少走弯路。

1. 动手之前先想清楚：这层混淆到底在防谁

1.1 uni-app App 里的代码其实分“两层”

uni-app 开发的应用运行在手机上，代码并不是一整坨，而是明显分层的。

第一层是 JS 层，也就是我们用 Vue 语法写的业务逻辑、页面、组件。这些文件在打包后会被编译进assets/apps目录（Android）或者 App 的 bundle 目录（iOS），本质上是明文 JS。手机上有的是办法解开看，比如把 APK 后缀改成 zip 解压，再随便找个格式化工具一看，业务逻辑、请求地址、密钥 Token，清清楚楚。第二层是 Native 层，也就是 Android 的 smali/Java/Kotlin 代码和 iOS 的 Mach-O 二进制。这一层里大部分是 uni-app 官方 SDK 和我们的第三方 SDK，以及我们自己写的原生插件。Native 层默认会被编译成字节码或机器码，但不做额外处理的话，反编译工具一样能读出来个大概。

这里有一个关键点：混淆工具的作用对象、成本、风险是完全不同的。JS 混淆要防的是“把 APK 解压看源码”的初级逆向；Native 混淆要防的是“用 jadx、GDA 这类工具分析原生逻辑”的中级逆向；而资源混淆防的是“扒素材、改配置、二次打包”的批量盗版行为。三者的目的不一样，所以不能只用一把锁。

1.2 云打包还是本地打包，决定你能做多深

很多刚接触 uni-app 混淆的人会问：HBuilderX 自带的“发行–原生App-云打包”能不能配置混淆？答案是：云打包只帮你做 JS 层的默认压缩，而且那个压缩仅仅是去除空白和缩短变量名，强度很低，更不可能碰 Native 层的混淆配置。你想改 Android 的 ProGuard 规则，想在 build.gradle 里加资源混淆插件，都得先切换到“本地打包”流程。

本地打包意味着你要把 uni-app 生成的资源包导入到 Android Studio（Android）或 Xcode（iOS）工程里，用传统原生工程的构建链路来出包。这多了一步操作，但换来的是完全可控的混淆配置能力。我把话放这儿：只要你的 App 需要长期维护、有核心业务逻辑，迟早得走本地打包这条路。云打包适合快速验证和简单工具，不适合构建真正的商业壁垒。

所以这篇文章接下来的内容，默认你已经具备本地打包的基础能力，也就是能用 HBuilderX 生成打包资源、能打开 Android Studio 工程、能跑通一次本地出包流程。不会没关系，HBuilderX 官方文档的“本地打包”章节写得很细，先把那个流程跑通再回来看这篇。

2. 整体思路拆解：三层混淆、两个阶段

2.1 把混淆任务分成三块

我习惯把 uni-app App 的混淆工作拆成三条线，每次发版前按这个清单过一遍：

这个表格建议存下来，每次发版对着检查。JS 层优先级最高，因为 uni-app 的业务代码几乎全在这里；Native 层看情况，如果纯用官方 SDK 没怎么写原生插件，混淆收益没有想象中那么大；资源混淆是针对“批发式盗版”的，上架正式产品建议必开。

2.2 为什么 JS 混淆要放在业务构建之后

很多初学者会在源码目录上直接跑混淆，结果混淆出来的代码跑不了，因为混淆器把 Vue 组件里的$mount、onLoad这些反射用的方法名也给改了。正确做法是把混淆步骤放在 uni-app 构建完成之后，只对最终生成的app-service.js这类运行文件做处理，不动源码，不动编译中间产物。

我的流水线是这样的：HBuilderX 里的项目用 CLI 方式管理，跑一遍npm run build:app生成dist/build/app，然后写一个 Node 脚本对app-service.js执行混淆，再把混淆后的文件覆盖回去，最后用原生工程打包。这样 HBuilderX 只负责“生成”，混淆脚本独立工作，出了问题可以快速回滚到未混淆产物。

2.3 工具选型的底层逻辑

JavaScript 层我推荐javascript-obfuscator而不是网上流传的各种“在线混淆网站”。原因很简单：你需要可复现的、可配置的、能集成进 CI 的混淆能力，在线工具难以保证这些。javascript-obfuscator 是 npm 包，支持数十项参数调节，而且社区活跃，uni-app 生态里也有人专门做过适配。

Native 层 Android 直接用官方 R8，不要自己再叠一层 ProGuard，因为 R8 已经取代了 ProGuard，而且和 AGP（Android Gradle Plugin）的配合最顺滑。iOS 那边没有免费的官方混淆方案，比较现实的做法是只做字符串加密和敏感逻辑的代码混淆（比如用 C/C++ 重写核心算法），全量类名混淆的成本太高，大多数团队扛不住。

资源层用微信开源的 AndResGuard，它专门做资源路径的 proguard 化重命名，能把res/drawable/icon_share.png这种路径重写成res/drawable/a.png，减小包体的同时给逆向者增加干扰。它和 Android 原生的shrinkResources不是一个东西，别搞混，后者只是删除未使用资源，不重命名。

3. JS 层混淆实战：把 app-service.js 变成天书，但别变成废纸

3.1 搭建基于 javascript-obfuscator 的混淆脚本

先装上依赖。我建议在项目根目录单独建一个scripts/obfuscate.mjs文件，保持和其他构建逻辑隔离：

npm install --save-dev javascript-obfuscator

然后写混淆脚本。这里提供一个我验证过可用的基础版本：

// scripts/obfuscate.mjs import fs from 'fs'; import path from 'path'; import { fileURLToPath } from 'url'; import JavaScriptObfuscator from 'javascript-obfuscator'; const __dirname = path.dirname(fileURLToPath(import.meta.url)); const targetDir = path.resolve(__dirname, '../dist/build/app'); const targetFile = path.join(targetDir, 'app-service.js'); if (!fs.existsSync(targetFile)) { console.error('未找到 app-service.js，请先执行 uni-app 构建'); process.exit(1); } const source = fs.readFileSync(targetFile, 'utf8'); const obfuscationResult = JavaScriptObfuscator.obfuscate(source, { compact: true, // 压缩成一行，减小体积 controlFlowFlattening: true, // 控制流平坦化，增加阅读难度 controlFlowFlatteningThreshold: 0.4, deadCodeInjection: true, // 注入无用代码，干扰静态分析 deadCodeInjectionThreshold: 0.2, identifierNamesGenerator: 'hexadecimal', // 变量名变成 0x 开头的十六进制 renameGlobals: false, // 千万别开，容易把全局对象改坏 selfDefending: true, // 防格式化，检测到非浏览器环境会崩 stringArray: true, // 字符串抽到数组里 stringArrayEncoding: ['base64'], // 字符串编码 stringArrayThreshold: 0.5, splitStrings: true, splitStringsChunkLength: 12, transformObjectKeys: true, // 对象键名混淆 unicodeEscapeSequence: false // 不建议开，会显著增大体积 }); fs.writeFileSync(targetFile, obfuscationResult.getObfuscatedCode(), 'utf8'); console.log('混淆完成，输出文件：', targetFile);

有几个参数要特别注意。renameGlobals是坑中之坑，uni-app 运行时依赖一些全局变量和函数，你要是把全局重命名了，启动时直接白屏，我一开始就吃过这个亏。selfDefending建议开，但要清楚它的副作用：如果用户把混淆后的代码放到美化工具里格式化，脚本检测到环境异常会自己崩掉，这对于“防止别人轻松调试”来说反而是优点。deadCodeInjection不要调太高，1.0 会让包体暴涨，而且部分低端 Android WebView 解析大 JS 文件会更慢，我实测 0.2 以下比较稳。

3.2 在 HBuilderX 构建链里正确接入

如果你的项目是 HBuilderX 创建的纯可视化工程，你看不到dist/build目录下的中间产物也没关系，可以用package.json里的脚本串起来：

{ "scripts": { "build:app": "vue-cli-service uni-build --mode production", "obfuscate": "node scripts/obfuscate.mjs", "build:release": "npm run build:app && npm run obfuscate" } }

跑完npm run build:release后，dist/build/app下除了app-service.js，还有app-config-service.js、manifest.json等文件。我遇到过有人把资源目录带上但忘了对app-service.js做覆盖，结果 HBuilderX 又把旧的没混淆版本打包进去了。所以我的脚本里专门加了校验：混淆完成后对比一次文件哈希，变了才继续，没变就报错退出。

3.3 千万别混淆的几类文件

不是所有 JS 都应该混淆。app-config-service.js里主要是路由页面配置、分包信息，uni-app 运行时需要按约定读取，你混淆了它反而会导致页面路由失效。app-service.js是业务逻辑主文件，混淆它收获最大。另外html5plus插件相关的 JS、第三方 SDK 的 JS 文件，最好不要动，或者保持它官方提供的压缩版，以免触发 SDK 内部的反射调用问题。

还有个隐蔽的坑：如果你的 App 在 WebView 里加载了外部 H5 页面，这些页面的 JS 跟 uni-app 打包资源不是一回事，别在 uni-app 这层混淆，要在 H5 项目里单独处理。

4. Native 层混淆：Android 的 R8 配置与 iOS 的现实选择

4.1 在本地打包工程里开启 R8

拿到 HBuilder 本地打包生成的 Android 工程后，打开app/build.gradle，在release构建类型里开启混淆：

android { buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } }

minifyEnabled true是让 R8 做代码裁剪和混淆；shrinkResources true是删掉没用的资源；proguard-rules.pro是我们的自定义规则文件。这里最关键的是规则文件，一旦写错，轻则运行异常，重则启动崩溃。针对 uni-app，我至少会在proguard-rules.pro里加上这些 keep 规则：

# uni-app 官方 SDK 核心类 -keep class io.dcloud.** { *; } # 如果你用了 HTML5+ 相关能力 -keep class com.taobao.weex.** { *; } -keep class org.apache.** { *; } # 第三方 SDK 一般会自带 proguard 规则，但像推送、统计这类，建议主动 keep 入口 -keep class com.xxx.push.** { *; } # 保留注解，防止 R8 把反射要用的注解信息吞掉 -keepattributes *Annotation* -keepattributes Signature -keepattributes InnerClasses # 如果用了反射读取 BuildConfig 之类的，保留 -keep class **.BuildConfig { *; }

为什么io.dcloud.**要全 keep？因为 uni-app 的 JS 与 Native 之间是靠反射、类名硬编码来桥接的，R8 如果把这些类名改了，JS 层调用 plus 能力时就会找不到类。我见过一个最典型的报错：混淆后移动端使用plus.android.importClass动态调原生，结果 R8 把目标类重命名，运行时报ClassNotFoundException。

4.2 R8 混淆后的重点回归项

开了 R8 之后，不是能出包就完事了。我给自己定了一个“混淆回归清单”，每次开启混淆后必测：

• App 冷启动是否正常，能不能进入首页，有没有白屏
• uni-app 的 plus API 调用是否正常，比如plus.device.getInfo、plus.runtime.openURL
• 原生插件是否正常工作，尤其是涉及反射的插件
• 第三方登录/支付/推送是否正常，SDK 的回调有没有丢失
• 不同 Android 版本（至少 Android 8、11、14 各选一台）跑一遍主流程

白屏和回调丢失是 R8 混淆最常导致的两类问题。回调丢失大多是 SDK 内部用了反射来找接口实现类，R8 裁剪掉了，解决办法是去 SDK 官方文档找它要求的 keep 规则，或者直接把 SDK 的包名整段 keep。我在使用某个地图 SDK 时就被坑过一次，混淆后onSuccess回调死活不触发，最后排查到是 SDK 内部用反射读取一个内部接口，R8 把它当成无用代码干掉了，keep 掉就好了。

4.3 iOS 端别硬上类名混淆，先做字符串和重点模块加固

iOS 的 Native 层混淆比 Android 麻烦很多。Android 有官方 R8，iOS 没有同类工具，开源社区里obfuscator-llvm可以做到控制流平坦化和字符串加密，但它要求你用 LLVM 全家桶重新编译整个工程，uni-app 本地打包工程里大量依赖 cocoapods 的第三方库，全量重编基本不现实，而且 Apple 审核对代码混淆有潜在合规风险。

所以我的 iOS 策略是“重点保护，不做全量”：

• 核心算法用 C/C++ 或 Swift 重写，藏在 Native 层，这比混淆更有意义
• 敏感字符串（API Key、密钥、加密盐）用运行时拼接或加密存储，不要明文写在二进制里
• 关键逻辑（比如会员校验、内购穿透）做服务端校验，不要只靠客户端判断
• 有必要再上obfuscator-llvm，且只对包含核心逻辑的几个模块增量编译

iOS 的“混淆”更多要靠代码结构和架构设计来实现，单纯的工具混淆性价比很低。多数团队实践下来，服务端校验 + 核心逻辑下沉到 C 层，已经能挡住绝大多数人。

5. 静态资源与打包产物加固：别让资源路径暴露你的 App 结构

5.1 用 AndResGuard 做资源路径混淆

uni-app 打包后，图片、音频、配置文件都堆在assets和res目录里。默认情况下资源名是icon_share.png、splash_screen.png这种语义化的名字，逆向者光看资源名就能猜出你的功能结构。AndResGuard 的核心作用就是把资源路径压缩成无意义的短名，同时通过资源复用和压缩减少包体。

在 Android 工程根目录的build.gradle里加插件：

buildscript { dependencies { classpath 'com.tencent.mm:AndResGuard-gradle-plugin:1.2.20' } }

然后在app/build.gradle中配置：

apply plugin: 'AndResGuard' andResGuard { mappingFile = file('./resource_mapping.txt') use7zip = true useSign = true keepRoot = true compressFilePattern = ['*.png', '*.jpg', '*.jpeg', '*.gif', '*.webp', 'resources.arsc'] whiteList = [ // 如果有动态获取资源 ID 的代码，这里要加白名单 'R.string.xxx', 'R.drawable.yyy' ] }

这里最核心的参数是whiteList。uni-app 的 JS 层和原生层有时候是动态拼接资源名再反射获取 ID，R.string.app_name这类资源如果被重命名，反射直接拿不到，所以要在白名单里显式保留。我建议第一次做资源混淆时，先按全量跑一遍，看日志里哪个资源访问报错，把对应项加进白名单，再迭代下一轮。

5.2 别忽略 assets 目录下的静态资源

AndResGuard 处理的是res目录，但 uni-app 的很多核心资源放在assets下。这些资源没有统一的混淆方案，我的做法是分情况处理：

• assets/apps下的 JS 已经用上一节的 javascript-obfuscator 混淆过了
• 敏感的 JSON 配置可以改成加密存储，运行时解密后再用，但要注意首次启动耗时
• 图片素材体积大的可以做 WebP 压缩，既能减小包体，也能顺带破坏原始格式
• so 库文件不要尝试用混淆工具处理，正确方式是做动态加载或者至少做一次加壳保护

so 库加壳属于另一个领域，如果你有 NDK 代码需要保护，建议关注一下各大厂商的商用加固方案，这里不展开讲。但你至少要意识到：资源层的混淆是让“拿到包的人”不能轻易整理出结构，而不是让文件完全不可解，所以别期待一份混淆能彻底拦住所有攻击者。

5.3 每次发版都要做的事：对比混淆前后包体与启动时间

我习惯用同一台 Android 手机，装混淆前和混淆后的包，分别记录冷启动时间和首屏渲染时间。重点看 3 个指标：

• 包体大小：混淆后应该持平或略小（R8 裁剪、资源压缩会减小）
• 冷启动时间：增加 1 秒以内还算正常，超过 2 秒就要查是不是字符串数组抽取过猛导致解析变慢
• 首屏白屏时长：JS 混淆后如果白屏超过 3 秒，我一般会把deadCodeInjectionThreshold调低，或者把controlFlowFlatteningThreshold从 0.4 降到 0.2

6. 常见问题与排查技巧实录

6.1 混淆后启动白屏，怎么定位

这个问题被问得最多。如果你的 App 在开启 JS 混淆后出现白屏，先不要慌，分三步排查：

第一步，把dist/build/app下的 app-service.js 换成未混淆版本，重新跑一遍打包，如果恢复正常，说明问题出在混淆脚本参数上。第二步，把selfDefending改成 false 试一次，有些 WebView 环境和自防御逻辑有冲突，导致 JS 执行失败但不报错，白屏就是结果。第三步，检查app-service.js开头有没有报语法错误，用 node 直接执行一遍混淆后的文件，如果 node 都报语法错，说明混淆器生成了非法代码，这时候把compact调成 false 再看看。

如果是 R8 导致的，方法类似：临时把minifyEnabled改回 false，确认是否恢复；恢复后再开启，并且用proguard-rules.pro里逐步加 keep 规则，用二分法定位到崩溃点。Android 的崩溃日志如果显示在io.dcloud里面挂的，那十有八九是 keep 规则不完整。

6.2 混淆后 API 密钥被报不安全，怎么处理

有的团队把 API Key 写在 JS 里，混淆后感觉安全了，但实际用真机抓包还是能看到请求头里的明文 Key。JS 混淆只能防“静态阅读”，防不了“动态抓包”。真正的做法是服务端签好短期有效 token，客户端启动时换取，核心接口用 token 认证，再配合 HTTPS 证书校验，才有可能把暴露面降到最低。

还有团队把 token 直接写死在 JS 里，混淆后以为万事大吉，结果一看抓包工具，照样被拉出来。我的原则是：永远不要把真正的业务密钥放进客户端代码里，不管混淆强度多大。

6.3 第三方 SDK 在混淆后出现异常行为的排查顺序

如果你开了混淆后某个 SDK 不正常了，我的排查顺序是：

1. 看 SDK 官方文档有没有 proguard 规则，复制粘贴到proguard-rules.pro
2. 在proguard-rules.pro里把该 SDK 的入口类全包 keep，验证是否为 keep 缺失问题
3. 看日志里有没有“Class not found”“Method not found”之类关键字
4. 用未混淆包对比，如果未混淆正常、混淆后异常，基本可以确定是 keep 规则问题
5. 如果 SDK 有 provider 或者 manifest 里声明的组件，确保这些组件也没被裁剪掉

有一些 SDK 很贴心，会在 AAR 里自带proguard.txt，AGP 会自动读取，不需要我们手动配置。但 uni-app 离线打包工程里，SDK 来源比较杂，有些是手动放到 libs 文件夹下的，AGP 不会自动读取规则，必须手动复制到我们的proguard-rules.pro里。

6.4 混淆后保活/推送失败，和混淆的关系大不大

说实话，推送和保活更多是厂商服务和进程模型的问题，混淆影响相对小。但有一种情况确实有关：如果你把推送 SDK 的服务类混淆了，Android 系统在拉起服务时可能因为类名变了找不到对应的Service，导致推送点击通知后崩溃。这种情况下把 SDK 的服务类、广播接收者类全部 keep 住就行。

6.5 混淆参数速查表

6.6 还应该配合做的一件事：检查和加固你的签名配置

混淆能让代码难读，但资源混淆和代码混淆都解决不了一个问题：别人把你的 APK 解包后重新打包。只要你发布包没有使用签名校验，别人完全可以反编译、改代码、重新签名做成“马甲包”。所以我强烈建议在 uni-app 发布前，额外做两个动作：一个是开启签名校验，在 JS 层和 Native 层分别检查当前包的签名是否和预期一致；另一个是使用加固平台对 APK 做整体加固，提升逆向成本。

6.7 关于混淆的“够用”标准

最后聊点实在的。混淆不是万能的，它只能提高门槛，不能做到绝对安全。Google Play 上很多知名 App 也会被逆向，只是攻击者要付出更高成本而已。我把“够用”定义为：对方用 jadx 和一般解包工具无法在 30 分钟内理清你的业务结构和核心逻辑。达到这个标准，你已经超过了市面上大多数 uni-app 应用的安全水平。

我踩过很多坑，现在最深的体会是：混淆一定要在项目初期就加入构建流程，而不是产品快上线了才想起来。一开始就把混淆跑起来，后续每次加新功能、新依赖，都会顺手验证混淆规则；如果拖到后期再处理，几十个 SDK、几百个资源文件一起排查，那真的是自己给自己挖坑。你可以在本地打包工程里先做好基础配置，然后逐渐完善规则，不用一步到位。反正混淆这件事，越早开始，越省心。