MUI的側(cè)滑菜單動畫做得很不錯，其中分為兩種，一種是以webview，另一種是DIV形式

webview模式

主頁面和菜單內(nèi)容在不同的webview中，兩個頁面根據(jù)內(nèi)容需求分別組織DOM結(jié)構(gòu)，mui對其DOM結(jié)構(gòu)無特殊要求，故其有如下優(yōu)點(diǎn)：

菜單內(nèi)容是單獨(dú)的webview，故可被多個頁面復(fù)用；菜單內(nèi)容在單獨(dú)的webview中，菜單區(qū)域的滾動不影響主界面，故可使用原生滾動，滾動更為流暢；

另一方面，webview模式也有其缺點(diǎn)：

不支持拖動手勢（跟手拖動）；主頁面、菜單不同webview實(shí)現(xiàn)，因此若需交互（如：點(diǎn)擊菜單觸發(fā)主頁面內(nèi)容變化），需使用自定義事件實(shí)現(xiàn)跨webview通訊；div模式

主頁面和菜單內(nèi)容在同一個webview下，嵌套在特定結(jié)構(gòu)的div中，通過div的移動動畫模擬菜單移動；故該模式有如下優(yōu)點(diǎn)：

支持拖動手勢（跟手拖動）；主頁面、菜單在一個頁面中，可通過JS輕松實(shí)現(xiàn)兩者交互（如：點(diǎn)擊菜單觸發(fā)主頁面內(nèi)容變化），沒有跨webview通訊的煩惱；

另一方面，div模式也有其缺點(diǎn)：

不支持菜單內(nèi)容在多頁面的復(fù)用，需每個頁面都生成對應(yīng)的菜單節(jié)點(diǎn)；主界面和菜單內(nèi)容的滾動互不影響，因此會使用div區(qū)域滾動，在低端Android手機(jī)且滾動內(nèi)容較多時，可能會稍顯卡頓；
個人傾向于使用DIV模式，因?yàn)椴藛胃撁嬷g的交互是很頻繁的，而且對于移動APP來說。支持拖動手勢才是至關(guān)重要的。
下面簡單的官方案例：

??...這里是菜單的內(nèi)容??主頁面標(biāo)題??這里是主界面具體內(nèi)容

mui.init({
????swipeback:true//默認(rèn)左滑返回，可以達(dá)到offCanvas.hide的目的
????
??});
??
??mui('body').on('swiperight','.mui-content',function(){//綁定右滑事件，當(dāng)mui-content上發(fā)生右滑時（菜單原本是隱藏狀//態(tài)的）
?mui('.mui-off-canvas-wrap').offCanvas('show');??//顯示側(cè)欄	
??});
??//關(guān)于側(cè)滑欄的動畫有N種，這里是主界面不懂，菜單欄動的效果，其他效果請到官方查看

關(guān)閉菜單還有一種方式，就是點(diǎn)擊菜單外面，所以為了增加這個事件需要以下代碼

mui('body').on('tap','.mui-content',function(){
?	if(mui('.mui-off-canvas-wrap').offCanvas().isShown())
?	{
?	mui('.mui-off-canvas-wrap').offCanvas().close();?
?	}
?	
?})

因?yàn)榻壎ǖ氖莔ui-content,官方介紹中建議把頭部和底部導(dǎo)航之類的部分放在content外面，其他內(nèi)容放在里面，所以以上的綁定mui-content 觸摸事件可能會導(dǎo)致在菜單隱藏時候，都會執(zhí)行菜單隱藏代碼，為此需要加一個判斷，判斷菜單是否為顯示狀態(tài)，isShown()，否則在菜單隱藏時點(diǎn)擊里面的內(nèi)容會報錯，Uncaught TypeError: Cannot read property 'offsetWidth' of null