再看 Google Chrome

大約一個月前，緊跟著 Opera 9.5、Firefox 3、IE 8 之後而來的 Google Chrome，似乎驗應了瀏覽器大戰又將火熱展開。Google Chrome 測試版推出的那一天，網路上大大小小的媒體無不爭相報導；本專欄從來不盲目追逐流行，所以讓我們在一個月之後的現在，再來冷靜地檢視這枚由穀歌拋出的震撼彈，看看在鮮明簡潔的表面之後，究竟有些什麼。

Google Chrome 目前僅釋出一個測試版本，版次為 0.2.149.27 Beta，標榜的功能不外乎介面簡潔、反應敏捷等；許多相關報導都集中在多執行緒的記憶體用量，以及 V8 這個 JavaScript 引擎的執行效率上，認為這兩者搭配起來，讓 Google Chrome 更快、更穩健。實際使用了整整一個月之後，筆者發現這兩點似乎都不是那麼一回事。

首先要說明一下測試的環境。筆者使用的環境是四年多前購入的筆記型電腦，CPU 為 Intel Pentium M 1.1GHz，配有 768MB 的記憶體，採用 Toshiba 2.5 吋、轉速 5400rpm、容量 100G 的硬碟，作業系統則為繁體中文版的 WindowsXP Pro SP3。這樣的硬體配備以今天的標準來看，恐怕是寒酸得很，但是這麼多年來，這台筆記型電腦一直勤奮地工作著，沒有出過任何問題，而且筆者平日慣用的瀏覽器 Opera 也表現得相當敏捷，實在沒有不能拿來測試 Google Chrome 的道理。

Google Chrome 本身是多語介面的，意味著在中文版的 Windows 上安裝時，就會從一開始以中文介面呈現；但是穀歌向來只注重全球市場，比較不花精力在各地區市場，於是在剛開始安裝的時候，就讓人皺起了眉頭─相信許多人都看到了，那個「歡迎使用 Google 瀏覽器」的安裝視窗標題，把「歡」誤植為「觀」了。但這不是 Google Chrome 當中唯一出現的中文錯字；在 Google Chrome 下載管理畫面的右鍵選單當中，也把「複製檔案」誤植為「複雜檔案」，真是讓人越看越複雜，對軟體使用比較沒經驗的使用者，恐怕是丈二金剛摸不著頭緒，弄不懂這個選項到底是做什麼用的。

不只是程式介面有這種本地化時的錯誤，就連相關的說明文件也不例外。在 https://www.google.com/chrome/intl/zh-TW/webmasters-faq.html#useragent 這一頁，指出 Google Chrome 的使用者代理程式字串為：

Mozilla/5.0 (Windows；U；Windows NT 5.1；en-US) AppleWebKit/525.13 (KHTML，如 Gecko) Chrome/0.X.Y.Z Safari/525.13。

如果真的有網頁管理者按照上述內容來判定 Google Chrome 的話，一定會音訊全無，因為目前為止，沒有任何程式送出來的使用者代理程式字串，會含有全型標點符號跟中文字；上述這段字串在英文版的文件當中其實是這樣的：

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13.

這段字串應該要保留隻字未動才對，因為即便是中文介面的 Google Chrome，也會送出相同的使用者代理程式字串。這一點，負責製作中文版文件的人顯然疏忽了。一個錯字可以是意外，兩個錯字很難說是巧合；連文件都跟著有問題，則已經是商業軟體中相當嚴重的情況了。

接著再來看看 Google Chrome 的多緒分頁。按照穀歌的說法，Google Chrome 的每一個瀏覽器分頁，都會有一支獨立的執行緒，因此若有哪個分頁的記憶體洩漏了，哪麼只需要把該分頁關閉即可，不會波及其他分頁；西元一九一二年，當時號稱全世界最大最安全的郵輪鐵達尼號，也用了相同的概念來設計水密艙，但是首航就發生的罹難事件，證實了當時被認為最安全的船也還是會沈沒。同樣地，許多瀏覽網頁時可能發生的意外，也會讓整個 Google Chrome 瞬間沈沒，而不是只有一個分頁而已。例如 https://evilfingers.com/advisory/google_chrome_poc.php 指出，當 Google Chrome 遇到協定未註冊、內容含有特定字符的鏈結，像是「evil:%」時，就會馬上整個死掉，沒有任何分頁能存活下來。

