去年曾對Phonegap做過一次調研，當時還是1.1版本，印象也一般。對他的性能以及真實的跨平臺能力都不太確定。今年過完春節至今正好有機會參與了一個純Phonegap + HTML5開發的項目，項目至今已經完成了一期的App Store提交，所以也正好能抽時間來小結一下。一個月左右的開發過程讓我對這種開發模式有了更深的認識，這對于前端開發人員而言絕對是一個大的機會。Phonegap Native API + Plugin基本能訪問移動設備絕大部分本地功能，除此之外就是HTML5了，遷移成本非常的低，而開發效率也是很高的。

與傳統Web開發相比，在移動設備進行Web開發有著自己的特點，例如不同設備的屏幕尺寸以及分辨率都有可能不同，因此開發時需要考慮靈活性；移動設備上基本上都是使用webkit來跑Web，因此你的腳本和框架可以放心的使用一些高級的特性，以及可以徹底拋棄兼容IE的那些惡心代碼；當今移動設備的性能與PC相比還有很大的差距，因此性能問題在移動設備上更值得重視，尤其是腳本性能（DOM操作、Redraw、Reflow）。

關于Phonegap

Phonegap最大的價值在于跨平臺，理想情況下應該是只需開發一份代碼就可以同時發布到iOS/Android等N多平臺（理想情況一般僅限于一句hello world），因此開發效率與開發本地應用相比有非常大的提升。此外，由于可以使用HTML5開發，因此開發人群就由各種稀有的本地應用開發人員（OC、Android、Symbian等）轉向到相對傳統前端開發人群，資源相對來說要豐富一些。

Phonegap的最大問題則應該是性能問題，它實現跨平臺的方式基本上就是使用內置的瀏覽器內核來運行你的HTML CSS和Javascript，例如在iOS中就是創建一個UIWebview來加載index.html。因此這種運行在應用層的代碼和Native代碼相比，效率上會有很大的差距。如果你想做很炫的動畫或需要大量運算的應用的話還是選擇Native吧，這里可以參考一下這個性能比較的Benchmark。

因此，就目前而言，如果你準備開發的應用沒有復雜的運算或動畫，能夠適合使用HTML+CSS來展現，那么可以果斷的使用Phonegap + HTML5的模式來開發。

關于前端框架

移動設備上的前端框架目前發展非常迅速，從Phonegap Development Tool列表上就可以看出，很大一部分都是前端開發框架。框架的種類很多，有打包了UI實現的例如Sencha Touch、jQuery Mobile、jQ Touch、jQ.Mobi，也有UI無關的例如Zepto。

項目中使用了jQuery + jQuery Mobile + jQuery.tmpl，不過現在看來這個搭配并不理想：jQuery Mobile中基本上只使用了簡單的事件，其他諸如Page以及其他的特性都未使用上。一方面是因為我們的UI和jQuery Mobile有非常大的差別，如果按照它的結構來寫頁面反而效率更低；另一方面，我們的頁面表現相對來說復雜一些，資源也比較多，經測試發現它的Page功能（動畫效果類）在性能上并不理想。因此，我們徹底放棄了jQuery Mobile UI相關的功能，僅使用了一些諸如scroll、tap的事件而已。

jQuery Mobile的實現方式是在jQuery的基礎上寫了一套Mobile相關的代碼，例如事件、各種模擬的Native UI等。這種基于PC上的框架來實現移動框架的方式，我并不太認同，使用時還必須先引用龐大（相對于移動設備而言）的jQuery。jQuery兼容了PC上各種瀏覽器的實現，而相對于移動設備較為單一的瀏覽器環境而言是臃腫的。

jQ.Mobi則換了種方式，它針對移動設備重寫了jQuery中最常用的部分接口（jqMobi），因此在代碼體積和效率上有更佳的表現，此外，在jqMobi的基礎上還提供了jqUi。

jQ Touch與jQ.Mobi也很相似，既可以選擇jQuery，也可以選擇Zepto來作為底層腳本庫。

了解各個框架的特點后，就可以根據自己應用的特性來選擇合適的框架了，像我的這個應用UI完全自己實現，頁面切換也是Single Page + 自己實現切換，因此基本上使用Zepto或者jqMobi就足夠了。

關于性能

移動設備的硬件和PC相比還有很大的差距，因此，原先PC上可以忽略的性能問題在移動設備上會被放大。尤其是涉及到瀏覽器Redraw和Reflow的，例如使用循環遍歷并修改DOM節點。如果是在PC上，這樣的操作也許需要上千次或者更多次才可能表現出性能問題；但是在移動設備上，100次左右的操作就可能要消耗幾秒鐘的時間（真實案例）。對于此類問題，之前在PC上開發的經驗依然適用，而且需要更加重的重視。之前寫的一篇文章可以繼續作為參考。

