同层渲染
前言 可能作为 iOS 开发者，对同层渲染这个名词比较陌生，但是如果大家开发过小程序，应该对这个名词就不会陌生，因为小程序中有一类组件叫做原生组件（native-component），比如 camera、video 等，这类组件在渲染过程中最终会映射成下文提到的原生组件。 在正文开始之前，先给大家统一几个概念，方便后续的阅读。 原生组件：iOS、Android 等客户端 Native 组件，如 iOS 中的 UITextField、UITextView，Android 中的 EditText、ListView 等； H5 组件：是指 HTML5 语言编写的 web 组件，如 <input/>、 <textarea></textarea> 等； 相比于 H5 组件，原生组件不仅可以提供 H5 组件无法实现的一些功能，还能提升用户体验上的流畅度（特别是对于音视频播放器而言），又因为减少了客户端代码与 WebView 通信的流程，降低了通信开销，简单来说，原生组件功能全、速度快、开销少； 应用及概念 任何技术的产生都是伴随着需求或问题，那么同层渲染的产生到底是解决什么问题呢？ 我们上文已经提到原生组件比 H5 组件性能更好，所以说对于一些 H5 组件，我们希望其在客户端渲染时被映射成原生组件，那么问题来了：作为客户端来讲，我们一般会采用 WebView 加载 HTML，原生组件脱离在 WebView 渲染流程外，如果把 WebView 看成单独的一层，那么原生组件则位于另一个更高的层级。那么这样的层级就带来了一些问题： 原生组件的层级是最高的：页面中的其他组件无论设置 z-index 为多少，都无法盖在原生组件上； 部分 CSS 样式无法应用于原生组件； 原生组件无法在 scroll-view 等可滚动的 H5 组件中使用：因为如果开发者在可滚动的 DOM 区域，插入原生组件作为其子节点，由于原生组件是直接插入到 WebView 外部的层级，与 DOM 之间没有关联，所以不会跟随移动也不会被裁减。 未同层渲染的层级图如下图所示： <!DOCTYPE html> Responsive Image ...