Flutter应用混淆优化实战：从ProGuard配置到跨平台框架选型

先聊个现象。我去年帮朋友排查一个 Flutter 应用被“套壳”的问题：应用上线没几天，市面上就出现了逻辑几乎一样的马甲包，包体里能看到一模一样的接口地址和加密逻辑。反编译一看，整个 Flutter 产物里的关键字符串几乎都是明文，原生层的代码也只做了最基本的 ProGuard 压缩，等于把核心业务逻辑直接摊开给别人抄。从那天起，我就把“Flutter 应用混淆优化”列进了每个项目的强制验收项。这个主题其实包含两层意思：一是 Flutter 应用怎么在 Android/iOS 两端把混淆做到位，二是为什么框架选型会直接影响你后续的混淆、加固和上架策略。这篇文章就围绕这两个核心展开，把配置步骤、原理、坑和框架对比一次性讲透。

这篇内容适合谁？如果你是刚把 Flutter 用进生产项目的客户端开发，或者正在做技术选型、准备从传统原生转向跨平台方案，又或者你已经上架了几个 Flutter 应用但总觉得“反编译后有点心虚”，那这篇文章应该能帮你省掉不少试错时间。我不会只贴配置代码，更会讲清楚每一步背后的原因，以及我实际踩过的那些坑。

1. Flutter 应用为什么要做混淆优化

很多 Flutter 开发者有个误解：Flutter 的 Dart 代码在 Release 模式下会被 AOT 编译成机器码，和 Java/Kotlin 的字节码不一样，反编译难度本来就大，所以不需要再做混淆。这个说法只对了一半。

1.1 Dart AOT 编译到底保护了什么

Flutter Release 构建时，Dart 代码通过 AOT（Ahead Of Time）编译成 ARM 机器码，打进了libapp.so和libflutter.so。普通反编译工具确实很难把.so里的机器码还原成“可读的 Dart 源码”，但这不代表没有风险。

我实测过，用 IDA、Ghidra 这类工具加载libapp.so，配合 Flutter 引擎的符号信息，依然能定位到字符串常量池。只要你在代码里写了硬编码的接口地址、API Key、加密盐值，人家就能在二进制里直接搜到。即使字符串被简单拼接，也会在堆内存里暴露。所以 AOT 编译更像是“增加了逆向成本”，而不是“一劳永逸的安全保障”。

真正的风险点往往不在 Dart 层，而在原生层。Flutter 项目里 Android 端有MainActivity.kt、各种插件注册代码、支付或登录相关的原生桥接；iOS 端有AppDelegate.swift、Pod 库里的 Objective-C/Swift 代码。这些代码如果没有做混淆，用 jadx 打开 APK 就能看到非常清晰的类名、方法名、逻辑结构。很多 Flutter 应用的核心安全问题恰恰出在这一层，而不是 Dart 代码本身。

1.2 Flutter 工程里真正需要保护的目录

我接手过的 Flutter 项目里，很多同学的混淆配置只改了android/app/build.gradle里的两行代码，iOS 端完全没动，原生插件目录也基本是裸奔状态。实际上一个完整的 Flutter 混淆方案要覆盖四个方面：

• Android 原生层：MainActivity、自定义 MethodChannel、原生插件类，需要配合 ProGuard/R8 做压缩、混淆、优化。
• iOS 原生层：通过编译选项做符号剥离，减少 Objective-C/Swift 符号被直接 dump 的风险。
• Dart 层：虽然默认 AOT 编译，但要主动检查字符串常量、接口地址、敏感逻辑是否有足够“隐藏”。
• 资源层：Android 的assets、iOS 的 Bundle 资源，有时会泄露证书文件、配置文件、甚至后端 API 的路径。

这四层里，Android 原生层最容易被混淆“误伤”，因为 Flutter 引擎和插件依赖了大量反射和动态注册类。如果你只图省事开启minifyEnabled true而不加任何 keep 规则，轻则运行时崩溃，重则插件功能全废。下面我说的这套配置，是我在 Flutter 3.x + AGP 7.x 下反复验证过的组合。

2. Flutter 混淆优化实操：三层防护配置

下面进入最重要的部分。我会从 Android 端、iOS 端、Dart 层三个维度，给你一套可以直接抄的配置。先说结论：Flutter 的混淆不是“开一个开关”就结束，而是要在编译前、编译中、编译后都做检查。

2.1 Android 端：ProGuard/R8 与 Flutter 的兼容配置

