旧Kindle变身手写板：从触摸事件到E-ink刷新的嵌入式实践

Kindle Paperwhite 这台设备，在绝大多数人手里最终的归属就是“盖泡面神器”，吃灰几年后连充电口都积了灰。但总有一批人不这么想——他们看到的是那块售价不过百元、功耗极低、在强光下还能保持极高可读性的电子墨水屏，以及Kindle背后一整套经过深度定制的嵌入式Linux系统。Fingerink 这个项目的切入点，恰好就是这条“旧设备再利用”路上最吸引人的一道题：既然Kindle的触控和残影一直是它的软肋，那能不能跳过官方 SDK，直接在老的 Kindle Paperwhite 上，用自己的手指去写点东西？

以我看，这件事真正值得关注的地方，不是“用手写字”这个功能本身有多新奇，而是它背后做了一整套从触摸硬件层到内核输入事件、再到电子墨水屏图像渲染的完整链路闭合。这是一篇非常适合嵌入式 Linux 和物联网开发者拿来当案例拆解的实操样本。如果你平时主要写 Java 或 Python 业务代码，可能很少有机会认真思考“屏幕上的每一帧画面是如何被刷出来的”这个问题。而 Fingerink 给了一个窗口：原来在一块只有 300 PPI 的黑白屏上做实时手写，要想不卡顿、不残影、不误触，真的有那么多工程细节可以探索。

这篇文章，我会先把 Fingerink 这类项目真正解决的技术难题拆开讲清楚，然后再给出一个在通用 Linux 输入子系统上复现这套手写逻辑的完整思路和可落地代码框架。无论你是想折腾手里的旧 Kindle，还是想理解电子墨水屏触控驱动的原理，这篇文章应该都能给你一个比较直观的答案。

1. 这篇文章真正要解决的问题

很多人看到“复古手写板”的第一反应是：“这不就是个画图板吗？有什么技术含量？”如果你真这么想，说明你还没意识到这里面的第一个核心矛盾：Kindle Paperwhite 的硬件设计初衷是“阅读”，它的屏幕刷新率和触控采样率，天生就没有考虑过“书写”这种高实时交互场景。

具体来说，这里的难点分三层：

• 第一层：触控输入延迟。电容屏的触控事件从硬件中断触发、到内核驱动上报、再到上层应用拿到坐标，本身是一条比较长的路径。而在 Kindle 这种性能有限的设备上，系统中还跑着许多守护进程，事件响应的实时性并不高。如果你看过原始项目的讨论，会发现开发者很早就意识到，如果直接拿普通的触摸坐标去做全屏重绘，那个延迟会让人崩溃。
• 第二层：电子墨水屏的物理刷新特性。电子墨水屏不是液晶屏，它靠电场驱动微胶囊里的黑白粒子上下浮动。电压切换和“墨滴”沉淀都需要时间，这导致它天生就有残影（Ghosting）问题。你在屏幕上写一笔，如果不做特殊处理，之前写过的字迹就会像“橡皮擦没擦干净”一样留在背景上。
• 第三层：内存与性能占用。老款 Kindle Paperwhite 的处理器和内存都非常有限，在后台跑一个完整的图形界面应用本身就很吃力。Fingerink 要想实现“跟手”的手写效果，只能在渲染策略上做文章，比如局部刷新、抖动算法或者降低灰度等级。

所以，你把“用旧 Kindle 手写”这个标题翻译成技术语言，它真正在解决的问题是：在一个性能受限、屏幕刷新有物理时延、输入采样率不高的设备上，如何利用最小资源代价实现相对流畅的交互绘制。这才是值得技术人员关注的本质。

如果你手里恰有一台电池鼓包但屏幕完好的 Kindle Paperwhite，或者你正在做一个基于树莓派的电子墨水屏笔记项目，这篇文章能帮你省掉很多走弯路的时间。下文会从硬件驱动、Linux 输入设备、绘制管线这三个层面来完整拆解。

2. 基础概念与核心原理

在动笔写代码之前，有必要先把几个关键术语说清楚。因为 Fingerink 这类项目，新手最容易在“我以为我懂了”的地方翻车。

2.1 电子墨水屏（E-ink）与普通 LCD 的本质区别

