硬件开源 vs 软件开源——阅读器的两条路线

上一篇文章聊了 FreeInk，一个从 SDK 到硬件全栈开源的电子墨水屏阅读器生态项目。文章发出去后，有朋友问我一个很直接的问题：

「FreeInk 和 unobox 不是竞品吗？你们做 unobox，为什么还要写文章推荐 FreeInk？」

这个问题聊开来，其实指向的是整个开源阅读器世界的一个基础分野。

回答那个问题：不是竞品

FreeInk 解决的是「怎么造一台靠谱的电子墨水屏阅读器硬件」，unobox 解决的是「怎么让任何设备打开浏览器就能读书」。

前者的用户需要焊电路、刷固件、买 ESP32 开发板；后者的用户打开 URL 就能开始看。两个人买的书可能是同一本 ePub，但翻开它的方式完全不同。

这就像问「Linux 桌面和 Android 手机是不是竞品」。它们都是操作系统，但解决的问题、服务的场景、面对的用户，没有一个是重叠的。

但今天我不想只是区分它们。我想聊聊整个开源阅读器世界里的两条主线——硬件开源路线和软件开源路线——它们的逻辑、它们的边界、以及它们如何在不竞争的前提下互相成就。

硬件开源路线：为了那块电子墨水屏

代表项目：FreeInk、Open Book Touch、以及各种围绕 KOReader 打造的定制硬件方案。

这条路线的基本信念是：阅读器的核心是那块电子墨水屏。剩下的处理器、内存、存储、WiFi，都是为了服侍这块屏幕而存在的附属品。

它的优势

续航。 这不是按天算的，是按周算的。FreeInk 的参考设计里，单片机级别的 ESP32 配电子墨水屏，一次充电撑一个月是常态。Kindle 也是这个逻辑。

护眼。 被动发光，阳光下不用调亮度。这不是玄学，是物理——电子墨水屏本质是带电粒子的物理运动，不是 LED 的主动照射。

沉浸。 没有推送、没有通知、没有「猜你喜欢」。就是一个看书的东西。这种「单一用途设备的纯粹性」，在智能设备泛滥的今天，反而成了一种奢侈品。

完全可控。 从 FreeInk SDK 到编译固件到烧录，每一步都在你手里。不会有人远程更新你的阅读器让它变慢，也不会有后台偷偷上传你的数据。这个自由度，商业产品给不了。

它的局限

贵。 电子墨水屏的物料成本本身就高。一块 800×480 的屏幕组件就要几十美元，加上 PCB、电池、外壳，打样一套的成本轻松破百美元。和「手机装个 App」的软件方案比，这不是一个数量级的门槛。

输出受限。 屏幕刷新率就那么 300-500ms。做不了动画、炫酷的过渡效果、实时的高亮标注。你做什么都得绕着「电子墨水屏很慢」这个物理事实来设计。

需要动手。 这个我说过了。现在还不是普通用户能用的状态。FreeInk 目前的门槛是「有 PlatformIO 经验的嵌入式开发者」。

代表项目一览

KOReader 是这条路线上的老大哥，十年耕耘，兼容性最广。FreeInk 则选择了更彻底的开源道路——它不兼容任何现有硬件，而是从零定义新硬件。

软件开源路线：为了跨平台的一致体验

代表项目：unobox（自家的）、Readest、Koodo Reader、Foliate、Lector

这条路线的基本信念是：阅读器的核心是阅读体验。屏幕、操作系统、设备，这些都不是最重要的——重要的是你打开书、翻页、做笔记、放下书这个过程是否自然。而做到这一点，应该让用户在已有的设备上就能获得，不需要添置新硬件。

它的优势

零门槛。 Readest 在 App Store 搜一下装上去就能用。unobox 甚至不需要装——打开浏览器，输入网址，直接读。不像硬件方案那样需要下单、等快递、焊电路、烧固件。

跨设备一致。 在 Mac 上读到一半，合上电脑，掏出手机，同一本书接着看——如果用的是云同步方案，进度是延续的。硬件方案做不到这一点，因为每台设备是独立的。

功能丰富。 高亮、笔记、全文搜索、词典、TTS 朗读、书摘导出。这些功能在手机/电脑上做起来很自然，但在 ESP32 上实现难度大得多（尤其是 TTS 和全文搜索）。

更新快。 一个 Web 应用更新完下一秒所有用户都用上了新版本。固件更新需要编译、烧录、重启，这个循环慢得多。

它的局限

屏幕效果取决于硬件。 在手机上读书，蓝光是个问题。在 iPad 上读书，太重是个问题。在电脑上读书，没法躺着看。软件方案受限于宿主的物理特性。

续航靠手机。 如果看书看到手机没电，就不能边等边用手机回消息了。硬件方案没有这个问题——看书设备和通讯设备是分开的。

隐私是信任问题。 虽然 unobox 的架构决定了数据不上传（所有处理都在浏览器本地，根本没服务器端数据），但对于用户而言，「纯前端」这个概念需要理解成本。硬件方案在隐私上的优势是直觉性的——没网卡，怎么上传？

两条路线的交叉点

聊了这么多区别，其实它们有一个关键的交集：EPUB 排版引擎。

不管你是跑在 ESP32 上的 FreeInkBook，还是跑在浏览器里的 Epub.js，你要解决的问题是同一个：解析 EPUB 这个 ZIP 包里的 XHTML + CSS，按照屏幕尺寸分页，把文字和图片渲染到指定的画面上。

FreeInk 的排版流水线：

1

EPUB → ZipCatalog → Book → ChapterLayout → PageCache → PageRenderer

unobox 的排版流水线：

1

EPUB → JSZip → Epub.js → Rendition → iframe → 浏览器渲染

思路惊人地相似。只是底层的约束条件不同——FreeInkBook 要在 512KB 内存里干活，要用自己的排版引擎（不依赖浏览器的 CSS 引擎）；Epub.js 可以尽情调用 Chrome 的排版能力，但代价是依赖浏览器这个运行时环境。

我曾经想过一个问题：FreeInk 的硬件和 unobox 的阅读引擎能不能结合？

理论上可以。PC 端的阅读器（Koodo Reader、Alexandria）都在用 Electron/Tauri 套壳实现。FreeInk 如果要在桌面端有一个阅读器，完全可以内嵌一个 WebView 跑 unobox。反过来，FreeInk 的硬件如果跑一个轻量级的 HTTP 服务器，把排版好的页面推给浏览器，用户在浏览器里看书——这也是混搭的一种方式。

当然这只是个想法。两个项目现在都有自己的路要走，交叉可能还早。

所以谁的路线对？

这是个没有标准答案的问题，但我想提供一个视角来帮助思考。

如果你问「更多人会怎么读书？」——答案是软件路线。大多数人不折腾硬件，不想多带一个设备。他们已经在手机/平板/电脑上生活了，读书只是生活中的一个子活动。

如果你问「最好的读书体验是什么？」——答案可能倾向于硬件路线。一本好书值得你为此打开一盏灯、泡杯茶、放下手机、拿起一个安静的设备，沉浸在只有书的界面里。

但这不是一个非此即彼的选择。KOReader 的用户在用软件体验硬件，unobox 的用户在用硬件体验软件。

开源阅读器生态最迷人的地方就在于——选择权在用户手里。 你可以今天用 unobox 在浏览器里试读一本书，觉得不错，再去找 FreeInk 硬件来精读。工具不一样，但读的是同一本书。

这不挺好的。

📚 上一篇：FreeInk 全解析 → | 下一篇：从裸机到浏览器 →