HTML5 真能如此輕易擊敗 Flash 嗎？

2009/04/30

如今，HTML5 可謂如眾星捧月一般，受到許多業內巨頭的青睞。且不說谷歌、蘋果等業內巨頭把它描繪為互聯網體驗的未來，即便是以不服從標準著稱的微軟，也向它頻頻示好，決心在 Internet Explorer 9 中加入對 HTML5 的大量支持。然而，HTML5的路途真的將一帆風順麼？本文將列舉了一些在HTML5發展和普及過程中需要解決的問題。

什麼是HTML5？

根據維基百科上的解釋，HTML5 的前身是 Web Applications 1.0，由 WHATWG 於2004年提出。2007年，它被 W3C 接納，並於2008年1月22日發佈第一份正式草案。

以下摘錄自維基百科的文字介紹了 HTML5 的特點和與 HTML4 的差別：

新應用程序接口（API）
即時二維繪圖
定時媒體播放
儲存
離線
編輯
拖放
通訊／網絡
後退按鈕管理
MIME 和協議處理程序時表頭登記

與 HTML 4 的不同之處

新的解析順序
新的元素：section, video, progress, nav, meter, time, aside, canvas
input 元素的新屬性：日期和時間，email, url
新的通用屬性：ping, charset, async
全域屬性：id, tabindex, repeat
移除元素：center, font, u, strike, s, frameset, frame, applet

戰勝 Flash, HTML5 還需要什麼？

決定勝負的因素很多，在此分為兩部分分析。

一、技術方面

HTML5 與 Flash 在功能上並不是完全重疊的，比如對於攝像頭等計算機硬件的調用，仍然只能使用 Flash 或其他方法實現。但是 HTML5 卻引入了一些讓 Flash 不得不認真對待的元素。其中最為人所知的和最重要的即為 canvas 和 video 標籤。在我看來，其他的新屬性跟 Flash 的競爭關係很弱，只有此二者是真真正正要搶 Flash 的飯碗，而且一旦普及，將深刻的改變整個互聯網，可謂是 HTML5 的左膀右臂。

canvas

在 Flash 流行之前，曾經出現過很多種在網頁中實現繪圖功能的方法，其中包括著名的Java Applet 。這些方法各有千秋，相互競爭不休。但是在 Macromedia 公司推出 Flash 之後，這場戰爭很快就結束了。

為了對抗 Flash，又有很多新的技術被提出，其中就包括現在 Flash 的東家 Adobe 提出的 SVG。然而這沒有能夠阻止 Flash 迅速的被網民接受。基於 Flash 的動畫、遊戲等應用幾乎是在一夜之間蔓延到了互聯網的每個角落。

而今，新的挑戰者出現了，他就是 HTML5 的新標籤 canvas。

canvas 相比 Flash 顯然是有其優點的。它不依賴於外部插件、與瀏覽器渲染引擎緊密結合、節約資源，最重要的是極大的簡化了圖形和網頁中其他元素的交互過程。

對於 Flash 來說，使 Flash中的元素與網頁中其他元素進行交互是要消耗大量時間和資源的，另外在編程上也相當不方便。

而 canvas 本身就是 HTML5 的一個元素，可以像操作普通 HTML 元素一樣操作它。開發人員可以將所有的代碼整齊的寫在一個文件裡，降低了維護與更新的難度。

然而 canvas 也有其缺點:

其一，開發者不得不編程描繪每一個點和矢量曲線，在旋轉縮放時更需要和矩陣變換打交道，這會增加描繪複雜圖形的難度。而在 Flash 裡，圖形顯示的 API 被封裝在名為「Sprite(顯示列表)」的類裡，大部分圖形元素都繼承於此類，開發者可以使用多種工具設計圖形，對圖形進行旋轉放縮只需要簡單的調用類的函數。

