Skip to content

刷新调度与功耗约束 ​

本节是拟议系统行为,不代表现有 Mini App SDK。

  • 应用描述状态变化和脏区域,系统统一决定局部刷新、区域清理与全局刷新,并合并同一交互中的多个更新。
  • 官方列出的示例类别包括局部 DU 和全屏 GC16 S2;不能由此推断每种模式都适合任意灰阶内容。四阶界面不意味着所有快速刷新模式都能准确保留这四阶。
  • 换页时应覆盖分页容器完整矩形中的旧内容,包括变成空白的区域。先在帧缓冲中形成白底新页,再由驱动按支持的方式处理旧像素与新像素转换;不能只画新文字而不擦旧文字。
  • “局部完全刷掉”指更新区域的完整内容替换,不等价于每次都让全屏闪烁。是否需要独立清理波形由驱动策略决定。
  • 系统界面大幅变化、局部刷新残影累积到策略阈值、驱动判定需要清理或用户主动请求时,必须安排一次全局刷新。
  • 不过度依赖全局刷新;禁止给每次点击或每个小图标变化固定绑定全刷。
  • 全刷次数/面积/温度等阈值由目标驱动实测配置。不在设计规范中虚构“固定每 5 次/10 次局刷全刷”这样的通用事实。
  • 刷新调度器应记录所用模式、局部刷新累计情况、变化面积与清理时机;没有残影检测能力时采用经过测试的保守策略,不能假设可以自动视觉识别残影。
  • 补充建议:提供手动“清除残影/刷新屏幕”入口;后台小组件不可任意触发全屏刷新。
  • 空闲界面不因隐藏倒计时、光标闪烁、不可见动画或固定轮询而反复提交显示刷新。
  • 重要操作需有静态执行反馈;耗时任务显示状态文字,在开始/阶段变化/完成时刷新,避免旋转动画。
  • 全刷和触摸状态切换时防止一次触摸被执行两次;页面切换后不能把尚未释放的手指事件误派发给新页。

变化区域与提交顺序(补充建议) ​

对象移动、缩小或消失时,更新范围覆盖旧边界与新边界的并集,并裁剪到授权绘制区。仅提交新边界会留下旧像素。分页提交完整分页容器;菜单关闭恢复原覆盖矩形。

小组件在本地坐标计算变化范围,宿主裁剪后转成屏幕坐标。应用不得自行将更新扩展到系统栏或其他应用。

拟议顺序为:更新状态 → 完整排版白底终态 → 提交变化区域与清理意图 → 系统合并并按驱动选择模式 → 完成后发布已显示状态并恢复对应输入。失败时保留可恢复状态与静态说明。实际异步接口、回调与错误码尚未定义。

建议区分已排版状态和已提交显示状态,截图参考已显示的帧,避免截到尚未送至面板的内容。

实机记录(补充建议) ​

记录硬件修订、固件、驱动 / 波形版本、字体、环境温度(可测时)、内容类型、变化面积、耗时与残影观察。分别测试文字、灰阶封面、密集图标和连续分页,不能用 Demo 可运行代替目标界面验收。

JustRead 项目文档