Web移動(dòng)端Fixed布局的解決方案

發(fā)布時(shí)間：2021-06-22 15:26:45

移動(dòng)端業(yè)務(wù)開發(fā)，iOS 下經(jīng)常會(huì)有 fixed 元素和輸入框(input 元素)同時(shí)存在的情況。 但是 fixed 元素在有軟鍵盤喚起的情況下，會(huì)出現(xiàn)許多莫名其妙的問題。 這篇文章里就提供一個(gè)簡(jiǎn)單的有輸入框情況下的 fixed 布局方案。

iOS下的 Fixed + Input BUG現(xiàn)象

讓我們先舉個(gè)栗子，最直觀的說明一下這個(gè) BUG 的現(xiàn)象。 常規(guī)的 fixed 布局，可能使用如下布局（以下僅示意代碼）

然后看起來(lái)就是下面這個(gè)樣子。拖動(dòng)頁(yè)面時(shí) header 和 footer 已經(jīng)定位在了對(duì)應(yīng)的位置，目測(cè)沒問題了。

但接下來(lái)問題就來(lái)了！如果底部輸入框軟鍵盤被喚起以后，再次滑動(dòng)頁(yè)面，就會(huì)看到如下圖所示：

我們看到 fixed 定位好的元素跟隨頁(yè)面滾動(dòng)了起來(lái)… fixed 屬性失效了！

這是為什么呢？簡(jiǎn)單解釋下： ** 軟鍵盤喚起后，頁(yè)面的fixed 元素將失效（即無(wú)法浮動(dòng)，也可以理解為變成了absolute定位），所以當(dāng)頁(yè)面超過一屏且滾動(dòng)時(shí)，失效的 fixed 元素就會(huì)跟隨滾動(dòng)了**。

這便是 iOS 上 fixed 元素和輸入框的 bug 。其中不僅限于 type=text 的輸入框，凡是軟鍵盤（比如時(shí)間日期選擇、select 選擇等等）被喚起，都會(huì)遇到同樣地問題。

雖然 isScroll.js 可以很好的解決 fixed 定位滾動(dòng)的問題，但是不在萬(wàn)不得已的情況下，我們盡量嘗試一下不依賴第三方庫(kù)的布局方案，以簡(jiǎn)化實(shí)現(xiàn)方式。這里拋磚引玉作為參考。

解決思路：

既然在 iOS 下由于軟鍵盤喚出后，頁(yè)面 fixed 元素會(huì)失效，導(dǎo)致跟隨頁(yè)面一起滾動(dòng)，那么假如——頁(yè)面不會(huì)過長(zhǎng)出現(xiàn)滾動(dòng)，那么即便 fixed 元素失效，也無(wú)法跟隨頁(yè)面滾動(dòng)，也就不會(huì)出現(xiàn)上面的問題了。

那么按照這個(gè)思路，如果使 fixed 元素的父級(jí)不出現(xiàn)滾動(dòng)，而將原 body 滾動(dòng)的區(qū)域域移到 main 內(nèi)部，而 header 和 footer 的樣式不變，代碼如下：

CSS:

這樣再來(lái)看一下：

在原始輸入法下， fixed 元素可以定位在頁(yè)面的正確位置。滾動(dòng)頁(yè)面時(shí)，由于滾動(dòng)的是 main 內(nèi)部的 div，因此 footer 沒有跟隨頁(yè)面滾動(dòng)。

上面貌似解決了問題，但是如果在手機(jī)上實(shí)際測(cè)試一下，會(huì)發(fā)現(xiàn) main 元素內(nèi)的滾動(dòng)非常不流暢，滑動(dòng)的手指松開后，滾動(dòng)立刻停止，失去了原本的流暢滾動(dòng)特性。百度一下彈性滾動(dòng)的問題，發(fā)現(xiàn)在 webkit 中，下面的屬性可以恢復(fù)彈性滾動(dòng)。

在 main 元素上加上該屬性，嗯，絲般順滑的感覺又回來(lái)了！

另外，這里的 header 和 footer 使用的是 fixed 定位，如果考慮到更老一些的 iOS 系統(tǒng)不支持 fixed元素，完全可以把 fixed 替換成 absolute 。測(cè)試后效果是一樣的。

至此一個(gè)不依賴第三方庫(kù)的 fixed 布局就完成了。

Android 下布局

談到了 iOS ，也來(lái)簡(jiǎn)單說一下 Android 下的布局吧。

在 Android2.3+ 中，因?yàn)椴恢С?nbsp;overflow-scrolling，因此部分瀏覽器內(nèi)滾動(dòng)會(huì)有不流暢的卡頓。但是目前發(fā)現(xiàn)在 body 上的滾動(dòng)還是很流暢的，因此使用第一種在 iOS 出現(xiàn)問題的 fixed 定位的布局就可以了。

如果需要考慮 Android2.3 以下系統(tǒng)，因?yàn)椴恢С?nbsp;fixed 元素，所以依然要需要考慮使用 isScroll.js 來(lái)實(shí)現(xiàn)內(nèi)部滾動(dòng)。

其實(shí)在 fixed 和輸入框的問題上，基本思路就是： 由于 fixed 在軟鍵盤喚起后會(huì)失效，導(dǎo)致在頁(yè)面可以滾動(dòng)時(shí)，會(huì)跟隨頁(yè)面一起滾動(dòng)。因此如果頁(yè)面無(wú)法滾動(dòng)，那么 fixed 元素即使失效，也不會(huì)滾動(dòng)，也就不會(huì)出現(xiàn) bug 了。

所以可以在這個(gè)方面去考慮解決問題。

其他的一些細(xì)節(jié)處理

在細(xì)節(jié)處理上，其實(shí)還有很多要注意的，挑幾個(gè)實(shí)際遇到比較大的問題來(lái)說一下：

有時(shí)候輸入框 focus 以后，會(huì)出現(xiàn)軟鍵盤遮擋輸入框的情況，這時(shí)候可以嘗試 input 元素的 scrollIntoView 進(jìn)行修復(fù)。在 iOS 下使用第三方輸入法時(shí)，輸入法在喚起經(jīng)常會(huì)蓋住輸入框，只有在輸入了一條文字后，輸入框才會(huì)浮出。目前也不知道有什么好的辦法能讓喚起輸入框時(shí)正確顯示。這暫時(shí)算是 iOS 下的一個(gè)坑吧。有些第三方瀏覽器底部的工具欄是浮在頁(yè)面之上的，因此底部 fixed 定位會(huì)被工具欄遮擋。解決辦法也比較簡(jiǎn)單粗暴——適配不同的瀏覽器，調(diào)整 fixed 元素距離底部的距離。最好將 header 和 footer 元素的 touchmove 事件禁止，以防止?jié)L動(dòng)在上面觸發(fā)了部分瀏覽器全屏模式切換，而導(dǎo)致頂部地址欄和底部工具欄遮擋住 header 和 footer 元素。在頁(yè)面滾動(dòng)到上下邊緣的時(shí)候，如果繼續(xù)拖拽會(huì)將整個(gè) View 一起拖拽走，導(dǎo)致頁(yè)面的“露底”。

為了防止頁(yè)面露底，可以在頁(yè)面拖拽到邊緣的時(shí)候，通過判斷拖拽方向以及是否為邊緣來(lái)阻止 touchmove 事件，防止頁(yè)面繼續(xù)拖拽。

以上面內(nèi)滾動(dòng) layout-scroll-fixed 布局為例，給出一段代碼作為參考：

防止內(nèi)容區(qū)域滾到底后引起頁(yè)面整體的滾動(dòng)