Flutter 项目 Android 端的混淆入口有两个文件。第一个是android/app/build.gradle，核心配置大致长这样：

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

第二个是android/app/proguard-rules.pro，这里要写入 Flutter 和第三方插件的 keep 规则。我结合多个项目的经验，给你一份最小可用配置：

# Flutter 引擎与插件基础规则 -keep class io.flutter.** { *; } -keep class com.google.protobuf.** { *; } -dontwarn io.flutter.** # 你自己的原生桥接类（按实际包名替换） -keep class com.example.myapp.** { *; } # 使用 Gson/Jackson 的实体类 -keep class com.example.myapp.model.** { *; } # 微信/支付宝等 SDK 回调类 -keep class com.tencent.** { *; } -keep class com.alipay.** { *; }

这里有一个非常关键的细节：io.flutter.**必须整包 keep。Flutter 引擎在启动时会通过反射找到指定的 PluginRegistrant 和 DartExecutor，如果你把 Flutter 引擎相关类混淆了，轻则白屏崩溃，重则启动就直接闪退。很多新手在混淆后遇到“release 包打不开，debug 包正常”的第一反应是怀疑代码出了问题，实际上八成是 ProGuard 规则漏了io.flutter。

shrinkResources true这个参数我建议在正式包开启，它能顺带把无用资源删掉，减小包体。但要注意：如果你的资源是动态引用的，比如通过字符串拼接获取资源 ID，资源收缩可能导致运行时报错Resources$NotFoundException。这类问题会在后续常见问题章节单独说。

2.2 iOS 端：符号剥离与编译优化

iOS 端的混淆逻辑和 Android 完全不同。苹果不允许对系统 API 做 ProGuard 式的改名混淆，所以大家通常说的“iOS 混淆”实际指的是两件事：一是剥离调试符号，二是对 Objective-C 方法名做有限的混淆。

在 Xcode 的 Build Settings 里，Strip Style设置为All Symbols，Deployment Postprocessing设置为YES。在 release 打包时，Xcode 会自动剥离符号表，这样从 Mach-O 文件里能读到的类名和方法名就会大幅减少。你还可以通过脚本在编译后执行strip命令，把二进制的符号表再清理一轮。

如果你用了 Objective-C 代码，并且担心方法名泄露，可以用一些自动化工具做类名和方法名混淆。但这里我必须提醒：Flutter 插件生态里不少库是开源的，Swizzling 或 KVC 反射很依赖方法名，过度混淆极容易让第三方库在运行时直接崩掉。所以我的建议是先做符号剥离，再按需对自有代码做方法名混淆，第三方 Pod 库保持原样。

iOS 端还有一个容易被忽略的点：Info.plist里的反编译风险。你会在 plist 里配置 URL Scheme（比如微信登录必须的wx开头）、ATS 白名单、各种 API Key。这些东西在 IPA 里其实都是明文 XML，可以用plutil直接读出来。所以像微信 AppID、后端域名这类信息，尽量放到后台动态下发或做一层加密存储，别让 plist 变成“安全漏洞文档”。

2.3 Dart 层：代码压缩与敏感信息隐藏

Dart 代码本身在 release 构建时会被 AOT 编译，不需要也不能像 Java 那样做“ProGuard 改名”。但 Flutter 提供了一个--obfuscate编译选项，配合--split-debug-info使用，可以对 Dart 代码中的符号名做混淆处理：

flutter build apk --release --obfuscate --split-debug-info=build/symbols flutter build ios --release --obfuscate --split-debug-info=build/symbols

加了--obfuscate之后，Dart 层的方法名、类名会被替换成无意义的短标识符，这能显著提高反编译libapp.so的难度。注意几个细节：

• --split-debug-info指定的目录会生成一份符号映射文件（symbols），这份文件务必保存好，最好归档到 CI 系统或内部存储。因为线上崩溃日志里的堆栈是混淆后的，你需要在排查崩溃时用symbols文件还原原始堆栈。
• Firebase Crashlytics 或 Sentry 接入时，需要上传这套符号文件，否则线上看到的崩溃堆栈完全不可读。
• --obfuscate只对 Dart 编译产物有效，对 Android/iOS 原生层代码没有影响，所以它和前面提到的 ProGuard/R8 是互补关系，不能互相替代。

