低功耗刷新策略与产品取舍

返回00-项目导航；结合02-墨水屏驱动与串行通信、05-联网数据与人工智能阅读。

一、画面能保持，不等于整机不耗电

墨水屏的特点是画面在一定条件下可以保持，而不需要像某些主动发光显示器那样持续扫描发光。但本产品还有处理器、无线通信、稳压器、指示灯、存储卡和外部驱动电路。

把处理器保持运行、无线持续联网、网页一直开放，再让屏幕停止刷新，整机仍可能明显耗电。因此“屏幕省电”与“产品续航长”是两个需要分别测量的结论。

当前驱动验证工程 main.c:196 调用 epd_sleep()，随后函数向显示控制器发休眠命令。主程序没有调用 esp_deep_sleep_start()，不能把屏幕休眠写成处理器已进入深度睡眠。

信息终端主循环持续延时并处理交互，本次选定源文件也没有找到进入处理器深度睡眠的调用。这说明还没有从这条代码链证明整机深睡，不能进一步推断某个具体待机电流。

二、要区分四种状态

具体外设与存储保持范围以芯片文档和配置为准。手机持续连接、设备网页随时可访问，与长时间关闭无线和处理器不是天然兼容的产品承诺。

三、用能量账本估算，别只看最低电流

对于一个更新周期，用每阶段实际测得的电流和时长计算：

平均电流 = 各阶段电流×时长之和 ÷ 一个周期总时长

阶段可以划为唤醒、联网、获取资料、请求云端模型、绘图、屏幕刷新、等待交互与睡眠。

但只有在测量点电压条件一致时，直接比较电流才有意义。比较不同电压供电路径或推算电池续航，应计算能量，并纳入转换效率、稳压器静态消耗、电池实际可用容量和截止条件。

本项目没有本次测得的各阶段电流，因此不能给出“能用多少天”。应先记录波形或采样数据，再估算，并用完整放电试验校核。

四、获取、计算、绘图和刷新是四个不同动作

一条天气数据更新，不代表立刻进行一次全屏刷新。可以分开考虑：

1. 获取时机：是否到了数据需要更新的时间，或用户主动触发？
2. 计算时机：结构化天气接口是否已经足够，是否真的需要模型再次处理？
3. 绘图时机：新数据是否改变了用户可见内容？
4. 刷新时机：画布变化范围是否适合局刷，是否需要全刷恢复质量？

信息终端工程的 g_last_fb用于保留上次画布，主循环存在差分检查路径。它保存的是图像变化基线，不是第二份已验证的屏幕实际光学状态。

如果刷新失败却更新了基线，后续程序可能以为“屏幕已经是新图”。所以错误传播不仅影响日志，也影响下一次刷新决策。

五、快速与局部刷新为什么不能只追求速度

墨水屏刷新依赖面板支持的驱动波形、温度和前后图像条件。写入窗口更小或函数名叫“快速”，都不自动证明更快、更清晰或更省电。

验证工程中三条模式路径与官方驱动存在差异，详见驱动篇。本次不把注释里的“约1.5秒”当作已测性能。

比较刷新策略时至少记录：

• 从请求到忙信号释放的时间，以及画面实际稳定时间。
• 边缘残影、黑白反转、细字清晰度、连续更新后的质量。
• 同样内容、同样温度条件下的电量消耗。
• 复位或休眠唤醒后，局刷前置状态是否仍成立。

全刷和局刷交替的频率，应结合准确面板资料和实际试验决定，不直接照搬另一型号的固定次数。

六、交互与联网必须有产品取舍

如果定位桌面常供电终端，可以更重视手机配置、随时操作和内容响应；如果定位电池信息牌，则应优先明确更新时间、唤醒方式、断网回退和内容有效期。

现有工程里同时存在蓝牙、网页、天气、资讯和云端请求。模块越多，除了能耗，还会增加联网等待、内存占用、错误恢复和用户理解负担。

可以先定义一个完整的核心任务，例如“每天定时更新天气与日程，按键可查看最后成功内容”；其他功能是否保留，应看用户实际使用和测量结果。这个例子是产品练习，不代表已经改动工程目标。

七、建议做的可测练习

1. 搜索处理器睡眠接口与屏幕休眠接口，画出各自影响的器件，不以函数英文名猜范围。
2. 在同一测量点分别记录联网、获取资料、刷新、空闲四段电流，注明电源、电压、采样条件与固件版本。
3. 保持数据内容不变，比较每次都全刷与无可见变化时不刷；同时检查是否漏掉时间等应该更新的内容。
4. 关闭网络后保留上次成功数据，并在界面显示更新时间。旧数据可读，不等于旧数据仍然准确。
5. 若后续加入深睡，测试唤醒源、时间恢复、配置恢复、联网失败和屏幕重新初始化，不能只测“一次成功唤醒”。

所有练习当前均未执行。官方参考：乐鑫睡眠模式。