其二，動畫的實現存在缺憾。canvas 雖然提供了不同於傳統的通過 div 塊實現動畫的方法，但這種方法仍然非常繁瑣。開發者必須在每一楨動畫顯示時清空畫布，然後重畫所有元素，這必然導致包含大量元素的場景動畫緩慢，只移動少量元素就要重畫整個畫布會浪費大量資源。而且創建動畫也是一件十分繁瑣的事情。相比起來，Flash的實現就方便多了，雖然從最底層來說，動畫時仍然需要重畫整個畫布，但其被交予 Flash Player 自動處理，無需開發者手動管理。基於字節碼的 Flash 在解析的過程中將會比即時編譯的 HTML5 和 JavaScript 快速。一般來說，複雜動畫將會更流暢。另外，良好封裝的圖形類和強大的設計工具使得動畫的創建非常方便。

其三，沒有提供一套方便的事件體系。開發者也許需要通過捕獲鼠標在 canvas 中點擊的坐標，判斷用戶到底點擊了什麼圖形元素。在這個過程中可能要遍歷所有的顯示元素並判定點是否在圖形內，實現起來比較繁瑣，更不要說實現事件的冒泡和遞歸模型了。雖然今後出現的圖形庫可以解決這個問題，但這實質上相當於使用 JavaScript 構建了一套事件響應模型，其效率顯然不如內建於瀏覽器的原生事件模型高。在 Flash 中，事件也被良好封裝為類，捕獲點擊等事件自然不在話下，更重要的是提供了判斷兩個圖形是否有交集的事件和函數，這在遊戲編程中非常方便。另外，Flash 的最新版本將會支持多點觸摸事件的響應，而 HTML 想要支持這點恐怕要等到 HTML6 了。

由以上分析我們可以看出，HTML5 需要的幾個非常重要的東西：一個強大易用的圖形庫、硬件加速的圖形解析和重繪、一個強大的編輯器（IDE）。

目前已經出現了基於 canvas 實現的遊戲引擎。但是從效果上看仍然無法與 Flash 媲美。

WebGL 的提出讓我們看到了硬件加速的希望，這將極大的改進圖形顯示的速度。但是目前它只被少數開發版本的瀏覽器支持。

IDE 方面，諷刺的是恰恰是 Adobe 為 Adobe Flash CS5 添加了一個將 Flash 轉化為 canvas 的功能。在 JavaScript 方面，鑑於其為非強制類型的編程語言，對其進行代碼提示等非常困難，提高編程效率較難。

如果以上三個問題不能被良好解決，將會限制 canvas 所能實現的效果的豐富度，增加開發的複雜度，從而最終阻礙其普及。

圖為一個用 canvas 實現的繪圖應用

video

video 標籤可能是 Adobe 最反對的東西了，它極有可能打破 Flash 在在線視頻領域的壟斷地位。

但目前的情況是作為 video 內容的視頻存在編碼問題，Apple 和微軟所支持的 H.264 不是開放標準，瀏覽器廠商必須為其付費。因此，作為三大瀏覽器之一的火狐瀏覽器拒絕支持此編碼格式。谷歌雖然也收購了一套優質的編碼技術，但是目前沒有跡象表明谷歌會開放這個技術標準。

根據最近的統計，雖然 Google Chrome 瀏覽器和 Apple Safari 瀏覽器增長很快，但瀏覽器市場還是主要被火狐和 IE 所統治。如果火狐堅持不支持 H.264 編碼格式，video 標籤的推廣將會十分困難。

所以，HTML5 需要一個既開放又優質的視頻編碼標準。

圖為 video 標籤的演示

二、商業方面

團結

要讓微軟、谷歌、蘋果這三個在很多方面存在競爭關係的業界巨頭團結一心的支持同一套標準是很困難的。

蘋果方面對 Flash 痛下殺手，微軟方面則極少參與這場論戰。至於谷歌則在支持 HTML5 的同時在 Android 中加入了 Flash 支持，甚至存在將 Flash 納入 Chorme 安全沙箱的計劃。在這種情況下，如果 Adobe 能夠良好利用三大巨頭之間的分歧並加以運作，HTML5 的前景堪憂。

