行動應用程式爭議
簡介
行動應用程式和 HTML5 是目前最熱門的兩項技術，兩者有許多重疊之處。網頁應用程式可在行動瀏覽器中執行，也可以重新封裝為各種行動平台上的原生應用程式。由於需要支援的平台眾多，加上行動瀏覽器的強大功能，開發人員紛紛轉向 HTML5，將其視為「一次編寫，多處執行」的解決方案。但這真的可行嗎？原生開發仍有其優勢，許多開發人員也確實選擇這條路。這篇文章探討原生與網頁的優缺點。
功能豐富度
重點：原生廣告可提供更多功能
我們可以將行動功能分為兩個維度：應用程式本身的體驗，以及應用程式與裝置生態系統的連結方式，例如在 Android 上，這會是小工具和通知等功能。原生廣告在這兩個層面都表現出色。
就應用程式體驗而言，原生應用程式能提供更多功能。在支援這些事件的平台上，他們可以輕鬆取得滑動事件，甚至是多點觸控事件。通常可以對按下的實體按鍵做出反應，例如 Android 的搜尋按鈕和音量控制項。還能存取 GPS 和相機等硬體。在使用者許可下，部分平台可不受限制地存取作業系統。試著用 HTML5 偵測剩餘電量！
不過，除了應用程式內體驗，Android 等作業系統提供多種方式，讓應用程式與使用者互動，甚至與其他應用程式互動。首頁上有使用中的小工具。您有通知，這些通知會顯示在裝置的狀態列中。此外，您也可以使用意圖，讓應用程式宣告自己提供一般服務，其他應用程式有時可能會需要這項服務。
反方觀點：原生功能可以擴充，而且網頁技術正在迎頭趕上
HTML5 應用程式確實無法提供許多應用程式內功能。無論您的網頁開發技巧有多高超，如果應用程式受限於沙箱，無法使用相機 API，就無法立即拍照！幸好，您不必在沙箱中。如果網頁應用程式確實需要拍照，您可以建立原生應用程式，並嵌入網頁檢視畫面，提供大部分的使用者介面。這就是開放原始碼 PhoneGap 架構的運作方式：將原生功能公開為網路服務，並由網頁檢視使用標準網路 API 呼叫，藉此填補差距。建構這類混合式應用程式時，您也可以連結小工具、通知和意圖等平台功能。
打造混合式應用程式 (原生加上網頁) 絕非理想的解決方案。這會增加複雜度，且僅適用於封裝為原生應用程式的網頁應用程式，不適用於透過行動瀏覽器存取的傳統網站。但可能很快就不需要了。網路標準發展迅速，現代行動瀏覽器也與時俱進。舉例來說，離線儲存空間、地理位置、畫布圖形和影片/音訊播放功能，在現代智慧型手機中都廣泛支援。自 Android 3.1 起，甚至連相機也開始支援，可以使用網路標準拍攝相片和影片。最新的 iOS 瀏覽器支援 WebSocket 雙向串流，以及裝置方向偵測。
整體而言，行動裝置正在不斷演進。不過，網路也正在快速演變。光是電腦版瀏覽器，就有五家主要瀏覽器供應商，他們正以驚人的速度發展標準並新增功能。雖然將這些功能移植到行動裝置並非易事，但許多功能已進入行動瀏覽器。
原生應用程式發展迅速，但網頁應用程式正在縮小差距。
效能
重點：原生程式碼執行速度更快
原生應用程式則沒有網頁執行階段障礙需要處理。這類語言在接近硬體層級執行，可利用 GPU 加速和多執行緒等效能提升工具。
反方觀點：現在的網頁執行階段速度快上許多，而且大多數應用程式不需要這種速度
近年來，網路速度越來越快，V8 是 Chrome 隨附的 JavaScript 引擎，推出時是網頁效能的一大進展，自此之後，速度只會越來越快：
圖形算繪引擎也加快了網頁速度，現在硬體加速也開始出現。請看看硬體加速畫布帶來的速度提升：
此外，新的 Web Workers API 讓多執行緒成為可能，現代網頁程式開發人員也可以呼叫一系列效能最佳化的程式庫，以及經過充分研究的效能最佳化技術。雖然其中大部分都是從電腦版網站開始，但仍與行動裝置相關，而且行動裝置也越來越受到關注，例如效能專家 Steve Souders 有專門介紹行動裝置效能工具的頁面。
並非所有電腦版進階功能都已移植到每個行動平台，但趨勢顯示這些功能正在逐步推出。此外，請務必注意，大多數行動應用程式並非尖端 3D 遊戲，而是以資訊為基礎：新聞、郵件、時間表、社群網路等。從行動裝置造訪一些網站，例如 GMail、Amazon、Twitter，您就可以確認行動版網站效能已足夠。至於遊戲，2D 畫布已可支援基本遊戲，而 WebGL 也開始出現在行動裝置上，例如 Firefox 4。在 WebGL 普及之前，越來越多架構可將 WebGL 應用程式編譯為可利用 OpenGL 的原生應用程式，例如 ImpactJS。
開發人員體驗
觀點：原生應用程式較容易開發
原生應用程式使用強大的程式設計語言 (例如 Java、Objective C、C++)，這些語言專為複雜的應用程式開發而設計，且有良好的實績。這些 API 經過全新設計，可支援手邊的平台。您可以在電腦模擬器中輕鬆偵錯應用程式，模擬器會提供與目標裝置相近的呈現方式。
網頁開發之所以特別麻煩，是因為瀏覽器和執行階段種類繁多。應用程式執行時，不保證功能 X 可用。即使有，瀏覽器又會如何實作？標準可有多種解讀方式。
反方觀點：網頁通常更容易開發，尤其是針對多種裝置時
首先來談談核心技術。網頁標準最初是在網頁基本上是文件而非應用程式的時代構思，JavaScript 僅在 10 天內建構和部署！但事實證明，這些技術的能力遠超乎想像，網頁程式開發人員已學會善用優點並克服缺點，並瞭解可擴充設計的模式。此外，標準並非一成不變，HTML5、CSS3 和 EcmaScript Harmony 等努力都在改善開發人員體驗。您偏好 C++、Java 還是 JavaScript，取決於個人喜好，也取決於舊版程式碼集。但 JavaScript 絕對是當今的有力競爭者。
瀏覽器/執行階段分散化的另一面，是所有這些環境一開始就存在。如果您使用 Java 開發 Android 應用程式，就必須完整移植到 Objective C，才能支援 iOS。開發網頁應用程式後，就能在 Android 和 iOS 上執行，更不用說 WebOS、BlackBerry、Windows Mobile 等，至少理論上是這樣。在實際操作中，如果您真的想獲得正確的體驗，則需要針對每個平台進行調整。但如果是原生應用程式，您也必須這麼做，因為大多數行動作業系統都有不同的版本和裝置。
好消息是，網頁上的「片段化」一直都是這樣，而且有眾所周知的技術可以處理。最重要的是，漸進增強原則要求開發人員先以基本裝置為目標，並在可用時新增平台專屬的精彩功能。功能偵測的原則也有幫助，目前我們有 Modernizr 等程式庫支援回應式網頁設計。只要妥善運用這些技術，就能將觸及範圍擴大到絕大多數裝置，甚至是老式的「功能型手機」，以及手錶和電視等板型規格，無論廠牌和 OS 為何。歡迎觀看我們在 2011 年 Google I/O 大會上的多 UI 示範，我們針對不同的板型規格 (功能型手機、智慧型手機、平板電腦、電腦、電視)，使用通用的邏輯和標記程式碼集。
外觀和風格
重點：原生廣告符合平台外觀和風格
任何平台的一大特色就是外觀和風格。使用者希望控制項能以一致的方式呈現，並以相同的方式操作。某些慣用語會因平台而異，例如使用者執行「長按」(持續輕觸元素數秒) 時會發生什麼情況？平台有這類標準慣用語，您無法透過單一 HTML5 應用程式滿足所有需求。
此外，平台的外觀和風格是由平台的原生軟體程式庫所編排，其小工具封裝了使用者預期的外觀和風格。只要使用原生工具包，就能「免費」獲得許多預期的外觀和風格。
反駁：網頁有自己的外觀和風格，您也可以針對最重視的平台自訂網頁介面
如上一節所述，網頁開發的方法是編寫基本的「一體適用」版本，然後逐步強化。雖然強化通常是以功能為基礎，但您也可以針對最重視的平台進行強化。這是一種「瀏覽器偵測」機制，有時會受到網路社群的批評，主要是因為可能的瀏覽器太多了。但如果您認為有兩、三個平台非常重要，且願意付出額外努力，與原生替代方案競爭，這或許是可行的做法。
就基準版本而言，網頁有自己的外觀和風格，我們甚至可以說，每個行動平台都有自己的「網頁外觀和風格」，由預設瀏覽器和網頁執行階段建立。「網頁外觀和風格」可能適合您的使用者，事實上，這可讓您在電腦版瀏覽體驗以及使用者可能使用的其他裝置上，達到更高的一致性。此外，許多成功的應用程式並未提供原生外觀及風格。遊戲當然也是如此 (您最愛的手機遊戲是否遵循手機作業系統的外觀和風格？)，甚至更傳統的應用程式也是如此，例如查看您選擇的平台上更受歡迎的原生 Twitter 用戶端，您會看到各種使用者介面機制。
爭取曝光機會
論點：原生應用程式更容易找到
近年來，Android Market 和 Apple App Store 等應用程式發布機制大受歡迎，是整個行動產業的主要推動力。任何開發人員都可以將原生應用程式提交至市集，使用者則可透過瀏覽、搜尋和取得推薦等方式找到應用程式。不僅如此，如果您做得好，出色的評分和評論將說服使用者按下最重要的安裝按鈕。
反方觀點：事實上，網頁應用程式更容易找到
網路可說是有史以來最容易發現的媒介。理論上，網址是網路上所有發布內容的專屬 ID，包括在標準網站上發布的任何應用程式。搜尋引擎可讓使用者輕鬆找到這類內容，其他網站也能連結至這類內容，包括類似行動市集的網頁應用程式目錄。事實上，任何人只要在電子郵件和社群網路訊息中連結網頁應用程式，就能與朋友分享。連結也可以透過簡訊傳送，行動裝置使用者只要點選連結，就能在裝置的瀏覽器中啟動應用程式。
我們目前還沒有類似的市集，可讓使用者對應用程式評分及發表評論，但這種情況也正在改變。請繼續閱讀…
營利
重點：原生廣告可營利
「6 歲兒童在午休時間製作應用程式，以每個 $3 美元的價格賣出無數份」。這類新聞標題最近很常見，因此無論規模大小，開發人員都想透過行動市集營利，這並不令人意外。行動平台提供多種途徑，讓開發人員直接向使用者收取應用程式費用。最簡單的方法是單筆付費，永久解鎖應用程式。部分平台也提供應用程式內付款和訂閱機制，並以一致、安全的方式緊密整合。這些新付款方式可讓開發人員將熱門應用程式轉化為長期收益來源。
除了應用程式付款，您也可以透過傳統的網路模式營利，例如廣告和贊助。
反方觀點：在網路上營利一直都是可行的，而且機會越來越多
如果沒有充足的獲利機會，網路就不會成為現代產業的引擎。雖然直接「按用量付費」的機制尚未普及，但訂閱制的「軟體即服務」解決方案在各種利基市場中確實可行。例如 Google 應用程式、37Signals 的一系列產品，以及各種電子郵件服務的付費版本。此外，直接付款並非從網頁應用程式獲利的唯一方式。包括線上廣告、聯盟連結、贊助，以及交叉宣傳其他產品和服務。
話雖如此，網頁程式開發人員看到這些新聞標題，難免會對付款功能產生羨慕之情。您無法將網頁網址提交至原生市集，因此網頁程式開發人員該怎麼做？您需要為每個目標平台建立原生「包裝函式應用程式」，也就是只包含網頁檢視畫面的空白原生應用程式。網頁檢視是嵌入實際應用程式的地方。接著，您只需將這些應用程式提交到各個市集 (並希望看到金錢滾滾而來！)。目前主要市集上可能有數百甚至數千個網頁應用程式，其中有些應用程式經過巧妙整合，我們甚至根本不知道它們是網頁應用程式。
缺點是必須為每個平台進行跨平台程式碼編譯。這時 PhoneGap 等現有架構就能派上用場。更棒的是，PhoneGap Build 和 Apparatio 等網路服務正在開發中。只要將這些網站指向程式碼存放區，就能產生 Android 應用程式、iOS 應用程式等，並提交至對應的商店。您不需要在機器上安裝原生 SDK，只要有程式碼編輯器和網路瀏覽器，就能建構所有這些原生應用程式。
市集是否會直接支援網頁應用程式，而不需要以原生方式包裝？目前還不清楚。我們知道 Google 去年推出了 Chrome 線上應用程式商店，雖然該商店僅適用於電腦，但已引起其他瀏覽器廠商的興趣，且整體而言，這是網頁應用程式目錄的趨勢，包括一些針對行動裝置的嘗試。線上應用程式商店的概念仍處於初期階段，但前景看好。
結論
雖然我們很想在這裡宣布勝出者，但目前還沒有明確的勝出者。有些應用程式最適合原生，有些則最適合網頁。網頁堆疊或許更有發展潛力，但就功能和執行品質而言，原生應用程式也發展迅速。除非網頁技術在大多數行動作業系統上成為一等公民，否則原生技術永遠是重要考量。
本文提及的其中一項技術是混合式應用程式，這可能是部分開發人員的最佳折衷方案：在可能的情況下使用網頁檢視，在不可能的情況下使用平台專屬的原生元件。
如果選擇網頁路徑，請留意網頁標準和漸進增強原則。網路技術懂得如何指定各種裝置和作業系統。無論您選擇稱之為「分割」還是「多元性」，網路都擁抱這種現象，而開發人員可以從所有既有技術中受益。