移動(dòng)端業(yè)務(wù)開(kāi)發(fā)烟勋，iOS 下經(jīng)常會(huì)有 fixed 元素和輸入框(input 元素)同時(shí)存在的情況兽泣。 但是 fixed 元素在有軟鍵盤(pán)喚起的情況下因篇，會(huì)出現(xiàn)許多莫名其妙的問(wèn)題羹奉。 這篇文章里就提供一個(gè)簡(jiǎn)單的有輸入框情況下的 fixed 布局方案沪停。
iOS下的 Fixed + Input BUG現(xiàn)象
讓我們先舉個(gè)栗子煤辨，最直觀的說(shuō)明一下這個(gè) BUG 的現(xiàn)象。 常規(guī)的 fixed 布局木张，可能使用如下布局（以下僅示意代碼）：
對(duì)應(yīng)的樣式如下：
然后看起來(lái)就是下面這個(gè)樣子众辨。拖動(dòng)頁(yè)面時(shí) header 和 footer 已經(jīng)定位在了對(duì)應(yīng)的位置，目測(cè)沒(méi)問(wèn)題了舷礼。
如果底部輸入框軟鍵盤(pán)被喚起以后鹃彻，再次滑動(dòng)頁(yè)面，就會(huì)看到如下圖所示：
我們看到 fixed 定位好的元素跟隨頁(yè)面滾動(dòng)了起來(lái)… fixed 屬性失效了妻献！
這是為什么呢蛛株？簡(jiǎn)單解釋下： >軟鍵盤(pán)喚起后团赁，頁(yè)面的 fixed 元素將失效（即無(wú)法浮動(dòng)，也可以理解為變成了 absolute 定位）谨履，所以當(dāng)頁(yè)面超過(guò)一屏且滾動(dòng)時(shí)欢摄，失效的 fixed 元素就會(huì)跟隨滾動(dòng)了。
這便是 iOS 上 fixed 元素和輸入框的 bug 笋粟。其中不僅限于type=text的輸入框怀挠，凡是軟鍵盤(pán)（比如時(shí)間日期選擇、select 選擇等等）被喚起害捕，都會(huì)遇到同樣地問(wèn)題绿淋。
雖然isScroll.js可以很好的解決 fixed 定位滾動(dòng)的問(wèn)題，但是不在萬(wàn)不得已的情況下尝盼，我們盡量嘗試一下不依賴第三方庫(kù)的布局方案吞滞，以簡(jiǎn)化實(shí)現(xiàn)方式。這里拋磚引玉作為參考盾沫。
解決思路：
既然在 iOS 下由于軟鍵盤(pán)喚出后冯吓，頁(yè)面 fixed 元素會(huì)失效，導(dǎo)致跟隨頁(yè)面一起滾動(dòng)疮跑，那么假如——頁(yè)面不會(huì)過(guò)長(zhǎng)出現(xiàn)滾動(dòng)，那么即便 fixed 元素失效凸舵，也無(wú)法跟隨頁(yè)面滾動(dòng)祖娘，也就不會(huì)出現(xiàn)上面的問(wèn)題了。
那么按照這個(gè)思路啊奄，如果使 fixed 元素的父級(jí)不出現(xiàn)滾動(dòng)渐苏，而將原 body 滾動(dòng)的區(qū)域域移到 main 內(nèi)部，而 header 和 footer 的樣式不變菇夸，代碼如下：
這樣再來(lái)看一下：
在原始輸入法下琼富， fixed 元素可以定位在頁(yè)面的正確位置。滾動(dòng)頁(yè)面時(shí)庄新，由于滾動(dòng)的是 main 內(nèi)部的 div鞠眉，因此 footer 沒(méi)有跟隨頁(yè)面滾動(dòng)。
上面貌似解決了問(wèn)題择诈，但是如果在手機(jī)上實(shí)際測(cè)試一下械蹋，會(huì)發(fā)現(xiàn) main 元素內(nèi)的滾動(dòng)非常不流暢，滑動(dòng)的手指松開(kāi)后羞芍，滾動(dòng)立刻停止哗戈，失去了原本的流暢滾動(dòng)特性。百度一下彈性滾動(dòng)的問(wèn)題荷科，發(fā)現(xiàn)在webkit中唯咬，下面的屬性可以恢復(fù)彈性滾動(dòng)纱注。-webkit-overflow-scrolling: touch;
在 main 元素上加上該屬性，嗯胆胰，絲般順滑的感覺(jué)又回來(lái)了狞贱！
另外，這里的 header 和 footer 使用的是 fixed 定位煮剧，如果考慮到更老一些的 iOS 系統(tǒng)不支持 fixed 元素斥滤，完全可以把 fixed 替換成 absolute 。測(cè)試后效果是一樣的勉盅。
至此一個(gè)不依賴第三方庫(kù)的 fixed 布局就完成了佑颇。
Android 下布局
談到了 iOS ，也來(lái)簡(jiǎn)單說(shuō)一下 Android 下的布局吧草娜。
在 Android2.3+ 中挑胸，因?yàn)椴恢С?overflow-scrolling ，因此部分瀏覽器內(nèi)滾動(dòng)會(huì)有不流暢的卡頓宰闰。但是目前發(fā)現(xiàn)在 body 上的滾動(dòng)還是很流暢的茬贵，因此使用第一種在 iOS 出現(xiàn)問(wèn)題的 fixed 定位的布局就可以了。
如果需要考慮 Android2.3 以下系統(tǒng)移袍，因?yàn)椴恢С?fixed 元素解藻，所以依然要需要考慮使用isScroll.js來(lái)實(shí)現(xiàn)內(nèi)部滾動(dòng)。
其實(shí)在 fixed 和輸入框的問(wèn)題上葡盗，基本思路就是： > 由于 fixed 在軟鍵盤(pán)喚起后會(huì)失效螟左，導(dǎo)致在頁(yè)面可以滾動(dòng)時(shí)，會(huì)跟隨頁(yè)面一起滾動(dòng)觅够。因此如果頁(yè)面無(wú)法滾動(dòng)胶背，那么 fixed 元素即使失效，也不會(huì)滾動(dòng)喘先，也就不會(huì)出現(xiàn) bug 了钳吟。
所以可以在這個(gè)方面去考慮解決問(wèn)題。
其他的一些細(xì)節(jié)處理
在細(xì)節(jié)處理上窘拯，其實(shí)還有很多要注意的红且，挑幾個(gè)實(shí)際遇到比較大的問(wèn)題來(lái)說(shuō)一下：
1.有時(shí)候輸入框 focus 以后，會(huì)出現(xiàn)軟鍵盤(pán)遮擋輸入框的情況树枫，這時(shí)候可以嘗試 input 元素的 scrollIntoView 進(jìn)行修復(fù)直焙。
2.在 iOS 下使用第三方輸入法時(shí)，輸入法在喚起經(jīng)常會(huì)蓋住輸入框砂轻，只有在輸入了一條文字后奔誓，輸入框才會(huì)浮出。目前也不知道有什么好的辦法能讓喚起輸入框時(shí)正確顯示。這暫時(shí)算是 iOS 下的一個(gè)坑吧厨喂。
3.有些第三方瀏覽器底部的工具欄是浮在頁(yè)面之上的和措，因此底部 fixed 定位會(huì)被工具欄遮擋。解決辦法也比較簡(jiǎn)單粗暴——適配不同的瀏覽器蜕煌，調(diào)整 fixed 元素距離底部的距離派阱。
4.最好將 header 和 footer 元素的 touchmove 事件禁止，以防止?jié)L動(dòng)在上面觸發(fā)了部分瀏覽器全屏模式切換斜纪，而導(dǎo)致頂部地址欄和底部工具欄遮擋住 header 和 footer 元素贫母。
5.在頁(yè)面滾動(dòng)到上下邊緣的時(shí)候，如果繼續(xù)拖拽會(huì)將整個(gè) View 一起拖拽走盒刚，導(dǎo)致頁(yè)面的“露底”腺劣。
為了防止頁(yè)面露底，可以在頁(yè)面拖拽到邊緣的時(shí)候因块，通過(guò)判斷拖拽方向以及是否為邊緣來(lái)阻止 touchmove 事件橘原，防止頁(yè)面繼續(xù)拖拽。
