此页面由 Cloud Translation API 翻译。

使用 measureUserAgentSpecificMemory() 监控网页的总内存用量

了解如何衡量网页在生产环境中的内存用量，以检测回归问题。

Brendan Kenny

Ulan Degenbaev

浏览器会自动管理网页内存。每当有网页创建对象后，浏览器会“在后台”分配一块内存更改为存储对象。由于内存是有限的资源，因此浏览器会执行进行垃圾回收，以检测何时不再需要某个对象并释放底层内存块

不过，检测并不完美，经证实能够完美的检测是一项不可能完成的任务因此，浏览器将“对象”与需要”“可触及对象”这一概念如果网页无法通过某个对象的变量和其他可到达对象的字段访问该对象；那么浏览器就能够安全地收回对象这两种模式之间的区别两种概念都会导致内存泄漏，如以下示例所示。

const object = {a: new Array(1000), b: new Array(2000)};
setInterval(() => console.log(object.a), 1000);

此处不再需要更大的数组 b，但浏览器不需要收回，因为它仍可通过回调中的 object.b 访问。因此较大数组的内存泄漏。

内存泄漏在网页上很常见。引入事件监听器非常简单，只需忘记取消注册事件监听器即可，意外从 iframe 捕获对象，即没有关闭 Worker，累积数组中的对象，依此类推。如果网页存在内存泄漏那么其内存使用量会随着时间的推移而增加使用户感到臃肿。

解决此问题的第一步是对其进行测量。新的 performance.measureUserAgentSpecificMemory() API 让开发者可以衡量其网页在生产环境中的内存用量，从而检测内存用量通过本地测试遗漏的泄漏。

`performance.measureUserAgentSpecificMemory()` 与旧版 `performance.memory` API 有何不同？

如果您熟悉现有的非标准 performance.memory API，您可能会好奇新 API 与其有何不同它们的主要区别在于旧 API 会返回 JavaScript 堆的大小，而新 API 用于估算网页使用的内存这种差异会变为在 Chrome 与多个网页（或同一网页的多个实例）。在这种情况下， API 可能会被任意关闭。由于旧版 API 是在实现专用术语（例如“堆”），那么对它进行标准化将是无望的。

另一个区别是，新的 API 会在垃圾回收。这样可以减少结果中的噪声，但可能需要等待结果生成。请注意，其他浏览器可能会决定实现新 API，而不依赖于垃圾回收。

建议的用例

网页的内存用量取决于事件、用户操作和垃圾回收。正因如此，Memory Measurement API 适用于汇总生产环境中的内存使用情况数据。单个调用的结果没什么用处。应用场景示例：

发布新版本网页期间的回归检测，以捕获新的内存泄漏。
对新功能进行 A/B 测试，以评估其内存影响并检测内存泄漏。
将内存用量与会话时长相关联，以验证是否存在内存泄漏。
将内存用量与用户指标相关联，以了解内存用量的总体影响。

浏览器兼容性

浏览器支持

<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">

来源

目前，只有基于 Chromium 的浏览器（从 Chrome 89 开始）才支持该 API。通过该 API 的结果与实现高度相关，因为浏览器在内存中表示对象的不同方式来估算内存用量浏览器可能会将某些内存区域因此，结果无法跨浏览器进行比较。只有在比较同一浏览器的搜索结果。

使用 `performance.measureUserAgentSpecificMemory()`

功能检测

performance.measureUserAgentSpecificMemory 函数将不可用或可能不可用如果执行环境不满足，则失败并显示 SecurityError 旨在防范跨源信息泄露的安全要求。它依赖于跨域隔离，网页可以激活该隔离功能方法是设置 COOP+COEP 标头。

可在运行时检测到支持情况：

if (!window.crossOriginIsolated) {
  console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
} else if (!performance.measureUserAgentSpecificMemory) {
  console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
} else {
  let result;
  try {
    result = await performance.measureUserAgentSpecificMemory();
  } catch (error) {
    if (error instanceof DOMException && error.name === 'SecurityError') {
      console.log('The context is not secure.');
    } else {
      throw error;
    }
  }
  console.log(result);
}

本地测试

Chrome 会在垃圾回收期间执行内存测量 API 不会立即解析结果 promise，而是会等待进行下一次垃圾回收

在超时一段时间后，调用该 API 会强制执行垃圾回收，即当前设置为 20 秒，但可能会更早通过 --enable-blink-features='ForceEagerMeasureMemory' 命令行标志缩短了超时值为零，并且对本地调试和测试很有用。

示例

使用此 API 的建议用途是定义一个全局内存监视器，对整个网页的内存使用情况进行采样，并将结果发送到服务器进行汇总和分析。最简单的方法是定期采样，每 M 分钟训练一次示例。不过，这会给数据带来偏见，因为样本之间可能会出现内存峰值。

