jQuery Mobile和Zepto是移動端的js庫。jQuery Mobile相當(dāng)于PC端的jQuery UI,，它提供了很多頁面的UI庫,，能夠很快的開發(fā)出漂亮的界面，適合公司沒有UI設(shè)計師的前端開發(fā)人員來進行移動端的開發(fā),。Zepto相當(dāng)于PC端的jQuery,，它提供了很多方法和功能，能夠很快的實現(xiàn)各種需求和功能,，適合公司有UI設(shè)計師的前端開發(fā)人員來進行移動端的開發(fā),。

jQuery Mobile性能上沒有zepto好。

zepto.js是一個專為mobile WebKit瀏覽器(如：Safari和Chrome)而開發(fā)的一個JavaScript框架,。它標榜自己在其簡約的開發(fā)理念,，能夠幫助開發(fā)人員簡單、快速地完成開發(fā)交付任務(wù),。更重要的是這個JS框架,，是超輕量級的，只有5KB,。zepto.js的語法借鑒并且兼容jQuery,。

jQuery Mobile這個框架能夠幫助你快速開發(fā)出支持多種移動設(shè)備的Mobile應(yīng)用用戶界面。

jQuery Mobile不僅會給主流移動平臺帶來jQuery核心庫,，而且會發(fā)布一個完整統(tǒng)一的jQuery移動UI框架,。雖然jQuery Mobile相對較新，但開發(fā)人員可以用jQuery Mobile為許多移動設(shè)備（包括智能手機和平板電腦）開發(fā)網(wǎng)站應(yīng)用程序,，RSS閱讀器等應(yīng)用,。

jQuery Mobile是目前最流行的一個移動開發(fā)的框架，文檔豐富,，社區(qū)活躍,，有很多的UI控件供我們使用，并且提供對多頁面的支持（通過Ajax方式讀取內(nèi)容,，并提供頁面切換的過渡動畫）,。我認為jQuery Mobile的最強大之處就在于其UI方面的支持，但這一部分恰恰不是我所需要的，它對UI的限制比較多,。Sencha Touch是ExtJs的移動版,，對于不熟悉ExtJs的人來說有一定的學(xué)習(xí)成本。

jQuery Mobile的缺點,，主要有兩點：一是重,，二是UI限制太大。

我們選擇了zepto.js作為底層庫,，使用sea.js進行模塊的管理和發(fā)布,，當(dāng)然也可以使用requirejs來進行模塊的管理和發(fā)布，
requirejs比seajs的對應(yīng)的工具多一些,，因為requirejs是外國的,，而其他相應(yīng)的工具也是外國的，因此使用seajs,，相對應(yīng)的工具會少一些,。但是開發(fā)起來容易一些，都是中文資料,。此外,，我們使用backbone.js為基礎(chǔ)的MVC架構(gòu)，用來剝離應(yīng)用的數(shù)據(jù)部分,；使用underscore.js做為前端模板引擎（backbone重度依賴）,；使用iScroll.js為我們提供模擬滾動的功能（此庫在低端移動設(shè)備上，反應(yīng)慢）,。這些都是一些專業(yè)的“小庫”,，很適合移動端的開發(fā)。當(dāng)然,，具體情況需要具體分析,，沒有萬能的框架，只有萬能的開發(fā)者,。如果時間允許,，也可以自己來定制一套滿足自身需求的基礎(chǔ)庫。畢竟在移動端,，一切以 “精簡”為主,。

對于單頁應(yīng)用來說，iScroll確實是一個非常優(yōu)秀的解決方案,，但是iScroll卻有一個最大的缺陷——慢,，滾動的性能與瀏覽器原生實現(xiàn)相比，在低端的移動設(shè)備上有明顯卡頓,。

不過要兼容低端的移動設(shè)備,，原生的滾動還是有優(yōu)勢的。嘗試放棄使用iScroll組件,，使用原生的Scroll,。因為較新的瀏覽器已支持 {overflow: scroll; -webkit-overflow-scrolling: touch;}。