《如何減少瀏覽器的repaint和reflow?》

關于動畫

首先還是想說說性能的問題。原來在PC上實現的動畫，絕大部分都是setTimeout / setInterval來實現，或者適用HTML5的requestAnimationFrame，但是這兩種方式在移動設備上都是無法使用的。requestAnimationFrame目前在移動設備上還未支持；而使用setTimeout來繪制動畫的性能是讓人無法忍受的，例如jQuery的slideUp，即使是在iPhone 4S上性能也足以讓你瞠目結舌。

幸好CSS3支持了強大的動畫功能，瀏覽器自身解析而實現的動畫效率比Javascript實現要高得多。諸如之前介紹的移動框架的動畫也正是使用CSS3來實現的。關于CSS3的動畫語法之類的就不多說了，總之CSS3動畫是這種開發模式的必修課之一。

此外，分享一個關于動畫的小技巧，就是CSS動畫是可以添加回調的，包括TransitionEnd和AnimationEnd兩類，當動畫執行完畢后會調用，示例代碼如下：

  

view plaincopy to clipboardprint?

1. $('body').bind('webkitTransitionEnd',function(){});
2. $('body').bind('webkitAnimationEnd',function(){});

 

	$( 'body' ).bind( 'webkitTransitionEnd', function(){}  );

	$( 'body' ).bind( 'webkitAnimationEnd', function(){}  );

關于iScroll

iScroll4實現了各種"scroll"相關的功能，例如類似PC上傳統的Slide幻燈片效果、微博中常用的Pull to Refresh的效果以及在iOS上實現overflow:scroll效果。而我最初使用它的也正是因為第三點原因，iOS5以下的設備都不支持overflow:scroll屬性，也就是說沒法scroll元素的內容。這樣一來，常見的固定頭尾的布局就沒法實現了。iScroll則使用 Touch Event + CSS3 動畫的方式來模擬了原生的scroll效果。

不過在實際的開發過程中發現，一旦scroll的內容較多，尤其是有背景圖的情況下，iScroll模擬的滾動效果會非常卡，背景圖比要卡很多，估計是因為瀏覽器redraw時性能Hold不住了。于是，原先準備用它來實現固定頭尾的想法也就放棄了，而是在局部頁面的小塊內容中使用，以及新手幫助的slide效果中也使用到。

另外，透露一下目前固定尾部的實現方式：iOS5設備中，由于支持postion:fixed，因此可以直接定位在底部，用戶滑動的是整個頁面，而不是某個容器的內容；非iOS5設備中使用了類似ie6中的實現，scroll時隱藏，scroll結束時顯示，很惡心…而且由于性能以及瀏覽器本身一些渲染特性偶爾還會導致scroll時無法消失。這個問題目前只能期待iOS5設備的普及了。

關于Viewport和Retina屏

iPhone Retina屏幕的分辨率為640 * 960，因此如果希望獲得清晰的畫質，頁面在設計、布局時也應該按照該尺寸實現，否則如果按照320 * 480的實際屏幕大小進行布局，則在顯示時會被拉伸，頁面中的圖片會變模糊。

在顯示時，需要正確設置viewport，否則會顯示異常，這里需要設置viewport為640，也即把手機的屏幕當做640寬度來顯示。關于viewport的相關知識可以參考以下幾篇文章：

《Configuring the Viewport》

《A tale of two viewports》

《Using the viewport meta tag to control layout on mobile browsers》

關于工具

WEINRE是必須要介紹的工具，現階段而言簡直就是前端開發調試的神器！它允許你在ＰＣ上直接調試真機上的程序，例如在控制臺中輸入alert(’hello world’);，手機上就能蹦出一個對話框；Inspect DOM元素，修改屬性、修改CSS，真機上立即就能體現。它的功能基本上就是Chrome的開發者工具拿掉腳本調試那塊。

在實際開發過程中，從WEINRE中確實獲益匪淺，能夠快速高效的定位問題和驗證解決方案。關于它的使用方式已經有不少參考了，例如《使用weinre調試Web應用及PhoneGap應用》

此外是關于XCode Build方面的一個小技巧，XCode的Build是可以加入自己的編譯腳本的，用腳本可以訪問到打包后的APP。因此，我們加入了自己的編譯腳本，功能是使用Closure Complier對腳本進行壓縮并打包到APP中。大致方式如下：

在項目的Build Phases中添加一個Run Script Pharse，配置大致如下：

 

在build.sh中做了事情就是到Build的目標路徑中掃描所有JS，然后做壓縮等各種處理即可，由于最終的APP是帶簽名的，所以每次Build前需要先Clean。

---