普通手机屏幕是主动发光型，当你把手指放上去，屏幕会在极短的时间内刷新对应区域。而 E-ink 屏幕是被动反射型，它是通过电场驱动“黑白小球”翻转来形成画面的。每一次刷新，实际上就是在给一大堆微胶囊充电。这个物理过程的代价就是：

• 刷新速度慢，尤其是全局刷新（从白到黑），通常需要几百毫秒甚至更长。
• 有残影，如果你刷新部分区域，前一次的画面会残留在墨滴中。
• 没有背光（Paperwhite 虽然有前光，但那是用来照明屏幕表面，不影响墨水粒子运动）。

理解这个表，你才能明白为什么 Fingerink 在手写时需要特别设计一个“墨水笔划”缓冲区，而不是像手机备忘录那样直接全屏更新。

2.2 触摸控制器与内核输入事件（Input Subsystem）

Kindle 触摸屏本身属于电容式触摸屏，它的底层一般挂着一颗触摸控制芯片（常见的有 Synaptics、FocalTech 等）。这颗芯片对外暴露的接口，在 Linux 内核中通常会抽象成一个名为/dev/input/eventX的设备节点。

当你的手指在屏幕上滑动时，触摸芯片会产生以下类型的事件：

• ABS_MT_POSITION_X：当前触摸点的 X 坐标。
• ABS_MT_POSITION_Y：当前触摸点的 Y 坐标。
• BTN_TOUCH：触摸状态（按下/抬起）。

Linux 内核会把底层上报的原始信号，通过evdev驱动程序统一转换为标准事件，应用层通过read()这个设备节点就能拿到坐标。

在 Fingerink 的实现里，读触摸点不是关键，关键是把这些坐标点和 E-ink 屏幕的绘图坐标系对齐。屏幕的旋转、坐标轴的翻转，任何一个偏差都会让笔迹画在手指十几毫米开外的地方。

2.3 KUAL / Jailbreak：进入 Kindle 内部世界的钥匙

Kindle 本身是一个高度封闭的系统。你可以在根目录放一个名为kindle的目录，但内核并不认识。要想在 Kindle 上运行自己的程序，第一步通常是“越狱”并安装一个叫KUAL（Kindle Unified Application Launcher）的工具。

KUAL 本质上是一个扩展启动器，它能让你从 Kindle 的图书列表中启动第三方程序。Fingerink 这类项目，基本也是通过 KUAL 作为一个“附加程序”跑起来的。不过，这里要特别提醒一点：越狱有风险，会破坏设备的保修，如果你不确定自己在做什么，建议先找一台不重要的机器来练手。

3. 环境准备与前置条件

你要想实际运行这类手写应用，需要准备的东西不多，但每一步都容易踩坑。下面是我整理的通用清单。因为 Kindle 的固件版本繁多，具体版本号以你实际设备为准，本文重点演示的是一种思路，而不是某个特定固件的模板。

3.1 硬件与环境

• 一台 Kindle Paperwhite（任何一代都可以，老款性能虽然差，但原理完全一致）。
• 一根数据线，用于拷贝文件。
• 一台可以访问 Kindle 根目录的电脑（Windows/macOS/Linux 均可）。
• 网络环境：需要能够访问工具托管站点，具体看项目 README，这里不提具体站点。

3.2 软件准备

• Kindle 越狱工具包（对应你的固件版本）。
• KUAL 脚本包。
• Python 运行时（Kindle 系统自带的 Python 版本很老，如果项目需要，你可能需要自行交叉编译一个 Python 二进制放到 Kindle 上）。
• evdev用户态读取工具。

3.3 第一步：确认设备能读到触摸事件

在你开始写任何代码之前，请务必先证明你的 Kindle 的触摸输入设备节点是暴露给用户的。可以通过 SSH 或者 KUAL 的终端模拟器进入 Kindle 的 shell，执行以下命令：

# 进入根文件系统，一般在 /dev/input/ ls /dev/input/ # 期望看到 event0、event1 这样的设备文件 # 查看具体是哪一个设备是触摸屏 cat /proc/bus/input/devices

在输出中，你会看到类似下面的内容：

I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="kindle-touch" P: Phys=... S: Sysfs=... H: Handlers=event1

如果看到kindle-touch或者类似的名称，说明触摸事件被正常注册到了 event1（具体索引以实际为准）。这一步如果失败了，后面的所有工作都无从谈起。

3.4 确认项目依赖

