一、别把“想放大四倍”直接交给处理链

图像增强功能在示例界面里看起来很直观：用户从相册选图，点击二倍、三倍或四倍，再等处理结果。但是做工程预检时，最危险的情况往往不是按钮无响应，而是应用已经允许一个远超预期的目标尺寸进入解码与缓存队列。文件磁盘上可能只有几百 KB，真正解码后却要占用完整像素缓冲区；倍率再按宽高同时放大，像素量增长的是倍率的平方。

这次选一个更容易复核的问题：在真正调用任何超分算法之前，用 Node.js 给目标像素数和预估工作缓冲区设置项目预算，判定某次处理申请可以进入下一步还是需要拦截。本文为预算值定义一个项目边界，不假定某设备固定可用内存。它只是一个适合放在素材入库流程与客户端业务层之间的离线门禁。

演示项目名 PixelBudgetGate，任务编号 PB-409。这里预置 16,000,000 个目标像素作为项目示例上限、48 MiB 作为保守的双缓冲区预算；预估像素格式为每像素四字节 RGBA8，并按两份工作缓冲区计算。这并不是完整内存估算：图像编解码器的临时对象、纹理、对齐、缓存、图层和垃圾回收开销都没有计入。真实端侧阈值需要基于机型和路径测量后单独确定。

二、先说清哪些参数可以信任

业务入口接受一条记录的 width、height 和 factor。宽高要求是安全整数且大于零；倍率只开放 2、3、4 三个档位，避免出现小数、零、负数或者任意放大的请求。虽然这个规则简单，但非常重要：若有人传入字符串“1280”，JavaScript 的隐式乘法可能让它看似可以正常计算，后续字段又在序列化时出现不同类型。直接拒绝不符合合同的类型，比在业务边界悄悄转换更容易审计。

计算时不用普通浮点数累乘目标像素，而是先完成输入检查，再把宽、高、倍率转换为 BigInt。大多数常见图片用 Number 也足够，但 BigInt 可以消除极端构造数值下的整数精度疑问，且写出的报告采用字符串表示，避免 JSON.stringify 直接序列化 BigInt 的异常。所谓“大图拦截”首先是参数合同，不应该等到真正尝试分配一块巨大缓冲区之后才判断。

下面这段来自 tools/pixel-budget.mjs，在真正预算计算前给出统一的 HOLD_SIZE。它同时覆盖宽度为零、非整数、过大而不安全的整型，以及无效倍率。工程上更严谨的版本还会检测来源文件的实际宽高是否与申报字段一致；本篇只处理示例请求。

const MAX_PIXELS = 16_000_000n;
const MAX_BYTES = 48n * 1024n * 1024n;
function validShape({ width, height, factor }) {
  return [width, height].every(v => Number.isSafeInteger(v) && v > 0)
    && [2, 3, 4].includes(factor);
}
}

这里把错误尺寸和错误倍率归到同一个输出状态，是为了示意报告简短，并不妨碍将来细分成 BAD_WIDTH、BAD_HEIGHT、BAD_FACTOR。若在生产项目内发现大量异常输入，应细化错误码，以便定位到底是相册回调数据缺失，还是中间服务的倍率设置问题。输入参数有错误时不做任何分配，更不建议自动把四倍申请改成两倍，因为这个选择应该由用户确认。

三、像素约束与内存约束必须分层判断

接下来计算目标像素数和双缓冲保守预算。先判断像素上限，再判断字节上限；即使两个条件同时超标，报告也只返回首个确定的拦截原因。这个优先级不是算法规定，而是方便业务方阅读日志的诊断合同。若把所有异常统一写成“图片太大”，处理人员会无法判断是目标分辨率政策过窄，还是工作缓冲区保守预算偏小。

function judge({ width, height, factor }) {
  if (!validShape({ width, height, factor }))
    return { status: 'HOLD_SIZE', pixels: '-', bytes: '-' };
  const pixels = BigInt(width) * BigInt(height) * BigInt(factor) ** 2n;
  const bytes = pixels * 4n * 2n; // 估算RGBA8双缓冲
  const status = pixels > MAX_PIXELS ? 'HOLD_PIXELS'
    : bytes > MAX_BYTES ? 'HOLD_MEM' : 'PASS';
  return { status, pixels: String(pixels), bytes: String(bytes) };
}

以 900×900 图片做四倍申请为例，目标为 3600×3600，目标像素 12,960,000，没有达到 16,000,000 的像素上限；但按八字节每像素的两份缓存估算，需要 103,680,000 字节，超过 48 MiB，于是归到 HOLD_MEM。这恰好说明只设像素上限并不够，而且不同设备并不能简单照搬这个示意门限。

另一条 3000×2000 的二倍请求，目标像素达到 24,000,000，首先命中 HOLD_PIXELS。这不是说图片一定无法处理，某些云端服务或高规格设备完全可能承接；它意味着当前项目合同不允许这类请求走同一条预览路径。把“项目拒绝”和“平台不支持”写清楚，是工程文档对读者负责的基本要求。

