关于 “uBlock 在浏览器里更轻巧,功能必然低下”的说法 - fang5566/uBlock GitHub Wiki

我之所以写这篇文章,是因为下面这条以炮制 假消息(没有客观证据支持,只是说 “相信我吧” )为目的的评论:

Ublock 在浏览器里更轻巧,所以功能必然[比 Adblock Plus(ABP)]低下[原文]

喜欢 ABP 胜过 uBlock Origin(uBO) 没什么不对,但一些人因为喜欢 ABP 就忙着拿 uBO 造谣就有些不妥了。

下面是我对它的回答,以供参考。

uBO 更轻巧源于过滤引擎内部设计方面所做的诸多选择。这些选择我粗略列举如下:

  • 在内存中使用精简的过滤规则表达
  • 尽可能使用普通字符串而非正则表达式进行比对
    • 大多数网络规则可精简为基本的字符串比对,这正是 uBO 内部处理它们的方式。相反,ABP 会将 所有 网络规则转换为正则表达式。
    • 例如 &ad_zones= 这条规则(来自 EasyList)
      • ABP 的代码在概念上是:/&ad_zones=/.test(url) -- 整条 URL 都必须被扫描一遍
      • uBO 的代码在概念上是:url.startsWith('&ad_zones=', i) -- 无需扫描整条 URL
  • 避免不加区分地将 18,000 多条(仅开启 EasyList)通用 CSS 规则插入到所有页面或帧框架里
    这样不会产生内存占用过大的问题

相比 ABP,这些设计上的选择让 uBO 变得 “功能低下” 吗?看看下表里的功能对比再来回答吧(就在写作本文的时候):

特性 ABP uBO
网络过滤
多级过滤引擎
允许用户轻松按不同的站点覆盖第三方列表中的规则
@@...$document
可读取 hosts 文件
解除隐藏 CNAME
denyallow
domain 支持实体匹配
inline-script
可阻止执行内联的 Javascript
important
可覆盖例外规则
popunder
redirect
可重定向到本地资源,是保护隐私和对付反过滤机制的关键
csp=
参见原理说明
badfilter
可禁用一条已有的过滤规则
严格屏蔽
基于规则的过滤
通过相应的一指一点界面提供类似于防火墙或基于 URL 的规则
后台请求
uBO 的记录台可显示后台请求,可选择进行过滤
修饰过滤
基于实体的过滤规则
-abp-properties
:has 尚未支持 是 (:-abp-has)
:has-text (-abp-contains)
:if :if-not
:matches-css :matches-css-before :matches-css-after
:xpath
:remove
:style
:upward
小脚本过滤
+js(...)
可在页面内容区域插入小脚本
对付反过滤工具机制的关键
HTML 过滤
可即时修改响应数据
WebExtensions uBO 1.15+
隐私
高级用户默认设置
uBO 没有获利,没有对高级用户妥协的压力
禁止预读取
禁止超链接审计
禁止通过 WebRTC 泄露本地 IP 地址
屏蔽 CSP 报告
其他特性
预编译规则列表以便更快加载过滤规则
“可接受的广告”
完全禁用
过滤规则生效计数 是,默认禁用
可全局忽略通用修饰规则
适用于低性能移动设备
云存储 仅支持 Firefox
可一指一点实现类似于防火墙的过滤
可使用休闲严格的默认拒绝方式
记录台 每个页面一个 统一的
可一指一点实现每个站点禁止弹出窗口
可一指一点实现每个站点禁止修饰规则生效
可一指一点实现每个站点禁用大型媒体元素
可一指一点实现每个站点禁用远程字体
集成元素选择工具 仅支持基于 Chromium 的浏览器
元素去除器
轻松备份和恢复所有设置 仅支持 Firefox
⚠️ **GitHub.com Fallback** ⚠️