Fingerink 这类项目，通常是用 C 语言或 C++ 编写的，因为 Kindle 的 CPU 和内存实在太有限，Python 的运行时开销在绘制时会是灾难。如果你要在 Kindle 上交叉编译，你需要在电脑上建立一个交叉编译环境，或者直接使用设备上已有的工具链。不过更稳妥的方式是看项目源码里是否提供了预编译的二进制。

4. 核心流程拆解

把 Fingerink 的整体设计思路看成一个“流水线”，可以抽象成四个阶段。这一节我们只讲清楚每阶段“为什么这样做”，具体的代码实现在下一节给出。

4.1 触摸事件读取与坐标归一化

程序启动后，首先要打开一个输入设备文件，比如/dev/input/event1，然后进入一个无限循环，不断read()这个设备。read()返回的数据是一个struct input_event结构体，里面记录了事件类型、代码和值。

这一步最关键的一个错误处理是：触摸事件上报频率极快，如果你每收到一个事件就立刻去绘图，设备很容易被高频率的重计算拖垮。所以通常的策略是：

1. 读取到坐标后，先缓存在内存中的点集里。
2. 设定一个时间阈值（比如 30ms），如果在这个时间内没有新事件，就把这一整段笔划交给后续的渲染管线。

4.2 笔划采样与轨迹平滑

触摸屏的原始采样点通常伴有抖动，尤其是 Kindle 这种老式触摸屏。如果直接把这些带毛刺的点连线，画出来的线条会有锯齿。为了视觉上更接近真实墨水笔迹，需要在采样点之间插入贝塞尔曲线插值。

这一步的核心参数是降采样间隔和平滑系数。参数设大了，笔画会变得圆润，但延迟会走高；参数设小了，虽然跟手但会出现波浪线。

4.3 电子墨水屏刷新策略

这是整个项目里最关键，也最容易暴露物理限制的地方。我在 2.1 节提到过 E-ink 屏的残影问题。Fingerink 的常见做法是：

• 局部刷新：只在墨迹所在的矩形区域做电压驱动，其他区域保持静止。
• 灰度反色补偿：在绘制前景色（通常设为黑色）的同时，在相邻像素做反色或空白处理，以减少视觉残影。

如果你直接全局刷新，那么每写一划屏幕都会闪一下白帧，别说写一段话，写几个字眼睛就受不了了。

4.4 保留笔迹画布

最后一个关键设计是“笔迹画布”。Kindle 的显存是有限且受限的。当你在触摸屏上滑动时，老的一笔轨迹并不会自动消失。如果程序没有显存管理的概念，画完第一笔再去画第二笔时，第一笔可能会被 E-ink 控制器粗暴地擦掉。

Fingerink 的方案通常是维护一个“帧缓冲（Framebuffer）”。每次绘制前，先把上一笔的图像拷贝到临时画布上，再叠加新笔划，最后统一提交给窗口管理器。这跟你在手机画图软件里的“图层”概念是相通的。

5. 完整示例与代码实现

因为 Kindle 上的 C 语言交叉编译流程比较繁琐，本案例我们先用 Python 的evdev库在 PC 上模拟一遍完整的手写读取逻辑，然后再给出 Kindle 上更贴近真实场景的 C 语言版本核心逻辑。这两段代码合在一起，基本就是 Fingerink 从“触摸输入”到“笔迹生成”的骨架。

5.1 在 Linux 桌面上获取触摸事件（Python 示例）

这段代码的目的是验证你的触摸屏事件读取链路，同时演示坐标打印。运行环境需要 Linux 系统，并安装evdev库：

pip install evdev

# 文件路径: touch_monitor.py # 功能：在桌面上打印触摸屏的绝对坐标事件 import evdev # 先找到触摸屏的路径 devices = [evdev.InputDevice(path) for path in evdev.list_devices()] for device in devices: if "touch" in device.name.lower() or "kindle" in device.name.lower(): print("找到设备:", device.path, device.name) touch_device = device break else: print("没有找到触摸设备，请检查 /proc/bus/input/devices") exit(0) # 设置抓取模式，防止系统去处理事件 touch_device.grab() print("开始监听触摸事件，按 Ctrl+C 退出") for event in touch_device.read_loop(): if event.type == evdev.ecodes.EV_ABS: if event.code == evdev.ecodes.ABS_X: x = event.value elif event.code == evdev.ecodes.ABS_Y: y = event.value elif event.type == evdev.ecodes.EV_KEY and event.code == evdev.ecodes.BTN_TOUCH: if event.value == 1: print(f"按下: 坐标 ({x}, {y})") elif event.value == 0: print("抬起")

