字节码 try-catch 插桩治理第三方 Crash：用 hookPoint 精准止血
客户端 crash 治理通常优先从源码修复开始。自己写的代码可以加判空、改线程、调整生命周期；开源库可以升级版本或提交补丁；系统 API 可以按版本分支处理。但现实中总会遇到更棘手的情况：第三方 SDK 没有源码，问题只在少量机型出现，升级成本高，供应方响应慢，或者异常来自深层回调，短期内难以通过业务代码绕开。
如果这些 crash 影响面大，而异常本身又不属于必须让应用退出的严重错误，字节码 try-catch 插桩就是一种止血方案。它不需要修改第三方源码，可以集中治理多个风险点。但缺点是侵入编译链路，错误插桩可能改变方法语义，甚至引入新的稳定性问题。所以它必须被当作”受控治理工具”，而不是通用异常吞噬器。
为什么 hookPoint 配置是核心
在实际项目中，字节码防护配置放在统一的 App 配置里，而不是分散在各个页面。通过 tryCatchExtension 配置全局异常处理器和 hookPoint 列表，hookPoint 精确到”类 + 方法”。这比全局 try-catch 更克制：只保护已知高风险点，例如某些调试入口点击、WorkManager 内部 runnable、第三方弹窗销毁、ViewPager2 滚动适配等。
这个设计的价值有两点。第一，App 同时接入了多个第三方 SDK、动态模块、WorkManager、弹窗组件和复杂 UI 容器，某些 crash 发生在库内部，业务侧没法直接包住。第二，项目有多 App 壳和多构建类型，如果把防护写到业务代码里，容易漏掉某个壳；放到统一配置可以作用于所有宿主。
还有一个重要边界：不是所有方法都能插桩。比如 suspend 函数，协程状态机和字节码校验更复杂，盲目注入可能引发 VerifyError。插桩是止血工具，不是把异常吞掉的万能方案，hookPoint 越精确，副作用越可控。
配置驱动的插桩模型
每个 hookPoint 描述一个风险点，包含目标类、方法、描述符、插桩模式、捕获异常类型、返回策略和版本范围：
hookPoints:
- id: "third_party_render_guard"
enabled: true
owner: "com.example.thirdparty.RenderEngine"
methodName: "render"
descriptor: "(Landroid/view/View;Ljava/lang/Object;)Z"
mode: "METHOD"
catchTypes:
- "java.lang.Exception"
returnStrategy:
type: "CONST_BOOLEAN"
value: false
versionRange:
min: "1.0.0"
max: "2.5.0"
note: "Guard known non-fatal render exception on specific library versions."
- id: "third_party_callback_guard"
enabled: true
owner: "com.example.thirdparty.CallbackBridge"
methodName: "dispatch"
descriptor: "(Ljava/lang/String;)V"
mode: "INVOKE_AROUND"
targetInvoke:
owner: "com.example.thirdparty.NativeAdapter"
methodName: "notify"
descriptor: "(Ljava/lang/String;)V"
catchTypes:
- "java.lang.RuntimeException"
returnStrategy:
type: "RETURN_VOID"三种插桩模式各有适用场景。方法级插桩在方法入口到正常返回之间增加 try-catch，适合短小且副作用可控的方法。调用点插桩在某个 invoke 指令前后包裹保护，适合第三方方法内部某个已知风险调用。指令范围插桩通过标记起止点控制，适合高级场景但配置复杂度更高。
字节码改写与运行时保护
字节码改写阶段需要维护异常表、局部变量、操作数栈和 stack map frame。捕获逻辑把异常传给 GuardRuntime，再根据返回策略生成默认值。对于 void 方法，可以捕获后直接 return；对于对象返回，可以返回 null 或 fallback 对象；对于基本类型，需要返回 0、false 或配置指定值。构造方法和静态初始化方法要极其谨慎，一般不建议作为默认支持目标。
class TryCatchWeaver(private val matcher: HookPointMatcher) {
fun visitMethod(className: String, method: MethodNode): MethodNode {
val hook = matcher.match(className, method.name, method.descriptor)
?: return method
return when (hook.mode) {
HookMode.METHOD -> wrapWholeMethod(method, hook)
HookMode.INVOKE_AROUND -> wrapTargetInvoke(method, hook)
HookMode.RANGE -> wrapConfiguredRange(method, hook)
}
}
private fun wrapWholeMethod(method: MethodNode, hook: HookPoint): MethodNode {
val start = LabelNode()
val end = LabelNode()
val handler = LabelNode()
method.instructions.insert(start)
method.instructions.add(end)
method.tryCatchBlocks.add(
TryCatchBlockNode(start, end, handler, hook.catchTypes.first())
)
method.instructions.add(handler)
method.instructions.add(callGuardRuntime(hook.id))
method.instructions.add(buildReturnInstruction(hook.returnStrategy))
return method.withRecomputedFrames()
}
}运行时保护逻辑要保持简单，不要在异常路径里做复杂业务：
object GuardRuntime {
fun onCaught(hookPointId: String, error: Throwable) {
if (FatalErrorPolicy.shouldRethrow(error)) {
throw error // OutOfMemoryError 等严重错误不放行
}
CrashGuardReporter.report(
hookPointId = hookPointId,
errorType = error::class.java.name,
messageHash = error.message.safeHash(),
sampleRate = 0.1
)
}
}控制边界比能力更重要
捕获范围要保守。默认不要捕获 Throwable。严重虚拟机错误、内存错误、线程终止信号不应该被吞。对于业务必须感知的异常，也应重新抛出或转成明确错误，而不是静默返回默认值。
返回默认值要谨慎。返回 false、0、null 或空集合看似安全，但可能改变上层逻辑。如果返回值会影响交易、权限、安全判断或数据写入，通常不适合用简单默认值降级。
hookPoint 配置必须经过评审。评审重点包括：目标方法是否精确，异常是否非致命，返回策略是否合理，是否有观测指标，是否有下线计划。没有说明和负责人信息的配置，后续很容易变成无人敢删的历史包袱。
要设置过期机制。每个 hookPoint 都应该有复盘日期。若第三方库升级后问题消失，应删除配置；若异常持续高发，应推动根因修复；若插桩带来副作用，应快速关闭。插桩治理的目标是争取修复时间，不是永久掩盖问题。
字节码 try-catch 插桩是一把锋利但需要节制使用的工具。它能在源码不可控、第三方响应慢、线上 crash 影响明显时提供止血能力，但也可能改变程序语义。hookPoint 配置的价值，就是把这种能力关进一个可审查、可回滚、可观测的边界里。成熟的插桩治理不追求”所有异常都不崩”，而追求”已知非致命风险可降级，未知严重问题不掩盖”。最终，第三方 crash 的根治仍然应回到升级、替换、正确调用和推动供应方修复。字节码插桩负责在这之前保护用户体验和业务连续性。