即便 Adobe 沒有那樣的智慧與能力挑撥三大巨頭之間的關係，三大巨頭自己就可能葬送 HTML5 的未來。前車之鑑就是大名鼎鼎的 OpenGL。這一標準成立之初的聯盟成員幾乎可以用豪華來形容，結果因為各個成員之間為了自己的利益相互爭吵，使得OpenGL的發展速度遠不及 Direct3D，直至到目前這樣遊戲市場幾乎被競爭對手佔據、應用範圍侷限在專業領域的情況。

用戶的接受

無論各大廠商如何宣傳，用戶的接受才是最後的檢驗標準。目前來看 HTML5 在普通桌面領域可能的作為不大，與 Flash 的關係必然是長期並存。原因在於用戶並不在意頁面到底使用的是什麼技術，而更關心最後的效果怎麼樣。HTML5 的 canvas 若要達到 Flash 實現的相同效果所需要的難度更大，這樣限制了中小網站在網頁裡使用 canvas 的積極性，如果 canvas 不能普及，就相當於 HTML5 斷了一條腿，而 video 標籤的編碼問題再得不到解決，HTML5 真得就沒辦法和 Flash 競爭了。

大膽的預測

在最後，我將對 HTML5 和 Flash 的這場世紀之戰做出我自己的預測。

首先用一個比喻描述目前的情況：

谷歌、微軟、蘋果、Adobe 四家圍在一起打牌，其中 Adobe 是莊家，手中的牌最多最好。蘋果、微軟都很想把 Adobe 從莊家的位置上拖下來，但是又不願意合作。谷歌與 Adobe 關係曖昧，但是也有自己的打算。

在這場牌局中，Adobe 幾乎是立於不敗之地的，從目前來看 Flash 被 HTML5 完全取代的可能不大，原因在於Flash 已經佔領了絕大部分傳統桌面終端的市場，其地位幾乎無法撼動，即便 Flash 做得不夠好，但是只要沒到很不好的地步，還是無法被超越。雖然傳統桌面收到了新興的移動終端的挑戰，但是這一過程將發展的比 Flash 和 HTML5 之間的競爭更緩慢。Adobe 控制著 Photoshop、Dreamweaver 和 Fireworks 等知名軟件，製作網頁即便可以缺少 Flash 卻無法缺少 Photoshop，即便是編制全 HTML5 的網頁，Dreamweaver 依然是首選的網頁製作利器，製作 canvas 也可以使用 Flash CS5 新加入的生成 canvas 的功能。

圖為 Adobe Flash CS5

廣受詬病的 Flash Player 並不能給 Adobe 帶來直接的利潤，它的意義在於將富媒體應用的市場和標準掌握在手中。用於製作 Flash 的編輯器才是 Adobe 真正的利潤來源。如果在 HTML5 的時代，開發者仍然不得不選擇 Adobe 的產品來製作基於 canvas 的交互頁面，那麼又何必需要 Flash Player 的存在呢？Adobe 更是省下了維護一個複雜系統的費用。

至於微軟，他內心是非常糾結的，他手裡有 Internet Explorer 這張不知道是好是壞的牌，原因在於由 Internet Explorer 6 佔領的瀏覽器市場份額仍然沒有被有效釋放，新版本的 Internet Explorer 不得不跟自己的前輩競爭。另外，微軟也急於推廣自己的 SliverLight ，這一產品與 Flash 和 HTML5 都是競爭關係。支持 HTML5 或多或少會對 SliverLight 的推廣有所打擊。所以微軟必然不會全力支持 HTML5，而是只將他作為 SliverLight 的補充。

