引言

移动应用的用户体验，在很大程度上取决于它在各种网络环境下的表现。地铁穿行时刷短视频会不会卡顿？进出电梯的瞬间请求会不会断掉？地下车库里能不能正常加载内容？这些问题往往需要开发者跑到真实场景中才能验证，测试成本极高。

鸿蒙系统从 API version 20 开始，为手机和平板设备提供了网络领航员功能。它的核心价值很直接——让开发者坐在工位上，就能模拟各种典型的网络场景，快速验证应用体验，并获得针对性的网络优化建议。

本文面向有一定鸿蒙开发基础的开发者，系统梳理网络领航员的功能定位、使用方法、场景设计思路，以及配套的代码优化实践。

一、网络领航员解决什么问题

传统的网络体验测试面临两个痛点：一是场景复现成本高，你不可能为了测一个高铁场景就真的去坐高铁；二是网络状态不可控，即便到了目标场景，网络条件也在不断变化，难以做对比测试。

网络领航员提供的就是一种可控、可重复的网络模拟能力。它预置了 8 种典型网络场景，涵盖了日常出行中最常遇到的网络波动情形。开发者启用某个场景后，设备的网络行为会按照预设的参数运行——包括带宽、时延、丢包率的变化，甚至网络接口（WLAN 与蜂窝）的切换——从而在可控条件下观察应用的表现。

同时，网络领航员还与 Network Boost Kit 形成联动。开发者不仅能发现问题，还能获得该场景下的数据传输优化建议，通过接入 Network Boost Kit 实现应用与系统的跨层协同，提升上网流畅度。

二、如何使用网络领航员

2.1 开启入口

网络领航员有两种入口：设置界面和 HDC 命令行（即 netcopilot 工具）。

通过设置界面操作的路径为：

设置 → 系统 → 开发者选项 → 网络领航员

首次使用前需要先开启设备的开发者模式。

2.2 启用预置场景

进入网络领航员页面后，可以看到所有预置的网络模拟场景。点击任意一个场景即可启用，启用后可以在页面上查看当前生效的模拟场景，同时设备的实况窗会实时展示当前的网络模拟内容。

通过实况窗，开发者不仅能看到网络状态的变化，还可以点击进入查看该场景的详细介绍、网络参数，以及对应的代码开发最佳实践。

2.3 停止场景

需要停止模拟时，点击场景右侧的操作按钮，选择退出即可。

2.4 自定义网络场景

当预置场景无法满足需求时，可以通过页面底部的**”添加自定义网络场景”**来配置专属的网络参数。可配置的参数及其取值范围如下：

需要注意的是，自定义场景的参数配置会应用于启动时的默认网络，建议在网络环境稳定时使用。此外，自定义场景暂未接入 Network Boost Kit，如果需要模拟网络场景的注册回调能力，应使用预置场景。

三、8 大预置场景解析

网络领航员预置的 8 种场景，覆盖了移动用户日常中最典型的网络波动情形。理解每个场景的设计思路，有助于开发者更有针对性地进行测试。

3.1 涉及网络切换的场景

以下三个场景的核心特征是 WLAN 与蜂窝网络之间的切换，使用前需要同时连接 WLAN 并开启移动网络。

进出电梯（总时长 5 分钟，循环执行）：模拟了一个完整的”等电梯 → 进入电梯 → WLAN 信号消失 → 切换到蜂窝 → 出电梯 → 恢复 WLAN”的全过程。其中最关键的阶段是电梯关门后的 30 秒——WLAN 带宽从 1Mbps 线性下降至 0，时延飙升到 1000ms，丢包率升至 8%，随后切换到蜂窝网络逐步恢复。这个过程是考验应用网络切换处理能力的典型场景。

离家断开 WLAN（总时长 3 分钟，循环执行）：模拟用户从家中走向户外的过程。WLAN 信号逐渐减弱直到不可用，然后切换到蜂窝网络。最终蜂窝网络稳定后，下行带宽可达 300-500Mbps。

到家连接 WLAN（总时长 3 分钟，循环执行）：与上一个场景相反，模拟从户外回到室内、蜂窝网络切换到 WLAN 的过程。

3.2 涉及网络波动的场景

