AdBlock广告拦截插件的实现原理

在这里，我不会解释太多的代码，没有必要，说说原理就可以了。

AdBlock的广告拦截实际上分为2个部分：

1、对于URL请求的拦截

这一般都是页面中DIV元素嵌入一个IFRMAE/IMAGE元素，然后加载一个广告链接或者GIF图片什么的。

这部分的规则库描述比较复杂。规则大概有几万条，即使对于国内的使用，可能也会有个1000条左右。

不过我觉得没必要搞这么复杂，可以通过提取出最常见的100条，然后用这100条屏蔽80%的请求，就可以了。

这些规则的语法，基本上是对于URL中domain和path的字符串前缀或后缀匹配。可能附带一些额外的属性（理论上说来，这些属性都应该可以从NetworkRequest对象中获取到）

AdBlock Plus的作者实际上是使用JavaScript把这些URL匹配规则映射为了正则表达式，然后再用正则表达式对目标URL进行匹配过滤。

当然，也可以用Java来实现。前面已经说了，正则表达式是基于前缀或者后缀的，前缀可以用Trie树，后缀可以反转后当作前缀处理。

而对于keyword in查询，可以使用基于编译自动机的AC算法（我认为AC算法其实就是一个简化版的 key1|key2|key3|...|keyn 这种形式的正则表达式而已）

一旦匹配上，在shouldOverrideUrlLoading函数里return true;代表已额外处理，实际上不处理，这样就屏蔽了此URL请求。（shouldOverrideUrlLoading主要是用于特殊的scheme协议的，用于URL请求拦截实属误用），好像有额外的shouldIgnoreNetworkRequest

2、对于页面DOM嵌入广告内容的处理

基于规则是，通过CSS3 Selector定位到这些DOM元素，然后设置其display等于none !important。

AdBlock Plus对于页面内容的广告过滤是特定于网站的，也就是说，是对于domain字符串的精确匹配。这里使用一个简单的HashMap性能也就足够可以了。

问题是，有些广告内容是延迟加载的（通过setTimer），对于这部分内容，只能等个几秒钟等广告内容出来之后，才注入执行JS脚本。

当然，这种方法不是很好，最好是在浏览器内核里做一个DOM Mutation事件监控的daemon：如果检测到有新的DOM节点加入，当然必须是在DOM Content Loaded之后，就发送一个通知给客户端，客户端再调度广告屏蔽脚本的重新执行。

上面2类处理看起来有效，实际上无效。设想网站要求用户必须访问广告服务器，以提高一个特殊的cookie，这样才允许用户访问资源。这样第1种方法其实就没用武之地了。对于第2种则更简单，原则上来说，如果把广告跟正常内容混合在一起，你是没办法用计算机算法来区分谁是广告谁是正常内容的，除非用人来维护。或者立法。

从个人角度考虑，某部分广告则让让它下载显示也无不可，如果用户觉得它烦，就提供一个规则添加的UI交互入口。而对于弹窗、闪烁的GIF这类比较恶心的，杀之可也。

1/15更新：

AdBlock Plus做到的优化：假如一个URL为a.b.c，那么这个URL只会跟过滤规则里包含a,或者b,或者c的规则做匹配，后者还是得一个一个的执行JS正则表达式线性匹配

好处就是那些规则中不包含a,b,c的将不会与这个url做匹配。这可能使得把一个10000条规则的总线性扫描降低到了1000条的规模。

 但是，它还是没有猎豹浏览器的做法好：AdBlock Plus最终URL与过滤规则的匹配还是用JS正则表达式来执行的（当然，JS里的字符串高级处理都只能用用正则表达式，逐个字符比较对JS代码来说不现实），猎豹对于简单的前缀/后缀匹配可以使用Trie树或AC自动机，但这是基于字符的，只能在Java里执行才有效率。

不过，我想，更有技术含量的，是引入协作式过滤：当用户标明网页中的某个元素属于广告，那么，浏览器内核可以智能地定位到这个DOM元素，并生成一个有效的CSS Selector（这个就是难度之所在了），这样就可以动态地扩展用户的本地过滤规则库，然后再通过上传到云端服务器形成大数据，从中挖掘出公共的广告拦截规则库。