四、六组数据和实际运行状态

测试使用六组构造请求。PB-91 为 640×480、二倍，目标像素 1,228,800；PB-92 为 1280×720、二倍，目标像素 3,686,400；PB-95 为 600×400、三倍，目标像素 2,160,000。这三组都通过项目合同。PB-93 的目标像素超过上限，PB-94 的估算字节超过上限，PB-96 将宽度设为零，因此被拦截。

运行脚本后得到 PASS 3 / HOLD_PIXELS 1 / HOLD_MEM 1 / HOLD_SIZE 1。这里最重要的不是三条通过，而是每条失败都能清晰指向一条业务规则。要回归时，只需复制构造数据并执行 node tools/pixel-budget.mjs，不需要真实图像数据，也不会真的分配 100 MB 的缓冲区。脚本把估算字节当作普通字符串写入 reports/budget-report.json，保证 JSON 报告可以直接被流水线读取。

第三段代码把处理状态统计出来，并在 CI 模式下启用业务失败退出码。检查失败时返回 2，而不是系统资源崩溃产生的任意错误码。正式接入持续集成后，可以由流水线区分“脚本异常没有生成报告”与“报告正常生成但某项未通过”。

const counts = { PASS: 0, HOLD_PIXELS: 0, HOLD_MEM: 0, HOLD_SIZE: 0 };
for (const row of rows) counts[row.status] += 1;
console.log(`PB-409 summary PASS=${counts.PASS}`
  + ` HOLD_PIXELS=${counts.HOLD_PIXELS}`
  + ` HOLD_MEM=${counts.HOLD_MEM} HOLD_SIZE=${counts.HOLD_SIZE}`);
if (process.argv.includes('--ci') && counts.PASS !== rows.length) {
  process.exitCode = 2;
}

五、进入 ArkUI 页面以后，状态该怎么收口

在 HarmonyOS 前端页面里，倍率按钮通常属于 ArkUI 业务交互，用户点击后显示目标尺寸估算、预计占用和是否允许继续。可以用普通 Text、Button 和 GridRow 等组件来组织状态，但页面只能展示离线预算结论，不能将其描述为实时可用内存。尤其不要用 UI 的“通过”直接触发昂贵的解码或推理调用；正式实现仍应在真正启动任务的入口处复核一次尺寸与预算，防止 UI 状态过期或者被绕过。

对于已经通过预算的任务，也需要处理取消、切页、异常和资源释放。如果实际解码成 PixelMap，要结合所使用的 Image Kit 接口与生命周期释放相关对象；若使用 Native 路径，官方文档明确给出了 ImageSource 和 PixelMap 等资源的释放职责。

图片像素格式也会改变估算。这里的四字节假设只适用于示例 RGBA8，某些高位深、不同对齐方式、额外纹理复制或多级图像金字塔会使真实占用与估算不同。后续如果换成不同推理框架，应先收集实际内存数据，再决定新的安全系数。示意的 48 MiB 不应被当作低内存设备的通用保证。

六、把风险说明写在发布前

代码本身只有整数计算，很容易让人误以为“不过预算就不会崩溃”。这种理解是错的。Image Kit 图像处理可能涉及解码、编码、Bitmap/PixelMap、Native 资源和不同设备能力，最终真实消耗需要围绕具体实现路径测量。网络传输的压缩文件大小也不是像素缓冲区大小，不能拿一个 500 KB 的 JPEG 推断它在内存中很小。

另一个容易遗漏的风险是时间：用户调整倍率后旧的估算报告仍停留在界面，会造成状态错配。产品实现应把预算结果与输入文件标识、尺寸及 factor 绑定；三者任意一项改变，都应清除旧的 PASS 状态。为了减少错误弹窗，可以把具体原因转换成友好的界面提示，例如“当前倍率的预计工作区超出本项目预览预算，请选择较低倍率”，同时在研发日志里保留原始状态码。

官方参考：华为 Image Kit能力入口 汇总图片开发指导；使用 Image_NativeModule 完成位图操作 可用于核对位图尺寸、像素格式和资源释放；ArkUI 官方介绍 可核对页面框架。文中 BigInt、Number.isSafeInteger、JSON.stringify 属于标准 JavaScript/Node.js 语言能力。

复核时先运行本 ZIP 的 tools/pixel-budget.mjs 并检查六组结果，再以 --ci 参数运行，确认因存在有意构造的 HOLD 项返回退出码二。两张应用界面技术图是按上述结果独立绘制的 DevEco Studio 风格示意与 9:16 纯屏幕图。技术结论限定在可验证的范围内：先把目标像素、工作区估算和失败原因变成一份确定性合同，再讨论如何安全接入真正的增强处理链。