弱网环境专项优化：3G/4G/5G网络特征、WiFi与蜂窝切换的平滑过渡、网络恢复后的快速重建

各位同学，今天我们来聊聊一个让所有WebRTC工程师都头疼的话题——弱网环境。说实话，我入行那会儿，觉得WebRTC能通就行，管它什么网络。直到有一次在高铁上做演示，视频卡成PPT，领导脸都绿了。从那以后，我才真正开始研究弱网优化。

弱网环境，说白了就是网络条件不理想的情况。3G、4G、5G各有各的脾气，WiFi和蜂窝网络切换时更是容易出幺蛾子。咱们今天就把这些坑一个个填上。

一、3G/4G/5G网络特征与应对策略

不同的移动网络，延迟、带宽、抖动都不一样。我习惯把它们分成三类来对待。

网络类型	典型延迟	带宽范围	抖动特征	核心痛点
3G (HSPA+)	100-300ms	1-5 Mbps	高抖动，突发丢包	延迟大，带宽窄
4G (LTE)	30-80ms	10-50 Mbps	中等抖动，偶发丢包	信号波动大
5G (NR)	5-20ms	100-1000 Mbps	低抖动，极少丢包	覆盖不稳定

嗯，这里要注意。3G网络虽然现在用得少了，但在一些偏远地区还是主力。我在西北做项目时就遇到过，用户还在用3G，视频根本推不上去。

具体怎么做？看代码：

// 根据网络类型调整编码参数
function getCodecParamsForNetwork(networkType) {
  switch(networkType) {
    case '3G':
      return {
        width: 640,
        height: 480,
        frameRate: 15,
        bitrate: 500000, // 500kbps
        degradationPreference: 'maintain-framerate'
      };
    case '4G':
      return {
        width: 1280,
        height: 720,
        frameRate: 30,
        bitrate: 2000000, // 2Mbps
        degradationPreference: 'balanced'
      };
    case '5G':
      return {
        width: 1920,
        height: 1080,
        frameRate: 60,
        bitrate: 8000000, // 8Mbps
        degradationPreference: 'maintain-resolution'
      };
    default:
      // 回退到自适应
      return getAdaptiveParams();
  }
}

你想想看，如果3G网络下硬推1080p，那画面会卡成什么样？我曾经见过一个产品，在3G下推4K，结果延迟飙到5秒，用户直接卸载了。

二、WiFi与蜂窝切换的平滑过渡

这是个大坑。用户从家里WiFi走到户外，网络从WiFi切到4G，这时候视频通话不能断。我管这个叫「网络换手」。

为什么会出问题？因为切换过程中，IP地址变了，原来的连接就断了。WebRTC的ICE机制会尝试重新建立连接，但这个过程需要时间。

具体做法是这样的：

1. 监听网络变化：通过Network Information API获取网络类型
2. 预建候选连接：在切换前，提前创建新的RTCPeerConnection
3. 平滑迁移：使用ICE重启机制，无缝切换到新连接

// 监听网络变化
const connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection;

connection.addEventListener('change', async () => {
  const networkType = connection.effectiveType; // 'slow-2g', '2g', '3g', '4g'
  console.log(`网络类型变化: ${networkType}`);
  
  // 提前准备新连接
  const newPC = await createNewPeerConnection();
  
  // 执行ICE重启
  await performIceRestart(newPC);
});

async function performIceRestart(newPC) {
  // 创建新的offer
  const offer = await newPC.createOffer({ iceRestart: true });
  await newPC.setLocalDescription(offer);
  
  // 通过信令发送给远端
  signaling.send({
    type: 'ice-restart',
    sdp: offer.sdp
  });
}

我记得有一次在商场做演示，用户从门口走到里面，WiFi切到4G再切回WiFi，视频通话全程没断。当时团队都松了一口气。说白了，关键就是「预判」和「预建」。

三、网络恢复后的快速重建

网络断了又恢复，这种情况很常见。比如进电梯、过隧道。网络恢复后，我们要尽快重建连接，减少用户感知到的中断时间。

我习惯用「快速重连」策略，而不是从头开始建连。具体来说：

• 保留ICE候选信息：不要清空之前的候选列表
• 使用ICE重启：比新建连接快50%以上
• 快速同步状态：恢复视频帧率和音频同步

// 网络恢复后的快速重建
async function handleNetworkRecovery() {
  // 1. 检测网络恢复
  if (navigator.onLine) {
    console.log('网络已恢复，开始快速重建');
    
    // 2. 检查连接状态
    const iceState = peerConnection.iceConnectionState;
    
    if (iceState === 'disconnected' || iceState === 'failed') {
      // 3. 执行ICE重启
      await peerConnection.restartIce();
      
      // 4. 等待连接建立
      await waitForConnection(peerConnection, 5000); // 5秒超时
      
      // 5. 恢复媒体流
      await syncMediaState();
    }
  }
}

function waitForConnection(pc, timeout) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error('连接超时')), timeout);
    
    pc.oniceconnectionstatechange = () => {
      if (pc.iceConnectionState === 'connected' || 
          pc.iceConnectionState === 'completed') {
        clearTimeout(timer);
        resolve();
      }
    };
  });
}

嗯，这里有个细节。网络恢复后，视频编码器可能还保留着之前的参数。我建议在重建后重新评估带宽，避免用旧参数导致卡顿。

你想想看，如果网络恢复后重建需要5秒，用户早就等不及了。我见过一个极端案例，重建花了8秒，用户直接切到微信语音去了。

四、整体优化策略

说了这么多，咱们总结一下。弱网优化不是单一技术，而是一套组合拳。我习惯用下面这张图来梳理整体策略：

这张图展示了从网络检测到用户体验的完整链路。每一层都依赖下一层的数据，环环相扣。我个人习惯在项目初期就把这个框架搭好，后面优化起来就轻松多了。

好了，关于弱网环境专项优化，今天就聊到这里。记住一句话：网络不可靠，但我们的代码可以可靠。把这些策略落地到你的项目中，用户会感谢你的。

---

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