通过这段代码，你能直观理解 Linux 输入子系统在应用层暴露了什么。Fingerink 的底层获取事件的方式，和这段代码是同一个套路，只不过把 Python 换成 C，以提高效率。

5.2 笔划数据结构的定义（C 语言片段）

在真正做手写时，你需要一个适合增量绘制的数据结构。下面是一个典型的笔划结构体定义，它维护了点的数组和长度：

// 文件路径: stroke.h // 功能：定义笔划结构体 #ifndef STROKE_H #define STROKE_H #define MAX_POINTS 512 typedef struct { int x; int y; int pressure; // Kindle触摸不一定有压力，这里预留 } Point; typedef struct { Point points[MAX_POINTS]; int count; int active; // 1 表示正在书写，0 表示一个笔画结束 } Stroke; // 添加一个点到笔划中 int add_point_to_stroke(Stroke *s, int x, int y) { if (s->count >= MAX_POINTS) return -1; s->points[s->count].x = x; s->points[s->count].y = y; s->count++; return 0; } #endif

5.3 E-ink 绘制逻辑伪代码（模拟）

下面这段代码演示了如何在“收到笔划结束信号”后，把这一整段笔划渲染到屏幕的一个局部缓冲中。注意，这里我们不做真正的驱动层绘制，只模拟了“采集点 -> 画线 -> 刷新”的流程：

// 文件路径: render.c // 功能：演示如何将笔划点集渲染到一个像素缓冲区 #include <stdio.h> #include <string.h> #include "stroke.h" #define SCREEN_WIDTH 800 #define SCREEN_HEIGHT 600 // 模拟一个像素缓冲区，1 代表黑，0 代表白 unsigned char framebuffer[SCREEN_HEIGHT][SCREEN_WIDTH]; // 画线：在缓冲区内画一条直线（简化实现） void draw_line(unsigned char fb[SCREEN_HEIGHT][SCREEN_WIDTH], int x0, int y0, int x1, int y1) { int dx = abs(x1 - x0), sx = x0 < x1 ? 1 : -1; int dy = -abs(y1 - y0), sy = y0 < y1 ? 1 : -1; int err = dx + dy, e2; while (1) { if (x0 >= 0 && x0 < SCREEN_WIDTH && y0 >= 0 && y0 < SCREEN_HEIGHT) { fb[y0][x0] = 1; // 画成黑点 } if (x0 == x1 && y0 == y1) break; e2 = 2 * err; if (e2 >= dy) { err += dy; x0 += sx; } if (e2 <= dx) { err += dx; y0 += sy; } } } // 将一笔画完的点集绘制到 framebuffer void render_stroke(Stroke *s) { if (s->count < 2) return; for (int i = 0; i < s->count - 1; i++) { // 将触摸坐标直接映射到屏幕坐标，真实项目中需要做缩放/旋转 draw_line(framebuffer, s->points[i].x, s->points[i].y, s->points[i+1].x, s->points[i+1].y); } // 这里可以触发 E-ink 的局部刷新 API，比如 eink_cpu_update() // update_screen_partial(SCREEN_WIDTH, SCREEN_HEIGHT); } int main() { // 初始化 framebuffer 为白色（全 0） memset(framebuffer, 0, sizeof(framebuffer)); Stroke aStroke; memset(&aStroke, 0, sizeof(aStroke)); // 模拟收下几个触摸点 add_point_to_stroke(&aStroke, 100, 100); add_point_to_stroke(&aStroke, 200, 150); add_point_to_stroke(&aStroke, 300, 250); // 渲染笔画 render_stroke(&aStroke); // 打印一行引子像素，检查是否有黑点写入 printf("Pixel at (150, 125): %d\n", framebuffer[125][150]); return 0; }

5.4 Kindle 上的实际运行方式

如果你得到了编译好的 Kindle 二进制文件，通常它的放置位置是/extensions/fingerink/目录。然后，你可以在 KUAL 的目录结构中加入一个启动脚本：

#!/bin/sh # 文件路径: /extensions/fingerink/bin/fingerink.sh cd /extensions/fingerink/bin ./fingerink &