iScroll的誕生,，主要是因為早期的webkit內(nèi)核瀏覽器沒有一種原生支持固定高度的容器,。到目前為止，iScroll最大的問題就是慢,，在千元以下Android設(shè)備上表現(xiàn)尤為突出,。使用局部滾動來替代iScroll滾動是最好的一種方式，但很可惜,，現(xiàn)在只有iOS5,、6支持局部滾動，并且支持程度并不好,，而Android壓根就不打算支持,。這樣，我們就不得不使用iScroll,。

問題來了,，現(xiàn)在到底使用iScroll呢？還是不使用,？使用的話,，大部分Android設(shè)備在滾動時會很卡，如不使用,，部分功能又實現(xiàn)不了,。其實，這個問題也不必太糾結(jié),。

• 首先,， 對于header、footer需要固定位置的頁面,，可以直接使用position:fixed實現(xiàn),。部分不支持fixed定位的瀏覽器問題也不大，這部分設(shè)備一般都是Android2.x的系統(tǒng),，配置也較低,，相對交互而言，速度顯然更加重要,；
• 對于需要依賴固定高度實現(xiàn)切換動畫效果的交互,，應(yīng)盡量保證滾動條在頁面頂部時處理。必要時做出一些犧牲,，舍棄部分影響用戶使用流暢的交互,；
• 盡量使用瀏覽器原生支持代替iScroll；
• 如果必須使用iScroll才能實現(xiàn)的功能，一定要控制在最小范圍,，不要在常用場景應(yīng)用iScroll,；

雖然iScroll在iOS下表現(xiàn)得非常出色，但是都應(yīng)當(dāng)盡量使用瀏覽器原生支持特性來實現(xiàn)功能,，這樣才能最大化保證交互操作的流暢性,。

很長一段時間都有一個爭論，有頁面跳轉(zhuǎn)是不是WebApp,？我認為單獨討論single page webapp還是頁面跳轉(zhuǎn)是沒有意義的,，所有產(chǎn)品都是建立在用戶需求之上。對于現(xiàn)有的single page webapp產(chǎn)品,，瀏覽器沒有準備好,，硬件配置也沒有準備好，函數(shù)運算效率,、頁面渲染都跟不上,，尤其是Android設(shè)備?；谟脩粜枨蟪霭l(fā),，一些意識形態(tài)的東西該拋棄就拋棄，放開的使用頁面跳轉(zhuǎn),，只要能讓程序運行流暢的東西,，就應(yīng)該毫不猶豫的使用。

但凡事也沒有絕對,，在一定的功能范圍之內(nèi),，也可以使用炫一些的切換動畫，在一個頁面實現(xiàn)多個子功能,。

基于以上對移動端瀏覽器混亂程度的理解,，移動web產(chǎn)品要做到全平臺適配，工作量無遺是巨大的,，并且,，由于HTML5的支持程度，也會導(dǎo)致大部分低端用戶無法使用到一些高級特性,，或表現(xiàn)效果不佳,。而且，沒必要為了適應(yīng)低端Android用戶讓高端iOS用戶也忍受著簡陋無比的交互及界面,。那么,，將iOS、Android,、Windows Phone分為不同的版本,，做相應(yīng)的功能適配還是很有必要的,。

• 在iOS下，自由度比較高,，能隨意發(fā)揮,，很多有創(chuàng)意的交互及設(shè)計，都能在Safari下表現(xiàn)得比較好,；
• Android下由于設(shè)備硬件配置及瀏覽器版本差異比較大,，就會選擇相應(yīng)保守的方式,，舍棄部分影響用戶使用流暢的交互,，以及影響頁面渲染的界面設(shè)計；
• 對于Windows Phone我們是從WP8起步,，這樣會更好做瀏覽器兼容,。 做分版本適配的目的，是為了在保證功能交互的前提下讓每個用戶都能得到最流暢的操作體驗,。

用原生控件做外殼和交互,，保證流暢的用戶體驗和完整的推廣渠道；使用HTML5來展示內(nèi)容,，保證內(nèi)容的迅速迭代更新,，即時響應(yīng)用戶需求。于是就誕生了Hybrid  App,，這也是目前最流行最合適的一種App形式,。

下面提出我個人的建議：

如果你的團隊剛剛組建或者框架知識了解不深入，那么開發(fā)移動端,，使用單一的庫就行了,。

