滑屏的交互方式在運營類 H5 中已趨于普遍,，五月份在做 QQ 時光機時曾寫過《分屏滑動 H5 移動頁面 UI 開發(fā)小結(jié)》，轉(zhuǎn)眼半年已如白駒過隙,，最近在做會員 15 周年主會場,，對滑屏有了更多的心得與經(jīng)驗教訓，一言以蔽之：需求與場景是多變的,，而對性能和速度的要求卻是永恒的,。

陳皓（左耳朵耗子）曾經(jīng)在微博里說過：

如今 iOS 和 Android 系統(tǒng)兩家獨大，前者在性能與特性支持度上一直走在前沿,，而后者的開放性導致了如今良莠不齊的局面,，同時近幾年不斷增強的硬件配置并未讓人覺得性能上有顛覆性的突破（至少從 Webview 的表現(xiàn)上看）。作為大多數(shù)「麻煩」的始作俑者,，Android 總讓人愛恨交加,。但為了 iOS 與 Android 上一致的體驗，我們不得不尋求最佳的平衡點,。

回歸到「滑屏」這一出發(fā)點,，不禁自問，如何盡可能得保證頁面在安卓上的性能最佳,？

頁面隨手勢拖拽：

touchend 后頁面才翻屏：

如上面兩個 Gif 圖所示,，兩種方式的差異在于：

• 拖拽翻屏：頁面隨手指拖動而移動，手指松開（touchend）后翻頁

• 自動翻屏：頁面不隨手指拖動而移動,，手指松開（touchend）后翻頁

看似差別不大的兩種交互,，實現(xiàn)復雜度差別巨大，在 Android 中的體驗更是不一樣,。前者需要在每個 touchmove 的時候進行計算與定位,，計算量龐大，而后者只需要在松開手指后再進行計算與翻頁,，性能提升不是一兩點,。

更重要的是，從第一種方案切換到第二種時,，幾乎沒有人發(fā)現(xiàn)了這微妙的改變,。顯然這兩種交互方式并不能明顯區(qū)分開來，所以自動翻屏自然是最佳的選擇,。

控制 wrapper 滑動

控制每一屏滑動

如上 Gif 圖所示，滑屏可以在 wrapper 上操作,，也可以將每一屏作為獨立的滑動元素,。簡單的活動可能兩者并無太大差異,，但假如把多樣的需求和場景考慮到，可以發(fā)現(xiàn)在滑屏上也會細化出很多功能點：

• 循環(huán)滑動

• 滑動禁用

• 延時加載

• 初始化時直接在某一頁

• 滾動到某一頁,、跳過某一頁

• 提供滑動前,、滑動中、滑動后的接口

• 滑動時間,、速度,、緩動效果自定義

• 考慮動態(tài)增刪頁數(shù)

• 考慮頁面縮放、橫豎屏切換

在上述要求下,，前者已顯得分身乏術(shù),，而后者由于其元素間的自由性，可以滿足上述的需求,，且效果更佳,，雖然實現(xiàn)復雜度會提高。

然而我把最關(guān)鍵的給落下了,，最最最關(guān)鍵的是：前者的實現(xiàn)方式在部分安卓上經(jīng)常會出現(xiàn)卡在上一屏與下一屏中間的情況,，一開始遇到時做了很多補救都無果，最終才無奈替換了整個滑動方案,，采用第二種控制內(nèi)部元素的方式,，可謂血的教訓。

什么是卡在上一屏與下一屏中間呢,，類似這樣：

簡單分析下原因,，整個頁面都通過在 body 上監(jiān)測 touchmove 時增加 event.preventDefault 來阻止自然的頁面滑動，但唯獨安卓有時候在有動畫的元素上移動時,，body 會捕捉不到 touchmove 事件,，所以頁面可以滾動了，便出現(xiàn)上述可以滑動 wrapper 的情況,，而方案二控制每一屏滑動,，每屏最寬最高就只是屏幕的寬高，所以也不會出現(xiàn)正常的頁面滾動了,。

需要嗎？需要,。不需要嗎,？不需要。

需不需要看需求對 H5 的定位,，若是類似微信朋友圈廣告的這種品牌運營 H5,，有大量素材作為支撐的頁面，是需要進入時 loading 的，這一點希望提前跟產(chǎn)品達成共識,；但假如是系列活動中比較重要的入口,，需要多次進入的（如會員15周年的主會場），則不要有 loading,，力求一進入就能直接看到,。

針對有 loading 的情況，還需要考慮：

是否一次性將所有資源 load 完,？

no no no,，即使有專門的 loading 頁，都請分屏加載,，否則這里將會流失大量用戶,。

那資源的體積跟時間之間應該形成一個怎樣的認知呢？ 看表（根據(jù) Chrome 開發(fā)者工具 Network 換算數(shù)據(jù)）：

上述是理想數(shù)值,，實際上根據(jù)騰訊云統(tǒng)計到的 2G/3G 的下載速率,，遠未達到理想的速度：

（但4G 會高于 Network 里換算的值）

根據(jù)《工信部及三大運營商發(fā)布11月用戶發(fā)展情況》可得知：中國移動用戶 2G 用戶占 41.4%，3G 用戶占 31.3%,，4G 用戶占 27.3%,。遠遠沒有長期處于 WiFi 環(huán)境下的我們想象的那么美好。雖然這些用戶并非長期使用 2/3G,，但是我們的頁面必須確保在 2/3G 環(huán)境下有一個順暢的體驗,。建議首屏資源在 300KB 左右，并設置緩存,。

針對無 loading 的情況,，還需要考慮：

1、假如頁面有比較豐富的動畫,，需要先加載資源才能被正常播放呢,？

要么去掉動畫，要么用 CSS 或 JS 來實現(xiàn)動畫,，必須要做出取舍。

2,、既然是無 loading 的頁面,，自然對速度有要求，還能提高加載速度嗎,？

可以,，請分屏加載。若希望做到體驗無縫,，請在前一屏加載后一屏的資源,。

如果這一屏不涉及復雜的 DOM 跟很重的效果，我還是覺得可以使用 iScroll,，雖然它在安卓上的性能一直被詬病,，但經(jīng)過非常多安卓機的檢驗，效果還是在可接收范圍內(nèi)的,，但別忘了前提：DOM 不復雜（如活動規(guī)則頁）,。

那是否有更好的解決方案呢？有,！

我們再回看之前滑屏的最佳實現(xiàn)方式：

可以看到,，在每一屏上進行操作，當上一屏或下一屏滑動到當前屏時,，之前的那一屏會去掉 translate 屬性,，回歸到最初的狀態(tài)（被當前屏蓋在下面，即 position:absolute; left:0; top:0）,，這個時候,，將當前屏的 position:absolute; height:100% 去掉，使其回歸文檔流,，那么 body 將會被撐開,，頁面可以被正常滑動,，連 iScroll 都省了,。

相信對于大部分 UI 開發(fā)來說，寫出一個安卓下不卡頓,，沒有兼容性問題的頁面是最美好的愿望,，有時候甚至可以針對 iOS 跟 Android 專門寫一套代碼，看似工作量大,，其實可以規(guī)避掉很多不必要的麻煩,。同時也需要跟產(chǎn)品、設計師們在安卓上的體驗退化上達成一致,，以免頁面做出來后帶來預期上的落差,。

這次在會員15周年中嘗試了很多種技術(shù)，比如通過 Canvas 播放視頻,、視頻在移動頁面的應用以及 HTML5 音頻探索 等,，后續(xù)也將輸出文章。來體驗下會員15周年的活動吧：http://vip.qq.com/clubact/2015/clubbirthday15/index.html