视频链接：

2.20 live-player 与 live-pusher 组件介绍：如何在小程序中实现直播功能？（五）

片 1

上节课我们主要学习了live-pusher、live-player组件，以及如何使用它们，在小程序中如何实现直播功能。这节课我们继续学习这两个组件，并且看看同层渲染是怎么回事，以及在小程序中，使用同层渲染需要注意哪些问题。

在上节课的最后，我们在手机设备上做直播功能测试的时候，给你留了一个问题，为什么我们在微信开发者工具上，单击自动预览功能的“编译并预览”按钮，手机上没有效果呢？这是微信开发者工具的一个 bug 吗？

答案肯定不是的。自动预览这个功能，要求当前测试的微信帐号，必须与微信开发者工具中登陆的帐号，是一致的。上次我们测试的时候，我在微信开发者工具中，我登陆的是我的微信帐号，但是我用的测试手机呢，是我们课程主编的手机。所以在我自动预览测试的时候，其实新版本是推到了我的手机上，而并不是我们在微信开发者工具中扫码预览的手机。

之所以出现这种情况，其实也很简单，因为自动预览这个功能呢，它绑定的不是我们扫码时用的那个微信账号，而是我们在登录微信开发者工具时使用的那个账号。我们登录的微信开发者工具，本质和我们在微信上的好友帐号，以及我们进入的微信群都是一样的，是作为一个信息的推送和接收点存在的。微信开发者工具在这一点上，复用了微信强大的信息推送能力。这种推送协议，是微信经过http协议自行修改的一个推拉轮巡协议，你如果感兴趣，在github 上可以搜索微信网页Api 、微信聊天机器人，可以了解这种协议的具体客户端实现。

那这个问题怎么解决呢，解决方法也很简单，直接单击开发者工具左上角的微信头像，用测试手机，重新扫码登录就可以了。这是上节课的问题，接下来我们开始学习这节课的内容。

同层渲染

片 2

什么是同层渲染呢？同层渲染，本质上它的出现是为了解决普通组件与原生组件不相容的情况。

在以前呢，在旧的开发模式下，也就是在 2.9.0 基础库版本以前，原生组件是一直覆盖在普通组件之上的，始终会把普通组件遮挡住，原生组件也不会随页面一起滚动。

微信团队为了解决这个问题，后来推出了 cover-view 和 cover-image 这两个组件。这两个组件它们也是原生组件，并且它们可以放在其它原生组件上面，在他们里面可以放着一些需要在原生组件上覆盖的内容。这种方案，在一定程序上解决了，开发者需要在原生组件上实现覆盖 UI 的需求。

但是这种实现方式，它其实也不是完善的，使用限制太多，表现力太弱，cover-view 只可以嵌套 cover-view 与 cover-image，并不能嵌套普通组件。

所以，在 2.9.0 基础库版本以后，微信团队又实现了这个同层渲染方案。

同层渲染是微信团队自己实现的，不需要开发者做什么事情，只需要将基础库升级到 2.9.0 版本以后，原生组件就可以像普通组件一样使用了，可以放在普通组件的下面了。

感觉是不是很神奇，为什么之前不可以这样，那么这种同层渲染是怎么实现的呢？

大概来讲，是分两个平台分别实现的，我们先看安卓平台。

Android 端的同层渲染，就是基于 embed 标签，结合 chromium 内核扩展机制来实现的。

小程序在 Android 端采用 chromium 浏览器内核实现WebView 渲染层。这个 chromium 浏览器内核，它提供了一种 WebPlugin 机制，它允许小程序实现自定义的、自己的 embed 标签。

chromiun 为每一个 embed 标签创建一个 WebPlugin 实例，并单独生成一个 RenderLayer渲染层，这个 RenderLayer 可以直接渲染到最终的视图上面。

自实现的 embed 标签，都是独立的，所以也可以像其它组件，例如button、view 等一样，应用样式进行层与位置的控制。

