MoGallery-图片滚动优化

AI总结#

问题不是”照片没加载”,而是图片解码。上传接口在”压缩原图”模式下把压缩后的原图直接当缩略图(thumbnailUrl = url),导致 29 张最新上传的照片以 12~22MP 的分辨率进入画廊网格:

• 一张 4096×3072 的图,解码后的位图约 50MB(4096 × 3072 × 4 字节),单次解码 300~400ms 纯 CPU 开销;
• 缓存只免下载,不免解码。虚拟列表把滚出视口的卡片卸载,滚回来重新挂载 <img> 就要重新解码——9 秒滚动里发生了约 1500 次解码;
• decoding="async" 的行为是”先画一帧没有图的空白,解码完再补”——这正是”成片区域空白 + 卡顿、但 F12 无请求”的来源。

修复分两步:

1. 堵源头:hono/photos.ts 上传接口不再在压缩模式下复用原图当缩略图,无论什么模式一律生成独立的 800px AVIF 缩略图(每张多占 ~30-170KB 存储)。三端(Web/Flutter/Desktop)上传全部汇入这一个服务端接口,客户端零改动。
2. 补存量:scripts/backfill-thumbnails.ts(默认 dry-run,--apply 才写入)为 29 张存量照片生成缩略图上传到 R2 同目录 thumb-*.avif 并更新数据库,原图 232KB3.8MB → 缩略图 26170KB。原图不动、可回滚,以后也可当巡检工具复查。

此前对 masonic 布局层的重写(把已知的照片宽高预先种进 positioner)解决的是另一半问题——拖滚动条远跳时无上限隐藏渲染批次导致的冻结、首帧列数跳变;压测确认 JS/渲染层不是瓶颈(JS 总耗时 749ms,渲染断层≈0)。

修复前后压测对比(同机同脚本,headless Chrome + Performance trace):

一句话总结:文件小 ≠ 像素少。压缩解决的是字节,缩略图解决的是像素,两者不能互相替代;判断图片性能问题看 MP,不看 KB。