浏览器JS屏幕唤醒API？-js教程-PHP中文网

答案是浏览器JS屏幕唤醒API通过navigator.wakeLock.request('screen')阻止屏幕变暗，适用于演示、食谱、健身等需持续显示的场景，需用户手势触发，支持主流浏览器，但受系统省电策略影响，需妥善管理生命周期并监听visibilitychange事件以确保稳定性。

浏览器js屏幕唤醒api？

浏览器JS屏幕唤醒API，简单来说，就是一种让网页应用能够阻止屏幕自动变暗或关闭的能力。想象一下你在看食谱、做演示或者跟着健身视频锻炼，屏幕突然黑了，这体验真是糟糕透顶。这个API就是为了解决这种痛点而生的，它允许开发者在特定场景下，向浏览器请求保持屏幕常亮，确保用户能持续看到内容，而无需频繁触碰屏幕。

解决方案

使用浏览器JS屏幕唤醒API的核心，在于通过

navigator.wakeLock.request('screen')

登录后复制

方法来请求一个屏幕唤醒锁。这个方法返回一个Promise，成功时会解析为一个

WakeLockSentinel

登录后复制

对象。这个对象就是你持有锁的凭证，通过它的

release()

登录后复制

方法，你可以在不再需要时主动释放锁。

一个基本的实现流程会是这样：

let wakeLock = null; // 用于存储唤醒锁对象

const requestWakeLock = async () => {
  try {
    wakeLock = await navigator.wakeLock.request('screen');
    console.log('屏幕唤醒锁已激活！');

    // 监听锁被释放的事件，这可能是系统行为或用户操作
    wakeLock.addEventListener('release', () => {
      console.log('屏幕唤醒锁已释放。');
      wakeLock = null; // 清空引用
    });

  } catch (err) {
    // 用户拒绝，或者浏览器不支持
    console.error(`请求屏幕唤醒锁失败: ${err.name}, ${err.message}`);
  }
};

const releaseWakeLock = () => {
  if (wakeLock) {
    wakeLock.release();
    wakeLock = null;
    console.log('手动释放屏幕唤醒锁。');
  }
};

// 通常，你需要一个用户交互来触发请求，比如一个按钮点击
document.getElementById('activateWakeLockBtn').addEventListener('click', requestWakeLock);
document.getElementById('deactivateWakeLockBtn').addEventListener('click', releaseWakeLock);

// 考虑页面可见性变化，当页面不可见时，锁可能会被系统释放
document.addEventListener('visibilitychange', async () => {
  if (wakeLock !== null && document.visibilityState === 'visible') {
    // 如果页面重新可见，并且我们之前持有锁，尝试重新获取
    console.log('页面重新可见，尝试重新获取屏幕唤醒锁...');
    await requestWakeLock();
  }
});

登录后复制

记住，

request()

登录后复制

调用通常需要用户手势（比如点击按钮）才能成功，这是出于用户体验和电源管理的考虑。而且，即使你成功获取了锁，系统也可能出于各种原因（比如低电量、用户切换应用）随时释放它，所以监听

release

登录后复制

事件并做好重新获取的准备非常重要。

为什么我们需要屏幕唤醒API？常见应用场景有哪些？

我个人觉得，这个API的出现，是Web应用向原生应用体验看齐的一个重要信号。以前，在浏览器里看个视频、玩个小游戏，或者只是挂着一个需要持续关注的仪表盘，屏幕时不时就暗下去，用户不得不手动点一下或者动一下鼠标，这简直是反人类的设计。它打断了用户的沉浸感，也消耗了不必要的用户精力。

所以，我们需要屏幕唤醒API，它能让网页应用在特定场景下获得与原生应用相近的控制力。常见的应用场景非常多，我随便列举几个：

在线演示或幻灯片播放： 想象你在做Keynote或者Google Slides演示，屏幕突然黑了，那得多尴尬？这个API能确保你的内容持续显示。
食谱或教程应用： 边做饭边看菜谱，双手可能沾满了面粉，根本不方便去碰屏幕。屏幕唤醒能让你安心跟着步骤走。
健身或瑜伽指导： 跟着视频或文字指导做动作时，屏幕保持常亮，用户就不用担心错过关键的指令。
Kiosk模式或信息显示屏： 在公共场所，如博物馆、展览馆的触摸屏导览，或者商店里的产品介绍屏，都需要长时间保持屏幕亮起。
音乐乐谱或歌词显示： 演奏乐器时，乐谱或歌词保持不动，对表演者来说至关重要。
视频会议（部分场景）： 虽然很多视频会议应用本身就会通过播放视频来保持屏幕常亮，但对于一些纯音频或共享屏幕的会议，这个API也能提供额外的保障。
实时数据监控仪表盘： 比如股票行情、服务器状态监控，用户需要持续查看最新数据，屏幕熄灭就失去了意义。

