phantomJs之殤，chrome-headless之生

技術雷達快訊：自2017年中以來，Chrome用戶可以選擇以headless模式運行瀏覽器。此功能非常適合運行前端瀏覽器測試，而無需在屏幕上顯示操作過程。在此之前，這主要是PhantomJS的領地，但Headless Chrome正在迅速取代這個由JavaScript驅動的WebKit方法。Headless Chrome瀏覽器的測試運行速度要快得多，而且行為上更像一個真正的瀏覽器，雖然我們的團隊發現它比PhantomJS使用更多的內存。有了這些優勢，用於前端測試的Headless Chrome很可能成為事實上的標準。隨著Google在Chrome 59版本放出了headless模式，Ariya Hidayat決定放棄對Phantom.js的維護，這也標示著Phantom.js 統治fully functional headless browser的時代將被chrome-headless代替。

Headless Browser

也許很多人對無頭瀏覽器還是很陌生，我們先來看看維基百科的解釋：

A headless browser is aweb browserwithout agraphical user interface.

Headless browsers provide automated control of a web page in an environment similar to popular web browsers, but are executed via acommand-line interfaceor using network communication.

對，就是沒有頁面的瀏覽器。多用於測試web、截圖、圖像對比、測試前端代碼、爬蟲（雖然很慢)、監控網站性能等。

為什麼要使用headless測試？

headless browser可以給測試帶來顯著好處：

對於UI自動化測試，少了真實瀏覽器載入css，js以及渲染頁面的工作。無頭測試要比真實瀏覽器快的多。

那麼Headless Chrome與上面提到fully functional headless browser又有什麼不同呢？

什麼是Headless Chrome？

Headless Chrome 是 Chrome 瀏覽器的無界面形態，可以在不打開瀏覽器的前提下，使用所有Chrome支持的特性，在命令行中運行你的腳本。相比於其他瀏覽器，Headless Chrome 能夠更加便捷的運行web自動化測試、編寫爬蟲、截取圖等功能。

有的人肯定會問：看起來它的作用和phantomjs沒什麼具體的差別？

對，是的，Headless Chrome 發布就是來代替phantomjs。

我們憑什麼換用Headless Chrome?

我爸是Google,那麼就意味不會出現phantomjs近2k問題沒人維護的尷尬局面。 比phantomjs有更快更好的性能。

能帶給QA以及項目什麼好處？

前端測試改進

以目前的項目來說，之前的前端單元測試以及組件測試是用karma在phantomjs運行的，非常不穩定，在遠端CI上運行時經常會莫名其妙的掛掉，也找不出來具體的原因，自從Headless Chrome推出後，我們將phantomjs切換成Headless Chrome，再也沒有出現過異常情況，切換也非常簡單，只需要把karma.conf.js文件中的配置改下就OK了。如下

UI功能測試改進

原因一，Chrome-headless能夠完全像真實瀏覽器一樣完成用戶所有操作，再也不用擔心跑測試時，瀏覽器受到干擾，造成測試失敗

原因二，之前如果我們像要在CI上運行UI自動化測試，非常麻煩。必須使用Xvfb幫助才能在無界面的Linux上 運行UI自動化測試。（Xvfb是一個實現了X11顯示服務協議的顯示伺服器。 不同於其他顯示伺服器，Xvfb在內存中執行所有的圖形操作，不需要藉助任何顯示設備。）現在也只需要在webdriver啟動時，設置一下chrome option即可，以capybara為例：

無縫切換，只需更改下配置，就可以提高運行速度與穩定性，何樂而不為。

Google終極大招

Google 最近放出了終極大招——Puppeteer（Puppeteer is a Node library which provides a high-level API to controlheadlessChrome over theDevTools Protocol. It can also be configured to use full (non-headless) Chrome.）

類似於webdriver的高級別的api，去幫助我們通過DevTools協議控制無界面Chrome。

在puppteteer之前，我們要控制chrome headless需要使用chrome-remote-interface來實現，但是它比 Puppeteer API 更接近低層次實現，無論是閱讀還是編寫都要比puppteteer更複雜。也沒有具體的dom操作，尤其是我們要模擬一下click事件，input事件等，就顯得力不從心了。

我們用同樣2段代碼來對比一下2個庫的區別。

首先來看看 chrome-remote-interface

再來看看 puppeteer

對，就是這麼簡短明了，更接近自然語言。沒有callback，幾行代碼就能搞定我們所需的一切。

總結

目前Headless Chrome仍然存在一些問題，還需要不斷完善，我們應該擁抱變化，適應它，讓它給我們的工作帶來更多幫助。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！