先别急着换加固方案
APK 加固后出现闪退，最常见的处理方式是直接找加固厂商要说法，或者换一家再试。但在实际排查中，加壳本身引入的崩溃占比并不高，更多问题出在加固与运行环境、加固与业务代码、加固与其他 SDK 之间的交界处。把闪退一律归因于加壳，容易在错误的方向上反复试错。
更有效的做法是先建立分层假设：闪退发生在哪个阶段、在哪些机型上、是否有稳定复现路径。下面按三个高频方向展开。
方向一：机型与 ROM 差异
加固后的 APK 在启动阶段会做壳代码的解密与装载，这一步对系统加载器、内存布局、ART 运行时行为比较敏感。不同厂商 ROM 在类加载、dex 优化、内存限制策略上的实现并不完全一致，因此同一份加固包在部分机型上稳定、在另一部分机型上闪退，是很典型的现象。
排查时建议先做这几件事：
- 收集崩溃机型分布，看是否集中在特定厂商、特定系统版本或特定 CPU 架构（armeabi-v7a / arm64-v8a）。
- 检查是否只在 32 位运行时闪退，或只在 64 位运行时闪退，这往往指向 so 库与 ABI 的匹配问题。
- 关注低内存机型：壳在启动时需要额外内存做解密，内存紧张的设备更容易在冷启动阶段被系统杀掉或抛出异常。
- 对比加固前后同一机型的 logcat，重点看类加载失败、so 加载失败、VerifyError 一类信息。
如果崩溃集中在少数 ROM，且日志指向加载阶段，优先和加固厂商确认该 ROM 的已知兼容性问题，而不是整体推翻方案。
方向二：反射、动态加载与代码混淆的叠加
加固通常伴随代码保护处理，类名、方法名可能被重命名或结构调整。业务代码里如果大量使用反射、动态代理、注解处理器生成的代码、或按字符串拼接类名去加载，就很容易在加固后失效，表现为 ClassNotFoundException、NoSuchMethodException，最终以闪退形式暴露。
排查建议：
- 梳理项目中所有反射调用点，尤其是通过字符串硬编码类名、方法名的位置。
- 检查依赖注入框架、序列化框架、路由框架是否依赖类名或字段名，这类框架在加固后经常出问题。
- 确认加固配置中的保留规则是否覆盖了这些类，必要时把反射目标加入不混淆名单。
- 动态加载 dex、插件化、热修复相关逻辑，需要单独验证，因为壳与动态加载在类加载器层面容易互相干扰。
这一类问题的特点是：崩溃堆栈往往落在业务代码或框架代码里，看起来和加固无关，但根因是加固改变了类结构。定位时以“加固前能跑、加固后不能跑”的对照实验为准。
方向三：与第三方加固、热修复、安全 SDK 的冲突
一个 APK 里同时存在多套做代码保护或运行时修改的组件时，冲突概率会明显上升。常见组合包括：加固方案与热修复框架、加固方案与另一家加固/混淆工具、加固方案与某些安全风控 SDK。它们可能都在操作类加载器、Application 初始化顺序或 so 库加载，顺序稍有不同就会闪退。
排查思路是把变量收敛：
- 先做最小可复现包，只保留加固和必要依赖，逐个加回第三方组件，定位冲突对象。
- 检查 Application 与 ContentProvider 的初始化顺序，多个 SDK 争抢早期初始化时机是高频原因。
- 确认 so 库是否存在同名冲突或重复打包，多套加固同时携带 native 库时尤其要注意。
- 与各厂商确认已知的互相排斥清单，很多冲突是有公开说明的。
如果确认是两套保护方案互斥，通常的取舍是保留一套主方案，另一套降级或移除，而不是强行共存。
一套可复用的排查顺序
综合来看，可以按下面的顺序推进，避免一上来就怀疑加壳：
- 确认闪退阶段：启动即崩、进入首页后崩、还是特定功能触发。
- 看机型与系统分布，判断是否为环境兼容问题。
- 看崩溃堆栈落在壳代码、框架代码还是业务代码。
- 做加固前后的对照包，缩小变量范围。
- 检查反射与动态加载点，核对保留规则。
- 排查第三方组件冲突与初始化顺序。
加固只是整个交付链路中的一环，闪退排查同样需要放在完整链路里看。关于加固各环节分别解决什么问题，可以参考站内对 加固服务范围 的说明，先明确目标再选方案，能减少很多无效试错。
给运营与发布的建议
加固后的包不要直接全量。建议先小流量灰度，按机型、系统版本、渠道分组观察崩溃率，确认稳定后再放量。同时保留加固前的对照包，出问题时能快速判断是加固引入还是版本本身的问题。发布流程上的配套动作，也可以在 服务说明 中找到对应的验证建议。
把闪退当成兼容性问题来查，而不是当成加固产品的质量问题来吵，通常能更快找到真正的原因。