Bun.Image 让你的整个图像处理流水线彻底过时

中文العربيةEnglishEspañolहिन्दी한국어Русский
BBetter Stack
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00这是 Bun Image，随 Bun 1.3.14 版本发布的一个内置图像处理 API，可以调整大小、
00:00:06裁剪并在不同格式之间转换图像，无需任何原生依赖，
00:00:10而且整个过程都在主线程之外运行，意味着它在处理时不会阻塞你的服务器。
00:00:14但 Bun 本身已经是一个运行时、包管理器、打包工具、测试运行器了，
00:00:19现在又变成了图像处理器？这是否太过臃肿，还是说它在向我们暗示
00:00:24关于 Bun 未来方向的某种大动作？点击订阅，让我们一探究竟。
00:00:30如果你曾在服务器端用 JavaScript 处理过图像，可能用过一个叫
00:00:35Sharp 的库，甚至可能还没意识到，它每周在 npm 上的下载量超过 5500 万次，甚至
00:00:41被 Next.js 在底层用于图像优化。但 Sharp 依赖于一个名为 libvips 的原生二进制文件，
00:00:47这意味着每次安装都必须拉取适合你平台的构建版本。如果你曾因为这个
00:00:51而导致 Docker 构建或 CI 流水线失败，你就知道这有多让人抓狂了。所以 Bun 决定
00:00:57直接把图像处理功能内置到运行时中，而且在大多数基准测试中，它实际上比 Sharp
00:01:02更快。元数据读取速度快了 70 倍，调整大小速度快了约 30%。现在许多
00:01:08开发者真的很困惑为什么 Bun 要增加这个功能，但我大概能看出这一切的发展方向，
00:01:13之后我会详细说明。但现在，让我们通过几个演示来看看如何使用
00:01:17Bun 图像 API。我们将在我的博客上试用它，这是一个静态的 Waku 站点，上面
00:01:22有一些巨大的图片。首先，让我们通过一个简单的脚本来优化一张图片，
00:01:27就是那张我的头像，它成功将尺寸减小了 99%，这简直太疯狂了。
00:01:33来看看是怎么做的。首先，我们获取图像，注意这里我们用了 Bun.image，但你也可以用
00:01:37Bun file 配合图像函数。然后我们调整图像大小来缩小体积，设置宽度为 800
00:01:43像素，高度会根据纵横比自动计算。但如果你想的话，
00:01:47我们也可以在这里加上高度。接着我们设置输出格式为 WebP，并降低质量。当然，
00:01:52其他输出格式也支持，然后我们把新图片输出到一个文件中，
00:01:56这是一个 promise，所以需要 await 关键字。你可以看到这有多简单。
00:02:01事实上，所有这些代码都是不必要的，我们可以删掉它们，让代码更简洁。
00:02:06我们还可以设置调整大小的滤镜，更改重采样内核，进一步减小图像尺寸。
00:02:10我们可以旋转或翻转图像，这真的很酷。我们甚至可以改变亮度或
00:02:15饱和度，这可能会得到一些看起来很奇怪的图片。但有一件非常聪明的事
00:02:19你可以用来处理慢速连接，那就是使用 placeholder 函数，自动
00:02:23在主图加载时显示一张模糊的图片。为了做到这一点，我写了这个 for 循环，
00:02:29遍历包含所有块图像的目录中带有这些扩展名的每一个文件。
00:02:34所以每一张图片都在进行调整大小、缩放（不裁剪也不拉伸），
00:02:39然后我们为每张图片创建一个占位符，生成一个 thumb hash，意思是将
00:02:45任何图像编码为 28 字节的哈希值，非常适合作为模糊的图像占位符。
00:02:49这个哈希被添加到一个占位符对象中，然后写入一个文件，
00:02:53看起来是这样的。现在，占位符之所以是 base64 图像而不是
00:02:58单独的较小 WebP 图像，是为了让网络不必为了获取它而发起额外请求。
00:03:02所以我可以导入所有的占位符，并在 CSS 中将它们作为背景图片，
00:03:07同时等待主图加载完成，这对博客上的每一张图都适用。
00:03:11但如果你想在 MDX 文件中为单张图片实现这种效果，只需手动添加
00:03:16base64 代码即可，效果同样好。注意，你也可以通过
00:03:20将 progressive 设置为 true 来获得类似的 JPEG 图像效果。当然，还有许多
00:03:24Bun image 支持但我还没提到的功能，比如从 S3 兼容的
00:03:28存储桶中获取图像，或者将图像写入存储桶，将图像管道作为有效的响应体，
00:03:33以及当特定操作系统不支持某种格式时配置回退格式。
00:03:37那么这值得使用吗？嗯，如果你已经在用 Bun 了，那这绝对不用多想。
00:03:41但如果你在使用 Node，那么 Sharp 的工作表现非常好且经受过考验，
00:03:45没必要仅仅为了图像处理而更换到一个完全不同的运行时。
00:03:49还记得我说过 Bun 增加这个功能的深层原因吗？看看 Bun 在
00:03:54过去一年里所做的：内置 SQLite、S3、Postgres，现在又是图像，基本上
00:03:59就是构建全栈应用所需的一切，除了可能还有认证和邮件功能。这让我怀疑，
00:04:04Bun 是否正试图在运行时层面构建 JavaScript 的 Laravel 或 Rails？如果是这样，
00:04:11那么他们下一个工作目标就是认证。如果是的话，记住，你是从这听到的。
00:04:15但遗憾的是，如今你不能在不提及巨大的从 Zig 到 Rust
00:04:20重写的情况下谈论 Bun，希望在下一个版本中能看到它。让我们祈祷一切顺利。
00:04:25提到 Zig，如果你想进一步了解 Vercel 的 Language Zero，它看起来像 Zig，
00:04:29但又不是 Zig，并且是为 AI 代理构建的，请查看 James 的这个视频。