Google Chrome 的多緒分頁設計還有一個附帶效應，就是會佔用更多的記憶體。儘管穀歌宣稱隨著分頁越開越多，最後佔用的總記憶體應該會比其他瀏覽器少，甚至在 Google Chrome 的 about:memory 頁面中，還會列入其他所有開著的瀏覽器的記憶體使用狀況統計，但實際上不管是開了五個分頁還是一百五十個分頁，Google Chrome 會佔用的記憶體還是最多的，比 Opera、IE、Firefox 都還要多。

如果你自己做了這樣的實驗，那麼應該還會發現，當 Google Chrome 開了一堆分頁、佔用一堆記憶體之後，他會漸漸地把記憶體擠回來。仔細觀察之後，會發現 Google Chrome 一有機會就會把記憶體內的東西置換到硬碟上（虛擬記憶體），等到要用的時候再讀回記憶體，藉此試圖降低記憶體用量。然而就算如此，Google 佔用的實體記憶體，還是比我的 Opera 還多。而且這種拼命置換的做法，結果就是會產生大量的硬碟讀寫動作；如果你跟我一樣，用的不是下個月才要發表的全新電腦硬體，很容易就會被這種頻繁的硬碟讀寫給拖累，而讓整個作業系統動彈不得。

如果這時候你讓 Google Chrome 去處理複雜的網頁，情況就可能更糟糕。採用 V8 引擎的 Google Chrome 雖然執行 JavaScript 起來更快，但是也比其他瀏覽器耗用更多的 CPU 資源，而且支援程度並不理想，就連穀歌自己的網頁服務，遇到 Google Chrome 都有可能出錯。有人發現 Google Groups 裡面的「新增頁面」功能失常，筆者則是遇過 GMail 當中有一封信無論如何就是不會變成「已閱讀」的狀態。PicasaWeb 也同樣地不支援 Google Chrome（下載相簿的功能無法使用）。如果連穀歌自己的產品都支援不良了，第三方網站或程式又怎能期待有多好的支援呢？

目前為止，看來 Google Chrome 陷入了非常弔詭的局面：如果你的硬體配備夠快、夠好，那麼 Google Chrome 就能讓你體驗無比的速度；如果你的硬體配備比較慢、比較差，就會比別的瀏覽器更慢更遲滯，可以說是遇快則快、遇慢則慢。弔詭之處就在於，對於受瀏覽器緩慢所苦的使用者來說，Google Chrome 的「速度」只會幫倒忙。

那麼，這個為明天（CPU 更快、記憶體更多、硬碟讀寫更有效率）的電腦所設計的瀏覽器，真的就能在明天派上用場嗎？

真的拿 Google Chrome 來用上一陣子，會發現在他簡潔的介面背後，用起來麻煩得很。首先 Google Chrome 並沒有任何「選單」，除了網址列跟幾個工具按鈕外，只有「網頁功能」跟「工具」這兩個功能表，讓使用者藉此取用各項設定跟進階功能；然而這兩個功能表都沒有對應的按鍵，非得用滑鼠（或其他指標式輸入介面）操作不可。換句話說，你無法僅用鍵盤，開啟 Google Chrome 的「說明」或「選項」等。

瀏覽網頁內容時，一般的瀏覽器會在滑鼠點按任何網頁內容控制組件（例如按鈕、核選框、文字區域等）後，將該組件設為現用中的焦點組件，之後若使用者按下 Tab 鍵，則會根據文件流向，從現用中的組件繼續往後導覽；但是在 Google Chrome 中，按下 Tab 鍵卻會將焦點移回網頁文件開頭，重頭開始。我們常常在輸入完某些表單之後，直接按 Tab 鍵移往緊鄰的「送出」按鈕，但這種便利在 Google Chrome 當中則蕩然無存。

Google Chrome 這種逼你一定要用滑鼠的做法，違背了多項全球資訊網協會所訂定的「使用者代理親和力方針」。事實上，若我們進一步檢視，就會發現在 Google Chrome 使用介面中的各個控制元件，例如按鈕、輸入框等，以及網頁內容中的鏈結等，都缺乏正確的名稱、角色、狀態資訊，意味著各種輔助科技如螢幕朗讀軟體（像是 NVDA Screen reader、JAWS、Window-Eyes）等，都無法與 Google Chrome 搭配使用。

如果你試圖用 Windows 內建的親和力功能「協助工具選項」，把畫面顯示設定為「高對比」，會發現這個對比設定幾乎對 Google Chrome 無效─唯一看得出有大幅影響的地方是 Google Chrome 的「選項」畫面，而且是會讓此畫面的文字難以閱讀，而非協助使用者加以使用。