蘋果的算盤打得很響，他要從移動終端領域著手，逐步滲透到桌面領域。iPhone 是第一步，也是相當成功的一步，他的存在說明智能手機領域並不需要 Flash 的存在，事實上，Flash 在這一領域表現的確很差。但是真正關鍵的是 iPad。iPad無論是屏幕大小還是操作體驗都更接近與普通桌面電腦,如果平板電腦被證明不需要 Flash 的存在，那麼桌面電腦為什麼不可以？如果大量用戶通過使用平板電腦而習慣了沒有 Flash 的互聯網體驗，那麼 Flash 就真的沒有未來了。iPad發售之後 Adobe 與蘋果之間爭論的升級，從側面證實蘋果和 Adobe 都看到了平板電腦將在這場戰爭中發揮的作用。

但是蘋果真得能如願以償麼？蘋果的產品即便銷售很好，也不可能做到像微軟的產品這樣普及。原因在於蘋果的產品文化就在於提供高質量和高品位的體驗，而這種體驗伴隨著高價。必然只有少數人能夠用得起蘋果，必然只有使用蘋果是能夠成為一種身份和品味的象徵，蘋果的產品才會有這麼大的吸引力。難道除了蘋果就沒有其他廠商可以提供同樣的技術了麼？難道微軟不能像蘋果一樣以用戶體驗為先麼？顯然不是，重要的原因在與微軟所要提供的是一個給所有人使用的產品，這一產品要有廣泛性，要有繼承性，而且不能太昂貴。所以微軟在用戶體驗方面改變的動力不足，微軟試圖在 Visita 裡極大的改變用戶體驗的方式，原來使用 XP 非常熟練的用戶到了 Visita 裡就變得不知所措了。結果顯而易見。

事實上，蘋果從一開始就不打算讓所有人都用上蘋果，只要有少部分人願意掏錢購買，它就能賺足夠的錢。

到了平板電腦這裡也是一樣，iPad 不可能獨自積累到足夠大的用戶群，以至於可以挑戰傳統桌面終端。更具性價比的其他廠商的產品將會讓更多人享受到平板電腦。而且這些平板電腦很可能會支持 Flash。這樣的話，利用新興終端，改變用戶對 Flash 的依賴的計劃就會失敗。

谷歌方面，這場戰爭的勝負對谷歌的影響都不大，只要能把用戶留在頁面上，它並不在意到底使用的是 HTML5 還是 Flash。然而他卻最終勝負有者非同尋常的影響力。谷歌除了 YouTube 之外，很少在自己的產品中使用 Flash。也許谷歌認為一個開放的標準更容易控制。對於 Flash 這樣封閉的產品，雖然好用，但是谷歌很難對其發展方向有發言權。而今，Chrome 瀏覽器的迅猛發展日益增加了谷歌在 HTML 新標準中的發言權。但是這並不意味著谷歌會完全拋棄 Flash。

Flash 可以作為谷歌牽制蘋果的重要工具，作為 Android 挑戰 iPhone 的籌碼。谷歌正籌劃將 Flash 納入 Chrome OS 的安全沙箱。如果成功，Flash 飽受詬病的耗電問題、安全問題都能得到較好的解決。

由此得到結論，Flash 氣數未盡，仍將長期統治互聯網富媒體領域的市場。在移動領域的發展將取決於谷歌的態度，但可以預見的是將會有很多困難。

至於 HTML5，預計在1-3年內會達到相對普及的程度，但是不會取代 Flash。他們之間甚至是可以和諧相處，取長補短的。然而不要對 HTML5 的發展速度抱有太大希望，畢竟業內巨頭之間矛盾重重，現有標準能夠被各大瀏覽器無差別支持就已經相當困難了，想要加入任何新功能都要很久才會被廣泛支持。這樣緩慢的發展速度如何能夠體現強大的競爭力，我們拭目以待。

原文鏈接：http://www.techxav.cn/2010/05/13/how-can-html5-beat-flash/

本文作者：@akirasphere