4、直播拉流播放：HLS与FLV协议选择、播放器组件集成、低延迟优化

说到直播拉流，这其实是整个链路里最贴近用户的一环。用户能不能流畅地看直播，能不能在主播喊「上链接」的瞬间就点进去，全看这一步做得好不好。我这些年踩过的坑，有一半都跟拉流播放有关。

今天咱们就聊聊三个核心问题：协议怎么选、播放器怎么集成、延迟怎么压下去。

4.1 HLS vs FLV：到底选哪个？

先说说这两个协议。HLS 和 FLV，说白了就是两种不同的「切菜」方式。

HLS（HTTP Live Streaming） 是苹果搞出来的。它把直播流切成一个个小文件，通常是 2-10 秒一个 ts 片段。播放器像翻书一样，一页一页地拉。好处是兼容性好，几乎所有浏览器和手机都支持。坏处嘛——延迟高。你想想看，光一个片段就 6 秒，再加上缓冲，十几秒的延迟很正常。

FLV（Flash Video） 走的是 RTMP 或 HTTP-FLV 协议。它不切文件，而是把数据包源源不断地推过来。播放器收到一帧就播一帧。延迟能做到 1-3 秒。我在做电商直播时，用的就是 HTTP-FLV。为什么？因为用户抢单的时候，差一秒可能就抢不到了。

来，我直接给你一个对比表，看着更清楚：

对比项 HLS FLV（HTTP-FLV）
延迟 10-30 秒 1-3 秒
兼容性 极好（原生支持） 需 Flash 或 MSE 支持
首屏加载 慢（需下载 m3u8） 快（直接连流）
弱网表现 好（可自适应码率） 一般（断流即黑屏）
适用场景 点播、非实时直播 电商直播、互动直播

我的建议：小程序直播带货，首选 HTTP-FLV。延迟低，体验好。但如果你的用户网络环境很差，或者需要做回放，那就得 HLS 兜底。

4.2 播放器组件集成：别自己造轮子

嗯，这里要注意。很多新手喜欢自己写播放器，觉得「不就是拉个流嘛」。我当年也这么干过，结果被坑得够呛。视频解码、音画同步、缓冲策略、内存管理……每一个都是深坑。

我建议直接用成熟的播放器组件。在小程序里，最常用的是 live-player 组件。它是微信官方提供的，支持 FLV 和 HLS。

给你看个基本用法：

<live-player
  id="player"
  src="https://your-domain.com/live/stream.flv"
  mode="live"
  autoplay
  bindstatechange="onStateChange"
  binderror="onError"
/>

这里有几个关键属性：

  • mode="live"：直播模式，延迟最低
  • autoplay：自动播放，但要注意 iOS 的限制
  • bindstatechange：监听播放状态，比如缓冲、结束

避坑指南：我曾经在 iOS 上遇到过 autoplay 不生效的问题。后来发现，iOS 要求用户必须先有交互（比如点击按钮），才能触发自动播放。解决方案是：在页面加载后，先显示一个「点击进入直播间」的按钮，用户点击后再调用 play() 方法。

如果你需要更精细的控制，比如自定义封面、弹幕、美颜，那就得用 同层渲染 了。简单说，就是把 live-player 放在一个 view 里，然后在这个 view 上覆盖其他组件。但要注意，live-player 的层级很高，普通 view 盖不住它。

<view class="player-wrapper">
  <live-player id="player" src="..." mode="live" />
  <view class="overlay">
    <button bindtap="sendDanmu">发弹幕</button>
  </view>
</view>

这里有个小技巧：把 overlay 的 z-index 设得比 live-player 高，同时给 live-player 加上 enable-meta 属性，就能实现弹幕覆盖。

4.3 低延迟优化：从 10 秒压到 2 秒

这是最硬核的部分。我做过一个项目，用户反馈「主播喊 3、2、1 上链接，我点了 5 秒才刷出来」。这就是延迟的锅。

怎么优化？我总结了四个方向：

  1. 协议层面：用 HTTP-FLV 代替 HLS。这是最根本的优化。
  2. 播放器配置：把缓冲时间调到最小。live-player 有个 min-cache 属性，设成 0.5 秒。
  3. CDN 加速：把流推到离用户最近的节点。我一般用腾讯云或阿里云的边缘节点。
  4. GOP 大小控制：GOP 就是关键帧的间隔。间隔越大，延迟越高。建议设成 1-2 秒。

给你看个配置示例：

<live-player
  id="player"
  src="https://your-cdn.com/live/stream.flv"
  mode="live"
  autoplay
  min-cache="0.5"
  max-cache="1"
  object-fit="fillCrop"
/>

注意：min-cache 设得太小，弱网下容易卡顿。我建议做个自适应策略：网络好的时候用 0.5 秒，网络差的时候自动升到 2 秒。可以用 bindnetstatus 事件监听网络状态。

还有一个容易被忽略的点：首屏秒开。用户点进直播间，如果黑屏超过 2 秒，大概率会退出。我常用的做法是：

  • 预加载：在用户进入页面之前，先建立 WebSocket 连接
  • 封面图兜底：先显示一张静态图，等流拉通后再切换
  • DNS 预解析：在 HTML 的 head 里加上 <link rel="dns-prefetch" href="//your-cdn.com">

你想想看，用户从点击到看到画面，如果能在 1 秒内完成，那体验就非常棒了。

4.4 实战中的坑与解法

最后分享几个我踩过的坑：

  • iOS 黑屏问题：有一次 iOS 用户反馈黑屏，查了半天发现是 src 里用了 HTTP 而不是 HTTPS。小程序强制要求 HTTPS，改了就好了。
  • Android 声音不同步：某些 Android 机型会出现音画不同步。解决方案是让服务端把音频采样率固定为 44100Hz，不要用 48000Hz。
  • 后台播放被掐：用户切到后台再回来，直播断了。我加了个 onShow 生命周期监听，切回来时重新拉流。

总结一下：直播拉流播放，协议选 FLV，播放器用 live-player，延迟靠配置和 CDN 压。记住一句话——用户等不起，每一秒都是钱。

下一章咱们聊聊「弹幕与互动系统」，这可是带货直播的灵魂。到时候见。

← 上一章 📖 返回目录 下一章 →