这类场景的特征是网络信号在强弱之间快速变化，使用前连接 WLAN 或移动网络即可（乘坐高铁场景需插入双 SIM 卡）。

乘坐地铁（总时长 5 分钟，循环执行）：模拟地铁在站台与行驶区间交替的网络表现。站台上网络良好（下行 300-500Mbps），列车行驶时降至 0-10Mbps 并伴随丢包，到站后恢复——如此往复。

乘坐高铁（总时长 10 分钟，循环执行）：这是时长最长的场景，模拟了高铁从站台出发、经过市郊、进入山区、在山区发生 SIM 卡切换（从卡 1 切到卡 2）、再回到市郊到站的完整旅程。山区阶段的时延高达 300-2000ms，丢包率最高 5%，是对应用极端网络容忍度的严苛测试。

高速公路自驾（总时长 5 分钟，循环执行）：模拟城区行驶与穿越隧道交替出现的网络变化。隧道中下行带宽骤降至 0-2Mbps，时延升至 300-2000ms，丢包率达 5%。

3.3 网络持续不佳的场景

拥挤的食堂（总时长 5 分钟，循环执行）：模拟网络接入设备众多、空口竞争激烈的环境。排队取餐阶段带宽仅 0-5Mbps，时延 10-100ms，丢包率高达 2.4%。就坐后网络有所恢复但仍不理想。

信号弱的地库（总时长 5 分钟，循环执行）：模拟地下停车场信号覆盖差的情况。在停车场内的 3 分钟里，蜂窝网络带宽仅 0-10Mbps，时延 30-100ms。

四、面向三类网络特征的代码优化实践

8 种预置场景的网络特征，可以归纳为三类：网络切换、网络波动、网络质量差。针对每类特征，网络领航员配套提供了相应的优化建议。

4.1 网络切换：及时感知，快速重建连接

当设备在 WLAN 与蜂窝网络之间切换，或在多 SIM 卡之间切换时，会带来 IP 地址变更、TCP 连接被强制中断（触发 RST 复位），以及 DNS 重解析和新连接握手的延迟。

应对策略的核心是：及时识别网络切换，重建连接，重新发起未完成的请求。

一个直接的做法是使用 Network Kit 的 HTTP 数据请求模块发起网络请求。Network Kit 集成了通途协议栈的智能多网切换功能，能够在网络切换时自动将待发和进行中的请求切换到已激活的网络，避免请求失败或响应延迟。示例写法如下：

import { http } from '@kit.NetworkKit';
import { BusinessError } from '@kit.BasicServicesKit';

let httpRequest = http.createHttp();
httpRequest.request(
  "EXAMPLE_URL", (err: BusinessError, data: http.HttpResponse) => {
    if (!err) {
      console.info('Result:' + JSON.stringify(data.result));
      httpRequest.destroy();
    } else {
      console.error('error:' + JSON.stringify(err));
      httpRequest.destroy();
    }
  }
);

需要注意的是，每一个 httpRequest 对应一个独立的 HTTP 请求任务，不可复用。请求完成后应调用 destroy() 方法主动销毁。

4.2 网络波动：实时感知质量，动态调整策略

地铁穿行、高速公路驾驶等场景中，信号强度快速变化，带宽可能从 50Mbps 骤降到 1Mbps，RTT 波动超过 300%，并伴随短时丢包。

应对这类场景的关键在于实时感知网络质量的变化，动态调整请求行为，具体有两个方向：

第一，订阅网络质量变化事件。 通过 Network Boost Kit 的 netQosChange 事件，可以实时获取当前数据链路的上下行带宽等信息，据此判断网络质量并调整请求策略：

import { netQuality } from '@kit.NetworkBoostKit';
import { BusinessError } from '@kit.BasicServicesKit';

try {
  netQuality.on('netQosChange', (list: Array<netQuality.NetworkQos>) => {
    if (list.length > 0) {
      list.forEach((qos) => {
        console.info(`上行带宽: ${JSON.stringify(qos.linkUpBandwidth)}`);
        console.info(`下行带宽: ${JSON.stringify(qos.linkDownBandwidth)}`);
        // 根据带宽信息调整请求策略
      });
    }
  });
} catch (err) {
  console.error('errCode: ' + (err as BusinessError).code +
    ', errMessage: ' + (err as BusinessError).message);
}