这些场景的核心诉求，都是用户需要持续的视觉输入，并且不希望被设备自身的电源管理策略打扰。

如何优雅地管理屏幕唤醒锁的生命周期？

管理屏幕唤醒锁的生命周期，可不是简单地

request()

登录后复制

一下就完事了。这需要一些策略和对用户体验的深刻理解。我的经验告诉我，关键在于“适时而止”和“以用户为中心”。

首先，获取锁的时机至关重要。不应该在页面加载时就请求锁，这会显得很霸道。最佳实践是当用户明确表示需要持续关注（比如点击了“开始演示”按钮，或者进入了“全屏阅读模式”）时，再通过用户手势来触发

request()

登录后复制

。

其次，释放锁的逻辑要清晰。当用户不再需要屏幕常亮时，比如演示结束、退出全屏、导航到其他页面，甚至只是切换了浏览器标签页，都应该主动调用

wakeLock.release()

登录后复制

来释放锁。这不仅节约了用户的设备电量，也尊重了用户的控制权。

这里有一个更健壮的生命周期管理模式：

let wakeLockSentinel = null;

const requestWakeLock = async () => {
  if ('wakeLock' in navigator && !wakeLockSentinel) { // 检查API支持且当前未持有锁
    try {
      wakeLockSentinel = await navigator.wakeLock.request('screen');
      console.log('屏幕唤醒锁已激活。');

      wakeLockSentinel.addEventListener('release', () => {
        console.log('屏幕唤醒锁已由系统或用户释放。');
        wakeLockSentinel = null; // 清空引用
      });

    } catch (err) {
      console.error(`请求屏幕唤醒锁失败: ${err.name}, ${err.message}`);
      wakeLockSentinel = null; // 确保失败时也清空
    }
  }
};

const releaseWakeLock = () => {
  if (wakeLockSentinel) {
    wakeLockSentinel.release();
    wakeLockSentinel = null;
    console.log('手动释放屏幕唤醒锁。');
  }
};

// 监听页面可见性变化，当页面隐藏时，系统可能会释放锁
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden' && wakeLockSentinel) {
    // 页面隐藏时，主动释放锁是一个好习惯，也可以让系统自动处理
    // 但如果系统自动释放，我们会通过 release 事件得知
    console.log('页面隐藏，如果锁未被系统释放，也应考虑手动释放。');
    // wakeLockSentinel.release(); // 也可以选择不手动释放，让系统处理
  } else if (document.visibilityState === 'visible' && wakeLockSentinel === null) {
    // 页面重新可见，如果之前持有锁但被释放了，尝试重新获取
    console.log('页面重新可见，尝试重新获取屏幕唤醒锁...');
    requestWakeLock();
  }
});

// 监听页面卸载事件，确保页面关闭时释放所有资源
window.addEventListener('beforeunload', () => {
  releaseWakeLock();
});

// 举例：一个按钮点击来激活/禁用
document.getElementById('toggleWakeLockBtn').addEventListener('click', () => {
  if (wakeLockSentinel) {
    releaseWakeLock();
  } else {
    requestWakeLock();
  }
});

登录后复制

这里面，

visibilitychange

登录后复制

事件的处理尤为关键。当用户切换到其他标签页或最小化浏览器时，页面就进入了

hidden

登录后复制

状态。此时，浏览器或操作系统很可能会为了省电而自动释放屏幕唤醒锁。当页面再次变为

visible

登录后复制

时，如果你的应用仍然需要屏幕常亮，就应该重新尝试获取锁。这种响应式的管理方式，既保证了功能，又尊重了系统和用户的选择。

屏幕唤醒API的兼容性与潜在限制是什么？

聊到任何Web API，兼容性和限制总是绕不开的话题。就屏幕唤醒API而言，它虽然很实用，但也不是万能的。

Robovision AI

一个强大的视觉AI管理平台

查看详情

兼容性方面： 目前，主流的现代浏览器对

Screen Wake Lock API

登录后复制

的支持度已经相当不错了。Chrome、Edge、Opera等基于Chromium的浏览器都提供了良好的支持。Firefox也已支持。Safari在桌面端和iOS端也陆续加入了支持。不过，为了保险起见，在使用前总是建议通过

if ('wakeLock' in navigator)

登录后复制

来进行特性检测。这是一种稳健的开发习惯，能避免在不支持的浏览器上抛出错误。

潜在限制：

