e-ink UI 开发第一件事不是先写界面而是先接受它是一块“慢屏幕”。电子墨水屏的物理成像方式和普通 LCD/OLED 完全不同导致你以前熟悉的动画、渐变、滚动、即时反馈在这里几乎都要重来。如果你正在做 e-ink 阅读器、墨水平板应用、电子价签、桌面信息牌或智能家居面板这篇文章想跟你聊的是我在实际项目中沉淀下来的一些约定刷新策略怎么做、视觉怎么做减法、交互怎么设计、性能怎么控。最值得关注的点是e-ink UI 的价值不在把界面做得更炫而在于把每一次屏幕变化都控制得足够少、足够准。1. 先接受 e-ink 是一块“慢屏幕”能力边界决定设计底线在开始任何 UI 工作之前先盘点一下屏幕的物理能力和驱动方式。e-ink 不是把像素点亮而是让带电粒子在微胶囊中移动粒子迁移需要时间所以屏幕刷新天然比 LCD 慢。这个特性不是优化代码能解决的它决定了 UI 设计的基本约束。很多人拿到屏幕后第一件事就是写界面结果越写越痛苦因为很多看起来正常的设计在 e-ink 上会变成反复闪烁或者残影堆叠。1.1 刷新机制不是慢了一点而是运作方式不同普通屏幕可以逐帧刷新用户几乎感知不到刷新过程。e-ink 屏幕完成一次画面更新通常需要几百毫秒到数秒具体时间取决于屏幕尺寸、驱动芯片、温度以及刷新模式。更关键的是很多 e-ink 屏幕在更新过程中会出现明显的闪烁黑白色块交替扫过如果使用局部刷新画面中心区域可以保留但周围可能会留下“残影”。这说明 UI 不能像普通屏幕一样随意重绘。开发时首先要确认三件事当前屏幕是否支持局部刷新、支持的刷新模式有哪些、驱动库是否暴露了全刷和局刷的接口。很多情况下问题不是 UI 不好看而是每秒不知道被刷了多少次用户看到的是不断闪屏。所以 e-ink UI 开发的第一约定就是把“重绘”这件事当成一个高成本操作来对待。1.2 颜色与灰阶少就是稳定大多数 e-ink 屏幕只有黑白两色进阶型号支持 16 级灰阶或黑白红、黑白黄三色。支持的颜色越多刷新通常越慢画面更新时的视觉观感也可能更复杂。三色屏幕适合做信息看板和价签用来显示黑白红配色但红色区域一旦做过渡、渐变界面会显得很脏因为三色屏的显色颗粒和黑白灰阶不是同一个系统。如果要做的是电子书阅读器最好的选择通常是默认纯黑白灰度只用于图片或插画。UI 控件如果依赖颜色来区分状态比如绿色表示正常、红色表示错误在 e-ink 上要慎重。不同屏幕的灰阶表现差异很大浅灰在暗光下可能看不清深灰在残影背景下会显得很脏。更稳妥的做法是用线框、填充、图标位置和文字内容来传递状态信息颜色只做辅助。1.3 功耗模型与刷新频率e-ink 的核心优势是静态显示不耗电只有画面变化时才消耗能量。这意味着 UI 的“空闲状态”非常省电但如果你让程序无意义地定时刷新就会把这个优势毁掉。我见过不少项目明明只是显示时间却每秒整屏刷新一次电池很快就没了。这类场景应该只刷新秒表区域甚至只刷新分钟区域。如果屏幕内容根本没有变化那就不应该触发刷新。焦点变化、hover 状态、鼠标经过这类事件在 e-ink 上都不应该触发重绘。判断标准是每一次刷新都应该对应一个用户可感知的信息变化而不是一次内部状态变化。1.4 点亮后先做一次基线测试拿到新屏幕不要急着写界面。先把屏幕点亮逐个测试刷新模式。记录下这些信息全屏刷新一次需要多长时间刷新过程中是否出现强烈闪烁局部刷新一小时后残影是否积累到难以接受同一个区域连续局刷多次边缘是否出现明显痕迹当前温度下刷新速度是否有明显下降驱动库在刷新期间是否能响应查询还是必须阻塞等待。这些结果就是 UI 设计的边界条件。如果你发现局刷十几次后必须全刷一次那么在交互流程设计时就要预留这个全刷点。如果你发现温度低时刷新明显变慢那么户外设备的界面就要减少频闪更新。把基线数据写进开发文档会省掉后面很多来回报错。2. 刷新策略是 e-ink UI 的第一个约定界面设计可以慢慢调整但刷新策略从一开始就要定好因为它影响所有页面的行为。我通常把刷新分成三种全刷、局刷、定期清残影。三者不是随便选而是按场景走。2.1 全刷、局刷、定期清残影全刷适合页面整体切换、内容大面积变化、首次开机和系统状态恢复。优点是画面干净残影最少缺点是视觉上会闪一次黑白交替感比较强。如果频繁全刷用户会觉得屏幕在“刺眼地跳动”。局刷适合小范围状态变化比如页码更新、进度条前进、菜单高亮移动、章节标题变化。局刷的好处是用户视觉干扰小速度也比全刷快。但局刷不能无限次用时间一长上一次画面的影子会留在新画面上尤其在对比较明显的边缘区域。所以在设计方案时就要考虑“定期清残影”的时机。常见做法是每局刷 N 次或每隔一段时间强制一次全刷把残影清掉。N 的取值需要根据屏幕实测有的屏幕 10 次就要清有的可以撑到 50 次。不要一开始就把 N 设成固定值应该做成可配置参数并且把当前局刷计数显示在调试日志里。等到屏幕老化或温度变化导致残影变明显时只需要调整阈值不需要改 UI 代码。2.2 不要做传统意义上的动画这个可能是很多前端背景开发者最难接受的部分。e-ink 不适合做平滑动画因为每一帧都要驱动粒子迁移加上屏幕响应延迟所谓动画会变成一卡一卡的闪烁。如果偏要做结果往往是用户看到黑块来回跳动而不是流畅过渡。如果产品确实需要过渡尽量用离散状态切换。比如页面切换不要用滑动或渐变而是分成“当前页消失”和“下一页显示”两步。进度显示不要用连续进度条改用分段式步进或者只在关键节点更新百分比。倒计时不要逐秒刷新中间过渡改成按用户设置的粒度来更新。在 e-ink 上克制本身就是更好的体验。2.3 刷新请求必须排队因为一块屏幕同时只能执行一次刷新请求所以 UI 层经常出现的问题就是多个事件同时触发重绘屏幕驱动或渲染线程忙不过来最后出现花屏、撕裂、局部区域叠加显示不正常。更稳妥的做法是在 UI 框架里维护一个刷新队列。所有需要界面变化的事件都往队列里提交提交信息包含变更区域、是否强制全刷、有效期。刷新执行器从队列取任务完成一次刷新后再取下一个。如果同一个区域在短时间内收到了多个相同请求直接合并成最新状态。这样既能减少刷新次数也能避免屏幕驱动并发冲突。这里给一个最简单的思路实际实现可以按语言和框架决定refresh_queue.add(area, force_fullFalse) if not refreshing: process_queue() process_queue(): req refresh_queue.pop() if req.force_full or req.area.size threshold: display.full_refresh() else: display.partial_refresh(req.area) wait_for_refresh_done() ghost_count 1 if ghost_count max_partial_refresh_before_clean: display.full_refresh() ghost_count 0阈值根据屏幕实测调整。另外刷新队列一定要打日志因为排查 UI 问题时最需要知道“到底是谁触发了刷新”。2.4 更新类型与场景对照表下面这个表是我做阅读器和信息屏时常用的更新策略可以直接作为评审时的检查清单。场景建议更新方式原因翻页全刷内容大面积变化必须清干净旧内容页码/进度局刷变化区域小不需要全屏闪目录高亮移动局刷只在列表区域做小范围更新设置项变化局刷单个控件状态变化避免全局闪烁弹出对话框全刷涉及遮罩和大面积边框局刷容易残留定时刷新时间局刷对应区域不要整屏刷仅更新时间区域低电量警告全刷需要强提醒同时清一下残影长时间无操作唤醒全刷状态恢复确保画面干净这个表不是死的如果屏幕局刷质量特别好弹窗也可以考虑局刷。但是每次改动策略都要实际跑几十次不要只看单次效果。3. 视觉排版规范为低灰度、高残留做减法很多 e-ink UI 看起来“脏”不是分辨率不够而是视觉元素太多。普通屏幕可以用颜色、投影、阴影、透明度和细线来制造层次e-ink 上没有这些手段残影还会让额外线条更明显。3.1 黑白优先灰度只做辅助在 e-ink 上做视觉第一原则是默认只使用纯黑和纯白。这样能得到最高对比度刷新后最干净。灰度可以用于图片预览或大面积装饰背景但用量要少。浅灰文本在小字号下很难看清深灰文本在残影区域容易和背景糊在一起都不适合作为正文。如果你有品牌色也要转成黑白灰后检查可读性。比如某个品牌色是浅蓝色转到 e-ink 可能只是浅灰配合白色背景对比度偏低界面上显得很无力。开发时最好能把设计稿转成 1-bit 或 4-bit 灰度在目标设备上预览一遍再定稿。这里我可以给你一个比较实用的流程先把设计稿导成灰度图再转成 PNG 放到设备上用屏幕实际看一页。如果这页在局刷后仍有明显残影那就说明元素对比度或线条密集程度超标了。3.2 字体、字号、行距要重新校准中文内容在 e-ink 上尤其要关注字重。太细的字体在屏幕上可能出现笔画缺失特别是局刷以后字的边缘会残留上一帧的印记。建议选用标准或中等偏粗的字重字号不要小于 12pt 或同等级别具体要看屏幕分辨率和观看距离。行距也要比手机屏幕更大。因为 e-ink 刷新不是瞬时完成相邻行之间的残留容易干扰阅读。行间距最好达到字号的 1.5 倍以上段间距也要明确。正文区不要顶到屏幕边缘四周留出均匀边距一方面方便手指握持另一方面减少边缘残影的影响。3.3 大面积反白和纯黑块要慎用反白设计也就是黑底白字在 e-ink 上视觉冲击力很强但刷新时会带来非常明显的整屏闪烁黑白粒子大幅翻转给人感觉像在放电。而且黑色区域如果有轻微残影浅色文字很容易显得脏。如果某个页面必须使用反白比如夜间模式或强调区域要限制它的面积。按钮用黑底白字展示选中状态可以但不能让整屏变成黑底。纯黑块也不要紧贴高对比文字边缘否则残影会非常明显。设计时可以让黑色区域稍微浅一点比如用 80% 黑或深灰虽然理论上“不够纯”但实际观感更稳。3.4 图片要预处理不要运行时硬转e-ink UI 经常要显示封面、插图和二维码。这类图片如果直接按原始彩色图贴进去不仅会让屏幕刷新变慢还容易出现密密麻麻的噪点。正确做法是在进入屏幕前完成转换。转换流程大致是把图片统一缩放到目标尺寸再转成灰度然后按需求做抖动或阈值化。阈值化会损失很多层次适合线稿和文字抖动可以保留细节适合照片和插画但抖动的点阵在局刷时容易和残影叠加。所以我的建议是主要页面用阈值化详情页需要图片时再做一张专门的抖动版本。另外图片最好提前放进资源目录不要在界面每次显示时重新计算。如果确实需要运行时生成也放进后台任务生成完再触发刷新不要让主线程在刷新期间做大量图像处理。3.5 从 e-ink 小说转换看内容排版很多人搜索“e-ink 小说转换器”表面上是想要把 TXT 或网页小说转换成阅读器能打开的格式但真正要解决的问题是排版。原始文本可能没有分段、没有标点统一、一行很长、字体设置不合适直接丢到 e-ink 上根本不可读。一个合格的 e-ink 小说转换器本质上就是在做 e-ink 内容排版规范正文统一缩放重排、行距加大、识别章节目录、生成分页、去掉广告和多余图片、选择适合黑白的字体、把长按翻页等操作映射成可靠的翻页动作。开发这类工具时不要把注意力全放在格式转码上更值得做的是定义一套“e-ink 友好的内容结构”。这也是 e-ink UI 开发里最容易体现价值的地方不是界面多漂亮而是阅读时不用频繁操作、不用长时间盯着残影。4. 交互设计接受慢反馈但别让用户以为卡死e-ink UI 的交互原则和手机完全不同。手机讲究跟手、平滑、立即响应e-ink 因为刷新慢必须接受“反馈有延迟”的现实同时用各种方式减少用户焦虑。4.1 反馈方式要换思路如果用户点击某个按钮后屏幕要半秒甚至更久才能反应用户很快就会开始又点一次。所以交互上要做“操作已确认”的即时反馈。这个反馈不一定要来自屏幕本身可以搭配提示灯、声音、震动马达。屏幕刷新前先点亮一个 LED 或发一声短提示让用户知道系统收到了操作。如果只用屏幕反馈那么要设计一个低成本的视觉确认。比如点击翻页后先在一个小区域显示“Loading”或页码变化然后再做整页全刷。不要等到整页刷新完成后才给反馈那样体验太闷了。页面刷新期间还要把输入先屏蔽避免用户连点导致任务堆积。4.2 防误触、防重复触发e-ink 屏幕本身有触控层时触控响应通常也比手机慢。常见问题有两个一个是用户连续触摸系统把同一事件触发了很多次另一个是触摸位置偏差点按小按钮很容易误触。所以按钮尺寸要够大一般不建议小于 48px 的触控区域具体按屏幕 PPI 调整。按钮形状做成清晰的矩形或圆形状态切换的视觉差异要明显。在代码层面可以加入防抖和冷却时间。比如某按钮触发后 1 秒内忽略第二次点击翻页动画期间忽略新的翻页请求。不要用线程去手动延时最好在事件入口处做统一判断。这样既能减少刷新队列堆积也能避免残影加重。4.3 少滚动、多分页、浅层级滚动在 e-ink 上非常尴尬。连续滚动要么拖动时画面一直刷新要么抬起手才更新两种体验都很难受。阅读类应用应该坚持分页一页一页地翻列表类界面尽量让一屏展示完所有选项如果项目太多就分成几页或用展开式层级而不是无限滚动。菜单层级也要控制。普通 App 可以做一个复杂的二级三级菜单e-ink 设备回到上一级也要刷新一次层级越深用户等待越久。尽量让核心操作在首层完成比如阅读器首页直接放最近阅读的书、设置页合并低频项、文件管理只保留必要的过滤入口。能减少一屏刷新就减少一屏刷新。4.4 休眠、唤醒、状态恢复e-ink 设备的省电优势依赖休眠机制。UI 设计时要把“空闲多久进入休眠”作为一个显式参数并保证醒来后画面状态和休眠前一致。这里容易踩的坑是系统休眠后内存或渲染状态丢失唤醒时屏幕只刷新了一半就停在白屏。更稳妥的流程是进入休眠前保存当前页面的逻辑状态和渲染快照唤醒后先做一次全刷把之前画面重新画出来再恢复到交互状态。不要依赖硬件自动保留 e-ink 画面虽然静态显示不耗电但软件状态不恢复用户看到画面却无法继续操作体验会很差。5. 性能与资源管理在受限设备上跑 UIe-ink 设备不一定是高配设备。阅读器可能只有几百兆内存处理器的性能也远不如手机。UI 框架选型和资源管理要按嵌入式设备的逻辑来做。5.1 选框架先看刷新控制而不是看组件多寡评估一个 UI 框架能用不能用不是看按钮、列表、弹窗有多丰富而是看它能不能控制刷新策略。能区分全刷和局刷、能拿到脏矩形区域、能在刷新期间屏蔽渲染才是关键能力。如果框架每次状态变化都重绘整个画布那组件再多也不适合 e-ink。实际项目中轻量方案往往更稳。常见做法是直接操作 framebuffer自己维护界面状态和刷新区域或者使用跨平台框架但只把它当画布来用。具体选型要看团队熟悉度和设备平台没有哪个方案一定最好但有一点可以确定越重的界面框架越难控制刷新细节出了问题也越难排查。5.2 画布、位图、静态元素分离很多 e-ink UI 卡顿原因是每次刷新都把整屏画面重新渲染一遍。更合理的做法是拆分图层静态背景单独保留一张位图动态区域单独绘制刷新时只把需要变化的区域合成并提交。比如阅读器的页面正文背景、页眉页脚、页码和翻页按钮可以分成静态层和动态层。翻页时正文区全刷页脚页码局刷标题栏甚至可以不动。这样每一次翻页的刷新区域更小等待时间更短残影也更可控。注意位图数量要控制尤其不要为每个界面保留过大的缓存位图内存不够时优先释放不可见页面。5.3 批量合并且只更新变化区域如果在很短的时间里发生了多次状态变化比如用户快速翻了 5 页不要每一页都立刻刷新。可以把后 4 页变化合并成一次最终状态触发一次全刷。这个思路要在刷新队列里实现同一区域的待处理任务只保留最新的并且设置一个最短刷新间隔比如 300 毫秒内相同区域只允许提交一帧避免瞬时高频刷新。“只更新变化区域”不是简单地对整个屏幕做 diff。整屏 diff 的成本可能比局刷还高尤其是计算颜色差值需要遍历像素。更高效的方式是业务层主动标记 dirty rect比如“页码位置变了”“进度条位置变了”告诉刷新层具体区域而不是让刷新层自己猜。5.4 优先级和定时器设备上不只有 UI 在跑可能还有文件同步、索引、通信、日志等后台任务。如果后台任务和 UI 刷新同时抢 CPU屏幕刷新时序会被拖乱。所以后台任务要设计优先级UI 刷新事件或屏幕驱动刷新等待尽量保持高优先级关键刷新期间暂停大文件操作。定时器也要小心。不要在 UI 层创建一堆周期性高精度定时器因为每次触发都可能意味着屏幕变化。更合理的做法是合并定时任务比如时间显示、电量检查、日志落盘合并成同一周期并且只在数值变化时才触发布局更新。定时器的最短周期要大于屏幕刷新时间否则就会出现上一刷新还没结束下一次又开始的状况。6. 常见问题排查与验收清单最后说排查。e-ink UI 的问题有几个特点现象看起来像屏幕坏了实际往往是刷新策略或数据流问题今天跑得好好的环境一变就出现残影代码没有报错但用户的反馈就是“卡住”。所以排查要有顺序。6.1 硬件链路先排除屏幕不显示或显示乱码先别怀疑 UI 代码。第一步检查电源是否稳定e-ink 刷新瞬间电流会比平时高如果供电不足刷新会失败或出现闪线。第二步检查接口连接和驱动板型号不同型号的初始化命令差异很大固件或驱动库版本不同也可能导致刷新问题。第三步把屏幕厂家提供的 demo 程序烧进去如果 demo 也有问题基本可以判断是硬件或接线问题UI 层不用背锅。在开发过程中最好准备一个固定的测试板卡和正常的屏幕用来对比验证。不要每次都用一台刚焊接完、还没稳定供电的开发板去测 UI最后容易把软件问题和硬件问题混在一起。6.2 逻辑链路从状态变化到刷新完成的日志排查 UI 不刷新时我喜欢沿着链路打日志事件进入 UI 层、状态被更新、刷新请求提交到队列、队列执行、驱动返回完成。每一环都记录时间戳和变更区域。这样就能快速定位是事件没到、状态没变、刷新被合并、还是驱动等待超时。如果发现 UI 状态已经变化但屏幕没反应优先看刷新队列是否被一个长时间等待的刷新任务堵住了。如果日志显示刷新请求根本没提交说明 UI 层没有触发重绘可能是 dirty flag 没有设置或页面处于缓存状态。如果日志显示刷新执行了但画面不对再看具体刷新模式是全刷还是局刷局刷矩形坐标和宽高是否计算正确。6.3 高频问题排查顺序下面几个是 e-ink UI 开发中最高频的问题我按“先看什么、再看什么”列出来问题第一排查点第二排查点第三排查点翻页后残影严重是不是一直用局刷全刷频率有没有限制刷新模式与页面内容是否匹配屏幕乱闪刷新队列是否堆积是否多个事件同时触发重绘驱动是否每次刷新都等完成局部区域不更新脏矩形坐标是否算对局刷接口是否传了正确的 region页面是否被系统静默缓存触摸后反应慢是否刷新中屏蔽了输入冷却时间是否过大触控层上报频率是否正常长期运行后花屏内存或位图缓存是否异常刷新期间是否被外部中断驱动是否出现未处理的中断异常遇到这些问题时记得先看日志再改参数。不要一上来就把全刷改成局刷也不要把局刷改成全刷。很多问题不是刷新模式本身而是触发频率或区域计算错误。6.4 验收清单什么才算跑稳项目接近完成时我建议用一套固定清单来验收而不是只看几个页面能打开连续翻页 100 次残影不会积累到影响阅读局刷 20 次后边缘仍然干净没有越积越深的灰边页面切换全程不会出现花屏、半屏、明显的撕裂快速连点翻页按钮不会把刷新队列打爆也不会出现白屏进入休眠再唤醒画面能恢复状态能继续操作低电量状态下屏幕刷新依然可以正常完成整机待机电流符合预期没有因为没有变化的定时刷新导致掉电。这套清单看起来细但每一条都能在真实使用中暴露出问题。尤其是连点翻页和休眠唤醒很多项目就是在测试这 100 次翻页后才发现局刷策略要调整或者唤醒后必须全刷。功能上线前多花半天跑这些项目比用户反馈后再返工要划算得多。回到一开始说的e-ink UI 开发最值得固化的不是炫酷的组件和技术栈而是“克制”两个字少做刷新、少用灰度、少依赖颜色、少设计动画把每一次界面变化都当成一次重要的资源消耗。先跑通单页再验证连页和批量任务最后才谈视觉和交互细节。这套思路放到阅读器、信息看板、电子价签还是桌面摆件上我觉得都通用。如果你正准备接一块 e-ink 屏不妨从刷新队列和基线测试开始那是后面所有 UI 设计的地基。