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

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

關(guān)于Phonegap

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

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

因此，就目前而言，如果你準備開(kāi)發(fā)的應用沒(méi)有復雜的運算或動(dòng)畫(huà)，能夠適合使用HTML+CSS來(lái)展現，那么可以果斷的使用Phonegap + HTML5的模式來(lái)開(kāi)發(fā)。

關(guān)于前端框架

移動(dòng)設備上的前端框架目前發(fā)展非常迅速，從Phonegap Development Tool列表上就可以看出，很大一部分都是前端開(kāi)發(fā)框架?？蚣艿姆N類(lèi)很多，有打包了UI實(shí)現的例如Sencha Touch、jQuery Mobile、jQ Touch、jQ.Mobi，也有UI無(wú)關(guān)的例如Zepto。

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

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

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

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

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

關(guān)于性能

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

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

關(guān)于動(dòng)畫(huà)

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

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

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

  

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

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

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

關(guān)于Viewport和Retina屏

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

在顯示時(shí)，需要正確設置viewport，否則會(huì )顯示異常，這里需要設置viewport為640，也即把手機的屏幕當做640寬度來(lái)顯示。關(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是必須要介紹的工具，現階段而言簡(jiǎn)直就是前端開(kāi)發(fā)調試的神器！它允許你在ＰＣ上直接調試真機上的程序，例如在控制臺中輸入alert(’hello world’);，手機上就能蹦出一個(gè)對話(huà)框；Inspect DOM元素，修改屬性、修改CSS，真機上立即就能體現。它的功能基本上就是Chrome的開(kāi)發(fā)者工具拿掉腳本調試那塊。

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

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

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

 

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

---