图片压到200KB，为什么不能说只占200KB内存？

封面由内置 imagegen 生成，示意紧凑图像文件与展开的像素表示；不是200KB实测文件、压缩率或内存测试图。

某张图压缩后文件只有200KB，不代表解码后的像素数据也只有200KB，更不能直接推出游戏进程或GPU只用了这么多内存。优化前应先确认自己要减少下载、像素尺寸，还是目标环境里的实际占用。

可以先用 资源压缩工具处理交付文件，但压缩结果需要与像素尺寸和运行测量分别记录。本文不报告某个项目的实测性能。

先限定一个能计算的模型

MDN 的 ImageData.data 文档说明RGBA顺序及rgba-unorm8使用Uint8ClampedArray。只对每像素四个8位通道、单份连续像素缓冲这个模型，字节数可按宽×高×4计算。这里不包括其他副本、对象管理开销、GPU分配、mipmap或不同像素格式。

三个方图的算例

• 1024×1024：4,194,304字节，即4MiB。
• 2048×2048：16,777,216字节，即16MiB。
• 4096×4096：67,108,864字节，即64MiB。

本例1MiB＝1,048,576字节。数值只是上述RGBA8模型，不是浏览器进程内存、引擎纹理内存或加载峰值的预测。文件本身仍可能因编码方式与画面内容具有不同体积。

同尺寸降低文件体积，改变的是什么？

假设2048×2048图像在处理前后仍以同尺寸RGBA8展开，单份像素数据仍是16MiB这个模型值。交付文件变小可改善传输体积，但不能仅按文件下降百分比推算这份像素缓冲也同比变小。

这不等于压缩没有价值，也不证明某种格式一定更快。解码、缓存、格式与平台行为仍需在目标环境观察。选择文件编码时可结合 PNG、WebP与AVIF交付格式说明，不要把网站分享图的选择直接当成所有引擎纹理的配置。

宽高各减半，为什么模型变为四分之一？

在相同像素格式和缓冲份数下，2048×2048改成1024×1024，像素数量变为四分之一，因此模型从16MiB降为4MiB。但这不是无代价优化：细字、描边、图标和透明边缘可能不再满足实际显示要求。

先确定显示用途与所需分辨率，再决定是否缩小；不要为了得到较小数字而统一缩小所有源图。保留可编辑主素材，在交付副本上比较尺寸与画面。

透明区域也要分清文件与像素模型

在这个固定RGBA8完整缓冲模型里，全透明区域仍属于宽×高中的像素。它在编码文件中的表示可能较紧凑，但这不能让同尺寸缓冲的对应位置自动消失。

裁掉透明边可能减少像素尺寸，却可能影响序列帧参考空间。若处理动画帧，先核对统一规格或实际偏移表示，不要为缩小模型而破坏对齐。

用三项记录验收本轮优化

• 交付文件：格式与实际字节数，说明这是文件或网络传输观察。
• 图像本身：实际宽高、透明边与显示质量；只有假设成立时才附RGBA8模型。
• 目标运行：在同设备、同场景、相同加载范围下观察项目实际指标，明确使用的测量工具与口径。

如果只完成文件压缩，就报告文件变化，不宣称已降低GPU占用或首屏耗时。已有 压缩质量临界点检查方法可帮助验收画面；运行效果则需要独立测量。