hls.js 中处理404错误的正确方式

问题背景

在使用hls.js播放HLS流时，开发者经常会遇到一个常见问题：当首次请求manifest文件(m3u8)时，如果服务器返回404错误，hls.js默认会直接放弃而不会自动重试。这在某些场景下会造成困扰，特别是当manifest文件需要时间生成时。

默认行为分析

hls.js对于HTTP状态码的处理有明确的区分：

• 对于5xx服务器错误(如502、503等)，默认会进行重试
• 对于4xx客户端错误(如404)，默认不会重试

这种设计是合理的，因为4xx错误通常表示请求本身有问题(如URL错误)，重试不会有帮助。但在manifest文件延迟生成的场景下，这种默认行为就不太适用了。

解决方案

hls.js提供了灵活的配置选项来解决这个问题。关键在于使用shouldRetry回调函数来自定义重试逻辑。

配置示例

new Hls({
  manifestLoadPolicy: {
    default: {
      maxTimeToFirstByteMs: Infinity,
      maxLoadTimeMs: 20000,
      timeoutRetry: {
        maxNumRetry: 3,
        retryDelayMs: 0,
        maxRetryDelayMs: 0,
      },
      errorRetry: {
        maxNumRetry: 2,
        retryDelayMs: 1000,
        maxRetryDelayMs: 8000,
        shouldRetry: (
          retryConfig,
          retryCount,
          isTimeout,
          loaderResponse,
          retry
        ) => retryCount < retryConfig.maxNumRetry
      },
    },
  },

关键配置说明

1. maxNumRetry: 设置最大重试次数
2. retryDelayMs: 设置重试延迟时间(毫秒)
3. maxRetryDelayMs: 设置最大重试延迟时间
4. shouldRetry: 自定义重试条件判断函数

在shouldRetry函数中，我们可以根据实际需求决定是否重试。上面的示例简单地根据重试次数判断，实际应用中可以根据HTTP状态码、错误类型等更复杂的条件进行判断。

实现原理

hls.js内部使用了一个分层的重试机制：

1. 首先检查是否是超时错误
2. 然后检查HTTP状态码
3. 最后应用自定义的shouldRetry逻辑

这种设计既保证了默认行为的合理性，又为特殊场景提供了足够的灵活性。

最佳实践

对于manifest文件延迟生成的场景，建议：

1. 设置合理的重试次数(如3-5次)
2. 采用指数退避策略，逐步增加重试间隔
3. 在UI上显示加载状态，提升用户体验
4. 考虑在服务器端优化manifest生成速度

总结

hls.js通过灵活的配置选项，允许开发者自定义404等错误的重试行为。理解这一机制可以帮助开发者更好地处理各种边缘情况，构建更健壮的流媒体播放应用。关键在于根据实际业务需求，合理配置重试策略，平衡用户体验和服务器负载。