鸿蒙应用频繁被系统查杀？从 LastExitReason 到内存水位线的完整排查实录

前阵子收到一批用户反馈：App 切到后台再回来，经常被“重启”——不是崩溃，而是整个进程没了，用户看到的是一张冷启动白屏。查崩溃平台没有任何 crash 记录，说明不是代码异常，而是系统主动把进程杀掉了。这个问题在鸿蒙上尤其需要重视，因为系统的资源管控比 Android 激进得多，后台进程被查杀不一定是因为你的代码有 bug，也可能只是内存水位越过了系统划定的线。

一、先搞清楚：是谁杀了你的进程，为什么杀

鸿蒙提供了两种感知查杀原因的途径：一是 UIAbility 的 onCreate 回调参数中的 LastExitReason，二是通过 HiAppEvent 订阅 APP_KILLED 事件。前者在应用重新拉起时告诉你“上一次是怎么没的”，后者可以在事件发生时实时拿到更细的 reason 和前后台状态。

我们接入 APP_KILLED 后发现，大部分被查杀的 reason 是 LowMemoryKill——整机低内存触发的按优先级从低到高查杀，应用自身并没有异常，只是“恰好排在前面”。另一部分则是 ResourceLeak(IonLeak) 和 ResourceLeak(GpuLeak)，指向图片或 PixelMap 泄漏导致的特定内存类型超标。两类问题的处理思路完全不同：前者要降低应用的内存水位，后者要找到泄漏点。

二、降低水位：不是“少用内存”，而是“让系统看得见你的释放”

LowMemoryKill 的判定依据不是“你占了多少”，而是“整机还剩多少”。所以优化方向不是抠抠搜搜地少分配，而是确保该释放的内存在系统需要的时候真的被释放了。

我们做了三件事：

1. 页面退出时主动释放大对象，而不是等 GC。 ArkTS 的 GC 是分代回收，页面退出后如果不主动断开引用，大图、长列表的数据源可能在下一次 GC 之前一直挂着。在 aboutToDisappear 里显式把 @State 中的大数组置空、把 PixelMap 调 release()，能显著缩短内存高水位持续时间。

2. 大图加载必须走缩略图，并且用 autoResize。 很多 OOM 和 GpuLeak 的根源是 Image 组件加载了远超显示尺寸的原图。服务端返回的图片 URL 加上尺寸参数，ArkUI 侧配合 autoResize 让渲染管线按实际控件大小解码，内存占用能降一个数量级。

3. 监听 onMemoryLevel，在系统压力升高时主动降级。 系统在内存紧张时会回调 onMemoryLevel，此时应该立即清空图片缓存、释放非必要的 native 缓冲区，而不是继续持有等系统来杀。

typescript
onMemoryLevel(level: abilityConstant.MemoryLevel) {
  if (level >= abilityConstant.MemoryLevel.MEMORY_LEVEL_CRITICAL) {
    imageCache.clearAll();
    releaseNonEssentialBuffers();
  }
}
三、抓泄漏：Snapshot 对比 + Native 引用排查

对于 IonLeak / GpuLeak 这类问题，LowMemoryKill 的降水位手段无效，必须找到泄漏对象。用 DevEco Profiler 的 Snapshot 在“进入页面 → 反复操作 → 退出页面”前后抓两次堆快照，对比创建后一直未释放的对象实例。如果某个 ArkTS 对象的 Distance 为 1（直接由 GC Root 持有），通常意味着它被 native 侧通过 napi_ref 强引用了，ArkTS 侧的 GC 无法回收。我们最终定位到一个图片处理回调在 native 层持有 PixelMap 的 napi_ref，异步回调结束后没有调用 napi_delete_reference，导致每次进出页面都泄漏一张全尺寸位图。

四、总结

鸿蒙上的“被查杀”问题，第一步永远是读 LastExitReason 和 APP_KILLED 的 reason，区分“被整机低内存连带”和“自身泄漏超标”。前者靠降水位和主动释放，后者靠 Snapshot 对比抓 native 引用。把这两条线分开处理，查杀率从日均数十次降到了个位数。