弱网优化：自适应码率算法(ABR)、HLS/DASH分片策略、网络切换无缝恢复

说实话，弱网优化这块，是音视频开发里最磨人的部分。你想想看，用户可能在地铁里、电梯里、甚至是在高速移动的车上。网络状况说变就变，卡顿、花屏、断连，哪个都够用户骂娘的。

我这些年踩过的坑，十有八九都跟弱网有关。今天咱们就把这块掰开揉碎了讲清楚。核心就三件事：码率怎么自适应、分片怎么切、网络切换怎么无缝恢复。

一、自适应码率算法(ABR)的实战选择

ABR 算法，说白了就是让播放器自己决定「该用多高清的码率」。我见过不少团队直接拿开源播放器默认的 ABR 策略，结果在弱网下体验一塌糊涂。

目前主流的 ABR 算法有四种，我按推荐程度排个序：

算法类型	核心原理	优点	缺点	适用场景
吞吐量法	根据最近N秒的下载速度估算带宽	实现简单，响应快	容易受突发波动影响	带宽相对稳定的场景
缓冲区法	根据播放缓存水位决定码率	抗抖动能力强	码率切换滞后	弱网波动大的场景
混合法	吞吐量+缓冲区综合决策	兼顾响应和稳定性	参数调优复杂	大多数通用场景
预测法	用机器学习预测未来带宽	理论上最优	模型部署成本高	有AI能力的团队

这里给出一份我常用的混合法伪代码，核心逻辑是：缓存充足时信任吞吐量，缓存紧张时保守降码率。

// 混合ABR决策伪代码
fun decideBitrate(
    throughputHistory: List<Long>,  // 最近5秒的吞吐量
    bufferLevel: Long,               // 当前缓存毫秒数
    bufferThreshold: Long = 3000     // 缓存阈值3秒
): BitrateLevel {
    
    // 1. 计算平滑吞吐量（加权移动平均）
    val smoothThroughput = weightedMovingAverage(throughputHistory)
    
    // 2. 根据缓存水位调整决策
    val factor = when {
        bufferLevel < 1000 -> 0.5    // 缓存不足1秒，保守降码率
        bufferLevel < 3000 -> 0.8    // 缓存1-3秒，适度保守
        bufferLevel < 8000 -> 1.0    // 缓存3-8秒，正常决策
        else -> 1.2                   // 缓存充足，可以激进
    }
    
    // 3. 选择码率
    val targetBitrate = (smoothThroughput * factor).toLong()
    return findClosestBitrate(targetBitrate)
}

二、HLS/DASH分片策略的细节

分片策略，说白了就是「把视频切成多小块来传输」。HLS 和 DASH 是两大主流协议，底层逻辑差不多，但细节上有差异。

我个人的习惯是：直播用 HLS，点播用 DASH。为什么？HLS 的生态更成熟，CDN 支持好；DASH 的码率切换更灵活，适合点播场景。

2.1 分片时长怎么选？

这是个经典问题。分片太短，HTTP 请求太多，连接开销大；分片太长，切换码率时延迟高。

• 直播场景：推荐 2-4 秒。我做过测试，2秒分片在弱网下卡顿率比4秒低15%，但服务器压力大一些。
• 点播场景：推荐 6-10 秒。点播对延迟不敏感，分片长一点可以减少请求次数。

2.2 码率阶梯怎么设计？

码率阶梯不是随便列几个档位就行的。我踩过一个坑：把码率阶梯设成 500kbps、1Mbps、2Mbps、4Mbps，结果用户从 4M 降到 2M 时画面质量下降太明显。

正确的做法是：码率阶梯要符合人眼感知的「等距」原则。简单说，码率翻倍时，画质提升才明显。推荐阶梯：

档位	码率	分辨率	适用网络
L0	300 kbps	480p	极弱网（2G/3G）
L1	600 kbps	540p	弱网
L2	1.2 Mbps	720p	普通4G
L3	2.5 Mbps	1080p	良好4G/WiFi
L4	5 Mbps	1080p60	高速WiFi

三、网络切换无缝恢复的实战方案

这是最考验功底的部分。用户从 WiFi 切到 4G，或者从 4G 切到 5G，播放器不能黑屏、不能卡顿超过 200ms。

我总结了一套「三阶段恢复法」：

1. 检测阶段：监听网络变化广播，同时用心跳包探测实际连通性。
2. 缓冲阶段：检测到切换后，立即暂停播放，用旧连接继续缓冲数据。
3. 恢复阶段：新连接建立后，从断点处续传，对齐时间戳后恢复播放。

这里有个坑：不要等网络完全断开才行动。我建议在信号强度低于 -100dBm 时就提前准备切换，而不是等到断连。

// 网络切换恢复核心逻辑
class NetworkSwitchHandler {
    
    private var lastPlaybackPosition: Long = 0
    private var pendingSegments: Queue<Segment> = LinkedList()
    
    fun onNetworkSwitch(newNetwork: NetworkType) {
        // 1. 记录当前播放位置
        lastPlaybackPosition = player.currentPosition
        
        // 2. 暂停播放，但继续缓冲
        player.pause()
        startBufferingOnOldConnection()
        
        // 3. 建立新连接
        val newSession = createSession(newNetwork)
        
        // 4. 从断点处请求分片
        val resumeSegment = findSegmentByPosition(lastPlaybackPosition)
        newSession.requestSegment(resumeSegment)
        
        // 5. 对齐时间戳后恢复
        newSession.onSegmentReady { segment ->
            if (segment.startTime == lastPlaybackPosition) {
                player.resume()
            }
        }
    }
}

四、综合优化建议

最后，我给出几条实战中验证过的建议：

• 预加载策略：在弱网下，提前加载下一个码率档位的分片。比如当前是 720p，提前加载 540p 的分片，一旦降码率可以直接用。
• 冗余分片：对于关键分片（比如 GOP 起始帧），可以同时请求两个不同 CDN 的副本，哪个先到用哪个。
• 降级策略：如果码率降到最低档还是卡顿，可以考虑降帧率（比如从 30fps 降到 15fps），而不是继续降分辨率。

---

公众号:蓝海资料掘金营，微信deep3321