鸿蒙ASCF内存告警监听实战：onMemoryWarning防杀进程指南

鸿蒙专家

线上App被系统静默回收，是很多鸿蒙应用开发者都遇到过的头疼问题。上周我这边就出了一次线上事故：用户反馈应用在连续打开多个页面、加载大量图片后直接被系统杀掉，没有任何提示。排查发现是内存占用超过阈值，被鸿蒙系统的后台管控机制回收了进程。对比iOS和Android，鸿蒙对应用内存的约束更严格，一旦超过阈值就会直接回收，几乎没有商量余地。

后来通过has.onMemoryWarning这个API解决了大部分问题。它能在系统内存紧张时提前通知应用，让开发者有机会在进程被杀之前主动清理资源，降低被回收的概率。

为什么需要内存告警监听

应用在前台运行时，系统通常不会轻易下手。但内存占用过高时，系统依然会强制执行回收策略。尤其是鸿蒙面向多设备形态，从手机到平板、智慧屏，低端设备的内存往往只有2GB到4GB，留给应用的配额非常有限。

常见的做法是在onShow/onHide里手动管理资源，但这个方案存在一个根本问题：开发者无法感知系统当前的内存水位，也不知道系统什么时候会认为应用占用过高。onMemoryWarning提供的是一个系统级的提前量，相当于考试交卷前监考老师提醒"还有5分钟"，还有机会检查一遍答卷；如果老师直接抢卷子，那就什么都来不及了。

API接口说明

has.onMemoryWarning的使用非常简洁，核心方法就两个：注册监听和移除监听。

2. // 注册内存告警监听
3. has.onMemoryWarning(function(res) {
4.     console.info('内存告警等级:', res.level);
5. });

复制代码

res.level是内存告警的严重程度等级，当前系统定义了三个档位：5表示内存适中（系统开始关注）、10表示内存较低（需要认真清理）、15表示内存极低（系统即将回收）。注意这些level值不是连续的递增序列，中间存在间隔。

2. // 移除所有内存告警监听
3. has.offMemoryWarning();
5. // 移除指定的监听回调
6. function myCallback(res) {
7.     console.info('内存告警:', res.level);
8. }
9. has.onMemoryWarning(myCallback);
10. has.offMemoryWarning(myCallback);

复制代码

offMemoryWarning的callback参数是可选参数。不传参数时移除全部监听，传入指定函数则只移除对应的回调。

基础监听实现

一个最小的监听实现，在收到告警时记录等级并输出日志：

2. Page({
3.     data: {
4.         warningLevel: 0,
5.         warningCount: 0,
6.     },
7.     onReady() {
8.         this.startMemoryMonitor();
9.     },
10.     onUnload() {
11.         // 页面销毁时移除监听
12.         has.offMemoryWarning();
13.     },
14.     startMemoryMonitor() {
15.         const that = this;
16.         has.onMemoryWarning(function(res) {
17.             that.setData({
18.                 warningLevel: res.level,
19.                 warningCount: that.data.warningCount + 1,
20.             });
21.             that.handleMemoryWarning(res.level);
22.         });
23.     },
24.     handleMemoryWarning(level) {
25.         if (level >= 15) {
26.             console.error('内存极度紧张，立刻释放资源');
27.             this.releaseAllCache();
28.         } else if (level >= 10) {
29.             console.warn('内存较低，释放非必要资源');
30.             this.releaseNonEssentialCache();
31.         } else {
32.             console.info('内存适中，清理部分缓存');
33.             this.releasePartialCache();
34.         }
35.     },
36.     releaseAllCache() {
37.         // 清空所有图片缓存、数据缓存
38.     },
39.     releaseNonEssentialCache() {
40.         // 清空图片缓存，保留数据缓存
41.     },
42.     releasePartialCache() {
43.         // 清空最近最少使用的缓存
44.     },
45. });

复制代码

整体结构是监听回调 -> 根据level分级处理 -> 执行对应的清理策略。

分级清理策略

收到告警后怎么处理，这才是内存管理的核心。如果把所有缓存一股脑全部清掉，会直接影响用户体验：用户正在浏览的图片突然丢失、正在编辑的表单数据被清空。比较合理的做法是分三档递进清理。

level 5是内存适中的阶段，系统已经开始关注应用。这时清理一些不重要的缓存即可：

2. if (level === 5) {
3.     // 清理过期的请求缓存
4.     this.clearExpiredRequestCache();
5.     // 清理超出数量限制的图片缓存，保留最近50张
6.     this.trimImageCache(50);
7. }

复制代码

level 10是内存紧张阶段，需要认真清理较大的缓存对象：

