菜谱图库切后台后内存不降:HarmonyOS 7 appMemoryOptimizer 文件页回收实战
菜谱图库切后台后内存不降:HarmonyOS 7 appMemoryOptimizer 文件页回收实战
用户浏览过几十张菜谱大图后切到后台,进程内存长期不回落;再次进入时又偶发首屏抖动。直接清空所有缓存虽然能降内存,却让缩略图和索引全部重建,造成另一种卡顿。
本文交付:一个按资源热度决策的 MemoryEvictionPlan、图库与编辑器两个案例、回收前后采样字段,以及不可用时的降级路径。。
两种行为不同的案例
案例一:只读菜谱图库
原图文件页可按最近访问时间分批回收,缩略图索引保留;返回前台后按可见区重建。
案例二:图片裁剪编辑器
编辑中的临时文件不能回收;模块离开且草稿已持久化后,才允许回收整个编辑模块的文件页。
官方依据与版本边界
官方变更页:https://developer.huawei.com/consumer/cn/doc/doccenter-release-notes/js-apidiff-abilitykit-7003
- appMemoryOptimizer 在 API 26 提供文件页回收能力。
- evictFilePages 面向指定文件页。
- evictModuleFilePages 面向模块文件页。
- 回收动作需要结合前后台状态与可重建成本。
本文依据 HarmonyOS 7.0.0 Release(API 26)官方变更说明梳理接口,并对状态模型、分支选择和异常映射做了宿主侧 TypeScript 测试。当前本机 SDK 为 API 24,且没有连接 HDC 设备,因此不把示例描述为 API 26 编译通过、真机性能数据或上架审核结论。接入前请在 API 26 工程中按文末清单完成编译、设备与回归验证。
可复用的 ArkTS 集成片段
type FilePage = { path: string; bytes: number; lastVisibleAt: number; dirty: boolean }
+type EvictDecision = { files: string[]; keep: string[]; reason: string }
+
+export function planEviction(pages: FilePage[], now: number): EvictDecision {
+ const files: string[] = []
+ const keep: string[] = []
+ for (const page of pages) {
+ const cold = now - page.lastVisibleAt > 120_000
+ if (!page.dirty && cold && page.bytes > 256 * 1024) files.push(page.path)
+ else keep.push(page.path)
+ }
+ return { files, keep, reason: 'background-cold-clean-file-pages' }
+}
+
+async function applyPlan(plan: EvictDecision) {
+ for (const path of plan.files) {
+ await appMemoryOptimizer.evictFilePages(path)
+ }
+}
代码刻意把平台调用和业务状态分开:平台返回什么就记录什么,页面只消费稳定状态。接入时还应补齐项目的日志域、错误码类型和生命周期释放。

图中的每条箭头都应对应一条可查询日志:输入、平台调用、状态映射、UI 或降级结果。只有 UI 变化而没有中间证据,后续仍然难以区分接口失败和页面逻辑错误。
复现与验证
- 固定浏览 30 张相同尺寸图片并记录资源路径。
- 进入后台前记录 PSS、文件页候选数和脏数据数。
- 只回收 cold 且 clean 的文件页。
- 返回前台记录可见区重建耗时和失败资源。
- 对照“全部清空”和“不回收”两组结果。
| 输入/场景 | 预期分支 | 验收信号 |
|---|---|---|
| 可见缩略图 | keep | 避免首屏重建 |
| 冷原图 | evictFilePages | 按路径回收 |
| 未保存裁剪图 | keep | 禁止丢编辑态 |
| 编辑模块已离开 | evictModuleFilePages | 模块级回收 |
| API 不可用 | LRU 限额 | 保持兼容 |
| 回收失败 | 记录路径与码 | 不影响前台 |
取舍与落地清单
文件页回收不是“越多越好”。真正要平衡的是回收收益、重建成本和数据可恢复性。本文的阈值只是决策输入,项目应根据图片尺寸、前台恢复时间和设备档位重新标定。
- 已用 API 26 工程编译,并记录 SDK 与设备版本
- 已覆盖“只读菜谱图库”和“图片裁剪编辑器”两类行为
- 已记录成功、失败、降级三条路径的输入与结果
- 已核对监听、对象或任务的释放与幂等行为
- 已把本文宿主测试替换为项目自己的真机证据
小结
一个按资源热度决策的 MemoryEvictionPlan、图库与编辑器两个案例、回收前后采样字段,以及不可用时的降级路径。。建议先在最小页面复现,再接入完整“中式美食”流程;先证明状态链正确,再谈动画、缓存或埋点优化。
更多推荐


所有评论(0)