第二，在网络质量好时进行预取。 趁网络状态良好，提前发送后续可能产生的请求，缓存获取的资源。等真正需要这些资源时直接加载缓存，从而规避网络恶化带来的卡顿。可以借助 Remote Communication Kit 实现预取逻辑：

import { rcp } from '@kit.RemoteCommunicationKit';
import { HashMap } from "@kit.ArkTS";

export class PrefetchingRcp {
  private session = rcp.createSession();
  private responsePrefetched: HashMap<string, rcp.Response> = new HashMap();

  public async prefetch(url: string) {
    const request = new rcp.Request(url);
    try {
      let response: rcp.Response = await this.session.fetch(request);
      this.responsePrefetched.set(url, response);
      return Promise.resolve();
    } catch (reason) {
      console.error(`Rcp prefetch failed: ${reason.code}`);
      return Promise.reject();
    }
  }
}

在网络质量差时，则应反过来降低请求频率和请求数据量，避免加剧网络拥塞。

4.3 网络质量差：识别拥塞场景，主动降级

在地下停车场、拥挤的食堂这类场景中，网络呈现持续低带宽（<1Mbps）、高延迟（>100ms）和高丢包率的特征。

除了通过上述 netQosChange 判断网络质量外，Network Boost Kit 还提供了网络场景识别事件 netSceneChange，可以直接检测网络拥塞或信号差的状态。这让应用能够更精准地判断当前处于何种网络环境，并做出相应处理——检测到拥塞时减少请求，恢复正常后恢复请求频率：

import { netQuality } from '@kit.NetworkBoostKit';
import { BusinessError } from '@kit.BasicServicesKit';

try {
  netQuality.on('netSceneChange', (list: Array<netQuality.NetworkScene>) => {
    if (list.length > 0) {
      list.forEach((sceneInfo) => {
        if (sceneInfo.scene == 'congestion') {
          // 网络拥塞，减少请求频率
        }
        if (sceneInfo.scene == 'normal') {
          // 拥塞解除，恢复正常请求
        }
        if (sceneInfo.weakSignalPrediction) {
          // 弱信号预测：网络质量即将变差，提前应对
        }
      });
    }
  });
} catch (err) {
  console.error('errCode: ' + (err as BusinessError).code +
    ', errMessage: ' + (err as BusinessError).message);
}

值得关注的是 weakSignalPrediction 这个字段——它提供的是弱信号预测能力，让应用能够在网络质量实际变差之前就提前做好准备，这对用户体验的提升是非常有价值的。

五、关于数据收集

使用网络领航员时，需要注意以下数据收集事项：

• 使用前需要关联华为账号，选择打开”关联体验改进计划”开关即表示同意上传使用日志；
• 会收集应用的 bundle name 及版本号；
• 会收集使用的网络模拟场景及对应时间；
• 华为可能通过账号对应的联系方式进行使用回访。

六、总结

网络领航员为鸿蒙开发者提供了一种低成本、可控、可重复的网络场景测试手段。它的价值不仅在于模拟本身，更在于围绕模拟场景形成了”发现问题 → 理解问题 → 解决问题”的完整闭环：

1. 发现问题：通过 8 种预置场景和自定义场景，覆盖网络切换、网络波动、网络质量差三类典型网络特征，在可控条件下暴露应用的网络兼容性问题。
2. 理解问题：通过实况窗实时观察网络状态变化，结合每个场景细致的阶段划分和参数设计，准确定位问题出现的时机和条件。
3. 解决问题：结合 Network Kit 的智能多网切换、Network Boost Kit 的网络质量感知和场景识别能力，以及预取缓存等策略，针对性地优化应用的网络处理逻辑。

对于希望进一步提升应用网络体验的开发者，建议从与自身业务最相关的场景入手——如果你的应用主要在通勤场景中使用，重点关注地铁和电梯场景；如果是室内场景居多，则侧重食堂和停车场场景的测试。在验证基本表现后，逐步接入 Network Boost Kit 的事件订阅机制，实现更精细的网络自适应策略。