Key Takeaway

Bun 通过将图像处理功能内置于运行时，实现了无需外部二进制依赖且比 Sharp 更快的高性能图像处理流水线，持续完善其全栈开发能力。

Highlights

  • Bun 1.3.14 引入内置 Bun.Image API，支持图像调整大小、裁剪和格式转换，无需原生外部依赖。

  • 图像处理过程在主线程之外异步运行，避免阻塞服务器主进程。

  • 元数据读取速度比 Sharp 库快 70 倍，调整图像大小速度提升约 30%。

  • Bun.Image 能够将图像调整为 800 像素宽并转换格式，实验中测试图像体积缩小了 99%。

  • 通过 thumb hash 功能，可以将任何图像编码为 28 字节的哈希值，作为轻量级网页占位符。

Timeline

Bun.Image 功能概述与对比

  • Bun 1.3.14 版本内置图像处理 API，无需额外原生依赖。
  • 该功能在主线程外异步执行，不占用服务器主线程资源。
  • 元数据读取效率比 Sharp 快 70 倍，尺寸调整速度快约 30%。

Bun.Image 旨在解决 JavaScript 服务器端图像处理痛点。传统方案如 Sharp 依赖 libvips 原生二进制文件，常导致 Docker 构建或 CI 流水线失败，而内置 API 通过消除外部依赖规避了此类问题。

图像处理实操与占位符生成

  • 利用 Bun.Image 可轻松实现图像缩放、格式转换（如转为 WebP）和质量设置。
  • 支持旋转、翻转及亮度与饱和度等滤镜调整。
  • 通过生成 28 字节的 thumb hash 作为 base64 占位符，可优化慢速网络下的图像加载体验。

代码实现简洁，处理过程中可通过 await 异步处理图像流。通过遍历文件目录并生成 thumb hash，可在主图像加载前在浏览器渲染出模糊的占位符，避免产生额外的网络请求。

生态整合与发展方向

  • Bun.Image 支持 S3 存储桶交互及响应体管道处理。
  • Bun 持续整合 SQLite、S3、Postgres 和图像处理等功能，构建全栈开发环境。
  • 未来可能重点攻克认证（Authentication）和邮件处理功能。

Bun 正通过内置常用服务，试图成为 JavaScript 领域的全栈框架底座。目前已涵盖应用开发的核心需求，下一步发展重点指向认证系统，旨在提供类似 Laravel 或 Rails 的全栈式开发体验。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video