Harmony os 技术实战｜拼豆制图20：用 finally 关闭 ImageSource、PixelMap 与文件句柄

标签Harmony os、ArkTS、ImageKit、PixelMap、资源释放图片转换成功一次并不能证明资源管理正确。真正容易暴露问题的是连续操作用户从系统图库依次选择多张高分辨率照片前几次生成正常之后速度下降、内存峰值持续抬高甚至在某次解码时退出。页面看见的只是一条“图片解析失败”根因却可能是上一次 PixelMap 或文件句柄仍未释放。拼豆制图的图像入口同时处理三类需要明确收口的对象ImageSource负责解码PixelMap保存目标尺寸像素URI 直读失败时还会打开一个只读文件句柄作为回退。任何一步都可能抛错因此释放不能只写在成功路径末尾。当前服务用一个try/finally包围“创建图源 → 解码 70×70 → 读取 RGBA 缓冲区 → 生成普通格子”并按依赖逆序释放 PixelMap、ImageSource、File。本文把这条资源作用域写完整。本文重点解决系统选择器 URI 为什么优先直接交给createImageSource。何时回退到fileIo.openSync与文件描述符解码。如何在解码阶段把原图约束到 70×70、RGBA_8888。为什么缓冲区必须在资源释放前完整读取。finally如何覆盖创建失败、解码失败、读取失败和算法失败。为什么释放顺序应与创建依赖相反。如何保证页面最终只收到普通 Pattern不长期持有系统图像对象。先画出对象的创建与依赖顺序一次图片转换的资源关系为URI ├─ 直接创建 ImageSource └─ 失败时打开 File(fd) → 创建 ImageSource ↓ 创建 PixelMap ↓ 读取 ArrayBuffer ↓ 生成 BeadCell[]三个系统资源有不同所有者对象创建位置使用结束点释放方式fileIo.FileURI 直读失败后的回退分支ImageSource 不再需要 fdfileIo.closeSync(fd)image.ImageSourceURI 或 fdPixelMap 与读取流程结束release()image.PixelMap目标尺寸解码像素已读入 ArrayBufferrelease()ArrayBuffer 和BeadCell[]是普通数据不需要跟随上述系统对象长期存在。资源边界的目标就是尽快把系统对象转换成普通业务数据然后立即释放原生资源。URI 优先直接交给 ImageSource系统选择器返回的 URI 不一定等同于普通磁盘路径。当前服务先尝试直接创建图源letimageSource:image.ImageSource|undefinedundefined;try{imageSourceimage.createImageSource(uri);}catch(error){imageSourceundefined;}这一步不对 URI 做字符串裁剪也不擅自移除协议前缀。ImageKit 负责解释它支持的输入形式业务层只保留原始选择结果。局部catch的职责非常窄直读失败不立即结束整个转换而是允许进入文件描述符回退。它不在这里拼接最终用户文案也不把失败伪装成成功。文件描述符只作为明确回退分支当 URI 直读没有得到 ImageSource服务尝试只读打开letimageFile:fileIo.File|undefinedundefined;if(imageSourceundefined){imageFilefileIo.openSync(uri,fileIo.OpenMode.READ_ONLY);imageSourceimage.createImageSource(imageFile.fd);}这里创建了新的资源责任只要openSync成功最终就必须关闭 fd无论后续createImageSource、createPixelMap还是readPixelsToBuffer在哪里失败。文件对象不能被塞进 Pattern 或页面状态。它只服务于本次解码作用域离开方法后不再有合法用途。三个变量都从 undefined 开始记录所有权完整方法在进入try前声明letimageSource:image.ImageSource|undefinedundefined;letpixelMap:image.PixelMap|undefinedundefined;letimageFile:fileIo.File|undefinedundefined;这不是多余的防御代码。它让finally能判断每个对象是否真正创建成功URI 直读失败时imageSource仍为 undefined。openSync抛错时imageFile仍可能没有值。createPixelMap失败时pixelMap不存在但 ImageSource 仍需释放。若变量只在成功分支的局部块内声明finally无法访问它们若假设三个对象一定存在清理代码本身又会在失败路径抛错。解码时把像素规模限制在 70×70图纸目标固定为 70×70因此没有必要让算法长期持有原图分辨率的 PixelMappixelMapawaitimageSource.createPixelMap({desiredSize:{width:size,height:size},desiredPixelFormat:image.PixelMapFormat.RGBA_8888});desiredSize把缩放放在解码边界desiredPixelFormat让后续通道解释明确。理论上的目标缓冲区为70 × 70 × 4 19600 bytes这不等于原始图片在解码过程中没有任何内存成本但它保证交给纯算法的 PixelMap 与 ArrayBuffer按施工目标受控而不是随相册照片尺寸无限增长。创建结果仍要做空值保护当前代码在解码后保留保护分支if(pixelMapundefined){thrownewError(无法解码图片像素);}同样回退后仍确认图源存在if(imageSourceundefined){thrownewError(无法创建图片源);}这些错误发生在服务边界页面不应该继续使用上一次图纸冒充本次生成结果。外层转换函数会把失败包装为“图片解析失败”而已有图纸与选中状态由页面状态机决定是否保留。资源释放与业务恢复是两件事finally确保系统对象收口页面的错误分支确保用户可以重试二者缺一不可。缓冲区长度从 PixelMap 读取PixelMap 创建成功后服务获取真实字节数constpixelBytespixelMap.getPixelBytesNumber();constbuffernewArrayBuffer(pixelBytes);awaitpixelMap.readPixelsToBuffer(buffer);不要只用size * size * 4猜测分配长度再假设系统对象完全符合预期。getPixelBytesNumber()是当前 PixelMap 对自身数据量的说明。进入纯函数前仍可校验constrequiredBytessize*size*4;if(buffer.byteLengthrequiredBytes){thrownewError(RGBA 像素缓冲区长度不足);}读取完成后ArrayBuffer 已经拥有算法所需字节PixelMap 不需要再被页面或 Pattern 持有。纯算法只接收 ArrayBuffer资源层与算法层的交接点为returnImageConvertService.createCellsFromBuffer(buffer,size,size);后续函数只操作普通字节privatestaticcreateCellsFromBuffer(buffer:ArrayBuffer,width:number,height:number):BeadCell[]{constpixelsnewUint8Array(buffer);constresult:BeadCell[][];// RGBA → 空格或实体色号returnresult;}这种边界有三个收益颜色算法可以用人工缓冲区单独测试。PixelMap 的释放不受页面生命周期影响。Pattern 只包含普通数组、字符串和数字便于缓存与导出。不要为了在详情页显示原图而把 PixelMap 加进 Pattern。若确实需要原图预览应建立独立、可释放的媒体展示流程。finally 覆盖所有中途失败位置当前作用域结构为try{// 1. 创建 ImageSource// 2. 必要时打开 File// 3. 创建 PixelMap// 4. 读取 ArrayBuffer// 5. 生成 BeadCell[]returncells;}finally{if(pixelMap!undefined){awaitpixelMap.release();}if(imageSource!undefined){awaitimageSource.release();}if(imageFile!undefined){fileIo.closeSync(imageFile.fd);}}无论return cells正常执行还是任一步抛错finally都会运行。它覆盖的不只是系统 API 失败还包括createCellsFromBuffer内的算法异常。把释放代码复制到多个catch分支很容易新增一个失败出口却忘记同步统一 finally 才能让资源作用域闭合。释放顺序与创建依赖相反创建顺序通常是File → ImageSource → PixelMap释放顺序则是PixelMap → ImageSource → FilePixelMap 由 ImageSource 解码得到ImageSource 在回退路径中又依赖文件描述符。先释放最下游对象再关闭它的上游来源能避免仍在使用的对象失去依赖。这与嵌套作用域的退出顺序一致最后创建的资源最先离开。即使某条路径没有 Fileundefined 判断也会自然跳过。释放调用需要await的对象应等待完成后再进入下一步不能把 promise 留到函数已经返回后再由未知上下文处理。回退分支失败也必须关闭已经打开的 File最容易漏掉的场景是URI 直读失败 → openSync 成功 → createImageSource(fd) 抛错此时 PixelMap 与 ImageSource 都没有成功File 却已经打开。因为imageFile在外层变量中保存finally仍能关闭if(imageFile!undefined){fileIo.closeSync(imageFile.fd);}若把closeSync只写在 PixelMap 读取成功之后这条失败路径会泄漏句柄。资源校验必须逐个阶段制造异常而不是只反复跑成功图片。同理PixelMap 创建成功、缓冲区读取失败时PixelMap 与 ImageSource 仍会按顺序释放。错误包装不能吞掉真正阶段外层转换函数目前统一补充业务上下文staticasyncconvertFromPickedImage(uri:string,source:Pattern):PromiseImageConvertResult{try{constchartCellsawaitcreateCellsFromImage(uri,70);// 生成预览、统计与 Patternreturnresult;}catch(error){consterrerrorasError;thrownewError(图片解析失败${err.message});}}页面得到的是可理解的业务阶段内部错误仍保留在 message 中。更细化时可以把失败分成SOURCE_OPEN_FAILED、PIXELMAP_DECODE_FAILED、PIXEL_READ_FAILED和CELL_BUILD_FAILED但不要通过字符串包含关系反推类型。无论如何分类资源释放必须在内部 finally 先完成再把错误交给上层。页面只负责状态与重试动作不应该尝试释放 ImageSource。Pattern 不保存 URI、PixelMap 或文件对象成功结果只包含普通业务字段return{pattern:{id:user-generated-${Date.now()},title:我的图片图纸,width:70,height:70,previewCells,chartCells,colorStats,beadCount,colorCount},usedFallback:false,message:已根据图片生成 70 x 70 编号图纸};Pattern 可以在页面、收藏和生成记录之间传递不会延长系统图像对象的生命周期。URI 只在用户重新选择或展示来源时才需要当前图纸施工本身不依赖它。纯业务模型也让失败恢复更容易本次解码失败时页面可以保留上一张 Pattern因为它不依赖已经关闭的 PixelMap。连续转换要观察趋势而不是单次峰值资源回归建议固定执行连续选择并转换 10 张不同图片。在第 3、6、9 次穿插一次取消选择。加入一张无法解码或内容异常的文件。每次完成后立即打开编号图再返回创建页。记录成功次数、失败阶段、耗时趋势与内存趋势。单次转换出现峰值并不自动表示泄漏。真正值得关注的是完成并释放后基线是否随着次数持续抬高以及失败路径后下一次转换是否明显更慢。当前文章没有用未经执行的数字宣称内存改善。实际结论应来自目标设备或模拟环境中的连续操作记录并区分系统缓存、瞬时峰值和无法回落的增长。用故障注入覆盖四个释放阶段建议建立下表故障点已创建对象finally 应执行URI 直读失败、回退打开也失败无或部分 File关闭已成功的 Filefd 创建 ImageSource 失败File关闭 FilecreatePixelMap失败ImageSource、可选 File释放 ImageSource关闭 FilereadPixelsToBuffer失败PixelMap、ImageSource、可选 File三者逆序释放格子算法失败PixelMap、ImageSource、可选 File三者逆序释放全部成功三者按路径存在返回前全部释放纯构建无法证明这些运行时路径。可以通过替换测试输入、注入可控错误或封装资源工厂来观察释放计数至少要保证下一次转换仍能立即执行。ArkTS 层的目标不是捕获所有底层内存细节而是让每个创建动作都有唯一、可读的关闭位置。常见资源故障沿所有权定位现象先看哪里常见根因修复方向第二次转换明显更慢上一次 finallyPixelMap 或 ImageSource 未释放统一闭合资源作用域URI 能选中却无法打开直读与 fd 回退把 URI 当普通路径裁剪原值直读失败再回退多次失败后文件打不开File 关闭路径fd 创建图源失败时漏关外层保存 File 并 finally 关闭PixelMap 读取后仍被页面持有Pattern 字段系统对象跨层传递只返回 ArrayBuffer 派生数据缓冲区尾部异常字节数来源手工分配长度不匹配使用getPixelBytesNumber大图转换峰值过高解码目标尺寸先完整解码再缩放在 createPixelMap 指定 70×70失败日志只写“生成失败”错误边界阶段被过度吞并保留 source/decode/read/build 上下文释放后仍访问对象调用层职责页面保存了 imageSource 引用系统对象限制在服务方法内排查时为每个对象回答三个问题在哪里创建、谁拥有、在哪个 finally 关闭。无法回答其中一个就说明生命周期边界仍然模糊。小结稳定的图片转换不是“成功后调用一次 release”而是让所有路径都处于同一个资源作用域。拼豆制图先用 URI 创建 ImageSource必要时打开 File 并通过 fd 回退随后按 70×70、RGBA_8888 解码 PixelMap把像素读入 ArrayBuffer再交给纯函数生成 4900 个普通格子。finally无论成功、解码失败、读取失败还是算法失败都会执行并按 PixelMap → ImageSource → File 的逆序释放。页面最终只收到 Pattern不持有原生图像对象。只有把这种所有权写清连续选图、取消、失败重试和多次生成才不会把上一次资源带进下一次操作。