Hybrid移動應用：用網頁技術提供Native體驗

 　　根據最近的一篇報告顯示，HTML是移動應用開發人員使用最多的語言，開發人員對於選擇哪種網頁技術考慮的最主要因素，是代碼的跨平台便攜性和開發的低成本性。我們常常聽說，hybrid app使用起來非常慢，而且設計也很糟糕，讓我們看看是否有可能又有原生應用的形，又有我們習慣使用的感。

　　這篇文章會提供很多關於如何構建良好的hybrid移動應用的線索、代碼片段和經驗。我將會大致介紹一下hybrid移動應用的開發，包括它的優點和缺點。然後，我會分享一下過去兩年我在開發Hojoki和CatchApp時積累的經驗，這兩個項目都運行在主流的移動平台，並且是由HTML、CSS和Javascript建成的。最後，我們會介紹一下打包代碼到原生app的一些比較好的工具。

　　什麼是混合模式移動應用

　　移動app可以大致被分為三種，native、hybrid和web app。如果使用native app，你可以使用設備和操作系統的所有能力，同時，平台的性能負荷最小。然而，構建web app可以讓你的代碼跨平台，使得開發時間和成本大大減少。而hybrid app把這兩者的優點都結合起來，使用一套共同代碼，在許多不同的平台上部署類似原生的app。

　　有兩種構建hybrid app的方法：

　　Webview app：HTML,CSS和Javascript基礎代碼在一個內部的浏覽器(叫做WebView)中運行，這個浏覽器打包在一個原生的app中，一些原生的API可以通過這個包被Javascript獲得，比如Adobe PhoneGap和Trigger.io。