然后回到 Kindle 首页，打开 KUAL，你就会看到新出现的 Fingerink 入口。点击它，程序就开始监听触摸屏事件了。

6. 运行结果与效果验证

一个“能用”和“好用”的手写项目，二者差距主要看以下验证维度：

6.1 验证输入链路是否打通

你在 Kindle 上运行程序后，第一件要验证的事是：程序是否真的能拿到事件。如果程序启动也没有报错，但你画一笔屏幕上什么都没发生，大概率是坐标系映射错了，或者程序读错了设备节点（读到了物理键盘，而没读到触摸屏）。

在 PC 上使用前面 5.1 节的 Python 脚本，你可以进行同样的验证。如果终端上能输出坐标，那说明输入这一侧没问题。

6.2 验证延迟是否可接受

手写应用最大的敌人是延迟。你在 Kindle 屏幕上画一条线，从“手指抬起”到“屏幕上出现完整笔迹”，这个间隔如果超过 200ms，手感就会非常怪异。Fingerink 如果做得足够好，会让你感觉笔迹是“跟手”的。

一个直观的验证方法：用手机秒表录屏，画一笔然后回放慢速，数一下帧数。如果你做不到这种精细测试，起码用手指快速画一个圆圈，如果圆圈的形状保持圆滑，没有明显的断线或锯齿，就说明采样和平滑逻辑工作正常。

6.3 验证残影控制

E-ink 的残影问题，只有在写满大半页时才会彻底暴露。如果你写了二十个字之后，肉眼能清晰看到前面几笔的轮廓依然“隐隐约约”留在背景上，那说明局部刷新策略没有做边界处理。

正确做法是每一笔结束都对该笔划区域做一次“清屏补偿”。如果你的程序没有这个环节，至少你可以通过周期性地全屏刷新来“洗掉”残影，这也是一种在体验和稳定性之间妥协的策略。

6.4 失败时的第一排查步骤

如果程序启动后直接崩溃，第一件事不是查逻辑，而是看是否缺少动态库。Kindle 的 rootfs 是只读的，如果你没把程序依赖的.so库拷贝进/usr/lib或程序的本地目录，链接器会立刻报错。你可以进入 shell 用ldd ./fingerink查看缺了哪个库。

7. 常见问题与排查思路

作为 CSDN 读者，遇到问题先想怎么排查比直接问“怎么办”更高效。我在开发这类设备的过程中，发现下面几个问题是大家问的最多的，特意整理出来。

7.1 触摸坐标和屏幕显示方向不一致

Kindle Paperwhite 的屏幕在竖屏下正常显示，但如果程序内部使用了横屏的位图缓冲，你画的竖直直线可能显示成水平线。这不是程序逻辑错误，而是坐标轴没有在初始化触摸设备时完成校准。最简单的处理方式：画两笔来试探，打印原始坐标。如果发现横向换成了纵向，直接交换 X/Y 轴映射关系，这比在代码里加入旋转矩阵要省事得多。

7.2 笔画断断续续，像虚线

这个问题大概率不是程序 bug，而是 Kindle 触摸屏的采样率本身偏低，或者你设置的时间阈值太激进。当你快速滑动时，如果触摸点之间的间隔太大，后续的插值算法可能因为点都太远而画出来的线段会显得断裂。解决方案是适当增大贝塞尔插值的控制点，让路径在空档区域被算法“填”起来。

7.3 写着写着就出现整屏黑闪

黑闪是 E-ink 的“全局刷新”标志。如果你的程序为了清除上一笔的残影，而在每次笔划结束时都强制执行一次全局刷新，那么你得到的体验会非常糟糕。更好的方式是把“去残影”动作推迟到用户停顿的时候，比如检测到 2 秒没有触摸事件时再做全屏清洗。

7.4 程序在 Kindle 上卡死

如果你发现程序运行一段时间后屏幕无响应，要考虑是否内存越界了。E-ink 设备不会像 PC 那样弹“内存不足”对话框，它可能直接死机。Fingerink 的处理方式是：笔划缓冲区是有上限的（MAX_POINTS），一旦满了就丢弃最早的点，同时定期释放不再使用的临时缓冲。

8. 最佳实践与工程建议

从“能跑”到“能日常用”，中间隔着不少工程细节。我根据自己的实践，把一些关键教训整理成以下建议。

