Hybrid行動裝置 App：用網頁技術提供Native體驗

Hybrid行動裝置 App：用網頁技術提供Native體驗

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

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

　　什麼是混合模式行動裝置 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的檢測和替換

　　html5的picture元素

　　html5 的srcset屬性

　　css image-set屬性

　　css media queries

　　可伸縮向量圖形(SVG)

　　一直以來，針對響應式圖片都沒有一個完美的方法，這主要還是取決於圖片的類型和它們在app上的展現使用方式。如果是靜態圖片(比如logo和教程圖片)，我盡量使用SVG，它們能不費吹灰之力的完美縮放，並且只要你是Android 3+就能獲得很好的瀏覽器支援。

　　當你不能選擇SVG的時候，html5的picture元素和srcset屬性一定會成為日後前端開發人員的首選。當下，它們最大的不足就是在瀏覽器上的支援太局限，因此他們需要一些外掛程式.

　　同時，css背景圖片和media queries是比較可靠的解決方案:

　　css

　　/* Normal-resolution CSS */

　　.logo {

　　width: 120px;

　　background: url(logo.png) no-repeat 0 0;

　　}

　　/* HD and Retina CSS */

　　@media

　　only screen and (-webkit-min-device-pixel-ratio: 1.25),

　　only screen and ( min--moz-device-pixel-ratio: 1.25),

　　only screen and ( -o-min-device-pixel-ratio: 1.25/1),

　　only screen and ( min-device-pixel-ratio: 1.25),

　　only screen and ( min-resolution: 200dpi),

　　only screen and ( min-resolution: 1.25dppx) {

　　.logo {

　　background: url(logo@2x.png) no-repeat 0 0;

　　background-size: 120px; /* Equal to normal logo width */

　　}

　　}

　　但是，你的app也許已經包含了許多內容(比如新聞文章)，要調整所有的圖片標籤或者用css替代會讓我們筋疲力竭，在這種情況下，服務端解決方案就會是最好的選擇。

　　從去年開始，越來越多的android系統已經離XXHDPI(超高解析度)螢幕又進了一步。不論上面提到的哪種方案更適合你的需要，你要記住的是你需要用到三倍於原圖大小的圖片來支援android的最新的裝置。

　　使用系統字型

　　使用系統字型是一種讓使用者體感到賓至如歸的一種簡單但是重要的方法。

　　iOS、Android和Windows的原生字型

　　主流平台上，我比較推薦這些字型樣式：

　　/* iOS */

　　font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;

　　/* Android */

　　font-family: 'RobotoRegular', 'Droid Sans', sans-serif;

　　/* Windows Phone */

　　font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;

　　此外，iOS7提供了一些有趣的預先處理，這些預先處理可以自動的設定正確的字型、文字大小和行高，在普通文本中應用font:-apple-system-body,在標題中使用font:-apple-system-headline，這樣不僅簡化了文字的聲明，而且還提升了動態類型(這是Apple系統範圍的字型大小設定)的可訪問性，你可以在Thomas Fuchs的文章中瞭解到