在這里，我不會解釋太多的代碼，沒有必要，說說原理就可以了。

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（這個就是難度之所在了），這樣就可以動態地擴展用戶的本地過濾規則庫，然后再通過上傳到云端服務器形成大數據，從中挖掘出公共的廣告攔截規則庫。

總結

以上是生活随笔為你收集整理的AdBlock广告拦截插件的实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。