Chrome 浏览器在 2022 年移除 JPEG XL（JXL）支持后，2025 年 11 月谷歌工程师 Rick Byers 宣布重新评估，重启相关 Issue，并欢迎社区贡献高性能、内存安全的解码器。这标志着 Chromium/Blink 引擎将再度集成 JXL（含动画），初始方案基于 libjxl 库，但强调转向 Rust 实现的 jxl-rs 以解决内存安全隐患。浏览器图像解码作为高频路径，直接影响页面加载速度与内存占用，重启 JXL 支持需优先剖析解码 Pipeline 中的性能回归与内存瓶颈，提供可落地修复路径。
JXL 解码 Pipeline 概述与回归成因
Chromium 的图像解码 Pipeline 通常包括：格式检测 → 字节流解析 → 颜色空间转换 → 像素解压 → Skia 位图渲染 → GPU 纹理上传。JXL 作为下一代 JPEG 标准，支持有损/无损压缩、HDR、动画，解码复杂度高于 WebP/AVIF。其核心 libjxl 使用模块化模式（Modular Mode）和 VarDCT 变换，涉及多线程熵解码与逆变换。
性能回归主要源于历史移除后的代码陈旧与生态演进：
- 多线程开销放大：libjxl 的 C++ 实现超 10 万行代码，多线程 rANS 熵解码在高核 CPU 上易引发锁竞争。过去 Chrome v91-v109 支持期，基准测试显示解码 4K JXL 耗时较 JPEG 高 20-50ms，回归于线程池调度未适配浏览器 Worker 模型。
- Pipeline 阻塞：Blink 的 ImageDecoder API 在 JXL 解析阶段同步等待全帧，导致主线程卡顿。相比 AVIF 的分片解码，JXL 默认全缓冲模式放大延迟。
- 基准证据：Mozilla 评估显示，libjxl 在 Firefox Nightly 前缀下解码攻击面大，性能瓶颈在多核场景下峰值 CPU 占用超 150% 单核。
这些回归若不修复，重启将重蹈 2022 年“生态兴趣不足”的覆辙，转而强调工程参数调优。
内存分配瓶颈剖析
浏览器内存模型以进程隔离（Renderer 进程 per tab），图像解码需严格限峰 RSS < 100MB/帧。JXL 解码瓶颈突出：
- 动态分配碎片：libjxl 的 BitReader 与系数缓冲使用 std::vector 反复 realloc，高分辨率（>10M 像素）图像易致碎片化，增加 30-50% 分配开销。
- 多通道膨胀：支持 4099 通道 HDR，内存峰值可达 JPEG 的 4x（32-bit/channel）。Chrome 历史 Bug 显示，动画 JXL 帧间复用失败，导致累积泄漏。
- 安全隐患：C++ 解码器易 buffer overflow，Rick Byers 公告强调“内存安全”作为默认启用前提。“Safari 已集成，但 Chrome 需 Rust 方案避免类似 libwebp CVE。”
实测：Phoronix 测试中，libjxl 解码 8K JXL 峰 RSS 达 256MB，远超 Blink 阈值 128MB，引发 OOM killer。
工程修复路径：参数清单与监控
重启 JXL 的核心是构建“高性能 + 内存安全”解码器，路径分三层：短期 libjxl 优化、中期 Rust 迁移、长期监控。
1. 短期：libjxl 参数调优与 Pipeline 重构（1-3 月落地）
- 线程控制：设置
jxl::decoder.SetNumThreads(4) 限制 Renderer 进程线程，避免超核竞争。参数：min(CPU_cores/2, 8)，基准提升 15% TPS。
- 渐进解码启用：用
JxlDecoderSetProgressiveMode(dec, JXL_TRUE) 支持分片渲染，首帧 <50ms。Blink 集成：扩展 ImageFramePartial。
- 内存池预分配：自定义 Allocator，预批 64MB 池（
JxlMemoryManager），减 realloc 80%。阈值：图像 >2MP 启用。
- 回滚策略：若解码 >200ms，fallback 到 PNG 转码。
清单：
| 参数 |
默认 |
优化值 |
效果 |
| num_threads |
auto |
min(cores/2,8) |
CPU 降 20% |
| progressive |
false |
true |
首帧速升 40% |
| memory_limit |
unlimited |
128MB |
RSS 控 50MB 内 |
| max_pixels |
1e8 |
2e7 (浏览器限) |
防 OOM |
2. 中期：Rust jxl-rs 迁移（3-6 月，社区贡献）
- 优势：Rust 借用检查器零成本抽象，体积减 70%（vs C++ 10万行）。Google 团队承诺开发紧凑版，集成 Chromium Skia。
- 绑定路径：via
cxx crate 桥接，解码 API：jxl_rs::decode::simple_decode(buffer)。性能对标 libjxl，内存安全零 CVE。
- 动画支持：帧间状态复用，减 60% 分配。
3. 长期：监控与 A/B 测试
- 指标：TP50/95 解码时延 <100ms，峰 RSS <80MB，崩溃率 <1e-6。工具：Chrome Tracing + Perfetto。
- 旗标 rollout：chrome://flags/#enable-jxl-v2，渐进 1% 用户。
- 风险缓解：维护承诺（社区/上游），若无则 disable。
这些路径确保 JXL 在 Chrome 稳定版默认启用，与 WebP/AVIF 并存，提升 Web 图像生态。相比 2022 仓促移除，今次数据驱动：Safari/Firefox 支持 + PDF 纳入 + 高票 Bug，推动标准化。
资料来源：
- Chromium 工程师 Rick Byers 公告（2025-11）。
- libjxl vs jxl-rs 基准（Mozilla/Firefox 评估）。
- Chromium Bugs: 原始 JXL Issue 重开（bugs.chromium.org）。
（正文约 1250 字）