-
Notifications
You must be signed in to change notification settings - Fork 40
uBlock 0.4.0.0 版本更新,引入修饰规则
对我来说 0.4.0.0 版本是 uBlock 的一个重要里程碑,所以我将 0.3.2.3 版本号直接跳升到了 0.4.0.0。
相比 Adblock Plus,uBlock 并没有将所有通用修饰规则都插入到每个页面以及一个页面的每个内嵌框架,所以页面加载速度更快,同时打开网页后的内存占用明显更少。
为了能够做到只插入和网页有关的修饰规则(而不是所有修饰规则),uBlock 会等待主 DOM 载入完毕,然后调查并收集页面的信息以便找出该页面需要插入哪些修饰规则。
这样做显著优化了内存占用,提升了页面加载效率,使得用户可以自由开启更多的过滤规则列表,却又不会明显降低浏览器运行速度或导致低配置设备难以使用(例如:"Acer C720 running slow")。
但它有一点稍显不足,就是本该通过修饰规则隐藏的 HTML 元素有可能在消失前短暂闪现一下(不过我发现这实际上很少遇到),原因经过调查,是所挑选的通用修饰规则可能在网页显示之后才生效。
解决该问题的一种办法是引入之前说的基于实体的修饰规则。这种新型修饰规则可在主 DOM 载入完毕以前插入,使得目标 HTML 元素早在网页显示之前就被隐藏。
到目前为止只有用于隐藏 Google 搜索页面广告的通用规则可从中受益,而且是这类修饰规则的最佳应用场景,因为所有广告肯定得在 google.com
、google.ca
、google.com.br
等 Google 搜索页面中隐藏。例如有些针对 google.*
的基于实体的修饰规则,它们只会插入到任意的 Google 域名。之所以 Adblock Plus 必须使用通用修饰规则来隐藏 Google 搜索页面的广告是因为它不支持在修饰规则的主机名后缀使用通配符。
还有就是基于实体的规则不适合应对大量的通用修饰规则(EasyList 里可有超过 14,000 条通用修饰规则)。
0.4.0.0 版本为修饰规则引入了一个缓存机制,所有有关的通用规则在首次挑选以后就会被记住,在后续访问同一主机名下的网页时就可以提早插入。这更接近于 ABP 的做法,但 uBlock 仍保留了自己高效的特点,即只在网页上插入少量的通用修饰规则。
经过我对一些繁忙站点(例如 si.com
, 我把它用在了参考基准测试里,为的是在修饰规则开发上找到代码的性能热点)进行测试后确认,尽管缓存带来了额外的开销,0.4.0.0 版本的网页载入效率仍比以往更高(0.3.2.2 版本的更新内容也对提高效率有所助益)。虽然缓存机制增加了 uBlock 的内存占用,但在我看来这种影响极其有限。
下面是 www.si.com
被打开 10 次以后得到的结果,所以每个页面所花费的时间要把总时间除以 10:
正是因为这个测试,我决定也利用这一缓存机制来隐藏那些链接到已屏蔽网络请求的 HTML 元素,早在它们的网络请求注定被浏览器取消之前,这些元素就已经被隐藏掉了。
uBlock Origin - 一款支持 Chromium、Firefox 和 Safari 的高效过滤工具,快速且简洁