在 javascript 运行时中查看 idle 时间，最直接的方法是使用 performance api 中的 performanceobserver 监听 longtask 类型的事件，并通过计算帧间隔与任务耗时的差值来推导空闲期。具体做法是注册一个观察者，当检测到长任务（超过 50ms）时，记录任务的开始和结束时间，结合 requestanimationframe 的回调时机或手动打点，计算出任务执行完毕后到下一帧开始前的时间窗口即为 idle 时间。如果浏览器支持 interactiontonextpaint 或 firstinputdelay 等指标，也可以间接反映用户交互后的空闲等待情况，但针对纯 js 线程的空闲分析，基于长任务观测是最通用的方案。
如何配置 PerformanceObserver 来捕获长任务事件？
要捕获长任务，需要创建一个类型为 longtask 的 PerformanceObserver 实例，并调用其 observe 方法。这会告诉浏览器监控主线程上耗时超过 50 毫秒的任务块。当这样的任务发生时，观察者的回调函数会被触发，传入一个包含任务详细信息的列表。每个条目都提供了 startTime、duration 以及所属的 entryType。通过收集这些数据，开发者可以构建出主线程被占用的时间轴，从而识别出哪些时间段是忙碌的，进而推断出空闲时段。
const observer = new PerformanceObserver((list) => {
const entries = list.getEntries();
entries.forEach((entry) => {
console.log(`Long Task: ${entry.name}`);
console.log(`Start Time: ${entry.startTime}`);
console.log(`Duration: ${entry.duration} ms`);
// 这里可以记录任务区间，用于后续计算空闲时间
});
});
observer.observe({ entryTypes: ['longtask'] });
上述代码创建了一个观察者并启动了监控。运行这段代码后，控制台会输出所有检测到的长任务详情。例如，如果一个同步脚本执行了 100ms，那么在这 100ms 内，JavaScript 引擎无法响应其他事件，这段时间就是非空闲的。通过累加这些任务的持续时间，并与总运行时间对比，可以得到总的忙碌时间，剩余部分即为潜在的 Idle 时间。需要注意的是，这种方法只能看到“忙”的时间，Idle 时间是推导出来的，而非直接测量的属性。
如何利用 requestAnimationFrame 辅助计算帧间空闲时间？
除了监听长任务，还可以利用 requestAnimationFrame (rAF) 来更精细地测量每一帧内的空闲时间。浏览器的渲染循环通常包括处理 JS、样式计算、布局、绘制等阶段。如果在 rAF 回调中执行大量工作，就会挤压后续的渲染步骤。通过在 rAF 回调的开始和结束位置打点，可以计算出该帧中 JS 执行所占用的时间。假设一帧的标准时长为 16.67ms（对应 60fps），用这个标准值减去 JS 执行时间，即可得到该帧中留给浏览器进行其他操作（如合成、绘制）的理论空闲时间。这种方法特别适合优化动画性能，确保每一帧都有足够的余量来完成渲染。
let lastTime = performance.now();
function measureFrame() {
const start = performance.now();
// 模拟一些 JS 工作
for (let i = 0; i
<p>这段代码演示了如何在每一帧中估算空闲时间。它首先记录 rAF 回调开始时的时间戳，然后执行一段模拟的 CPU 密集型工作，最后记录结束时间。通过计算两者之差得到 JS 耗时，再用 16.67ms 减去该耗时，得出空闲时间。如果结果为负数，说明当前帧超时，可能导致掉帧。这种方法的优点是能实时反馈每一帧的性能状况，帮助开发者调整代码逻辑，避免在某一个帧中堆积过多任务。结合长任务观察器和 rAF 测量，可以更全面地掌握 JavaScript 运行时的空闲时间分布。</p>
<h2>当长任务持续时间超过 100ms 时，对页面响应性有何具体影响？</h2><p>当长任务持续时间超过 100ms 时，页面会出现明显的卡顿感，用户交互（如点击、滚动）的响应延迟会显著增加。这是因为 JavaScript 单线程模型决定了在主线程执行长任务期间，浏览器无法处理用户输入事件、定时器回调或网络请求的完成通知。具体来说，如果某个任务持续 100ms，用户在按下按钮后可能需要等待 100ms 甚至更久才能看到视觉反馈。此外，长时间的阻塞还会导致浏览器 UI 线程冻结，表现为页面无响应，甚至在某些极端情况下触发浏览器的“慢脚本”警告对话框。因此，保持单个任务在 50ms 以内是保证流畅用户体验的关键阈值。</p>
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
