HTML App及原生App兼用之效

在前文，我提到了以HTML技術為基礎來開發客戶端應用程式的優點。首先，最重要的當然是跨平臺的可攜性。個人電腦漸漸地不再是主要的運作平臺，行動裝置諸如手機、平板電腦數量迅速增加，而且提供隨時可用的便利性；Windows也漸漸勢微、Web成為網路服務應用的主流；而iOS及Android也都各擁山頭、互不相讓。在這種情況下，在各種平臺上的可攜性就成了一項關鍵的優勢。

而現今的網路服務自從進到Web 2.0世代後，改版的速度更是遠較從前來得飛快許多，此種模型可以因應頻繁的功能修改及擴增。

此外，由於在伺服器端的技術，Web已經成為主流的平臺，不僅相關的技術，諸如規模可擴充性、穩定度、容錯、等等，都已經有一定的成熟程度，而且大多開發團隊中的系統管理者、開發者，也都很熟悉、習慣在Web平臺上作業。這使得即使你要開發的是行動裝置上的App，也都能盡量運用相同、已被既有團隊成員熟悉的技術來達成。而且過去開發團隊所累積的既有資產，像是程式庫或應用程式框架，也都能便利地套用。

正因為以HTML技術為基礎來開發客戶端應用程式，有這些極具吸引力的優點，這才使得許多開發團隊紛紛決定採用。正如過去Facebook，以HTML5技術來開發iOS及Android上的App一樣。

用HTML開發App所面臨的挑戰
不過，這種架構並非全然只有優點而無缺點，否則Facebook也不會決定棄用，而且宣稱使用HTML5來打造行動裝置上的App是他們公司創立以來最大的決策錯誤了。那麼，使用這種模型的缺點，又有那些呢？

首先，以HTML技術為基礎的客戶端應用程式，提供的使用者體驗可能弱於原生的應用程式，許多豐富的視覺效果或是與使用者的互動方式，都會受限在HTML的本質，而沒有辦法做到。

相反的，原生的App可以直接運用原生的API，來運用原生平臺就提供的視覺或操作控制，也就能發揮該原生平臺最大的機能，不致於受限在HTML的本質之上。

其次，也可能是一個關鍵的因素，那就是效能的問題。原生的App在呈現任何資訊時，都是使用原生的元件來達成。而不論是處理來自使用者的輸入，或是在介面上做出任何視覺效果的變化，都是使用原生的元件、API，因此，其效能便是原生平臺上所能提供的最佳結果，因為中間再也沒有任何其他的中介層，足以影響效能。

相反的，對於使用HTML技術的應用程式來說，是把瀏覽器視為一個運行的平臺，所以整個瀏覽器呈現HTML頁面的引擎，以及執行JavaScript程式的引擎，就成了一個很龐大的中介層。這個中介層勢必具備一定的通用性，以便可以提供HTML通用性的作用。

而通用性通常影響到的就是效能，因此介於原生層和應用程式之間的這個中介層，就會影響到最後實際運行的效能。

舉例來說，當你想要在智慧型手機上呈現一個很長的清單時，使用HTML來呈現這資訊，最終就有可能受限在手機瀏覽器的呈現效能，而使得畫面的捲動效果不是十分流暢，甚至會有類似像「卡卡」的感覺。相反的，若是你自行用原生的使用者介面來實作這件事，就可以在清單呈現上做很多效能最佳化的動作。針對不同的使用者介面特性，量身打造最有效率的呈現方式。

HTML App的強項

以HTML技術為基礎的呈現方式，最適合應用的情境，就是用來呈現圖與文混雜的資訊。

HTML本身就像是個排版的語言，這使得它很容易可以因應不同尺寸的呈現畫面來適當的排列若干圖與文的資訊。

對於想同時兼容個人電腦、各式螢幕尺寸平板電腦、智慧型手機上的圖文資訊呈現的App，以HTML技術來實現是相當理想的。

開發者不需要設計複雜的呈現機制，也不用理會各種排版的規則，只要交給HTML以及已經熟悉在各種不同畫面尺寸上呈現資訊的設計者，就能妥善的將豐富的圖文資訊在畫面上排列美觀。不過，這樣子的便利要付出的代價往往就是效能。

在Fastbook對決Facebook的例子裡，我們看到Fastbook一樣採用HTML5技術，也做出了速度極快的App，但這並不是說HTML5就能比原生的應用程式來得快。Fastbook在資料的載入等存取上下了不少功夫，因為他們觀察到Facebook效能的問題，不單發生在HTML5的資訊呈現上，更有其他的環節與效能息息相關。

這說明了，之前以HTML5技術寫成的Facebook App其效能不彰雖是事實，但原因也不完全出在HTML5之上。

我們只能夠說，若是能經過有效的設計及調校，以HTML5技術寫成的App是可以提供足夠流暢的效能。不過，原生App的效能所佔的優勢也是肯定存在，這都是本質上存在的特性。當然，這也提供一個反思，那就是即使採用原生的方式來開發App，倘若其他的部份仍然存在效能低落的設計，整體運行的效能一樣不會理想。

混合式App開發的興起
在了純原生及純基於HTML技術兩種方式之外，還有一種方式現在也頗為流行，就是將二者混合在一起。這種混合的方式，便是希望同時取得二者的優點，當然也就是盡可能避開二者的缺點，讓兩種方式互補。

在這種混合的模式中，需要呈現大量圖與文資訊混雜、或是時常需要動態改變的部份，就利用HTML的方式來呈現，因為這正是以HTML為基礎的模式的優勢。相反的，需要效能、需要善用原生平臺上元件特性，或是只有透過原生的API才能做到的功能，就利用原生的程式碼來實作。

在混合的模式下，主體或許還是以HTML的瀏覽器元件，但是透過建立JavaScript程式，以及原生程式碼之間的溝通管道，就可以一方面在JavaScript端啟動原生程式碼的執行，並且可以傳入參數及取得回傳結果，也可以讓原生程式碼回過頭來，再呼叫瀏覽器元件中的JavaScript程式。只要能夠讓原生端及HTML端的程式碼相互溝通，那麼就可以達成這種混用的模式。

透過混用的模式，就可以依據應用程式本身的特性，分別從原生的部份以及HTML的部份擷取其長處，同時規避其缺點，可以說是在二者之間取得平衡點的作法。

原生 vs. HTML vs. 混合
在這個簡短的系列文章中，我們看到了客戶端應用程式逐漸運用HTML主流技術的一個趨勢，也分別看到了原生應用程式，與以HTML技術為基礎之應用程式的優缺點。

在現今平臺眾多、功能變化迅速的環境下，使用HTML技術於客戶端已成一種重要的應用模式。不過，受限於較簡單的使用者體驗、無法使用原生支援，以及效能上需要更加費心等種種的條件，原生的應用程式仍然有其發展的空間。

究竟要採用那一種模式，端視應用的環境及條件，並沒有那一種模式能夠取得絕對的支配性地位。此外， 混用兩種模式的方式可以兼收二者的優點，也是一種可以考慮的方向。