## 问题

Binder 死亡通知不是泛泛的稳定性口号，它通常出现在发布前最后一轮回归：开发机表现正常，灰度用户却开始暴露边界路径。这里先把入口缩小到一个可记录的动作、一个可复现的日志点和一个可回滚的开关，避免团队在无关模块里绕圈。处理这类问题时，我会先记录设备、系统版本、触发按钮和失败时间，再把业务日志、系统命令、最小样例放在同一个目录，后面判断是否修住就不靠感觉。

## 方案

方案按三步落地。第一步加观测，只记录必要字段，不改业务语义；第二步加隔离，把高风险路径收敛到单独函数；第三步加回归命令，让 CI 或值班同学能复跑。Binder 死亡通知的关键是别一次改太大，先让失败能稳定出现，再把修复点压到最小。上线前保留开关，出现异常时可以退回旧链路，同时保留新链路日志用于复盘。

adb shell getprop ro.build.version.release
adb logcat -c
adb logcat -v time | grep -i "yuandaima"

## 示例代码

下面的片段只保留核心边界，方便复制到 demo 或临时验证工程。命名故意和业务隔离，避免误把排障代码揉进正式模型。

val recipient = IBinder.DeathRecipient {
    Log.w("Svc", "binder died, schedule reconnect")
}
remote.asBinder().linkToDeath(recipient, 0)

data class YuandaimaProbe(
    val device: String,
    val stage: String,
    val costMs: Long,
    val success: Boolean
)

fun recordYuandaimaProbe(stage: String, success: Boolean) {
    val item = YuandaimaProbe(Build.MODEL, stage, SystemClock.elapsedRealtime(), success)
    Log.i("yuandaima", item.toString())
}

## 注意点

不要把样本不足当成已经稳定，也不要只在旗舰机上验证。Binder 死亡通知至少要覆盖冷启动、后台恢复、弱网或低电量其中两个场景。日志字段不要带用户隐私，只保留状态码、耗时、开关名和版本号。若修复涉及缓存，先验证清缓存和不清缓存两条路径；若涉及系统能力，先确认权限、厂商差异和 targetSdk 行为是否一致。

## 报错与排查

常见报错先分三类：入口没有触发、触发后状态丢失、修复后回归不稳定。每类都要有独立证据，不要用一条成功日志覆盖所有路径。

adb shell pm clear com.example.app
adb shell am force-stop com.example.app
adb shell monkey -p com.example.app 1

fun assertYuandaimaState(name: String, ok: Boolean) {
    require(ok) { "$name failed in Binder 死亡通知" }
}

如果线上只在少量机型出现，先拉出系统版本、厂商、App 版本三列，不要马上扩大改动面。能用远程开关压住就先压住，再补自动化用例。

## 可运行片段

把下面代码放进任意调试入口即可跑一遍，输出包含开始、执行和校验三个阶段。它不依赖业务服务，适合确认Binder 死亡通知的排查框架是否齐全。

fun runYuandaimaDemo() {
    recordYuandaimaProbe("start", true)
    val enabled = true
    assertYuandaimaState("switch", enabled)
    recordYuandaimaProbe("finish", enabled)
}