FreeInk 全解析——开源电子书阅读器的「全栈革命」

上周逛 Hacker News，一条 421 分的帖子直接把我拽住了。

FreeInk，一个号称要做「开源电子书阅读器全栈开放生态」的项目。站点干净利落，没有花哨的营销文案，开门见山：我们正在构建从软件、固件到硬件的每一层——全部开源，任何人拿去用、去改、去自己造。

看到这句话我脑子里冒出的第一个念头是：终于有人这么干了。

Kindle 时代结束的信号越来越明显了。硬件更新越来越慢，系统封闭得死死的，用户连换个字体都要折腾破解。大厂不干了，市场留给开源的机会就来了。KOReader 在固件层干了快十年，Readest 用 Flutter 横跨全平台，unobox 用纯前端走了一条完全不同的路——但 FreeInk 选择了一个更「重」的方向：从零开始，连 SDK 带固件再带硬件参考设计，一股脑全开源。

这篇文章是这个系列的开篇，我想好好聊聊 FreeInk 到底是什么、它怎么做到的、以及它凭什么有可能成为电子墨水屏世界的 Linux。

FreeInk 不是什么

聊清楚一个东西之前，先聊清楚它不是什么，反而省事。

FreeInk 不是一个开箱即用的阅读器 App。你下载它的 SDK，不会得到一个能打开 EPUB 的界面——你得自己写固件。

FreeInk 也不是一个单项目。它是「一个开源集体」，目前已经包含了 SDK、UI 框架、EPUB 排版引擎、以及多款电子墨水屏设备的板级支持包。

FreeInk 更不是一个硬件产品。它没有自己的阅读器硬件在卖。而是提供了一整套参考设计和 SDK，让硬件厂商或者有焊接能力的极客，能自己做出一个开源阅读器。

换句话说，FreeInk 想当的是电子墨水屏世界的「Android」——不是直接卖手机给你，而是让所有人能用它的东西自己造手机。

四层全开放，一层不少

这个项目的文档里有一句话很打动我：

every layer ships in the open for anyone to pick up, extend and make their own.

每一层都是开放的。不是只开源 SDK 然后硬件闭源，也不是只开源硬件但固件是黑盒。四层全部放开：

1. FreeInk SDK（硬件无关层）

这是整个项目的基石。SDK 用 C++17 写的，抽象了所有电子墨水屏硬件的差异。你写阅读器固件的时候，调的是同一套 API：

1
2
3
4
5
6
7
8
9
10
11
12
13

EInkDisplay display(
  BoardConfig::ACTIVE.display.sclk,
  BoardConfig::ACTIVE.display.mosi,
  BoardConfig::ACTIVE.display.cs,
  BoardConfig::ACTIVE.display.dc,
  BoardConfig::ACTIVE.display.rst,
  BoardConfig::ACTIVE.display.busy
);

display.begin();
display.clearScreen(0xFF);   // 白屏
// ... 画图 ...
display.displayBuffer(FULL_REFRESH);

这段代码换任何支持的面板都不用改。GPIO 引脚、屏幕分辨率、控制器型号，全部从 BoardConfig::ACTIVE 这个运行时选取的板级描述里读出来。

2. FreeInkUI（UI 框架）

阅读器的交互层。提供了：

• 书库列表（支持滚动、选中、手势）
• 阅读器界面（三分区点触翻页、左右滑动手势）
• 菜单系统（导航栏、居中文本、底部状态栏）

UI 框架用的是自己定义的一套 Builder 模式，而不是依赖 LVGL 或者任何第三方 UI 库。好处是二进制极小，坏处是你得用它的思路做界面。

3. FreeInkBook（EPUB 排版引擎）

这个是我个人最感兴趣的部分。FreeInkBook 实现了从 EPUB 包打开到页面渲染的完整流水线：

1
2
3
4
5
6
7

book::ZipCatalog::hashPath(path)    → 唯一标识一本书
book::Book::open(source, arena)     → 解析 EPUB 包
book::ChapterLayout::layout()       → 按屏幕尺寸分页
book::PageCacheWriter               → 缓存排版结果到 SD 卡
book::PageCacheReader               → 从缓存快速翻页
book::PageRenderer::renderText()    → 绘制文字到帧缓冲
book::PageRenderer::renderImages()  → 渲染图片

