Web自動化

這裡所說的Web自動化是所有跟頁面相關的自動化，比如頁面爬取，資料抓取，頁面內容檢測，頁面功能測試，頁面載入效能測試，頁面迴歸測試等等，當前主要由如下幾種解決方式：

文字資料獲取

這就是各種request庫或者類似curl這樣的工具做的事情，拿到的是頁面的文字，然後進行XML文件解析，獲得相應的內容。但如果頁面有一些動態執行的內容，比如JavaScript生成跳轉URL，這樣就搞不定了，需要有JS引擎的工具來搞，比如再配合JS引擎自行實現的工具，或者直接使用瀏覽器核心來搞的工具。

按照瀏覽器的方式來執行

這就是各種使用瀏覽器核心來實現的工具，比如基於Webkit的PhantomJS, 基於Gecko的SlimerJS, 經過包裝的CasperJS相容PhantomJS和SlimerJS，以及基於v8JS引擎和.net平臺的trifleJS等。這些工具更新迭代跟不上Web標準的發展，新的Web標準無法得到良好的支援。

透過協議直接操作真實瀏覽器

這就是Selenium的實現方式，透過WebDriver協議進行通訊，瀏覽器和瀏覽器驅動都實現了C/S結構的WebDriver協議,Selenium透過瀏覽器的驅動包，來傳送操作請求，瀏覽器根據請求響應相應的操作。這樣實現有一個問題是始終有一個真實瀏覽器的介面在渲染和變化，一方面效率低下，另一方面在服務端環境無法執行。於是就衍生出了使用Xvfb(virtual framebuffer X Server) 來配合實現在伺服器環境下的執行，基本解決了問題。但每一種瀏覽器的特性支援都依賴於相應的驅動的實現和支援情況。

無介面瀏覽器

前面的實現方式都或多或少有自己的問題或者侷限，如果瀏覽器本身支援在服務端環境執行，這將是一個近乎完美的解決思路。Chrome 59開始支援無介面模式，Firefox 55支援Linux版的無介面模式，Firefox 56支援全平臺的無介面模式，這樣一來，使用方不用被動等待瀏覽器的WebDriver的實現。

Headless Chrome相關的對比

Headless 是一種在無圖形介面環境執行的一種能力，比如高效能的伺服器端環境，參考。

PhantomJS的問題

使用老版本的Webkit，不支援新的Web標準，跟真實瀏覽器存在差異
開發者維護難度大，，起因是Chrome 將支援 Headless模式
要解決的問題多，1800+
記憶體佔用高，併發有問題，不穩定，有些奇奇怪怪的bug

Selenium的問題

使用介面和瀏覽器驅動來操作真實瀏覽器，帶介面渲染，速度慢
需要有圖形介面，顯示裝置的支援
需要使用（virtual framebuffer X Server）
- X是架構無關的遠端圖形介面和輸入裝置相容的系統，C/S架構
- 在沒有物理輸入和顯示裝置的機器上執行
- 這裡可以簡單理解為虛擬顯示器或者顯示器模擬器
也支援Headless實現，實現跟Web標準有差異
透過(WebDriver的Chrome實現)的來操作Chrome，需要依賴ChromeDriver的更新
- 可以在檢視支援的Chrome版本

Headless Chrome帶來的優勢

資源佔用少（相對於PhantomJS）
服務端環境(命令列，無圖形介面)
支援現代Web標準和技術(ES6,ServiceWorkers,WebGL…)
行為符合Web規範、版本能自動更新
Chronium/Chrome團隊維護

Web自動化之Headless Chrome概覽