除了符号混淆，Dart 层的字符串也要重点处理。我写过一个小工具，在 CI 构建时扫描代码中的硬编码域名、http://、https://、API Key 等模式，命中后强制要求改为通过环境变量或远程配置获取。这样即使有人逆向出libapp.so，看到的也只是一串解密函数，而不是直接可用的地址。

2.4 附加方案：字符串加密与资源防护

如果需要更高强度的保护，可以考虑给字符串做一层运行时解密。Dart 里可以这样写：

String _decode(String encrypted) { // 这里做异或或简单 AES 解密，密钥不要硬编码在同一个类里 return base64Decode(encrypted); } final apiHost = _decode('aHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20=');

但说实话，这种方案提高的是“逆向门槛”，不是“绝对安全”。逆向工程师只要 hook 住解密函数，或者直接抓包，依然能拿到真实地址。所以我的原则是：敏感信息能用后端下发的绝不放前端，能动态计算的绝不静态写死，字符串加密只作为最后的补充手段。

资源文件防护方面，Android 可以把assets目录里的关键配置改成加密文件，运行时先解密再使用；iOS 的 Bundle 资源也需要检查是否把证书私钥、数据库文件直接暴露在应用包里。热词里反复出现“Flutter 内嵌数据库”，这里特别提一句：如果你把 SQLite 数据库文件打进了应用包，里面又有用户隐私数据或业务敏感数据，那这个数据库文件本身就是巨大的安全隐患。建议对数据库做整体加密（比如 SQLCipher），或者只在首次启动时从服务端动态拉取。

3. 跨平台框架对比：Flutter 与主流方案怎么选

说完混淆，必然要聊框架选型，因为混淆只是“安全策略”的一个环节，而框架选型决定了你能做哪些混淆、做不到哪些混淆。比如 RN 和 uni-app 这类带 JS 引擎的方案，代码是解释执行的，混淆方式就和 Flutter 完全不同。

3.1 Flutter vs React Native：渲染机制与安全基座

React Native 的核心架构是 JavaScript 代码跑在 Hermes 或 JSC 引擎里，UI 通过 Bridge 映射到原生组件。它的跨端能力很成熟，生态里也有很多成熟三方库，但它的包体和性能一直被拿来和 Flutter 对比。我自己的项目在 2022 年做了一个即时通讯模块，当时对比了 Flutter 和 RN，最终选了 Flutter。

单看“代码保护”角度，RN 的 JS Bundle 是典型的解释执行文件，虽然 Hermes 提供了字节码预编译（hermesc），但字节码仍可被反编译成接近源码的形式，社区里也有人专门做了 Hermes 字节码还原工具。Flutter 的 AOT 编译产物是二进制机器码，逆向成本天然更高。这对安全敏感型业务来说是个很大的加分项。

但 RN 也有优势。它的 JavaScriptCore/Hermes 生态里有很多成熟的 JS 混淆工具（如javascript-obfuscator），如果你只是想做“源码层面的混淆”，RN 反而更容易找到现成方案。Flutter 则没有太多第三方 Dart 混淆插件，官方提供的--obfuscate是唯一的标准手段。

3.2 Flutter vs uni-app：国内生态与动态发布

uni-app 基于 Vue 语法，编译产物是小程序、H5、Android/iOS App 全平台覆盖，在国内中小企业里使用率很高。它的 App 端运行时主要依赖 WebView 或小程序引擎容器，业务代码最终会编译成 JS 或类小程序代码。它的跨端适配能力确实强，遇到国内各种小程序平台基本零成本迁移。

但在 App 安全这个维度，uni-app 的现状就比较困难了。因为核心逻辑跑在 JS 层，即使做压缩和混淆，反编译工具还原的难度也比 Flutter 低一截。更重要的是，uni-app 的动态更新正是通过下发 JS 代码来完成的，一旦打包密钥泄露，攻击者可以直接伪造更新包，这个风险比“静态逆向”严重得多。

所以我的选型经验是：如果团队以 Vue/前端为主，核心诉求是“小程序+H5+App 三端复用”，uni-app 没问题，但要在业务逻辑里做好权限校验和加密校验。如果团队能接受 Dart/Flutter 的语法成本，同时业务有明确的性能和安全诉求，Flutter 是更稳的选择。

3.3 Flutter vs Kotlin Multiplatform：共享逻辑与原生体验

Kotlin Multiplatform（KMP）是近年来越来越多被讨论的方向，JetBrains 推出的 Compose Multiplatform 也在向生产可用推进。KMP 的思路是共享 Kotlin 业务逻辑，UI 层各端用原生组件渲染。它的性能表现和原生几乎一致，也天然具备 Kotlin/JVM 生态里的混淆工具基础，比如 Android 端可以直接走 ProGuard/R8。

如果你已经深度使用 Kotlin 且很重视原生体验，KMP 是很有吸引力的。但它的跨端覆盖范围暂时还比不上 Flutter，尤其在 iOS 之外的桌面、Web 端，生态还不够开放。对比混淆层面：KMP 共享代码在 Android 端和 iOS 端分别编译成字节码和机器码，保护强度取决于各端的构建配置，整体和 Flutter 相近，但需要更加小心地处理 expect/actual 声明。

3.4 Flutter vs WPF / 原生桌面方案：不同赛道的取舍

热词里出现了“Flutter 和 WPF”，这其实是桌面端场景的对比。WPF 是 Windows 上非常成熟的桌面 UI 框架，基于 .NET，绑定能力强大，企业管理系统里大量使用。但 WPF 的编译产物也是 .NET 中间语言，反编译工具（比如 ILSpy）能几乎 100% 还原出接近源码的 C# 代码，所以 WPF 应用的混淆基本是“必选项”，通常靠商业混淆器做控制流混淆和字符串加密。

Flutter 在桌面端的支持已经进入稳定期，Windows/macOS/Linux 都能构建。就代码保护来说，Flutter 桌面端同样依赖 AOT 编译，逆向难度反而比 WPF 更高。不过 Flutter 桌面生态还比较年轻，复杂表格、多窗口管理、系统集成等场景需要踩的坑多一些。如果项目是纯 Windows 内网工具，WPF 的开发效率和生态成熟度依然有优势；如果是追求跨平台统一、面向未来发布，Flutter 桌面值得认真评估。

下面这张表是我自己团队内部做技术选型时用过的，非常朴素但实用：

这个表不需要作为结论，但可以帮助你理清思路：选框架不能只看 UI 写得多快，还要看“代码最终以什么形式运行”“被反编译的难度有多大”“出了安全事件还能不能补”。

4. 框架选型对混淆与上架体验的连带影响

框架选定之后，混淆就不是一个孤立动作了，它会连带影响插件兼容、登录支付、数据库同步、甚至应用商店审核。这里我把热词里反复出现的几个场景串起来讲。

4.1 动态化框架（RN/uni-app）能做什么混淆

如果你用了 RN 或 uni-app，想通过给 JS 代码做重度混淆来保护业务逻辑，一定要小心两个副作用。第一，混淆后的 JS 代码会在运行时显著变慢，尤其是在低端 Android 机上，初始化耗时可能翻倍。第二，很多混淆器会改变函数的调用栈信息，导致你在排查线上问题时看到的堆栈完全不可读，如果没提前上传源码映射表，线上 Bug 根本定位不了。

有人会问，能不能用“服务端下发加密 JS、客户端动态解密”这种方案？当然可以，但这对“密钥管理”要求很高。密钥放端上就会被逆向，密钥不放端上又没法解密，本质上是个“藏钥匙”的游戏。我的做法是：核心逻辑放原生模块，JS 层只做 UI 事件转发和展示逻辑，即便 JS 被逆向，攻击者也拿不到真正的核心算法。

4.2 微信登录、内嵌数据库与后端同步的混淆注意点

热词里“Flutter 微信登录”出现频率很高。微信登录 SDK 要求你在AndroidManifest.xml里配置包名、签名和回调 Activity。一旦你开启了资源收缩（shrinkResources）或做了 ProGuard 混淆，微信 SDK 的某些类或资源文件被误删，登录可能直接没反应或回调不到。

我遇到过一个典型案例：一个 Flutter 项目接入了微信登录，release 包在点击授权后毫无反应。排查半天，最终发现是 ProGuard 规则把微信 SDK 的WXEntryActivity相关类混淆了，导致回调页面无法拉起。解决方案也很简单，在proguard-rules.pro里显式 keep：

-keep class com.tencent.mm.opensdk.** { *; } -keep class com.tencent.wxop.** { *; } -keep class * extends android.app.Activity { *; }

“Flutter 内嵌数据库 + 后端同步”也是一个高频组合。本地数据库文件如果被反编译提取出来，等于把用户数据和业务缓存全部交给别人。我建议三层处理：一是用 SQLCipher 对 SQLite 加密，二是把数据库文件放到应用私有目录而不是公共存储，三是在同步接口里做数据签名校验，防止本地被篡改后污染服务端数据。

混淆规则方面，如果你用了drift、sqflite这类数据库插件，它们的原生层类名也尽量保持 keep，避免反射创建表结构时找不到类。

4.3 Flutter 兼容鸿蒙与 IAP 拉起支付的实战边界

热词里“flutter兼容鸿蒙拉起iap支付”也是一个典型场景。鸿蒙生态逐渐起来后，很多 Flutter App 需要跑在鸿蒙设备上，还要拉起鸿蒙的 IAP 支付。这里最容易出问题的点恰恰和混淆强相关：鸿蒙的支付 SDK 通常通过Ability方式拉起，它的类名、包名如果被混淆或资源被裁剪，支付拉起很容易失败。

如果你遇到“鸿蒙设备上点击支付没反应”的问题，第一步别怀疑代码逻辑，先关掉混淆和资源收缩，打一个不混淆包试试能不能拉起支付页。如果能拉起，基本确定是混淆/裁剪规则漏配了。把支付 SDK 的目录整体 keep 掉，再重新构建验证即可。

还有一个小细节：鸿蒙 IAP 的支付结果回调是异步的，混淆时如果把回调类名改了，商家签名验签就可能失败。所以在proguard-rules.pro里，凡是用到“回调”“监听”“跳转”的第三方 SDK 类，尽量整包 keep，不要为了那几百 KB 的压缩收益去抠规则。

4.4 包体积控制与混淆的平衡

minifyEnabled true和shrinkResources true确实能减小 APK 体积，但 Flutter 应用本身有一个大体积的libflutter.so和libapp.so，就算你把 Java 代码混淆得再狠，Dart 编译产物也不会显著变小。所以 Flutter 应用的包体优化重心应该放在裁剪 ABI 和精简资源上，而不是指望混淆器帮你“瘦身”。

我实际测试过，一个中等规模的 Flutter 应用，开启 ProGuard/R8 后 Java 层代码体积能减少 30%~50%，但整个 APK 可能只减少 3%~5%，因为大头在.so和assets。如果为了包体继续压缩，可以参考 Flutter 官方支持的--split-per-abi，只打包目标机型的 ABI，发布后在应用商店里按 ABI 分发。这一步和混淆没有直接关系，但很多人混淆时顺手把abiFilters配错了，导致部分设备安装后无法运行，这点也值得列入检查清单。

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

最后分享几个我踩过的坑，基本覆盖了 Flutter 混淆和框架使用时最常遇到的诡异问题。

5.1 混淆后 Release 包闪退、插件失效怎么办

最典型的现象是：debug 包正常，release 包一启动就闪退，或者某个插件功能无法使用。这种问题九成是 ProGuard/R8 规则漏配。我的排查顺序是：

1. 先关掉minifyEnabled，把 release 包变成不混淆包，如果问题消失，确认是混淆导致。
2. 打开崩溃日志或adb logcat，看崩溃堆栈里提到的类名是哪个，按类名补 keep 规则。
3. 如果是第三方插件崩溃，直接去插件的 GitHub 页面搜索 “proguard” 或 “R8”，看官方维护的 keep 规则，贴到自己的proguard-rules.pro。
4. 在本地用./gradlew :app:minifyReleaseWithR8打出混淆后的映射文件mapping.txt，通过retrace工具反解崩溃堆栈，找到真实崩溃位置。

很多插件会在使用文档里写明“需要添加如下 ProGuard 规则”，但实际上一半的开发者根本没往下翻到那一页。这里提醒一句：接了插件之后，务必去插件文档里搜 “proguard” 关键词。

5.2 Flutter 构建时的 Gradle 插件警告与 CMake 问题

热词里有一条 “you are applying flutter's main gradle plugin imperatively using the apply s...”，这是 Flutter 旧版 Gradle 集成方式在新版 AGP 下的兼容性警告。通常出现在项目升级 Flutter 版本之后，解决方案是把android/settings.gradle里的插件声明方式改为：

plugins { id "dev.flutter.flutter-gradle-plugin" }

再看热词里的 “Flutter cmake error at CMakeLists.txt:3 ... generator Visual Studio 16 2019”，这是 Windows 桌面端开发常见问题，通常是 CMake 版本或者 Visual Studio 工具链不匹配导致的。解决方案是在 Android Studio 里安装对应的 Visual Studio 桌面 C++ 负载，并确保flutter doctor不报 Visual Studio 相关错误。如果你不开发 Windows 桌面版，可以忽略，但如果团队要走桌面端发布，这个工具链问题要在项目初始化时就处理干净。

5.3 反编译与解混淆的长线对抗策略

说到底，混淆不是一锤子买卖。每次发版前，我都会执行一遍“自查反编译”流程：拿 release 产物跑一遍 jadx，看看 Android 原生层的代码可读性；用 Ghidra 简单加载libapp.so，看看字符串是否直接暴露；检查assets目录下有没有明文配置文件。这个过程只需要十几分钟，却能提前发现大量安全隐患。

有段时间我喜欢在 CI 里集成一个字符串扫描脚本，对 APK 内的lib/arm64-v8a/libapp.so执行strings，如果检测到类似api_key、secret、password等高风险关键词，构建直接失败，强制开发改代码。这套做法看着笨拙，但确实帮团队拦住了几次“把密钥提交到仓库又打进了安装包”的事件。

5.4 混淆后的崩溃堆栈还原

前面提到--split-debug-info会生成符号文件，这里再补充一个实战细节。你把flutter build apk --obfuscate --split-debug-info=build/symbols的构建产物上线后，线上日志里的堆栈会变成类似：

#00 pc 0x0000000000316c84 /data/app/.../libapp.so #01 pc 0x0000000000317a40 /data/app/.../libapp.so

没有符号文件根本无法定位。这时候在项目目录执行：

flutter symbolize -i stack.txt -d build/symbols

就能把混淆后的地址还原成具体文件和行号。所以再次强调，build/symbols目录一定要妥善归档，别删完 build 就彻底丢失了。

5.5 混淆、上架与审核的联动问题

从应用商店审核角度看，混淆做得太猛也可能带来问题。比如某些商店会做自动化安全扫描，对“过度加密”“动态加载代码”等行为比较敏感。Flutter 自带的--obfuscate和原生层的 ProGuard 通常没问题，但如果你在此基础上又叠加了商业加固壳，就需要提前确认所选商店的兼容性。

“iOS 代码社交遭遇 4.3”这类问题也常被提及。审核被拒的原因往往不在于混淆本身，而是应用功能太单一、缺乏足够差异。如果遇到 4.3，别把精力全放在改混淆策略上，重点要审视应用的核心价值功能和交互设计是不是太“模板化”。一套合理的混淆方案能保证代码安全，但不能替你解决产品层面的同质化问题。

6. 跨平台框架演进中的再思考

从 2022 年到 2025 年，Flutter 的桌面端和 Web 端支持越来越成熟，社区对“一套代码跑全端”的期待也在变高。但跨端开发从来不是“写得爽”就完事，还要考虑维护成本、性能、安全边界和团队技术栈匹配度。我在接触了 WPF、RN、uni-app 等项目之后，最大的感受是：没有最好的框架，只有最适应当前团队和业务场景的框架。

如果团队本身就熟悉 Kotlin 和服务端共享逻辑，演进到 Kotlin Multiplatform 是一个顺滑路径。如果团队的主要人力来自前端，且需要快速发布到小程序和 App，uni-app 或 Taro 这类多端方案效率更高。如果追求的是“一份 UI 代码在所有平台上有接近原生的渲染结果”，并且希望代码尽量不被逆向，Flutter 是我目前综合推荐度最高的选项。

框架对比和混淆优化并不是两条独立的线，你在选型时越早清楚“业务代码将如何运行、会被谁看到、需要防护到什么程度”，后面做混淆方案时越省力。比如选 Flutter 就尽早把--obfuscate和原生 ProGuard 规则纳入 CI，选 RN 就尽早引入 Hermes 字节码和 JS 混淆工具链，而不是等项目上线被扒了再补救。

我个人在实际操作中的体会是：混淆方案做得早、做得稳，远比做得狠、做得猛更重要。与其在发版前一天手忙脚乱地补 keep 规则，不如在项目初始化时就搭建一套“默认开启混淆 + CI 自动扫描敏感信息 + 发版前反编译自查”的流水线。最后再分享一个小技巧：每次升级 Flutter 版本后，不要只看新特性，要重新跑一遍你的混淆构建，因为 Flutter 引擎和 Gradle 插件的反射逻辑经常会变，一个看似无关的 keep 规则可能会在新版本里突然变成崩溃源。