行動應用程式辯論會
簡介
行動應用程式和 HTML5 是目前最熱門的兩項技術，有相當多重疊。網頁應用程式是在行動瀏覽器中執行，也可以在各種行動平台上重新封裝為原生應用程式。支援的平台種類繁多，再加上行動瀏覽器的強大效能，開發人員逐漸改用 HTML5 做為「編寫一個、執行多個」的解決方案。但這個想法真的可行嗎？採用原生做法仍具有充分理由，而且許多開發人員確實選擇採用原生程式碼。本文是原生和網路方面的爭論。
功能豐富度
要點：原生廣告可執行更多工作
我們可以將行動功能分為兩個維度：應用程式本身的使用體驗，以及應用程式連結至裝置生態系統的方式 (例如在 Android 中)，這是小工具和通知等功能。這兩個維度都採用原生格式。
就應用程式體驗而言，原生應用程式可提供更多協助。只要是支援滑動事件的平台，都可以輕鬆控制滑動事件，甚至可以互換。一般而言，這些快速鍵可在使用者按下時執行動作，例如 Android 的搜尋按鈕和音量控制。而且還能存取 GPS 和相機等硬體。有些平台在取得使用者權限後，就能提供無限制地存取作業系統的權限。只需嘗試偵測 HTML5 的剩餘電量即可！
但應用程式內體驗不只是應用程式體驗。作業系統 (例如 Android) 為應用程式提供多種不同的使用者互動方式，事實上與其他應用程式互動。首頁上有使用中的小工具。您有通知，顯示在裝置狀態列中。此外，有了意圖，應用程式就能表明自己提供一般服務，供其他應用程式在特定情況下使用。
論點：原生功能可能擴增，但網路仍會持續偵測
事實上，許多應用程式內功能都無法滿足 HTML5 應用程式的需求。無論您的 Web-fu 技能有多高，如果應用程式停在沒有相機 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 應用程式編譯為可使用 OpenGL 的原生應用程式，例如 ImpactJS。
開發人員體驗
要點：原生廣告的開發較簡單
原生應用程式使用穩固的程式設計語言 (例如 Java、Goal C、C++)，該語言是專為複雜的應用程式開發而設計，具有經驗證的追蹤記錄。這些 API 的設計初衷就是要支援平台。您可以在電腦模擬器中輕鬆對應用程式進行偵錯，這類模擬器會清楚呈現目標裝置。
瀏覽器和執行階段的多元性，是網頁開發特別棘手的原因。應用程式執行時無法保證功能 X 可供使用。即使是它，瀏覽器也如何執行呢？標準可以接受解讀。
點子：網路的開發通常較為輕鬆，在指定多種裝置時更是如此
讓我們先來探討核心技術。網路標準最初就只是一個時代，現在網路基本上是文件而非應用程式，而是在短短 10 天內就建構及部署 JavaScript！不過，後來展現出比想像中更強大的功能：網頁開發人員已學會利用優質部分並竄改不良部分，現在也瞭解可縮放設計的模式。此外，這些標準尚未受到認可，HTML5、CSS3 和 EcmaScript Harmony 等方面的努力都有助於改善開發人員體驗。無論您偏好 C++、Java 還是 JavaScript，都屬於宗教辯論議題，而且也必須仰賴您的舊版程式碼集。不過，我們當然可以考慮將 JavaScript 納入未來的努力上。
改用瀏覽器/執行階段分段的做法，就是一開始所有環境都已準備就緒。使用 Java 開發 Android 應用程式，此時您需要將通訊埠完整轉移至目標 C，才能支援 iOS。開發一次網頁應用程式一次後，它就能在 Android 和 iOS 上執行，更不用提 WebOS、BlackBerry、Windows Mobile 等等。這也說明瞭這個理論。實際上，如果您希望提供正確的體驗，就必須針對每個平台進行調整。但對於大多數行動作業系統而言，您也必須在原生環境中執行這項作業，因為作業系統為不同的版本和裝置。
值得慶幸的是，網路上一直是「零碎片段」這種說法，而且市面上也有眾所皆知的處理技術。最重要的是，漸進式強化原則要求開發人員先以基本裝置為目標，並視情況新增平台專屬優質功能。功能偵測功能也很有幫助，現在我們從 Modernizr 等服務提供了程式庫支援，以支援回應式網頁設計。只要善用這些技術，您就能將觸及範圍擴展至絕大多數裝置，即使是舊式「功能手機」，甚至是手錶和電視等板型規格，無論品牌或作業系統為何。查看 Google IO 2011 的多使用者介面示範，在這個網站上，我們使用常見的邏輯和標記程式碼集，鎖定不同的板型規格 (功能手機、智慧型手機、平板電腦、電腦、電視)。
外觀和風格
要點：原生適合平台的外觀和風格
外觀與風格是任何平台定義的功能之一。使用者期望控制項能以一致的方式呈現及操控。某些用語會因平台而異，例如當使用者執行「長時間按住」(持續輕觸元素幾秒鐘) 時會發生什麼情況？這些形式的廣告都設有標準慣例，而且一個 HTML5 應用程式無法滿足這些形式。
此外，平台的外觀和風格會由平台的原生軟體程式庫自動化調度管理，其小工具封裝了使用者預期的外觀和風格。您只要使用原生工具包，就能以「免費」獲得許多預期的外觀和風格。
目標：網路有獨特的外觀和風格，您可以依自己最重視的平台自訂網頁介面
如上一節所述，網頁開發的做法是編寫一個基本的「單一尺寸」版本，然後逐步強化版本。雖然強化措施通常是以功能為基礎，但您也可以指定自己最重視的平台，藉此加強強化。這種「瀏覽器偵測」方式有時不是由網路社群對策，原因是市面上有很多可能的瀏覽器。不過，如果您檢視兩個或三個優先程度極高的平台，並且願意付出額外心力來與原生替代方案比較，那麼這可能會是更好的選擇。
就基準版本而言，網路的外觀和風格設計各不相同，我們甚至可以說，每個行動平台在預設瀏覽器和網頁執行階段都有各自的「網頁外觀和風格」。「網站外觀和風格」對使用者而言可能相當不錯，事實上，電腦版瀏覽體驗以及使用者可能用於運作的其他裝置，都具有更高的一致性。此外，許多成功的應用程式對原生外觀和風格皆無法支援。這正是遊戲的必要條件 (您最喜愛的手機遊戲是否遵循行動作業系統的外觀和風格？) 更是常見的應用程式，例如在您選擇的平台上看看更受歡迎的原生 Twitter 用戶端，您可能會在工作上看到各式各樣的使用者介面機制。
Shorts 曝光機制
要點：原生應用程式更容易發掘
應用程式發布機制 (例如 Android Market 和 Apple 的 App Store) 近年來廣受歡迎，是整個行動產業的主要驅動力。任何開發人員都可以將原生應用程式提交至市集，讓使用者透過瀏覽、搜尋及取得建議等方式發掘應用程式。不僅如此，如果您確實完成了工作，醒目顯示的評分和評論也能說服使用者點選最重要的安裝按鈕。
概念：實際上，網頁應用程式更容易找到
可說是史上最容易發現的媒介。根據理論，我們至少擁有網路上所有發布內容的專屬 ID，包括在標準網站上發布的所有應用程式。搜尋引擎讓搜尋引擎更容易發現內容和其他網站可以連結到這些內容，包括類似行動市集的網頁應用程式目錄。事實上，所有人都可以透過電子郵件和社群網路訊息的連結，與朋友分享網頁應用程式。系統可透過簡訊傳送連結，讓行動裝置使用者能點選連結，並在裝置的瀏覽器中啟動應用程式。
我們並未提供相同的市集，讓使用者為應用程式評分及留下評論，但這也會改變。請繼續閱讀...
營利
要點：原生廣告可用於營利
「6 歲的人在午餐時段製作應用程式，每個價格只要 $3 美元。」我們發現，近年來標題很常見，因此大小不多的開發人員想要透過行動市集營利。行動平台提供多種方式，可讓開發人員直接向應用程式收費。最簡便的一次性付款，用於解鎖應用程式，以滿足所有長久的需求。某些平台也提供應用程式內付款和訂閱機制，並且能夠以一致、安全且一致的機制緊密整合。這些較新的付款方式可讓開發人員將速成下應用程式轉換為長期收益來源。
除了應用程式付款之外，您也可以透過傳統網路模型 (例如廣告和贊助) 營利。
目標點：透過網路營利可以透過網路營利，且商機日益增加
如果沒有任何充裕的機會可以帶來現金，網路就不會是現代產業的引擎。雖然直接「按用量付費」直接機制尚未發展，但仍有許多小眾市場，提供以訂閱為基礎的「軟體式服務」解決方案確實可行。例如 Google Apps、37Signals 的產品範圍，以及各種電子郵件服務的付費版本。 此外，直接付款並不是透過網頁應用程式營利的唯一方式。包括線上廣告、聯盟連結、贊助、與其他產品和服務交叉宣傳。
話雖如此，網頁程式開發人員還是能閱讀標題並體驗少量付款的環境，這是理所當然的事。您無法將網址提交至原生市集，但網頁開發人員可以怎麼做？做法是建立原生「包裝函式應用程式」，並為每個要指定的平台建立空白的原生應用程式，而此應用程式將包含網頁檢視畫面。網頁檢視畫面是嵌入實際應用程式的地方。接著，只要將這些應用程式提交至各個市集即可 (希望各位也看得如何投入資金！)。目前主要市場中有數百個 (甚至數千個) 以網頁應用程式為基礎的應用程式，其中有些應用程式甚至令人驚訝地說，我們甚至完全不知道他們的網頁應用程式。
缺點是跨平台編譯到每個平台。此時，PhoneGap 等現有架構可以派上用場。更棒的是，PhoneGap 建構和 Apparatio 等網路服務仍在開發中。將這些網站指向您的程式碼存放區，然後彈出 Android 應用程式、iOS 應用程式等項目， 您就可以提交至各商店。您不需要在機器上安裝原生 SDK，只要打造這些原生應用程式，就能輕鬆使用程式碼編輯器和網路瀏覽器。
這些市集是否會直接支援網頁應用程式，而不會以原生方式包裝這些應用程式？目前還不夠清楚。我們知道 Google 去年推出了 Chrome 線上應用程式商店，雖然它僅適用於電腦，但商店曾觸發其他瀏覽器供應商的興趣，而且是網頁應用程式目錄整體趨勢的一部分，包括部分行動裝置專用嘗試。網路商店的概念已發展成初期，但背後的跡象卻很值得期待。
結論
很高興在這裡宣告得獎者，但目前還沒有明顯的勝出組合。有些應用程式最適合原生使用，有些則最適合網頁使用。網頁堆疊的發展潛力較大，但就功能與執行品質而言，原生應用程式也能快速移動。在大多數行動作業系統上，如果沒有時間安排在大多數行動作業系統上領先業界的公民，原生就永遠是重要的考量因素。
本文中提到的一項技術是混合應用程式，對部分開發人員來說，最好的方法可能是最理想的機制：在可能的情況下使用網頁檢視畫面，而不適用平台特有的原生元件。
如要選擇網站路徑，請留意網路標準和漸進式強化原則。網路這項技術知道如何針對附近的裝置和作業系統指定各個裝置。無論您選擇稱之為「片段化」或「多元性」，網路可滿足這個架構，開發人員也可以從所有先前的設計中受益。