一缕阳光 - 人间正道是沧桑

引言：在云端时代，做一款“反潮流”的本地应用 前几天，我分享了为什么我还在维护 Electron 架构的 Hummingbird。那是为了跨平台的妥协与务实。 但在 Apple 的生态花园里，我有着更极致的追求。我经常问自己：如果我不计成本地利用 Apple Silicon 的每一分算力，如果不依赖任何云端 API，一个媒体工具能做到多快、多安全？ 答案就是 Medrea。 不同于市面上那些仅仅是“FFmpeg 命令行套壳”或者“Web 页面打包”的工具，Medrea 是完全基于 Swift 和 SwiftUI 构建的原生应用。它是 Medrea (Media Area) 的缩写，也是我为 macOS 和 iOS 用户打造的终极媒体工具箱。 1. 视频处理：VideoToolbox 的暴力美学 在 Electron 应用还在为了调用本地 FFmpeg 而苦恼于进程通信时，Medrea 已经直接接管了你的 GPU。 Medrea 的视频压缩与转换核心，深度集成了 Apple 的 VideoToolbox 框架。这意味着： 硬解硬编： 无论是 H.264, HEVC 还是最新的 AV1，Medrea 都会优先调用硬件加速。这不仅意味着速度起飞，更意味着你的 Mac 不会像直升机一样起飞（风扇狂转），你的 iPhone 不会瞬间发烫。 智能音频拷贝 (Smart Audio Copy)： 这是我很自豪的一个细节。当视频编码需要转换但音频兼容时，Medrea 会自动“复制”音频流而不是重新编码。这看似简单，却能极大程度地保留音质并缩短处理时间。 严格的编解码保留： 很多工具会暴力把所有视频转成 MP4 (H.264)。但 Medrea 懂得尊重原始画质，除非必要，它会严格保留原始 Codec。 最懂你的“智能决策”： 你一定遇到过“压缩后文件反而变大”的尴尬。Medrea 内置了智能回退机制——如果压缩结果不如原片（体积更小且画质可接受），它会自动保留原文件。不为了压缩而压缩。 2. 图像工具：Vision 框架与算法的胜利 在 AI 抠图这一项上，Medrea 没有选择调用昂贵的云端 API，也没有引入臃肿的 Python 库。 得益于 iOS 17+ / macOS 的原生 Vision 框架 (VNGenerateForegroundInstanceMaskRequest)，Medrea 实现了完全离线、毫秒级的背景移除。 隐私： 你的照片不需要上传到别人的服务器，一切都在你的 Neural Engine 上完成。 批量： 支持一次性处理 20 张图片，自动识别主体，输出透明 PNG。 而在压缩方面，Medrea 并没有因为追求速度而牺牲质量。 JPG： 使用 MozJPEG 编码，保证了 Web 级别的极致压缩率。 PNG： 采用了 Zopfli 算法（虽然慢一点，但压缩率惊人）。 动图支持： 它是市面上为数不多能完美处理 Animated WebP/AVIF 的工具。它甚至能智能检测动图，让你选择是保留动画还是提取静态帧。 3. 音频与转录：不止是转换 Medrea 不仅仅是一个转换器，它还是一个迷你的音频工作台。 可视化波形编辑： 既然是原生 App，就不应该只有枯燥的进度条。你可以直接在可视化的波形图上拖拽、分割、修剪音频。 本地语音转文字： 利用 Apple 的 Speech 框架，Medrea 支持 10 种语言（中/英/日/韩/西/法/德/意/葡/俄）的离线转录。没有订阅费，没有时长限制，只要你的设备有电，它就能一直转。 4. 2026 年的隐私承诺 在这个万物皆云、万物皆订阅的时代，Medrea 显得有点“笨”。 它没有账户系统。 它没有服务器上传按钮。 它所有的处理——无论是视频转码、AI 抠图还是语音转写——100% 在本地完成。 这不仅是出于对隐私的保护（毕竟很多公司禁止上传素材），更是为了在断网环境（飞机上、高铁上）下，你依然拥有一个完整的工作流。 结语 如果 Hummingbird 是为了解决“温饱”（基本的压缩需求），那么 Medrea 就是为了追求“品味”。 它是用 Swift 一行行代码堆出来的性能怪兽，也是用 SwiftUI 细细打磨的交互艺术。如果你手里有一台 Apple 设备，我诚挚地邀请你体验一下什么叫Native Experience。