这就是同城渲染在Android 端的实现，比较简单，但是在 iOS 平台上的实现，就稍微有点复杂了。

小程序在 iOS 端，是使用 WKWebView 进行渲染的。这是iOS体系下的视图组件，并且iOS 在渲染时自行做了优化。WKWebView 在内部采用的是分层的方式进行渲染的，它会将 WebKit 内核，生成的合成层，渲染成 iOS 上一个 WKCompositingView，这是一个原生的View。

问题是这个 WKCompositingView 会将多个 DOM 节点，渲染到同一个合成层里面，这样就造成我们的 DOM 节点，与渲染的层之间，不是一对一的映射关系了。既然不是一对一的对应关系，那怎么控制它们与原生组件之间的上下层关系呢。

但是微信团队发现，当把一个 DOM 节点的 CSS 属性设置为 overflow: scroll 之后，WKWebView 会为其自动生成一个 WKChildScrollView，iOS 这种机制呢，本身它是为了改善滚动性能的，在iPhone手机上，即使再长的滚动列表，也不会出现卡顿的情况。

微信团队发现，我们可以把原生组件插入到WKChildScrollView这个子视图层里面，这样不就可以控制上下层关系了吗。

上面就是两个平台，大致实现同层渲染的原理。了解了这个实现的机制以后，接下来我们看一看，在开发中应该注意什么问题。同层渲染目前并不是十分稳定，在项目中可能会出现一些奇怪的问题，这些问题是我们需要避免的。

不是所有情况均能启用「同层渲染」

片 3

我们之前在使用 wxml-to-canvas 这个扩展组件时，也出现过 canvas 随着页面一起滚动的情况。

组件在应用同层渲染的时候，不一定会成功，最好在开发时，通过 bindrendererror 事件，监听同层渲染可能引发的错误。

样式使用有限制

片 4

并非所有的 WXSS 样式属性，都可以在原生组件上生效。

一般来说，像定位样式，例如 position、margin、padding，还有尺寸样式，例如 width、height，还有 transform 样式，例如 scale、rotate、translate，以及层级样式 z-index，这些样式都可以设置。

还有，应用在原生组件外部的属性，例如 shadow、border 样式，一般也会生效。

但对组件做裁剪操作，可能会失败，例如 border-radius 属性，可能就不会产生圆角效果。

注意冒泡事件

片 5

由于使用了非常规的方式实现了同层渲染，特别是在 i OS 平台上，DOM 事件的派发机制，也受到了影响。

在启用了「同层渲染」之后，原生组件上的事件也会冒泡。在 iOS 平台上，作为 WKChildScrollView 子组件的原生组件，可能会将事件冒泡到，与它没有父子关系的上层组件上。

通常在这种情况下，我们可以使用 catch 来代替bind ，阻止事件冒泡。

支持同层渲染的原生组件有限

片 6

原生组件列表：

camera

input（仅在focus时表现为原生组件）

textarea

video

map

canvas

live-player

live-pusher

支持同层渲染的：

video v2.4.0

map v2.7.0

canvas 2d（新接口） v2.9.0

live-player v2.9.1

live-pusher v2.9.1

片 7

我们可以看一下这两个列表，其中上面是所有的原生组件列表，只有下面这些原生组件是支持同层渲染的，

其中我们今天主要学习的两个原生组件 live-pusher 与 live-player，也在这个支持的列表里面。

虽然同层渲染是在 2.9.0 基础库版本开始支持的，但是，一般做运行时版本判断时，是以 2.9.2 版本作为比对版本的。

在了解了同层渲染机制之后，我们就可以直接将原生组件放在普通组件下面了，这样在直播功能中实现全屏效果就很容易了。具体怎么实现，这个问题先留给你思考一下。

好，这节课就讲到这里。这节课我们主要学习了同层渲染相关的内容，下节课我们继续学习在小程序中如何实现直播。

2020年6月6日