2. if (level === 10) {
3.     // 先做基础清理
4.     this.clearExpiredRequestCache();
5.     this.trimImageCache(20); // 只保留20张
6.     // 释放大数据缓存
7.     this.clearLargeDataCache();
8.     // 建议GC
9.     this.suggestGC();
10. }

复制代码

level 15是内存极低阶段，系统随时可能回收进程，能清的全清：

2. if (level === 15) {
3.     // 清空所有缓存
4.     this.clearAllCache();
5.     // 关闭非活跃的页面栈
6.     this.closeInactivePages();
7.     // 强烈建议GC
8.     this.suggestGC();
9. }

复制代码

这里要重点强调的是：level 15时系统可能已经准备动手了，清理操作不一定来得及执行完。关键资源的释放应该在level 10时就开始，而不是等到最后一刻。

与生命周期配合使用

内存告警监听与页面生命周期配合，推荐在onReady中注册、在onUnload中移除：

2. Page({
3.     onReady() {
4.         const that = this;
5.         has.onMemoryWarning(function(res) {
6.             that.handleWarning(res.level);
7.         });
8.     },
9.     onUnload() {
10.         has.offMemoryWarning();
11.     },
12.     handleWarning(level) {
13.         console.info('收到内存告警, level:', level);
14.     },
15. });

复制代码

一个容易踩的坑：如果应用有多个页面都注册了监听，每个页面都会收到告警回调，导致同一个告警被重复处理。解决办法是只在主页面注册一次，或者用全局标志位做控制：

2. let isMemoryWarningListening = false;
4. function setupMemoryWarning(callback) {
5.     if (isMemoryWarningListening) return;
6.     has.onMemoryWarning(callback);
7.     isMemoryWarningListening = true;
8. }
10. function removeMemoryWarning() {
11.     has.offMemoryWarning();
12.     isMemoryWarningListening = false;
13. }

复制代码

告警历史记录功能

把收到的内存告警记录下来，方便后期排查问题时回溯。每一轮告警记录下时间、level和对应的等级描述，并保留最近50条历史：

2. Page({
3.     data: {
4.         warningHistory: [],
5.         logList: [],
6.     },
7.     onReady() {
8.         this.addLog('内存告警监听已开启');
9.         const that = this;
10.         has.onMemoryWarning(function(res) {
11.             const levelText = that.getLevelText(res.level);
12.             const record = {
13.                 time: new Date().toLocaleTimeString(),
14.                 level: res.level,
15.                 levelText: levelText,
16.             };
17.             const history = that.data.warningHistory;
18.             history.unshift(record);
19.             if (history.length > 50) {
20.                 history.pop();
21.             }
22.             that.setData({ warningHistory: history });
23.             that.addLog('内存告警: ' + levelText + ' (level=' + res.level + ')');
24.         });
25.     },
26.     onUnload() {
27.         has.offMemoryWarning();
28.     },
29.     getLevelText(level) {
30.         if (level >= 15) return '极低';
31.         if (level >= 10) return '低';
32.         if (level >= 5) return '适中';
33.         return '未知(' + level + ')';
34.     },
35.     addLog(msg) {
36.         const time = new Date().toLocaleTimeString();
37.         const logList = this.data.logList;
38.         logList.unshift('[' + time + '] ' + msg);
39.         if (logList.length > 20) {
40.             logList.pop();
41.         }
42.         this.setData({ logList: logList });
43.     },
44.     clearLog() {
45.         this.setData({ logList: [], warningHistory: [] });
46.         this.addLog('日志已清空');
47.     },
48. });

复制代码

调试时的事件日志非常有价值。内存告警不像键盘高度变化那样有直观的视觉反馈，不记录日志几乎无法感知触发时机。

2. <view class="log-list" if="{{logList.length > 0}}">
3.     <text class="log-item" for="{{logList}}">{{$item}}</text>
4. </view>
5. <text class="log-empty" if="{{logList.length === 0}}">暂无日志</text>

复制代码

模拟告警的几种方式

开发阶段触发真实的内存告警并不容易，总不能在开发机上把内存撑爆。尝试过的模拟方式有：

2. // 制造内存压力
3. function simulateMemoryPressure() {
4.     let bigArray = [];
5.     for (let i = 0; i < 1000; i++) {
6.         bigArray.push(new Array(10000).fill('test'));
7.     }
8.     console.info('已分配大量内存，等待告警...');
9.     return bigArray; // 保持引用，防止被GC
10. }

复制代码

