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

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

關(guān)于Phonegap

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

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

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

關(guān)于前端框架

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

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

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

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

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

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

關(guān)于性能

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

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

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

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

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

此外，分享一個(gè)關(guān)于動(dòng)畫的小技巧，就是CSS動(dòng)畫是可以添加回調(diào)的，包括TransitionEnd和AnimationEnd兩類，當(dāng)動(dòng)畫執(zhí)行完畢后會(huì)調(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實(shí)現(xiàn)了各種"scroll"相關(guān)的功能，例如類似PC上傳統(tǒng)的Slide幻燈片效果、微博中常用的Pull to Refresh的效果以及在iOS上實(shí)現(xiàn)overflow:scroll效果。而我最初使用它的也正是因?yàn)榈谌c(diǎn)原因，iOS5以下的設(shè)備都不支持overflow:scroll屬性，也就是說沒法scroll元素的內(nèi)容。這樣一來，常見的固定頭尾的布局就沒法實(shí)現(xiàn)了。iScroll則使用 Touch Event + CSS3 動(dòng)畫的方式來模擬了原生的scroll效果。

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

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

關(guān)于Viewport和Retina屏

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

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

《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)試真機(jī)上的程序，例如在控制臺(tái)中輸入alert(’hello world’);，手機(jī)上就能蹦出一個(gè)對(duì)話框；Inspect DOM元素，修改屬性、修改CSS，真機(jī)上立即就能體現(xiàn)。它的功能基本上就是Chrome的開發(fā)者工具拿掉腳本調(diào)試那塊。

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

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

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

 

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

---