DEX 加固和 SO 加固有什么区别？Java 层与 Native 层保护怎么选
DEX加固主要保护Java和Kotlin字节码，适合降低业务逻辑、类结构和调用关系被分析与篡改的风险；SO加固主要保护Native二进制，适合提高核心算法和本地模块的逆向成本。选择时应先盘点高价值资产，再根据代码所在层、攻击后果、性能要求和团队维护能力决定，不能认为Native天然安全，也不能用客户端加固替代服务端鉴权。多数应用适合采用DEX、SO与服务端校验相结合的分层保护方案。
我想保护 App 的代码和核心逻辑，DEX 加固与 SO 加固的保护对象有什么不同？
保护对象的差异
DEX 加固主要针对 Android 的 Java/Kotlin 字节码及相关代码逻辑，常见方式包括代码加密、动态加载和反编译防护。SO 加固主要针对 Native 层的共享库文件，通常通过加密、混淆、反调试等手段提高逆向分析难度。两者保护的文件和运行环境不同，不能简单视为同一种方案。
如果核心算法已经写在 C/C++ 的 SO 库中，只做 DEX 加固是否足够？
应针对核心代码所在层加固
只加固 DEX 通常不能直接保护 SO 中的实现。若核心算法位于 Native 层，应评估 SO 加固；若 Java/Kotlin 层也包含关键逻辑，则需要一并考虑 DEX 保护。还要注意，接口调用、参数传递和运行时行为可能暴露线索，保护边界应覆盖关键调用链。
项目里既有 Java/Kotlin 代码，也有 C/C++ 模块，我该如何确定加固范围？
根据资产分布和风险确定范围
先盘点需要保护的代码、资源和业务逻辑：Java/Kotlin 代码占主要风险时，重点评估 DEX 加固；核心算法、协议处理或关键计算位于 C/C++ 模块时，重点评估 SO 加固。两层都承载敏感逻辑时，可组合使用，并结合威胁模型、设备覆盖范围和维护成本验证方案。
采用 DEX 或 SO 加固后，是否可能出现启动变慢、崩溃或特定机型无法运行？
上线前应进行性能与兼容性验证
加固方式可能影响启动耗时、内存占用、调试流程或特定系统环境下的加载行为，具体影响取决于加固实现和应用结构。建议在目标 Android 版本、主流芯片架构及不同厂商设备上测试冷启动、核心功能和异常恢复，并预留回滚方案。