注意排版缓存这个设计，在嵌入式设备上是很有想法的。电子墨水屏刷新慢（300-1000ms），如果翻页时才去重新排版，等待感会非常明显。FreeInk 的做法是把排好版的页面缓存到 SD 卡上，翻页时直接从缓存读——第一次打开一本书可能需要几秒去做全本排版，但排版一次之后，后面的翻页就是毫秒级的了。

4. 硬件参考设计 + 板级支持（目前 8 款设备）

这是 FreeInk 最硬核的部分。已经支持了 8 款电子墨水屏设备：

特别提一下 M5 PaperColor。它是 Spectra 6 六色墨水屏，理论上能显示白、黑、红、黄、蓝、绿——但完整的六色刷新需要大约 15 秒。15 秒翻一页的书，谁也受不了。

FreeInk 搞了个骚操作：中断刷新。在刷新开始约 340ms 时强行截断，此时白色还没完全沉淀，显示的是暖黄色。他们把 UI 设计成「浅色纸」风格（深色文字 + 暖黄底色），利用这个未完成的刷新状态做出了可接受的快速翻页体验。

有人可能会觉得这叫「偷工减料」。我倒觉得这才是嵌入式工程师该有的思维——不跟物理定律较劲，而是顺着硬件的脾气来设计体验。

一个二进制，跑两台设备

FreeInk 还有一个细节让我印象深刻：编译模型。

Xteink X3 和 X4 都用的 ESP32-C3，引脚设计也兼容。FreeInk 的解法是——编译一次，两个设备都能跑。固件里同时携带两块板子的配置文件，运行时通过 I²C 指纹检测自动判断是哪种硬件，然后激活对应的配置。

这个设计在商业产品里很常见（比如同一套固件跑不同硬件版本的手机），但在开源项目里看到这么讲究的编译管理，说明团队里有做量产产品的人。

这跟 unobox 是什么关系？

既然这是我的博客，免不了要扯一扯自家的孩子。

FreeInk 做的是硬件路线——你买一块 ESP32 开发板 + 电子墨水屏，刷上 FreeInk 的 SDK 和固件，得到一个真的阅读器硬件。

unobox 做的是纯前端路线——你打开浏览器，访问一个页面，得到一个阅读器。

两条路线的选择其实取决于你的场景：

想要通勤路上不用带手机、看一天不充电？ FreeInk 路线。电子墨水屏的续航不是以天计，而是以周计的。

想要上班摸鱼时在电脑上偷偷看书？ unobox 路线。浏览器打开就行，不用装任何东西。

想要一个像 Kindle 但不受亚马逊绑架的阅读器？ 两条路线都能回答这个问题，但路径不同。

有趣的是，FreeInk 的排版引擎架构和 unobox 的 Epub.js 渲染在思路上是殊途同归的。它们都有一个「解析 → 排版 → 缓存 → 渲染」的流水线。只不过一个跑在 ESP32 的 512KB PSRAM 里，一个跑在 Chrome 的 V8 引擎里。物理限制不同，但解决的问题是同一个：怎么让 EPUB 看起来舒服。

一些不那么完美的角落

光说好话不是我的风格。FreeInk 现在还在很早期的阶段（GitHub 上 SDK 只有 68 个 star），距离一个普通用户能用的完整阅读器，还有不少路要走：

1. 文档还在填充中。 站点上 Architecture、Adding a device 这些页面已经有了，但很多 API 的详细参考还是占位符。
2. 中文排版支持未知。 EPUB 中文排版是个大坑——竖排、注音、中英文混排的字间距——我没看到 FreeInk 在这些方面有特别的处理。考虑到团队似乎是英文背景，这块可能需要社区贡献。
3. 需要一定动手能力。 不是买了就能用。你得先弄一块支持的开发板，装好 PlatformIO，clone SDK，写自己的固件，然后编译烧录。这个门槛对普通读者来说不低。

但这些都不致命。开源项目最动人的地方就在于——只要方向对了，缺陷可以靠社区慢慢补上。

FreeInk 能不能成长为电子墨水屏世界的 Linux，现在下结论太早。但至少有一点值得庆祝：电子书阅读器的版图上，终于有人在认认真真做「全栈开放」这件事了。

下一篇文章我会聊聊开源阅读器世界的两个阵营——硬件路线的 FreeInk 和软件路线的 unobox——看看它们各自的逻辑、各自的局限、以及它们如何在不竞争的前提下互相成就。

📚 下一篇：硬件开源 vs 软件开源 →