8.1 永远不要直接操作硬件驱动层

如果你在 Kindle 这样封闭的设备上开发，一定要记住：接官方 SDK 是不现实的，但你可以使用内核已经暴露的/dev/input/接口。当你需要写底层驱动时，第一选择是看内核模块是否已经加载，而不是自己重新编译一个。你要做的是“用户态应用 + 高效 IO”，而不是去碰协议栈。

8.2 构建一个高效的采样循环

在 C 语言中，打开设备文件后，建议使用epoll或select来监听事件，而不是用多线程 + 阻塞 read。Kindle 的 CPU 资源太少，线程上下文切换的损耗会被放大。用一个单线程的while (poll() > 0) { handle_event(); }循环，既能保证实时性，又不会给系统增加额外负担。

// 文件路径: event_loop.c // 功能：使用 poll 监听触摸事件，并读取坐标 #include <stdio.h> #include <poll.h> #include <fcntl.h> #include <linux/input.h> int main() { int fd = open("/dev/input/event1", O_RDONLY); if (fd < 0) { perror("open"); return -1; } struct pollfd fds[] = { {fd, POLLIN, 0} }; struct input_event ev; while (1) { int ret = poll(fds, 1, 1000); // 1 秒超时 if (ret > 0 && (fds[0].revents & POLLIN)) { read(fd, &ev, sizeof(ev)); if (ev.type == EV_ABS) { // 在这里处理坐标 printf("code=%d value=%d\n", ev.code, ev.value); } } } close(fd); return 0; }

8.3 关于 E-ink 渲染：提前做“黑区”规划

我在 4.3 节提到过局部刷新。在实际项目中，更推荐你把整个屏幕分成若干个固定大小的“瓦片”区域。每次更新时，你只需要把所有包含笔划变化的瓦片打包，一起发给刷新 API。这样做的好处是，你不用担心旧笔迹因为刷新区域变大而被意外擦除，还能显著减少计算量。

8.4 安全提醒：越狱与数据备份

动手之前，先对 Kindle 的整个文件系统做一个镜像备份。越狱操作本身具有一定的风险，不稳定的第三方内核模块可能会导致设备变砖。操作过程中，尽量保持外接电源供电，避免因电量耗尽导致写入中断。不管是在设备上安装任何程序，都不是官网正式渠道支持的，请评估清楚后再动手。

8.5 当你不知道该把代码放在哪一层

很多从业务开发转过来的人，一开始会纠结：Fingerink 应该写成内核模块吗？不该。内核模块出错会导致整机崩溃。最佳实践是在用户态做所有可视化操作，只通过/dev/input/和/dev/fb（帧缓冲设备）跟内核交互。如果项目对刷新频率要求极高，你可以考虑用mmap方式直接访问帧缓冲内存，跳过标准的 read/write 调用。

9. Fingerink 带来哪些启发

过去我们对一台旧 Kindle 的期待，大多是“看看书，偶尔刷个进度”。Fingerink 这类项目最吸引人的地方，是它证明了只要你能摸透硬件暴露的接口，一台已经停产的老设备，依然可以完成一些被官方战略抛弃的创新。

从技术上看，它跟做树莓派或RK3399开发板上的 E-ink 面板逻辑没有任何本质不同：触摸层拿到坐标，坐标系对齐，数据刷到屏幕。差别只在于 Kindle 的封闭生态需要你先解锁一把“越狱的钥匙”，而这是很多只玩开源硬件的开发者没有试过的门槛。

如果你想把这件事研究得更深入，可以按以下路径去延伸学习：先尝试在 Linux PC 的触摸屏上实现一个 EVDEV 鼠标手势识别；然后移植到一个普通的 E-ink 开发板；最后再回头挑战 Kindle。你会发现，无论是哪一个阶段，你遇到的最难啃的骨头，永远是屏幕刷新策略的优化，而不是“读事件”这层代码。

Fingerink 本身只是一个很小的手写工具，但当你把它背后的输入子系统、触摸坐标映射、电子墨水屏刷新机制这几个知识点串起来之后，你得到的是一套在低功耗嵌入式设备上实现人机交互的通用方法论。建议你收藏这篇文章，下次在群里看到有人抱怨 Kindle 只能盖泡面的时候，可以非常平静地转发给他，然后告诉他：其实它还可以变成一块非常安静的手写板。