菜谱图库切后台后内存不降HarmonyOS 7 appMemoryOptimizer 文件页回收实战用户浏览过几十张菜谱大图后切到后台进程内存长期不回落再次进入时又偶发首屏抖动。直接清空所有缓存虽然能降内存却让缩略图和索引全部重建造成另一种卡顿。本文交付一个按资源热度决策的 MemoryEvictionPlan、图库与编辑器两个案例、回收前后采样字段以及不可用时的降级路径。。两种行为不同的案例案例一只读菜谱图库原图文件页可按最近访问时间分批回收缩略图索引保留返回前台后按可见区重建。案例二图片裁剪编辑器编辑中的临时文件不能回收模块离开且草稿已持久化后才允许回收整个编辑模块的文件页。官方依据与版本边界官方变更页https://developer.huawei.com/consumer/cn/doc/doccenter-release-notes/js-apidiff-abilitykit-7003appMemoryOptimizer 在 API 26 提供文件页回收能力。evictFilePages 面向指定文件页。evictModuleFilePages 面向模块文件页。回收动作需要结合前后台状态与可重建成本。本文依据 HarmonyOS 7.0.0 ReleaseAPI 26官方变更说明梳理接口并对状态模型、分支选择和异常映射做了宿主侧 TypeScript 测试。当前本机 SDK 为 API 24且没有连接 HDC 设备因此不把示例描述为 API 26 编译通过、真机性能数据或上架审核结论。接入前请在 API 26 工程中按文末清单完成编译、设备与回归验证。可复用的 ArkTS 集成片段typeFilePage{path:string;bytes:number;lastVisibleAt:number;dirty:boolean}typeEvictDecision{files:string[];keep:string[];reason:string}exportfunctionplanEviction(pages:FilePage[],now:number):EvictDecision{constfiles:string[][]constkeep:string[][]for(constpageofpages){constcoldnow-page.lastVisibleAt120_000if(!page.dirtycoldpage.bytes256*1024)files.push(page.path)elsekeep.push(page.path)}return{files,keep,reason:background-cold-clean-file-pages}}asyncfunctionapplyPlan(plan:EvictDecision){for(constpathofplan.files){awaitappMemoryOptimizer.evictFilePages(path)}}代码刻意把平台调用和业务状态分开平台返回什么就记录什么页面只消费稳定状态。接入时还应补齐项目的日志域、错误码类型和生命周期释放。图中的每条箭头都应对应一条可查询日志输入、平台调用、状态映射、UI 或降级结果。只有 UI 变化而没有中间证据后续仍然难以区分接口失败和页面逻辑错误。复现与验证固定浏览 30 张相同尺寸图片并记录资源路径。进入后台前记录 PSS、文件页候选数和脏数据数。只回收 cold 且 clean 的文件页。返回前台记录可见区重建耗时和失败资源。对照“全部清空”和“不回收”两组结果。输入/场景预期分支验收信号可见缩略图keep避免首屏重建冷原图evictFilePages按路径回收未保存裁剪图keep禁止丢编辑态编辑模块已离开evictModuleFilePages模块级回收API 不可用LRU 限额保持兼容回收失败记录路径与码不影响前台取舍与落地清单文件页回收不是“越多越好”。真正要平衡的是回收收益、重建成本和数据可恢复性。本文的阈值只是决策输入项目应根据图片尺寸、前台恢复时间和设备档位重新标定。已用 API 26 工程编译并记录 SDK 与设备版本已覆盖“只读菜谱图库”和“图片裁剪编辑器”两类行为已记录成功、失败、降级三条路径的输入与结果已核对监听、对象或任务的释放与幂等行为已把本文宿主测试替换为项目自己的真机证据小结一个按资源热度决策的 MemoryEvictionPlan、图库与编辑器两个案例、回收前后采样字段以及不可用时的降级路径。。建议先在最小页面复现再接入完整“中式美食”流程先证明状态链正确再谈动画、缓存或埋点优化。
