昨天，我在 Google 搜索 iOS Safari 的键盘问题，已经不知道是第几次这样绝望地寻找了，直到我找到了这篇 Safari 13, Mobile Keyboards, And The VisualViewport API.。文章指出，Safari 13（iOS 13）已经支持了 VisualViewport API，这是一个可以反映实际可视区域的实验性标准。根据 MDN 页面，目前只有 IE 和 Legacy Edge 不支持这个 API。

经过测试，iOS 13 对于这个 API 支持非常完善，已经能够完全体现页面上不含键盘的可视区域所在的位置了。可是，明明只有 iOS 8.2 不会报告键盘弹出，为何却有一个跨平台的 API 来补偿呢？其他浏览器有 window.innerWidth、window.innerHeight 和 resize 事件不是就足够好了吗？

没错，问题在于页面缩放。可以看出，当页面发生放大后，fixed 元素是不会一起移动到实际可视区域的。而且经过测试发现，Android 下的 window.innerWidth、window.innerHeight 也不会随页面放大而一起变化。

反而在 iOS 下，window.innerWidth、window.innerHeight 会随着页面放大而等比例减小，虽然不会去掉键盘高度，但确实反映了显示在屏幕内的页面区域尺寸。

而 VisualViewport API 在 Android 和 iOS 两端，都完整反映了在缩放和键盘弹出等一系列影响下，实际可视区域在页面中的位置和大小。

因此，VisualViewport API 对于 iOS 以外的平台，最大的意义是可以反映页面的放大区域；而对于 iOS Safari 浏览器，最大的意义是可以反映键盘的弹出。 基于这一点，我们可以实现一个真正相对于可视区域 fixed（固定）的 fixed 容器。

如何实现一个 fixed 容器？关于这一点，也许有一部分 Web 开发者并不知情。在 Web 开发者的直觉中，fixed 元素是始终相对于视口定位，没有任何一个元素能够改变它的定位方式；但事实上，问题却有些不同。

如果你曾经使用过一些性能优良的滚动容器，如 iScroll、BetterScroll、AlloyTouch 等，你可能会遇到这样一个问题：fixed「不灵了」，它们可能不再相对于视口定位，而是被限制在了滚动容器之内。

这是因为，在滚动容器经常会遇到的性能瓶颈中，组件的开发者通常会选择 CSS 3D Transform 来强制硬件加速，让滚动体验更顺畅。在开启了 3D Transform 的容器内，由于渲染限制，fixed 元素无法再相对于视口布局，而是被「圈」在了 3D Transform 容器之内。我们只需要反其道而行之，给一个容器开启 3D Transform，就可以让内部的 fixed 元素相对于该容器布局了。

实现一个可以兼容 Android/iOS 13+，始终贴着可视区域的 VisualViewport 组件。