共计 2185 个字符，预计需要花费 6 分钟才能阅读完成。
刚刚，谷歌正式公布了 Chrome 94 稳定版。作为 3 周前 Chrome 93 版公布后的再次更新，Chrome 94 稳定版只管更新幅度较小，但也有不少小惊喜和亮点。
下载地址：https://www.google.com/intl/z…
全新 Chrome 94 稳定版 降级了其画布色彩形式化治理，实现了屏幕捕捉标准中的显示捕捉性能策略。同时，新版本增加了围绕音频 / 视频编码和解码以及原始视频帧解决等的低级编解码器 API、虚构键盘 API、本地调度 API 以及用于确定用户是否与零碎交互的闲暇检测 API。
据悉，Webcodes API 这一性能最后是在 Chrome 93 中作为一个源代码试用引入的。此次 Chrome 94 稳定版引入 Webcodes API，总体来说也是令人兴奋的，因为它曾经通过了先前的 origin 试用版。WebCodecs 是围绕音频 / 视频编码和解码以及原始视频帧解决等的低级编解码器 API。WebCodecs API 解决旨在比 JavaScript 或 WebAssembly 编解码器实现更高效。
早在上个月，谷歌公布的 Chrome 93 稳定版中，就为桌面端增加了对 WebOTP 的反对，但破除了传输层平安（TLS）中的 3DES 明码套件。而 8 月 30 日，谷歌发表了 Chrome v94 的测试版，并强调其中将包含一个新的 Webcodecs API，该 API 旨在解决宽泛级别的低级别视频解决。
Chromium 在此前的博客中对这一新 API 的重要性进行了概括，原文指出：
“A low-level codec API would better support emerging applications, such as latency-sensitive game streaming, client-side effects or transcoding, and polyfillable media Container support, without the increased network and CPU cost of JavaScript or WebAssembly codec implementations.”
“低级别编解码器 API 将更好地反对新兴应用程序，如对提早敏感的游戏流、客户端成果或转码，以及多填充媒体容器反对，而不会减少 JavaScript 或 WebAssembly 编解码器实现的网络和 CPU 老本。”
同时，本次 Chrome 94 中，蕴含了新的开发者界面——虚构键盘 API。该 API 能够让网页开发者在如何搁置虚构键盘及其形态方面有更多控制权，目前该 API 是齐全由用户代理行为解决的。
谷歌在全新的 Chrome 94 版本中删除了 AppCache，示意这是一个废除的规范，并倡议开发者应用 Service Workers 来代替。目前 Mozilla 和苹果也正在将其从各自的浏览器中删除。
Chrome 94 还将反对一个本地调度 API，该 API 容许开发者以用户阻挡、用户可见和背景这三个级别的优先级来调度工作。同时，本地调度 API 还启用了一个工作控制器（TaskController），以动静地扭转工作的优先级或齐全勾销优先级。
另外，Chrome 94 还有一些让人兴奋的小亮点，比方取得了一个新的显示捕获性能政策，反对 2D 画布中的更多色调空间。同时，Chrome 94 还更新了 WebGPU，作为 WebGL 的下一代 web 图形 API 替代品，WebGPU 是为当今网络中的古代图形需要而设计的，它能够容许依据平台映射到 Vulkan、Direct3D 或 Metal。
默认启用“闲暇检测 API”引争议
此次 Chrome 94 稳定版的到来，除了上述令人兴奋的亮点之外，其中提供的“为开发者提供更多信号以理解用户何时处于闲置状态”的“闲暇检测 API”，成为该版本颇具争议的中央。
据悉，在 Chrome 94 稳定版中，更新后的“闲暇检测 API”为开发者提供了更多信号，以理解用户何时处于闲置状态。该面向开发者的告诉当初不仅仅对以后的浏览器窗口进行监测，还将对（如与其余应用程序的互动）全局信号进行触发。
相比网络开发者更加踊跃的反馈，但业内对该 闲暇检测 API 示意担心。Mozilla 认为其是一种“资本主义的视监”，他们放心一些歹意网站会通过该 API 搞“毁坏”，比方在用户不批准或不晓得的状况下，最大限度地利用设备的计算资源。
对此，WebKit（苹果 Safari 浏览器引擎）背地开发团队也对 该 API 示意拥护。该团队示意：
“没有短缺的理由来应用这个 API。首先，不能保障用户不会立刻回到设施上。另外，这样的服务应该由谁来晓得用户在任何时候可能应用的其余设施？咱们必定不会让一个网站晓得一个特定的用户在任何时候可能应用的所有设施。这是对上述用户的隐衷的十分重大的进犯。在我看来，这样的压抑 / 散发机制最好留给底层操作系统 / 网络浏览器来解决。
在这一点上，我将进行对这个主题的回应，因为这里或其余中央提出的用例没有一个是令人信服的，而且你在这里提出的和我在其余中央发现的隐衷或平安缓解措施没有一个是充沛的。然而，不回应这个主题或将来对于这个主题的主题并不意味着咱们会重新考虑咱们的立场。除非在咱们提出的任何一个问题上有重大的新进展，否则咱们的立场仍将是拥护减少这个 API，除非另有阐明，无论咱们是否持续在公开场合这么说。”
只管有拥护的声音，但目前这个闲暇检测 API 将在 Chrome 94 中默认启用，以提供给开发者应用。
