如果只把一套为液晶屏设计的 UI 原样搬到墨水屏上你通常会在第一眼就发现问题界面不是闪烁就是残影文字看起来灰蒙蒙点击一次要等很久才刷新。前阵子 Hacker News 上有人问In your experience, what are sound conventions for e-ink UI development? 这个问题问得很准。它不是在找某个组件库而是在问当屏幕的物理特性决定了它不能像普通显示屏那样实时呈现时界面应该怎么重新设计。我的核心判断是e-ink UI 开发真正要管理的不是像素而是刷新时序和阅读节奏。 后面的内容我会从显示链路、交互时序、刷新策略、工程化验证和适用边界几个角度展开。你看完以后可以拿着这篇文章当成一份设计清单去对照自己的产品。1. 先理解 e-ink UI 开发到底在解决什么问题1.1 真正要管理的不是屏幕坐标而是刷新时序普通液晶屏和 OLED 屏的渲染模型是每一帧画面整体刷新像素响应在几毫秒到十几毫秒内完成所以你可以放心做动画、滚动、拖拽甚至可以按 60fps 的标准去设计交互流程。墨水屏不一样。它的显示原理是让带电颜料粒子在电场中移动移动需要时间。快的局部刷新可能也要几百毫秒全屏刷新经常要 1 秒以上而且刷新过程中会产生肉眼可见的黑白闪动或残影。这个物理过程并不透明它会直接影响 UI 的每一个决策。很多开发者在第一版里犯了同一个错误把电子阅读器当成一个弱一点的平板把 Android 或 Web 写好的界面原样跑在墨水屏上。结果其实可以预料触摸一个按钮整块屏幕闪一下翻几页之后上一页的文字残影还留在背景里打开一个带渐变的页面灰阶看起来像蒙了一层雾。这不是代码能力问题而是没有把“墨水屏”本身当成交互系统的一部分来设计。1.2 一个容易被忽略的显示链路framebuffer、波形、显示控制器常规嵌入式 Linux 或 Android 方案里UI 层把自己的内容写进 framebuffer然后由 EPD 显示控制器把这份内容刷到屏上。这里最关键的一点是写进 framebuffer 不等于马上就显示。控制器选择哪种“波形”去驱动粒子决定了这次刷新是快是慢、灰度好不好、残影多不多。常见的波形模式有整体刷新、局部刷新、快速低灰度刷新等。快速模式更适合笔迹和光标但会牺牲灰阶局部刷新适合小范围文字变化但用久了会积累残影全屏刷新残影最少但每次都会伴随一次比较明显的黑白闪烁。这意味着 UI 开发不只是写布局和样式还需要在用户操作、内容变化和刷新模式之间做协调。你可以在应用层决定“这次更新走局部刷新”下一个动作决定“这个页面必须强制全刷”。如果完全忽略这层显示控制器就会用默认策略处理结果往往就是闪、慢、乱。所以“sound conventions”的第一条不是去选颜色或字体而是先接受这个显示链路的存在并且把刷新模式当成 UI 状态机的一部分。2. 不要追求实时反馈而要把 UI 设计成一组离散状态2.1 操作反馈可以先走音频、LED 或应用层状态在墨水屏上一个最折磨人的问题就是用户点了按钮界面要等一会才有反应。如果这个反应还伴随一次闪屏体验会更差。更常见的工程处理方式是不要求屏幕即时响应而是让系统立即产生一个非屏幕反馈。比如物理按键可以同时触发一个小的 LED 灯或蜂鸣声触摸操作可以立即更新应用内部的选中状态界面刷新则放进队列等当前刷新完成后再执行。这里有一点容易被忽略应用层的状态变化和屏幕上的显示变化可以不同步。也就是说用户点了“下一页”逻辑层立刻记住这个动作按钮也进入“已按下”状态但屏幕上的新页面可能还要几百毫秒才出现。这个间隔是可接受的只要用户不觉得系统死了。2.2 用“有限状态机”代替“动画过渡”墨水屏上做动画通常不是加分项而是闪屏和残影的来源。平滑的过渡动画在电子墨水屏上很难达到普通屏幕的流畅度硬做只会让整块屏不断刷新。更适合的做法是离散状态切换。界面从状态 A 到状态 B不经过中间帧而是直接完成一次刷新。如果需要给用户一点“过程感”可以设计一个静态的 loading 提示而不是旋转动画。旋转动画在墨水屏上会变成一个快速闪烁的残影集合。如果产品里确实需要动画比如开机引导或演示模式尽量把它限制在固定区域并在这段动画前后安排一次全屏刷新来清理残影。不要试图让动画常驻更不要让动画成为页面主体。2.3 一个交互时序参考表下面给出一组参考约定方便团队在写交互说明时对齐预期用户操作普通屏幕的默认反应墨水屏推荐反应点击按钮立即改变按钮颜色或位移先给声音/震动反馈屏幕更新排队刷新时使用局部刷新翻页/加载下一页平滑过渡或瞬间切换一次整页内容替换常用局部刷新每连续多次后安排一次全刷手写笔迹高频绘制像素逐笔显示使用快速低灰度波形画完后对笔迹区域做一次局部清残影打开弹窗动画弹出背景变暗弹窗区域强制全刷或局部重置避免文字残影叠在弹窗上数值变化定时器/进度条每秒更新或平滑滚动只在数值变化时更新区域优先使用小范围局部刷新这些不是绝对标准但它们体现了一个共同的思路先判断用户能不能等再判断屏幕要不要闪。3. 显示层面的约定灰度克制、字体优先、残影可控3.1 灰度不是越多越好而是“够用且稳定”很多墨水屏面板标称 16 级灰度。理论上可以通过抖动算法模拟更多灰度但真实观感会带上噪点或颗粒感尤其在浅色背景上很明显。在进行 UI 设计时我通常建议先把界面调成纯灰度来看。哪些元素需要最深色哪些需要中等灰色哪些只需要浅色背景这个层级要在灰度模式里就能看清而不是依赖颜色区分。颜色在墨水屏上不是第一信息层级尤其是黑白墨水屏红、黄、蓝等颜色通常会被映射成不同灰阶观感很难预测。不要在背景上使用大面积渐变也不要在正文里使用灰度很接近的文字和背景。黑白墨水屏的对比度本来就有限再压低对比度阅读会很吃力。图片处理上优先使用针对灰度屏优化的抖动算法而不是直接拿彩色 JPEG 压缩后硬显示。3.2 字体与排版宁可大一点不要轻一点墨水屏对字体的要求比普通屏幕更严格。衬线、细体、极细字重、很小的抗锯齿边缘在液晶屏上看起来还行到了墨水屏上就可能糊成一片。这里有几条较稳妥的约定正文字重选择 medium 或 regular避免 thin 和 light。字号要针对目标设备的 DPI 和阅读距离测量理想情况下在真机上至少连续阅读 30 分钟再确认。行距不要太紧段落间距要明显。墨水屏上密集文字容易让视线疲劳。标题与正文之间除了字号差异最好还有明显的间距差异不要只靠字重区分。如果目标设备支持尽量选用为屏幕阅读优化过的中文黑体或开源字体。另外除非你明确知道面板特性否则不要轻易做“黑底白字”的深色模式。大面积的黑色背景在全刷和局刷之间切换时残影和闪屏会更明显阅读体验未必比白底深字好。3.3 残影管理该全刷的时候不能省残影是墨水屏最典型的问题。局部刷新速度快但上一帧的内容不会完全清干净连续多次局部刷新后页面上会叠着很多层旧内容。合理的做法是给刷新策略加一个“预算”局部刷新多少次之后强制执行一次全屏或区域全刷新。具体次数要真机测试比如每 3 到 10 次翻页强制一次全刷或者在用户切换章节、打开菜单、弹窗关闭时直接全刷。这里有一个常见的错误为了省掉闪屏把所有刷新都改成局部刷新。刚开始可能觉得体验不错但用一段时间后残影积累起来用户反而会觉得屏幕“脏了”。残影管理不是不做全刷而是有节奏地做全刷。刷新模式速度灰度表现残影程度典型用途全屏刷新慢完整灰阶残影少页面切换、弹窗打开、清理残影局部刷新中灰阶尚可容易积累文字更新、列表变化快速波形快灰度损失明显残影较多光标、手写笔迹、简单图表区域重置不一定看波形看波形对特定区域做清残影处理4. 刷新策略把界面拆成静态区、动态区和状态区4.1 三种区域使用不同刷新模式一个完整的墨水屏界面最好被拆成三类区域来规划静态区页面框架、侧边栏、顶部导航。它们不经常变化只在进入页面或切换主题时刷新。动态区正文内容、列表主体。它们最频繁变化是局部刷新的主要对象。状态区电池、时间、进度条、连接状态。它们变化频繁但范围小适合独立的小区域刷新。区域类型常见内容推荐刷新策略静态区导航栏、页面标题、固定说明页面进入时全刷之后不主动刷新动态区正文、列表、图表局部刷新多次后强制全刷状态区电池、时间、进度小范围局部刷新定时或仅在变化时更新静态区不是永远不刷新而是不要在每次内容变化时被牵连。很多 UI 框架会默认把整个页面标记为 dirty导致状态区一个电量的变化也触发全屏刷新。针对墨水屏需要主动控制 dirty region尽量只上报真正变化的矩形区域。4.2 用一个刷新队列统一管理所有渲染请求当 UI 层和硬件刷新层不协调时最常见的现象是“刷到一半又来一个新请求”然后显示控制器被打乱界面卡顿。一个有效的方法是引入刷新队列。下面是一个最小示意帮助你理解这个思路# 示意代码一个简单的墨水屏刷新队列 class RefreshQueue: def __init__(self): self.pending []# 等待中的刷新请求 self.busy False def request(self, region, mode): # region 是需要刷新的矩形范围mode 是刷新模式 self.pending.append((region, mode)) self._process() def _process(self): if self.busy or not self.pending: return self.busy True region, mode self.pending.pop(0) # 这里调用具体显示驱动执行一次刷新 epd_update(region, mode) # 刷新完成后再处理下一个请求 self.busy False if self.pending: self._process()这个队列里还可以加入合并逻辑如果两个请求的刷新区域接近就把它们合并成一个区域如果应用层短时间内连续提交了三次刷新可以只保留最后一次结果。调好队列你会减少很多闪屏和异常刷新问题。4.3 每次更新前先回答四个问题在提交一次 UI 刷新之前可以像过一个 checklist 一样确认内容真的变了吗如果只是设置相同的值直接跳过刷新。这个区域需要马上显示给用户还是可以延迟到当前刷新结束后这次更新适合用全刷还是局部刷新有没有残影风险它会不会被下一次更新覆盖如果 500 毫秒后还要再变一次建议合并。这个步骤看起来很琐碎但它恰恰是墨水屏 UI 工程化和普通 UI 工程化最不一样的地方。5. 从原型到量产一套可执行的验证流程5.1 先跑通“一页照片、一页正文、一页表单”我建议不要一开始就搭完整应用而是先做一个最小测试页。这个页面里至少包含三类内容大图、正文、可交互表单。为什么是这三类大图能暴露灰阶和抖动问题正文能暴露字体和残影问题表单能暴露刷新模式和输入反馈问题。用这个测试页在真机上跑一遍你很快就能判断出颜色映射对不对、字体清不清楚、刷新模式下残影能不能接受、点击按钮后用户会不会等太久。5.2 做连续翻页和刷新压力测试单次刷新正常不代表连续使用正常。墨水屏的产品一定要做连续操作测试连续翻 50 页、快速点击菜单、反复打开关闭弹窗、长时间停留在同一页面后切换内容。测试过程中重点记录几个问题是否出现越来越明显的残影局部刷新后文字边缘是否变毛连续快速操作时界面是否出现乱码或卡死每次全刷产生的闪屏是否让用户烦躁如果某个操作连续执行 20 次后出现严重残影那就说明这个路径上的刷新模式需要调整或者需要在特定节点强制全刷。5.3 常见排查链路残影、闪屏、点击无效、刷新异常遇到墨水屏 UI 问题建议按以下顺序排查先看现象是残影、闪屏、白闪还是点击无反应再看请求来源是应用层重复提交还是系统组件自动刷新了状态栏再查 dirty region当前只更新了目标区域还是把整个 framebuffer 都标记为脏再看刷新模式这个路径用的是全刷还是局刷连续多少次局部刷新后该触发全刷最后看硬件边界当前面板的温度、波形库版本、显示控制器是否支持这次刷新模式很多“刷新异常”不是驱动 bug而是应用层在全屏刷新请求和局部刷新请求之间没有串行化导致两个刷新任务同时到达。加一个刷新队列通常能解决大部分问题。5.4 保留日志和远程调试接口墨水屏设备一旦量产现场问题往往很难复现。建议在 UI 框架层埋点把每次刷新请求的区域、模式、触发原因、耗时记录下来。这样用户反馈“屏幕花掉”时你可以回放当时的刷新序列判断是不是某个操作触发了不该有的全刷。如果产品支持 OTA 或调试模式保留一个不刷屏的文本日志通道会很有价值。日志本身对墨水屏也有影响不要让调试信息直接显示在主界面上否则会把整个刷新队列拖慢。6. 适合与不适合别让 UI 设计去对抗物理6.1 适合 e-ink 的典型场景电子书阅读器、学习本、电子单词卡、电子货架标签、慢速信息看板、家庭备忘屏、会议铭牌、便携写作设备这类产品都有一个共同特征界面以阅读和低频率交互为主不需要高帧率动画用户可以接受几百毫秒到一秒左右的刷新等待。在这些场景里e-ink UI 的核心价值是“读起来舒服”和“待机时间长”。如果你的产品足够聚焦UI 设计完全可以围绕大字号、清晰层级、低动态内容来做。这类产品不需要像手机一样吸引眼球它需要让人长时间使用不累。6.2 不适合 e-ink 的场景视频播放、快速滚动信息流、实时地图导航、动作游戏、高精度绘图、需要流畅动画的营销页面这些场景不适合用墨水屏做主力显示器。硬做的结果不是体验差而是经常闪屏、残影明显、刷新跟不上操作。如果一个需求同时要求“高帧率动画”和“墨水屏”那就需要重新审视产品定义。不要认为 UI 技巧能解决一切。有些问题是物理限制解决方式只能是在产品层面妥协。6.3 长期工程化建议波形库、温度补偿和显示控制器差异墨水屏不像普通 LCD光调好 UI 层还不够。长期做产品你还需要关注下方的硬件和驱动层。不同批次的面板、不同厂家的波形库哪怕看起来是同一类屏实际显示效果也可能有差异。如果你的团队能做驱动层开发建议设计一个“波形库抽象层”让 UI 层不要直接接触具体波形索引而是通过“语义化刷新模式”来调用。比如 UI 层告诉驱动这次是正文翻页这次是状态栏更新这次是清理残影。具体用哪个波形由驱动层决定。还要考虑温度。墨水屏在低温下粒子移动变慢刷新时间变长残影更容易出现。如果产品有户外使用场景一定要做低温环境下的整机刷新测试。不要用常温测试结果直接替代低温表现。最后给 UI 团队和显示驱动团队之间留一个“真机判断通道”。很多问题必须把屏拿在手里看才能判断是 UI 布局问题、灰度映射问题还是波形配置问题。只看模拟器截图永远发现不了残影和闪屏。说到底e-ink UI 开发的意义不是把普通屏幕上的设计搬到新设备上而是用另一种方式重新理解界面把内容组织成清晰的离散状态把刷新时序当作一种可见的交互反馈把字体和灰度当作核心体验变量。先接受物理限制再做设计决策这才是“sound conventions”的本质。