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

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

關(guān)于Phonegap

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

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

因此，就目前而言，如果你準(zhǔn)備開發(fā)的應(yīng)用沒有復(fù)雜的運算或動畫，能夠適合使用HTML+CSS來展現(xiàn)，那么可以果斷的使用Phonegap + HTML5的模式來開發(fā)。

關(guān)于前端框架

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

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

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

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

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

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

關(guān)于性能

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

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

關(guān)于動畫

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

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

此外，分享一個關(guān)于動畫的小技巧，就是CSS動畫是可以添加回調(diào)的，包括TransitionEnd和AnimationEnd兩類，當(dāng)動畫執(zhí)行完畢后會調(diào)用，示例代碼如下：

  

view plaincopy to clipboardprint?

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

 

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

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

關(guān)于iScroll

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

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

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

關(guān)于Viewport和Retina屏

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

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

《Configuring the Viewport》

《A tale of two viewports》

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

關(guān)于工具

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

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

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

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

 

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

---