摘要

  • W3C 2015 年第一份公开 Wake Lock 草案用菜谱举例：document.keepScreenAwake 表达网页希望屏幕继续亮着。网页持有请求标志，浏览器再按页面状态与设备条件处理。
  • 2017 年候选推荐文本同时谈屏幕与系统唤醒锁。2020 年起，专门的 Screen Wake Lock 草案使用请求与可释放的 WakeLockSentinel；可见性、电源状态和用户设置仍决定它能否持续。

自动熄屏通常是个好员工：没人使用设备时，它默默省电。到了厨房，它偶尔像个不看场合的同事，偏在厨师双手沾满面粉、锅里咕嘟作响时把菜谱藏起来。网页确有理由申请让屏幕多亮一会儿。但一台设备有用户、有电池、有系统电源策略；菜谱不能因为写了“再搅拌三分钟”，就接管整个房子的电闸。

W3C 2015 年 2 月 12 日首份公开草案直接拿菜谱演示：显示时将 document.keepScreenAwake 设为 true，不再需要时改回 false。看上去像网页自己拨动开关，规范里却写得更细：文档有一个请求标志；浏览器判断哪些文档仍在用户眼前，再请求操作系统施加唤醒锁。设备是否允许，还取决于电量与设置。网页递交的是申请，不是拿到了钥匙。

2015 年文本还关心一件实用的小事：厨师切到别的标签页，原来的菜谱还该替设备点灯吗？草案把页面是否活跃、是否在前台纳入判断。浏览器在多份请求之间做汇总，设备最后执行或拒绝。一篇被遗忘的菜谱无法凭过去那句 true 永久霸占屏幕。这里的节制比 API 的拼写更重要。

2017 年 12 月的候选推荐文本一度把讨论扩到两种锁：屏幕唤醒锁让人继续看见内容，系统唤醒锁关乎处理器是否继续工作。做菜需要看清下一步；后台计算想要的是另一种资源。文本还描述请求对象，以及可见性和设备条件变化时如何自动切换状态。“别睡”三个字下面，其实藏着两笔不同的电费。

2020 年 9 月的 Screen Wake Lock 草案收紧了题目：专谈屏幕。可见的文档发出请求，获得可释放的 WakeLockSentinel；锁被释放时，页面也能得知。低电量、省电模式或页面转入后台都可能结束这份临时安排。这像借来一盏工作灯，借用者有收据，也有归还动作；灯仍属于设备。

W3C 发布历史把 2015 年初稿、2017 年候选推荐、2020 年屏幕专用草案及后续修订串了起来。这些年份记录规范如何改写，不是证明每家浏览器同一天安装完毕的时间表。沿着文本看，最明显的变化是请求越来越有边界：网页提出具体的屏幕需求，浏览器和设备保持撤回能力。

2026 年 9 月的现行草案仍要求页面可见，并受许可、策略、浏览器及操作系统条件约束。设备电量低或进入节能状态，锁可以被释放；用户手动关屏，也有最后决定权。对操作系统的唤醒请求具有建议性质。菜谱解释自己为什么需要亮光，系统判断自己还能拿出多少电。

网站的选择同样值得看。人在照着步骤揉面时申请亮屏，任务结束便归还，这叫帮忙。页面被搁在一边，还坚持替广告留灯，那是另一种算盘。接口无法替出版者决定何时该停；用电池支付注意力的人，倒会看得很清楚。

面团还没揉完，屏幕可以尽力别睡。如果电池坚持要打烊，菜谱也得接受厨房的现实。