在 H5 項目中，我們會經常遇到頁面中存在單個甚至多個 input/textarea 輸入框與底部固定元素的布局情況。在 input/textarea 輸入框獲取焦點時，會自動觸發鍵盤彈起，而鍵盤彈出在 ios 與 android 的 webview 中表現并非一致，同時當我們主動觸發鍵盤收起時也同樣存在差異化。而無論如何，我們希望功能流暢的同時，盡量保持用戶體驗的一致性，因此有了下面一系列兼容性問題的研究。

1. 鍵盤彈出的不同表現

• IOS：IOS 的鍵盤處在窗口的最上層，當鍵盤彈起時，webview 的高度 height 并沒有改變，只是 scrollTop 發生變化，頁面可以滾動。且頁面可以滾動的最大限度為彈出的鍵盤的高度，而只有鍵盤彈出時頁面恰好也滾動到最底部時，scrollTop 的變化值為鍵盤的高度，其他情況下則無法獲取。這就導致在 IOS 情況下難以獲取鍵盤的真實高度。
• Android: webview 中留出空間，該空間小于等于的鍵盤空間，變化的高度差會隨著布局而不同，有的認為 鍵盤高度 + 頁面高度 = 原頁面高度； 是錯誤的誤導，只有在某種很巧合的布局情況下才可套用此公式。

2. 鍵盤收起的不同表現

• IOS：觸發鍵盤上的按鈕收起鍵盤或者輸入框以外的頁面區域時，輸入框會失去焦點，因此會觸發輸入框的 blur 事件。
• Android: 觸發鍵盤上的按鈕收起鍵盤時，輸入框并不會失去焦點，因此不會觸發頁面的 blur 事件；觸發輸入框以外的區域時，輸入框會失去焦點，觸發輸入框的 blur 事件。

3. 監聽鍵盤的彈出與收起
在 h5 中目前沒有接口可以直接監聽鍵盤事件，但我們可以通過分析鍵盤彈出、收起的觸發過程及表現形式，來判斷鍵盤是彈出還是收起的狀態。

• 鍵盤彈出：輸入框獲取焦點時會自動觸發鍵盤的彈起動作，因此，我們可以監聽輸入框的 focus 事件，在里面實現鍵盤彈出后所需的頁面邏輯。這在 ios 及 android 中表現一致。
• 鍵盤收起：從第 2 部分可知，觸發鍵盤收起的不同形式會存在差異化表現，當觸發其他頁面區域收起鍵盤時，我們可以監聽輸入框的 blur 事件，在里面實現鍵盤收起后所需的頁面邏輯。而在通過鍵盤按鈕收起鍵盤時在 ios 與 android 端存在差異化表現，下面具體分析：
• IOS：觸發了輸入框 blur 事件，仍然通過該辦法監聽。
• Android：沒有觸發輸入框的 blur 事件。但通過第 1、2 部分我們可以知道，在 android 中，鍵盤的狀態切換（彈出、收起）不僅和輸入框關聯，同時還會影響到 webview 高度的變化，那我們不妨通過監聽 webview height 的變化來判斷鍵盤是否收起。

下面舉例說明，其中頁面中含有一個輸入框：
<div class="txd"> Welcome to TXD! </div> <div class="input"> <input id="input" type="tel" /> </div>
ios & android 鍵盤彈出：
const $input = document.getElementById('input'); $input.addEventListener('focus', () => { // 處理鍵盤彈出后所需的頁面邏輯 }, false);
ios 鍵盤收起：
const $input = document.getElementById('input'); $input.addEventListener('blur', () => { // 處理鍵盤收起后所需的頁面邏輯 }, false);
android 鍵盤彈出與收起：
/*鍵盤彈起后頁面高度變小*/ const originHeight = document.documentElement.clientHeight || document.body.clientHeight; window.addEventListener('resize', () => { const resizeHeight = document.documentElement.clientHeight || document.body.clientHeight; if (resizeHeight < originHeight) { // 鍵盤彈起所后所需的頁面邏輯 } else { // 鍵盤彈起所后所需的頁面邏輯 } }, false);
在實踐中通過判斷 userAgent 來決定使用哪種方法：
const ua = window.navigator.userAgent.toLocaleLowerCase(); const isIOS = /iphone|ipad|ipod/.test(ua); const isAndroid = /android/.test(ua);
4. 使用案例
接下來根據上面的討論說明幾種常見場景：
（1）頭部及中間輸入框處于正常的文檔流，底部元素 fixed

ios 鍵盤遮擋在頁面上，頁面高度始終不變，頁面可以滾動，底部元素被遮擋；
android 頁面高度減少，頁面不可滾動，fixed 元素的 bottom 屬性的基線為鍵盤；
（2）頭部及輸入框處于正常文檔流，且所占可視區域變大，底部元素 fixed

ios 的 height 沒有發生變化，頁面可以滾動；
android 頁面高度變小，但為了使正常文檔流的元素可以正常顯示，頁面可以上下滾動，fixed 元素的 bottom 屬性的基線為鍵盤；
（3）頭部處于正常文檔流，輸入框脫離正常文檔流 fixed bottom 定位

（上面為了便于觀察，將輸入框包裹元素的背景設置了透明度）
ios 的 height 沒有發生變化，且始終保證輸入框處于可視區域中；
android 頁面高度變小，頁面不可滾動，fixed 輸入框 bottom 屬性的基線為鍵盤；
5. 小結

在 ios 中，無論何種布局，為了使輸入框展示在可視區域中，鍵盤彈出時，頁面會向上滾動，該過程與 Element.scrollIntoViewIfNeeded() 方法（將不在瀏覽器窗口的可見區域內的元素滾動到瀏覽器窗口的可見區域）產生的效果一致；且高度始終不變，頁面可滾動。

在 android 中，鍵盤喚起后，頁面可滾動與否由其處在正常文檔流中的元素決定：如果正常文檔流中的元素可全量展示，頁面不可滾動，否則頁面支持滾動；

在 android 中，鍵盤喚起后，fixed 元素的基準會發生變化：根據 bottom 定位的元素，其基線變為鍵盤上部；根據 top 定位的元素，仍然根據頁面頂部，因此為照顧正常文檔流及 fixed 元素的用戶體驗，有的元素可根據頂部定位，有的可以根據底部定位。

在了解清楚 h5 中鍵盤的彈出收起的性質后，在處理兼容性問題會容易很多。同時也可使用Element.scrollIntoViewIfNeeded() 方法輔助解決問題（比如在切換不同的輸入法時，可能導致有用信息被遮擋的情況）優化體驗。

總結

以上是生活随笔為你收集整理的android accessibility 模拟键盘事件_H5 键盘兼容性小结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。