比如：jQuery mobile或Zepto。

使用jQuery mobile可以省略很多UI設(shè)計或者說重構(gòu)的一些工作,，在公司團隊中,，如果沒有這方面的成員時，可以使用此庫,。但是此庫性能不好,，兼容性一般，UI限制大,，請慎重使用,。

使用Zepto開發(fā)，性能上最好的,，而兼容性比較好,，跟jQuery有同樣的API，只是需要自己設(shè)計UI,，以及重構(gòu),。touch功能上有一定的兼容性問題,。推薦使用此庫，這樣你可以任意發(fā)揮你的想法,。

如果你的團隊具有一定的框架基礎(chǔ),，像模塊化開發(fā)的代表requirejs和seajs，那么,，完全可以把這個項目進行模塊化開發(fā),，把這兩個庫的任意一個加入到項目中，將對你項目的協(xié)同開發(fā),，以后的代碼維護都將有很好的貢獻,。這兩個庫的學(xué)習(xí)成本不大，很容易上手,。

如果你的團隊,，個個都是高手了，那么就可以進行mvc模式的開發(fā)了,。在你的項目中,，加入backbone+underscore，這是目前為止,，最簡單的mvc模式的開發(fā)組合,。但是大家都知道，使用backbone,，你就必須按照backbone的模式來進行項目的開發(fā),，具有一定的限制。也就是說,，開發(fā)和維護,，都需要了解backbone這個框架。

如果你的團隊,，個個是大牛的話,，那么就可以使用angularjs或react了。這種模式的開發(fā),，現(xiàn)階段是前端開發(fā)的最新研究成果了,。此種框架，學(xué)習(xí)成本大,，但是代表著公司的實力和創(chuàng)新,。

當(dāng)然，除了以上這些基礎(chǔ)庫和基礎(chǔ)框架,，我們可能還需要添加一些第三方庫,，比如iscroll，此庫兼容性好,，唯一缺點就是在低端設(shè)備上,，會卡,，所以項目不能全局使用iscroll實現(xiàn)滾動效果。我們需要添加原生的scroll來實現(xiàn)項目中的滾動效果,，如果使用原生scroll不能實現(xiàn)的,，那么才使用iscroll來實現(xiàn)。

比如：faskClick,，它解決點擊事件延遲的bug,，當(dāng)然zepto的touch模塊也可以解決。

比如：模板引擎,，像underscore,，handlerbars等。

比如：HTML5的application cache本地緩存機制,。

移動開發(fā)總結(jié)：

（2）seajs或requirejs+Zepto

（3）seajs或requirejs+Zepto+Backbone+underscore

（4）angularjs或react

我個人希望能夠使用第三種,，然后項目成熟了,，再使用第四種,。畢竟新技術(shù)的實踐，還是很有想象空間的,。

當(dāng)然,，如果對技術(shù)不需要深入，只要實現(xiàn)功能,，那么使用第二種我覺得還是不錯的,。 至于第一種，我個人覺得模塊化開發(fā)還是非常必要的,，之前在公司里面看之前的前端負責(zé)人開發(fā)的一套系統(tǒng),，代碼寫的太混亂了，簡直看不得,，維護起來非常不方便,，所以模塊化開發(fā)，我個人覺得,，必須使用,。

關(guān)于移動端的UI組件，我推薦騰訊的frontUI,。百度的gmu很久沒更新了,，也沒人維護了，而且耦合性比frontUI大,，不推薦,。

關(guān)于移動端的調(diào)試工具，我暫時只用過weinre,。由于公司網(wǎng)絡(luò)不行,，我使用的是低版本的weinre,，只支持safari調(diào)試，而且反應(yīng)比較慢,。但是,，還是能夠解決問題的，只是效率不高,。網(wǎng)上有很多教程,，百度一下就知道怎么用了。 

擴展閱讀

• zepto/jQuery,、AngularJS,、React、Nuclear的思考
• [原創(chuàng)]zepto打造一款移動端劃屏插件
• 移動設(shè)備web開發(fā)首選框架：zeptojs介紹
• 移動開發(fā)流量省起來之Zepto