但这种方式的触发效果取决于设备总内存和当前空闲内存：在8GB设备上可能无论如何分配都触发不了，在2GB设备上很快就会出现告警。DevEco Studio的Profiler工具可以模拟内存压力，但需要连接真机或模拟器，纯代码层面不太好模拟。

另一种思路是在Demo中放一个"模拟告警"按钮，手动触发不同等级的告警逻辑，方便查看UI效果和验证清理策略是否符合预期。真实的系统告警只能在实际内存紧张时才能触发。

实际场景：图片列表页的内存管理

图片列表是内存消耗最大的场景之一。瀑布流页面随着用户不断下滑，图片越来越多，内存持续上升。接入onMemoryWarning后可做如下优化：

2. Page({
3.     data: {
4.         imageList: [],
5.         fullList: [],
6.         imageCache: {},
7.         cacheSize: 0,
8.     },
9.     onReady() {
10.         const that = this;
11.         has.onMemoryWarning(function(res) {
12.             if (res.level >= 10) {
13.                 // 内存紧张，只保留当前可见区域的图片缓存
14.                 that.trimCache();
15.             }
16.         });
17.     },
18.     onUnload() {
19.         has.offMemoryWarning();
20.         this.clearAllCache();
21.     },
22.     trimCache() {
23.         const cache = this.data.imageCache;
24.         const keys = Object.keys(cache);
25.         const keepCount = 20; // 只保留20条
26.         if (keys.length <= keepCount) return;
27.         // 按最后访问时间排序，删除最旧的
28.         keys.sort(function(a, b) {
29.             return cache[b].lastAccess - cache[a].lastAccess;
30.         });
31.         const toRemove = keys.slice(keepCount);
32.         for (let i = 0; i < toRemove.length; i++) {
33.             delete cache[toRemove[i]];
34.         }
35.         this.setData({
36.             imageCache: cache,
37.             cacheSize: keepCount,
38.         });
39.     },
40.     clearAllCache() {
41.         this.setData({ imageCache: {}, cacheSize: 0 });
42.     },
43. });

复制代码

核心思路是：收到level 10告警就开始缩减缓存，不要等到level 15。清理策略遵循LRU思路，保留最近使用的，删除最旧的。

几个容易踩的坑

告警回调里的this指向问题

function(res)形式的回调中，this并不会指向Page实例。直接写this.setData会导致页面无法更新，而且控制台不会报错。需要在外部先用const that = this保存引用：

2. // 错误写法
3. has.onMemoryWarning(function(res) {
4.     this.setData({ level: res.level }); // this不是Page实例
5. });
7. // 正确写法
8. const that = this;
9. has.onMemoryWarning(function(res) {
10.     that.setData({ level: res.level });
11. });

复制代码

清理操作本身也耗内存

清理过程中，遍历大缓存并逐条删除的操作本身就占用内存。在遍历过程中内存可能不降反升。一种更高效的方式是直接清空整个缓存对象：

2. // 低效：逐条删除
3. for (let key in cache) {
4.     delete cache[key];
5. }
7. // 高效：直接重置对象
8. this.setData({ cache: {} });

复制代码

level值不是连续整数

level的取值为5、10、15，中间有间隔。不要写类似if (level > 5 && level < 10)这样的区间判断——虽然当前文档只定义了三个等级，但系统可能传其他值。使用>=做边界判断更安全。

页面切换的监听残留

如果在页面A注册监听后没有在onUnload中移除，跳到页面B后页面A的回调依然生效。每次收到告警，页面A的回调都会执行，但此时页面A的上下文可能已经销毁，容易引发异常。注册和移除必须成对出现。

版本兼容性判断

has.onMemoryWarning的起始版本是1.0.16。如果应用需要兼容更早的系统版本，调用前需要先判断API是否存在：

2. if (has.onMemoryWarning) {
3.     has.onMemoryWarning(function(res) {
4.         // 处理告警
5.     });
6. } else {
7.     console.warn('当前版本不支持onMemoryWarning');
8. }

复制代码

后台任务场景的额外注意点

如果应用有后台任务（音乐播放、定位上报等），内存告警的处理需要更谨慎。后台任务被系统回收的影响远比前台页面大得多。之前做过一个带后台定位的应用，因为内存告警处理不当导致后台定位被杀，用户反馈"走到一半导航断了"，排查很久才发现是内存告警释放策略没有覆盖后台场景。

总结

onMemoryWarning这个API很小，只有两个方法，但背后的内存管理思路才是关键。收到告警后清理什么、什么时候清理、清理到什么程度，都需要根据实际业务形态确定。最重要的一点是：不要等到level 15才开始处理。level 5时做基础清理，level 10时做大清理，level 15时可能已经没有足够的时间执行复杂的清理逻辑了。