移动端开发:使用jQuery Mobile还是Zepto
jQuery Mobile和Zepto是移動端的js庫。jQuery Mobile相當于PC端的jQuery UI,它提供了很多頁面的UI庫,能夠很快的開發出漂亮的界面,適合公司沒有UI設計師的前端開發人員來進行移動端的開發。Zepto相當于PC端的jQuery,它提供了很多方法和功能,能夠很快的實現各種需求和功能,適合公司有UI設計師的前端開發人員來進行移動端的開發。
jQuery Mobile性能上沒有zepto好。
zepto.js是一個專為mobile WebKit瀏覽器(如:Safari和Chrome)而開發的一個JavaScript框架。它標榜自己在其簡約的開發理念,能夠幫助開發人員簡單、快速地完成開發交付任務。更重要的是這個JS框架,是超輕量級的,只有5KB。zepto.js的語法借鑒并且兼容 jQuery。
jQuery Mobile這個框架能夠幫助你快速開發出支持多種移動設備的Mobile應用用戶界面。
jQuery Mobile不僅會給主流移動平臺帶來jQuery核心庫,而且會發布一個完整統一的jQuery移動UI框架。雖然jQuery Mobile相對較新,但開發人員可以用jQuery Mobile為許多移動設備(包括智能手機和平板電腦)開發網站應用程序,RSS閱讀器等應用。
jQuery Mobile是目前最流行的一個移動開發的框架,文檔豐富,社區活躍,有很多的UI控件供我們使用,并且提供對多頁面的支持(通過Ajax方式讀取內容,并提供頁面切換的過渡動畫)。我認為jQuery Mobile的最強大之處就在于其UI方面的支持,但這一部分恰恰不是我所需要的,它對UI的限制比較多。Sencha Touch是ExtJs的移動版,對于不熟悉ExtJs的人來說有一定的學習成本。
jQuery Mobile的缺點,主要有兩點:一是重,二是UI限制太大。
我們選擇了zepto.js作為底層庫,使用sea.js進行模塊的管理和發布,當然也可以使用requirejs來進行模塊的管理和發布,requirejs比seajs的對應的工具多一些,因為requirejs是外國的,而其他相應的工具也是外國的,因此使用seajs,相對應的工具會少一些。但是開發起來容易一些,都是中文資料。此外,我們使用backbone.js為基礎的MVC架構,用來剝離應用的數據部分;使用underscore.js做為前端模板引擎(backbone重度依賴);使用iScroll.js為我們提供模擬滾動的功能(此庫在低端移動設備上,反應慢)。這些都是一些專業的“小庫”,很適合移動端的開發。當然,具體情況需要具體分析,沒有萬能的框架,只有萬能的開發者。如果時間允許,也可以自己來定制一套滿足自身需求的基礎庫。畢竟在移動端,一切以 “精簡”為主。
對于單頁應用來說,iScroll確實是一個非常優秀的解決方案,但是iScroll卻有一個最大的缺陷——慢,滾動的性能與瀏覽器原生實現相比,在低端的移動設備上有明顯卡頓。
不過要兼容低端的移動設備,原生的滾動還是有優勢的。嘗試放棄使用iScroll組件,使用原生的Scroll。因為較新的瀏覽器已支持{overflow: scroll; -webkit-overflow-scrolling: touch;}。
iScroll的誕生,主要是因為早期的webkit內核瀏覽器沒有一種原生支持固定高度的容器。到目前為止,iScroll最大的問題就是慢,在千元以下Android設備上表現尤為突出。使用局部滾動來替代iScroll滾動是最好的一種方式,但很可惜,現在只有iOS5、6支持局部滾動,并且支持程度并不好,而Android壓根就不打算支持。這樣,我們就不得不使用iScroll。
問題來了,現在到底使用iScroll呢?還是不使用?使用的話,大部分Android設備在滾動時會很卡,如不使用,部分功能又實現不了。其實,這個問題也不必太糾結。
- 首先, 對于header、footer需要固定位置的頁面,可以直接使用position:fixed實現。部分不支持fixed定位的瀏覽器問題也不大,這部分設備一般都是Android2.x的系統,配置也較低,相對交互而言,速度顯然更加重要;
- 對于需要依賴固定高度實現切換動畫效果的交互,應盡量保證滾動條在頁面頂部時處理。必要時做出一些犧牲,舍棄部分影響用戶使用流暢的交互;
- 盡量使用瀏覽器原生支持代替iScroll;
- 如果必須使用iScroll才能實現的功能,一定要控制在最小范圍,不要在常用場景應用iScroll;
雖然iScroll在iOS下表現得非常出色,但是都應當盡量使用瀏覽器原生支持特性來實現功能,這樣才能最大化保證交互操作的流暢性。
很長一段時間都有一個爭論,有頁面跳轉是不是WebApp?我認為單獨討論single page webapp還是頁面跳轉是沒有意義的,所有產品都是建立在用戶需求之上。對于現有的single page webapp產品,瀏覽器沒有準備好,硬件配置也沒有準備好,函數運算效率、頁面渲染都跟不上,尤其是Android設備。基于用戶需求出發,一些意識形態的東西該拋棄就拋棄,放開的使用頁面跳轉,只要能讓程序運行流暢的東西,就應該毫不猶豫的使用。
但凡事也沒有絕對,在一定的功能范圍之內,也可以使用炫一些的切換動畫,在一個頁面實現多個子功能。
基于以上對移動端瀏覽器混亂程度的理解,移動web產品要做到全平臺適配,工作量無遺是巨大的,并且,由于HTML5的支持程度,也會導致大部分低端用戶無法使用到一些高級特性,或表現效果不佳。而且,沒必要為了適應低端Android用戶讓高端iOS用戶也忍受著簡陋無比的交互及界面。那么,將iOS、Android、Windows Phone分為不同的版本,做相應的功能適配還是很有必要的。
- 在iOS下,自由度比較高,能隨意發揮,很多有創意的交互及設計,都能在Safari下表現得比較好;
- Android下由于設備硬件配置及瀏覽器版本差異比較大,就會選擇相應保守的方式,舍棄部分影響用戶使用流暢的交互,以及影響頁面渲染的界面設計;
- 對于Windows Phone我們是從WP8起步,這樣會更好做瀏覽器兼容。 做分版本適配的目的,是為了在保證功能交互的前提下讓每個用戶都能得到最流暢的操作體驗。
用原生控件做外殼和交互,保證流暢的用戶體驗和完整的推廣渠道;使用HTML5來展示內容,保證內容的迅速迭代更新,即時響應用戶需求。于是就誕生了Hybrid App,這也是目前最流行最合適的一種App形式。
下面提出我個人的建議:
如果你的團隊剛剛組建或者框架知識了解不深入,那么開發移動端,使用單一的庫就行了。
比如:jQuery mobile或Zepto。
使用jQuery mobile可以省略很多UI設計或者說重構的一些工作,在公司團隊中,如果沒有這方面的成員時,可以使用此庫。但是此庫性能不好,兼容性一般,UI限制大,請慎重使用。
使用Zepto開發,性能上最好的,而兼容性比較好,跟jQuery有同樣的API,只是需要自己設計UI,以及重構。touch功能上有一定的兼容性問題。推薦使用此庫,這樣你可以任意發揮你的想法。
如果你的團隊具有一定的框架基礎,像模塊化開發的代表requirejs和seajs,那么,完全可以把這個項目進行模塊化開發,把這兩個庫的任意一個加入到項目中,將對你項目的協同開發,以后的代碼維護都將有很好的貢獻。這兩個庫的學習成本不大,很容易上手。
如果你的團隊,個個都是高手了,那么就可以進行mvc模式的開發了。在你的項目中,加入backbone+underscore,這是目前為止,最簡單的mvc模式的開發組合。但是大家都知道,使用backbone,你就必須按照backbone的模式來進行項目的開發,具有一定的限制。也就是說,開發和維護,都需要了解backbone這個框架。
如果你的團隊,個個是大牛的話,那么就可以使用angularjs或react了。這種模式的開發,現階段是前端開發的最新研究成果了。此種框架,學習成本大,但是代表著公司的實力和創新。
當然,除了以上這些基礎庫和基礎框架,我們可能還需要添加一些第三方庫,比如iscroll,此庫兼容性好,唯一缺點就是在低端設備上,會卡,所以項目不能全局使用iscroll實現滾動效果。我們需要添加原生的scroll來實現項目中的滾動效果,如果使用原生scroll不能實現的,那么才使用iscroll來實現。
比如:faskClick,它解決點擊事件延遲的bug,當然zepto的touch模塊也可以解決。
比如:模板引擎,像underscore,handlerbars等。
比如:HTML5的application cache本地緩存機制。
移動開發總結:
(1)jQuery mobile或者Zepto+自己設計UI
(2)seajs或requirejs+Zepto
(3)seajs或requirejs+Zepto+Backbone+underscore
(4)angularjs或react
我個人希望能夠使用第三種,然后項目成熟了,再使用第四種。畢竟新技術的實踐,還是很有想象空間的。
當然,如果對技術不需要深入,只要實現功能,那么使用第二種我覺得還是不錯的。 至于第一種,我個人覺得模塊化開發還是非常必要的,之前在公司里面看之前的前端負責人開發的一套系統,代碼寫的太混亂了,簡直看不得,維護起來非常不方便,所以模塊化開發,我個人覺得,必須使用。
關于移動端的UI組件,我推薦騰訊的frontUI。百度的gmu很久沒更新了,也沒人維護了,而且耦合性比frontUI大,不推薦。
關于移動端的調試工具,我暫時只用過weinre。由于公司網絡不行,我使用的是低版本的weinre,只支持safari調試,而且反應比較慢。但是,還是能夠解決問題的,只是效率不高。網上有很多教程,百度一下就知道怎么用了。