有次帮一个准备上线的项目做代码混淆，团队之前没接触过这块，问了我几个很实际的问题：类名方法名全都改掉会不会影响功能？混淆强度设多少合适？哪些类不能随便动？这些问题光靠文档说明不太好理解，走一遍流程就知道了。

Obfuscator-LLVM：源码级混淆

Obfuscator-LLVM 是开源的源码级混淆方案，基于 LLVM 做指令替换、控制流扁平化和虚假控制流插入。配置流程：下载定制的 clang 编译器 → 在 Xcode Build Settings 里替换默认编译器 → 添加 -fla（控制流扁平化）、-bcf（虚假控制流）、-sub（指令替换）等编译标志 → 编译项目。

优点是混淆强度高，二进制基本不可读。缺点是配置成本不低——升级 Xcode 后工具链可能不兼容，Swift 混编项目支持不完善，每次 Clean Build 时间明显变长。而且必须拿到项目源码才能操作，接手别人编译好的 IPA 就没法用了。

手动代码混淆：批量脚本改名

有些团队会在源码层写脚本做批量改名，用 sed 或 Python 正则替换类名和方法名前缀。优点是灵活，想怎么改自己控制。缺点是维护成本高，发版前要跑一遍脚本，改了以后要全局测试有没有漏改或改错的地方。Swift 项目涉及 module 和命名空间，比 OC 复杂得多。

IpaGuard：编译后 IPA 直接混淆

IpaGuard 不需要源码，直接对编译好的 IPA 操作。流程分几步：打开工具把 IPA 拖进去 → 在代码模块里选择可执行文件 → 工具自动列出所有类和方法的名称列表并按风险等级标注 → 勾选需要混淆的目标 → 设置模式（白名单/黑名单）和处理强度 → 开始处理 → 重签名安装到手机验证。

风险等级是个参考值：低风险的类一般可以全量混淆，中高风险的涉及动态调用、反射或者被第三方库引用的类，建议先测试再决定。模式方面，第一次做混淆建议用白名单——从低风险的类开始勾选，逐步扩大范围，比黑名单更可控。处理强度控制混淆后字符串的乱码程度，强度越高越难逆向，但如果 App 里有通过字符串拼接方式调用的方法名，强度太高可能导致调用失败。

处理完成后生成的 IPA 用开发证书重签名装到设备上测试。主要检查各页面跳转、接口调用和核心功能是否正常。没问题就换发布证书打出正式包上架。

选型建议

Obfuscator-LLVM 适合对安全性要求高、有源码、能接受编译流程调整的团队。IpaGuard 更适合普通项目——不需要动源码和编译配置，多平台支持全，上手门槛低，发版前走一遍就能出混淆包。手动脚本适合极小规模项目或者只需要做部分代码保护的情况。