從網頁親和力的觀點來看，Google Chrome 簡直是一場災難。就算撇開親和力的眼光，從可用性的角度來分析 Google Chrome，也會發現些不對勁的地方，像是檔案下載的功能。

Google Chrome 的設計是，每個分頁在下載檔案時，就會在該分頁最底下出現一個「下載內容列」，列出下載有關的資訊。舉例來說，當我在下載一個 562 MB 大的 foo.avi 影片檔時，可能就會看到這些資訊：

foo.avi    3.8/562 MB，剩餘時間...

沒錯，我可能最關心的「還有多久可以抓完」的資訊，就這麼攔腰截斷；按照目前的 Google Chrome 來看，不論你下載多大的哪種檔案，在下載內容列都無法顯示出剩餘時間的資訊─既然如此，為什麼還要煞有其事地寫個「，剩餘時間...」呢？有個合理的猜測是這個資訊在英文版的 Google Chrome 當中是看得到的，中文版則是意外；若真如此，那麼 Google Chrome 可以說再度驗證了 Google 不重視非英文世界的一貫態度。

為了要知道到底檔案還要下載多久，我們得按下一旁的「顯示所有下載...」，開啟「下載」頁面。在這個頁面當中，終於我們可以看到更多資訊了；但是同樣讓人不解的是，不論你的螢幕有多寬、Google Chrome 瀏覽器檢視區域開了多大，檔案資訊硬是要擠在 500 像素不到的寬度內，而往往無法一口氣顯示出全部的內容，唯有將滑鼠游標移動到檔案資訊上，纔能由滑鼠提示畫面看到全部的內容。再一次地，Google Chrome 不讓我們輕易看到所有的資訊，順便歧視了不方便使用滑鼠（例如滑鼠用到一半沒電）的使用者。

筆者在下載檔案時，還發現了一件神秘的事：下載較大的檔案時，當剩餘下載時間低於一分鐘，檔案資訊中就會出現「正在安裝新版本...」的訊息。不論下載的是執行檔、壓縮檔、影片檔、聲音檔或任何檔案都一樣─到底 Google Chrome 是在安裝些甚麼呢？（當然我們也可以合理地猜測，又一次地，這是本地化時造成的中文版慘劇）尤其要知道，Google Chrome 的使用條款當中，有著這麼一條：

12.1 您使用的「軟體」將不時自動從 Google 下載並安裝更新。這些更新之設計旨在改善、強化和進一步發展「服務」，採取的形式則可能包括錯誤修正、增強功能、新軟體模組和全新版本。您同意接受此類更新 (並同意 Google 對您傳遞此類更新) 做為使用「服務」的一部分。

不論下載任何檔案是否會造成 Google Chrome 安裝我所不知道的更新，出現了這樣的訊息就足以讓人困惑；而按照使用條款，真的安裝起來我也無法拒絕，這更是讓人惶恐。

到底為什麼 Google Chrome 會變成這樣的瀏覽器呢？有人想到了，「Google Chrome 是開放源碼軟體嘛，我們可以來研究一下他的源碼」。

事實上這種說法不大精確，因為 Google Chrome 受到使用條款保護，並不符合自由軟體基金會對自由軟體的定義，也不符合開放源碼組織對開放源碼軟體的定義。穀歌只是「將 Google Chrome 所用到的源碼整理後，採 BSD 授權釋出給公眾」而已，用那份源碼編譯出來的瀏覽器（他有個自己的名字，叫「Chromium」）是個開放源碼瀏覽器，但 Google Chrome 不是。沒有任何人能夠擔保 Chromium 的源碼真的跟 Google Chrome 用的一樣，任何對 Chromium 源碼的修改補綴貢獻，也不見得一定會回到 Chrome 的源碼中。在這個「開放源碼」的口號背後，仍然埋伏著這些不定。

整體來說，我們在 Google Chrome 上可以看到穀歌的行銷用心，包括採創用 CC 授權釋出的說明漫畫、提供（經整理過的）源碼等，但是 Google Chrome 本身的品質還很粗劣，談不上是β外部測試版了，祇能勉強算是α內部測試版的水準。

所幸有了 Chromium 這個開放源碼專案，無論 Google Chrome 未來變得多邪惡，我們都還能選擇 Chromium。不過，身為使用者，我們還是殷切地期盼穀歌如他們所說的，歹行莫做，早日弭平 Google Chrome 帶來的災難才是王道啊。