同层渲染导致的问题：小程序直播悬浮窗踩坑记录

2024-02-14 03:44:44

在小程序开发中，我们经常会遇到一些原生组件的特殊表现，这其中就包括 live-player 。live-player 是微信小程序提供的用于播放直播流的原生组件，功能强大，但也存在一些需要注意的细节，尤其是在与其他组件组合使用时，容易出现一些棘手的问题。今天我们就来聊聊 live-player 在小程序中遇到的一个典型问题——同层渲染问题。

小程序的视图层和逻辑层是分离的，这使得它在渲染性能方面表现出色。但当我们需要使用一些原生组件，例如地图、视频、相机等，这些组件的渲染方式与普通组件有所不同，它们会直接渲染到屏幕上，而不是通过小程序的渲染引擎。这种渲染方式被称为“原生组件同层渲染”。

同层渲染本身是为了提升性能，例如播放视频时，使用原生组件可以获得更流畅的体验。但当原生组件与其他组件，特别是可交互组件（例如 movable-view ）结合使用时，就可能出现一些冲突。

举个例子，如果我们想实现一个可拖动的直播悬浮窗，我们会很自然地想到使用 movable-view 和 live-player 组件来实现。movable-view 负责拖动，live-player 负责播放直播流。

但实际操作中，你会发现，当拖动 movable-view 时，live-player 可能会出现卡顿、闪烁甚至黑屏的现象。这是因为 movable-view 在拖动过程中会不断触发重绘，而 live-player 作为原生组件，它的渲染过程比较复杂，频繁的重绘会导致它无法及时更新画面，从而出现卡顿等问题。

那么如何解决这个问题呢？

一种方法是尽量减少 movable-view 的重绘次数。我们可以通过 requestAnimationFrame API 来控制重绘频率。requestAnimationFrame 会在浏览器下次重绘之前执行回调函数，这样可以将多个重绘操作合并成一次，提高渲染效率。

let moving = false;
let requestId = null;

movableView.addEventListener('touchmove', (e) => {
  moving = true;
  if (!requestId) {
    requestId = requestAnimationFrame(() => {
      // 更新 movable-view 的位置
      movableView.style.left = e.touches[0].clientX + 'px';
      movableView.style.top = e.touches[0].clientY + 'px';
      moving = false;
      requestId = null;
    });
  }
});

另一种方法是利用 live-player 组件的一些特性。live-player 提供了一个 autoPauseIfNavigate 属性，当设置为 true 时，如果页面跳转或隐藏，直播会自动暂停。我们可以利用这个特性，在 movable-view 开始拖动时，将 live-player 暂停，拖动结束后再恢复播放。

movableView.addEventListener('touchstart', () => {
  livePlayer.pause();
});

movableView.addEventListener('touchend', () => {
  livePlayer.play();
});

当然，以上只是一些通用的解决思路，具体的解决方案还需要根据实际情况进行调整。例如，如果直播流的码率很高，即使使用 requestAnimationFrame 也可能无法完全解决卡顿问题，这时可能需要考虑降低码率或者使用其他优化手段。

小程序开发中，原生组件同层渲染是一个比较复杂的问题，需要开发者仔细分析和处理。希望本文能够帮助你更好地理解 live-player 组件的同层渲染问题，并找到合适的解决方案。