用户手势要求： 这是最常见的一个限制。浏览器为了防止恶意网站滥用，通常要求
```
request()
```
登录后复制
方法必须由用户手势触发。这意味着你不能在页面加载时就偷偷摸摸地激活它。这很好理解，谁也不希望打开一个网页，手机屏幕就一直亮着耗电。
系统级干预： 即使你成功获取了锁，操作系统或浏览器也可能出于各种原因强制释放它。例如，设备电量过低、用户手动关闭屏幕、切换到其他应用程序（特别是在移动设备上）、或者浏览器自身的电源管理策略。这解释了为什么我们需要监听
```
release
```
登录后复制
事件并准备好重新获取。
单一类型： 目前，
```
Screen Wake Lock API
```
登录后复制
主要支持
```
screen
```
登录后复制
类型，即只阻止屏幕变暗或关闭。未来可能还会出现其他类型，比如阻止CPU进入低功耗模式（虽然这更复杂，且对电池影响更大），但目前我们主要关注屏幕。
权限和用户体验： 某些浏览器可能会在首次请求时向用户显示一个权限提示，询问是否允许该网站保持屏幕常亮。如果用户拒绝，你的
```
request()
```
登录后复制
调用就会失败。此外，浏览器通常会在地址栏附近显示一个图标，表明屏幕唤醒锁正在生效，用户可以随时点击这个图标来手动释放锁。这意味着，用户始终拥有最终的控制权。
后台标签页： 当你的网页应用运行在后台标签页时，即使你持有屏幕唤醒锁，浏览器也可能选择忽略它，以节省资源。毕竟，用户不在当前标签页，保持屏幕常亮的需求就大大降低了。

总的来说，这个API是一个强大的工具，但它被设计成以用户为中心，并与系统级的电源管理策略协同工作。开发者在使用时，需要充分理解这些限制，并编写出能够优雅应对各种情况的代码，才能真正提供流畅且负责任的用户体验。

遇到屏幕唤醒API失效时，我该如何排查问题？

有时候，你会发现自己明明写了代码，屏幕却还是暗了。这种时候，排查问题就显得尤为重要。这通常涉及到几个常见的坑点和调试思路。

首先，检查浏览器支持和API可用性。这是最基础的一步。打开开发者工具，在控制台中输入

if ('wakeLock' in navigator) { console.log('API supported'); }

登录后复制

。如果返回

false

登录后复制

，那问题就出在浏览器版本或兼容性上。

其次，确认用户手势触发。这是导致

request()

登录后复制

失败的常见原因。如果你在没有用户交互的情况下调用了

request()

登录后复制

，它很可能会被浏览器拒绝。检查你的代码，确保

requestWakeLock

登录后复制

函数是在点击事件、触摸事件等用户行为的回调中被调用的。

再来，捕获

request()

登录后复制

的 Promise 拒绝。

navigator.wakeLock.request()

登录后复制

返回的是一个 Promise，它可能会被拒绝。

try {
  wakeLock = await navigator.wakeLock.request('screen');
  // ... 成功逻辑
} catch (err) {
  console.error('请求屏幕唤醒锁失败:', err.name, err.message);
  // 根据错误类型（例如 NotAllowedError, AbortError）进行处理
}

登录后复制

通过捕获

catch

登录后复制

块中的错误，你可以看到具体的失败原因，比如

NotAllowedError

登录后复制

可能表示用户拒绝了权限，或者没有用户手势。

检查

visibilitychange

登录后复制

事件处理逻辑。如果你的应用在用户切换标签页或最小化后屏幕又暗了，很可能是

visibilitychange

登录后复制

事件没有正确处理。确保当

document.visibilityState

登录后复制

变为

visible

登录后复制

且你的应用需要屏幕常亮时，会重新调用

requestWakeLock()

登录后复制

。有时候，开发者会忘记在

release

登录后复制

事件监听器中将

wakeLock

登录后复制

变量置为

null

登录后复制

，导致在

visibilitychange

登录后复制

中误判为仍然持有锁。

排查系统级或浏览器设置。

省电模式： 设备的省电模式或低电量状态可能会强制覆盖屏幕唤醒锁。尝试在设备电量充足、未开启省电模式的情况下测试。
浏览器权限： 检查浏览器设置中是否对你的网站禁用了屏幕唤醒权限。
浏览器扩展： 有些浏览器扩展可能会干扰页面的行为，尝试在无痕模式下（禁用扩展）测试。
操作系统电源管理： 在某些操作系统上，可能会有更高级别的电源管理设置，它们可能会覆盖浏览器行为。

最后，利用开发者工具进行调试。

断点： 在
```
request()
```
登录后复制
和
```
release()
```
登录后复制
调用处设置断点，观察它们的执行流程和返回值。
控制台输出： 打印出
```
wakeLock
```
登录后复制
对象的状态，以及
```
release
```
登录后复制
事件是否被触发。
应用面板： 某些浏览器（如Chrome）的开发者工具在“Application”面板下可能会显示当前页面激活的各种锁状态，包括唤醒锁。这能直观地告诉你，你的页面是否真的持有一个唤醒锁。