关于内存占用测试和快照的说明 - fang5566/uBlock GitHub Wiki

相比大多数过滤工具，uBlock 在内存使用上更高效，但在有些用户看来却名不副实，或没有官方文档“标榜”的那样令人印象深刻。

为此我写过相应的文章进行说明，但实际上影响因素不仅仅是垃圾收集，所以接下来我会在这里详细说明。

我在基准测试中所用的方法主要是为了重现我认为最普遍的场景，即用户按照自身喜好完全设置好 uBlock 并打开浏览器，开启的过滤规则列表也不做任何修改，也就是打开后放任不管。对于其他过滤工具我也是按这样的场景设定进行测试。

但我发现一些特定的操作会引起 uBlock 短期内存占用突增（我们称它为“内存波动”），虽然一旦操作完成 uBlock 就会释放这部分内存，但出于各种原因并非所有释放的内存都会被浏览器当作垃圾收集，其中一个原因可能是内存碎片。

引起内存波动的操作使得 uBlock 基准内存占用值始终有所增加，从浏览器的_任务管理器_ 可见一斑。

所以基本上如果在你查看内存占用值之前就让 uBlock 发生内存波动，那你肯定不会测到和我相同的值，即使你在内存波动之后也进行了垃圾收集。

当然其他所有扩展也都会发生内存波动，不同之处在于是什么操作引起的。在 uBlock 里能引起最严重内存波动的操作是重新加载所有过滤规则。有以下几种操作会使得所有规则重新加载：

• 打开或重新启动 uBlock（这是最明显的）。
• 对过滤规则列表的选择发生了变化。
• 添加和删除自定义规则。
• 更新过滤规则列表（如果勾选了_自动更新_选项，那就会自动更新列表）。

此外，从 0.6 版本开始，uBlock 支持建立快照来改善它在下次浏览器打开时的载入时间，而建立快照同样也会引起内存波动，不过一旦这个操作完成，后续 uBlock 启动时就会非常节省 CPU 和内存资源 -- 从原始文本文件下载和解析规则步骤可以完全跳过，使得没有新快照时 uBlock 能在很短的时间内完全载入并准备就绪。

至于快照建立时间完全是由 uBlock 来决定，目前是在规则列表加载几分钟以后建立，主要是避免在建立快照之前用户可能会更改对过滤规则的选择。

请注意首页里的基准测试距离现在已经有些时日，期间 uBlock 有大量代码被添加或修改，而列表本身的规则条数也有所增加（我得检查一下）。所以下面我将通过测试找出 uBlock 0.6 何时更节省内存，比较对象为 ABP 1.8.3。

不包含有效的快照（快照是在测试过程中建立的）：

包含有效的快照：

基准测试细节：

• Google Chrome 37 的 64 位版本，Linux Mint 系统
• 插件设置为_"点击后运行"_
• 禁用第三方 cookie
• uBlock 使用默认过滤规则列表
• ABP 开启_EasyList_、EasyPrivacy 和 Malware Domains。关闭_"允许非侵入式广告"_
• 参考基准测试完成至少 15 分钟以后再截图，同时关闭_扩展_页以外的所有页面。

提醒

请记住上述测试的对象是扩展_本身_ 的内存占用，如果是打开网页以后的内存占用 Adblock Plus 会更大。打开网页以后 ABP 与 uBlock 的内存占用值之差远比上述测试结果来得大，这是因为 ABP 会将 14,000 多条 CSS 规则插入每个网页以及每个网页的每个 iframe 框架，这还是在只开启了 EasyList 的情况下。

附录

如果你要测试内存占用，你还需要记住 uBO 在以下几种场景下内存占用会更高：

• uBO 的控制面板打开时；
• uBO 的记录台打开时；
• uBO 的元素选择器在当前页面处于激活状态；
• 你在 uBO 的记录台查找某条过滤规则来自于哪些规则列表；
• 你阻止了在进行内存密集型的操作以后浏览器所要执行的垃圾收集工作，例如：
  • 刚刚打开了 uBO 的弹出面板；
  • 刚刚打开了 uBO 的控制面板；
  • 刚刚使用了 uBO 的记录台；
  • 刚刚使用了 uBO 的元素选择器；
  • 刚刚重新加载了过滤规则列表；
  • 未超过 10-15 分钟前查找了某条过滤规则的来源；