以下示例展示了如何使用泊松过程进行无偏见内存测量，可以保证样本在任何时间点出现的几率相同，（演示、来源）。

首先，定义一个函数，该函数使用随机间隔的 setTimeout()。

function scheduleMeasurement() {
  // Check measurement API is available.
  if (!window.crossOriginIsolated) {
    console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
    console.log('See https://web.dev/coop-coep/ to learn more')
    return;
  }
  if (!performance.measureUserAgentSpecificMemory) {
    console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
    return;
  }
  const interval = measurementInterval();
  console.log(`Running next memory measurement in ${Math.round(interval / 1000)} seconds`);
  setTimeout(performMeasurement, interval);
}

measurementInterval() 函数计算随机间隔（以毫秒为单位）以便平均每五分钟测量一次。请参阅指数分布。

function measurementInterval() {
  const MEAN_INTERVAL_IN_MS = 5 * 60 * 1000;
  return -Math.log(Math.random()) * MEAN_INTERVAL_IN_MS;
}

最后，异步 performMeasurement() 函数调用 API，记录结果，并安排下一次衡量。

async function performMeasurement() {
  // 1. Invoke performance.measureUserAgentSpecificMemory().
  let result;
  try {
    result = await performance.measureUserAgentSpecificMemory();
  } catch (error) {
    if (error instanceof DOMException && error.name === 'SecurityError') {
      console.log('The context is not secure.');
      return;
    }
    // Rethrow other errors.
    throw error;
  }
  // 2. Record the result.
  console.log('Memory usage:', result);
  // 3. Schedule the next measurement.
  scheduleMeasurement();
}

最后，开始衡量。

// Start measurements.
scheduleMeasurement();

结果可能如下所示：

// Console output:
{
  bytes: 60_100_000,
  breakdown: [
    {
      bytes: 40_000_000,
      attribution: [{
        url: 'https://example.com/',
        scope: 'Window',
      }],
      types: ['JavaScript']
    },

    {
      bytes: 20_000_000,
      attribution: [{
          url: 'https://example.com/iframe',
          container: {
            id: 'iframe-id-attribute',
            src: '/iframe',
          },
          scope: 'Window',
      }],
      types: ['JavaScript']
    },

    {
      bytes: 100_000,
      attribution: [],
      types: ['DOM']
    },
  ],
}

总内存用量估算值会在 bytes 字段中返回。该值为高度依赖实现，无法跨浏览器进行比较。它可能会甚至可以在同一浏览器的不同版本之间进行更改。该值包括内所有 iframe、相关窗口和 Web Worker 的 JavaScript 和 DOM 内存当前进程

breakdown 列表提供了有关所用内存的更多信息。每个该条目描述了内存的某个部分，并将其归因于窗口、iframe 和工作器。types 字段会列出与内存关联的特定于实现的内存类型。

务必以通用方式处理所有列表，而不是硬编码基于特定浏览器进行的预测。例如，某些浏览器可能会返回空的 breakdown 或空的 attribution。其他浏览器在 attribution 中返回多个条目，这表明它们无法区分其中哪个条目拥有该内存

反馈

网页性能社区小组和 Chrome 团队非常愿意分享您对 performance.measureUserAgentSpecificMemory()。

向我们介绍 API 设计

API 是否存在无法按预期运行的地方？或者，在那里还缺少一些属性？提交规范问题 performance.measureUserAgentSpecificMemory() GitHub 代码库中，或添加您对现有问题的想法。

报告实现存在的问题

您在 Chrome 的实现过程中是否发现了错误？还是与规范不同？在 new.crbug.com 上提交 bug。请务必请提供尽可能多的细节，提供重现问题的简单说明修正 bug，然后将 Components 设置为 Blink>PerformanceAPIs。 Glitch 非常适用于分享轻松快速的重现问题。

表示支持

您打算使用 performance.measureUserAgentSpecificMemory() 吗？你的公开支持可帮助 Chrome 团队确定各项功能的优先级，并向其他浏览器供应商展示但为他们提供支持至关重要向 @ChromiumDev 发送推文并告诉我们您使用它的地点和方式。

实用链接

致谢

非常感谢 Domenic Denicola、Yoav Weiss 和 Mathias Bynens 对 API 设计进行审核，以及 Dominik Inführ、Hannes Payer、Kentaro Hara、Michael Lippautz 和 Michael Lippautz 的代码审核。此外，我们还要感谢 Per Parker、Philipp Weis、Olga Belomestnykh、Matthew Bolohan 和 Neil Mckay 提供了宝贵的用户反馈，改进了 API。

主打图片，作者：Harrison Broadbent，来源于 Unsplash 用户