在 AI 和 Native 盛行的时代，聊聊 Hummingbird 的技术取舍与长期主义 引言：房间里的大象 现在是 2026 年。打开 GitHub Trending，满屏都是 AI Agent、Rust 重写的 CLI 工具，或者是追求极致性能的 Native 应用。 在这个时间点，继续维护一个基于 Electron 的桌面端图片压缩工具——Hummingbird，听起来似乎有点“政治不正确”。毕竟，大家都会问：“为什么不重写？为什么不用 Tauri？为什么不用纯 Swift/C++？” 作为一个同时也是 iOS/macOS 开发者（正在开发 Medrea）的我，其实比谁都更在意性能和包体积。但今天我想聊聊，为什么对于 Hummingbird 来说，Electron 依然是当下最好的选择，以及这款工具背后的“长期主义”。 1. 跨平台的“最大公约数” 做开源工具最怕的是什么？是维护疲劳。 我希望 Hummingbird 能同时服务 macOS 和 Windows 用户。如果我追求极致原生，我需要写一套 Swift (AppKit/SwiftUI) 给 Mac，再写一套 C# (WPF) 或 C++ 给 Windows。这对于独立开发者来说，维护成本是指数级上升的。 Electron 虽然常被诟病“吃内存”，但它在 2026 年依然是UI 表现一致性最好的解决方案。对于一个图片压缩工具，用户用完即走，他们更在意的是“拖进去就能用，界面不丑”，而不是它占用了 100MB 还是 30MB 内存。 2. 成熟的生态 vs. 重复造轮子 Hummingbird 的核心价值不在于 UI，而在于压缩算法。 Node.js 社区拥有极度成熟的图片处理库（如 pngquant-bin, mozjpeg, cwebp 等的封装）。通过 Electron，我可以无缝地桥接这些经过工业级验证的底层二进制文件，而不需要自己在 Rust 或 C++ 里重新处理复杂的跨平台编译链问题。 我们在 v4.x 版本中解决的多线程问题，正是得益于这种架构的灵活性。我不造算法，我只是优质算法的“搬运工”和“组装工”。 3. 2026年的稀缺品：离线与隐私 这几年，AI 生成图片爆发，SaaS 订阅制横行。你随手搜一个“图片压缩”，大概率会搜到： 在线工具： 让你上传图片（隐私风险），或者每天限制 20 张。 AI 增强工具： 强行给你 upscale，然后收费。 Hummingbird 在 2026 年存在的意义，恰恰是因为它“不够智能”且“完全离线”。 很多设计师和开发者告诉我，他们依然坚持用 Hummingbird，是因为公司的保密协议（NDA）禁止将设计稿上传到任何云端。基于 Electron 的本地化处理，让它成为了一个绝对安全的“黑盒”。不联网、不上传、不搜集数据，这种“老派”的作风在今天反而成了一种 feature。 4. 维护一个“完成品”的乐趣 软件工程里有一种迷思：只有不断重构的代码才是好代码。 但对于工具类软件，稳定性 > 追逐新框架。 Hummingbird 不需要变得更复杂。它不需要集成 AI 聊天，不需要社交功能。它只需要在用户把一张 10MB 的 PNG 拖进去时，吐出一张 2MB 的图片，并且肉眼看不出区别。 只要它还能在最新的 macOS 和 Windows 上稳定运行，只要它还能帮大家省下带宽和流量，我就有理由继续维护它。 结尾：写在最后 Hummingbird 是完全免费且开源的。如果你是一名开发者，欢迎去 GitHub 看看代码，甚至 Fork 一个属于你的版本。如果你觉得它好用，点个 Star 就是对我最大的支持。 最后，夹带一点私货： 如果你对我开发的这类“小而美”的工具感兴趣，或者是 Apple 生态的开发者，欢迎关注我的另一个核心项目 Medrea。那里汇聚了我对原生开发更深层的思考。 GitHub: https://github.com/leibnizli/hummingbird