　　被編譯的hybrid app：用一種語言編寫代碼(如C#或者Javascript)，對於每一種支持的平台都把代碼編譯進原生代碼中，這樣做的結果是，每一個平台都有一個原生的app，但是在開發過程中少了一些自由空間。可以看一下這些例子，Xamarin，Appcelerator Titanium，Embarcadero FireMonkey。

　　這兩種方法都被廣泛使用，存在即合理，不過今天我們只關注WebView app ，因為WebView app可以讓開發人員平衡他們現有的網頁技術。我們來看一下hybrid app相對於native app和web app的各種優點和缺點。

　　優點

　　開發人員可以使用現有的網頁技術

　　對於多種平台使用一套基礎代碼

　　減少開發時間和成本

　　使用響應式網頁設計可以非常簡便的設計出多樣的元素(包括平板)

　　一些設備和操作系統特征的訪問

　　高級的離線特性

　　可見度上升，因為app可以原生發布(通過app store)，也可以發布給移動端浏覽器(通過搜索引擎)

　　缺點

　　某些特定app的性能問題(那些依賴於復雜的原生功能或者繁重的過渡動畫的app，如3D游戲)

　　為了模擬native app的UI和感官所增加的時間和精力

　　並不完全支持所有的設備和操作系統

　　如果app的體驗並不夠原生化，有被Apple拒絕的風險(比如說一個簡單的網站)

　　這些缺點比較顯著，不能忽略，它們告訴我們，並不是所有的app都適合混合模式，你需要小心的預計你的目標用戶、他們對平台的選擇和對app的需求。對於許多app來說，好處都是大於壞處的，比如內容驅動的app。

　　Hojoki和CatchApp都是內容驅動的app，所以我們一開始覺得它們非常適合混合模式的開發方式。我們之前提到的好處中的前三點對於我們構建Hojoki的移動app幫助很大，不過也僅僅是4周的時間而已。顯而易見，Hojoki的第一個版本缺失了很多重要的東西，接下來的時間裡，我們都把精力撲在提升性能、對每一個平台制作自定義的UI和利用不同設備的高級特性上。那個時候積累的那些經驗對於讓app形似並神似native app很重要，下面我會盡可能多的分享一下我的經驗。

　　那麼， 怎麼能讓你的app形似並神似一個原生的app呢?對於一個移動網頁開發人員來說，能夠使用設備和操作系統的能力，能夠打包他們的app，這些都聽上去很棒。然後，如果要用戶相信這是一個native app，那麼它就必須長得像並且表現的像。如何完成這一點對於混合模式移動開發人員來說仍然是最大的挑戰之一。

　　讓你的用戶賓至如歸

　　雖然我們只寫一套基礎代碼，但這並不意味著多種不同平台上的感官都要完全一樣，你們用戶根本不在乎什麼潛在的跨平台技術，他們只想要app根據他們的期望來展現，他們想要“賓至如歸”。你的第一步應該是為每一個平台做設計概覽：

　　“IOS設計資源”, IOS開發人員庫

　　“Android設計”, Android開發人員

　　“設計”, Windows開發中心

　　雖然這些概覽並不能完美適應全部的app，但是它們仍然提供了一套非常全面和標准的界面和體驗，每一種平台的用戶都會希望得到這樣的體驗。

　　DIY VS. UI框架

　　如果你一個人實施這些組件、樣式和動畫，這是個很大的挑戰，現在有各種各樣的UI框架來幫助你，從商業(Kendo UI)的到開放(lonic)的，從共同UI(JQuery Mobile和Onsen UI)到許多有平台針對性的UI(Sencha Touch和ChocolateChip-UI)。有些能夠很好的提供精確到像素的布局，有些則相對粗糙，這些各式各樣的框架能夠很方便的讓使用者定義一個web app。然而，就我的觀念而言，框架最主要的缺點關乎性能，因為大多數UI框架都盡量“海納百川”，要根據自己的情況在設備上試試demo後再決定是否要使用。

　　在制作Hojoki的時候，我們嘗試自己用CSS3和極少的Javascript來創建所有的組件，這樣做的好處是能夠幫助我們控制性能，減少負荷。當然，我們也會使用一些別人使用過的較小的庫來解決一下復雜的任務。

　　自定義UI組件

　　自定義UI組件也有很多很好的使用例子，你需要根據你的目標用戶來決定使用平台的UI還是自定義UI，如果你想要單干，你需要對UX設計有很深的理解，因為之前的那些概覽都是專家們為了迎合他們平台用戶的需求而制作的。

　　不管你是決定堅持使用平台的UI概覽還是自己做自定義的組件，你都必須知道，有一些特定的設計樣式是用戶每天使用並熱愛的。通常我們如何把一個app介紹給用戶呢?通過幻燈片講演或者教學覆蓋。用戶如何導航?如果標簽欄或者側邊欄。用戶如何快速加載或者刷新數據?下拉刷新。(在接下來的文章中會講到類似原生的滾動)

　　移動端UI設計的資源

　　“移動端UI設計樣式：10幾個靈感迸發的網站”，Jacob Gube，Six Revisions

　　“用HTML、CSS和Javascript克隆IOS 7的UI”，C?me Courteault

　　“用HTML5點進移動端UI”(幻燈片)，Luke Melia and Yael Sahar, Slideshare

　　設計一個看起來原生的標題欄

　　在UI中，標題欄是一個很重要的部分，包括它的標題、導航元素、尤其是前進和後退按鈕。對於我來說，許多流行框架在提供HTML和CSS解決方案方面，相比一些原生的app是失敗的，而為每個平台用最小的DOM和最少行的css代碼來仿照這個UI部分其實相當的簡單。

　　1htmlFeedDetails

　　在JSFiddle中查看“iOS、Android和Windows Phone中看起來原生的標題欄”的完整代碼，下面是我的成果：

　　用html5和css做成的看起來原生的標題欄

　　在不同的平台上使用相同的DOM更為便利，因為代碼整潔而且易於維護，我發現這樣做對於許多IOS和Android上的UI組件都適用(包括標題欄、標簽欄、定制的導航菜單、設置頁面、浮層，還有很多其他的東西)。然而，想要更多的支持Windows Phone變得更加困難，因為它帶來了許多非常不一樣的設計模塊。

　　支持高分辨率屏幕

　　現如今，高分辨率的智能手機和平板構成了巨大的移動設備市場，在iOS設備中占有率超過80%，在Android設備中占有率超過70%。為了讓你設備上的圖片展現得更清晰，你通常不得不將其尺寸放大到超過它原本大小的兩倍，因此現在響應式網站設計中，如何針對所有不同的分辨率提供適合尺寸的圖片，成為了現在熱議的話題之一。現在有非常多的途徑解決，每一種的優點和缺點都與帶寬、代碼易維護性和浏覽器的兼容性有關，現在讓我們來快速的回顧一下當下最流行的方法，順序不分先後：

　　服務端的調整和傳輸

　　客戶端通過javascript的檢測和替換