搞无线性能这块也有七八年了平时最常被问到的问题就是我这 Wi-Fi 信号到底好不好蓝牙怎么老断连其实“好不好”这件事光靠感觉是不行的必须有数据支撑。这篇就完整梳理一下在 Ubuntu 系统上测试 Wi-Fi、蓝牙性能的整套思路和实操方法从环境准备、工具选型到参数解读、踩坑排查一次说透。1. 测试前的环境准备与设备识别1.1 先搞清楚你的无线硬件到底长什么样很多人一上来就装 iperf3、开 bluetoothctl结果发现工具全都正常就是找不到设备这时候八成是第一步就没做对——没确认硬件是否被系统正确识别。Linux 下查看无线网卡和蓝牙适配器最核心的命令是lspci和lsusb这两个命令一个管 PCIe 接口设备一个管 USB 总线设备。举个例子我手上这台测试机用的是 Intel AX210 网卡通过 PCIe 接口连接Wi-Fi 和蓝牙功能都在这张卡上。运行lspci | grep -i network输出里会出现类似“Network controller: Intel Corporation Wi-Fi 6 AX210”这行这就说明系统 PCIe 枚举阶段已经看到了网卡。如果用的是 USB 接口的无线网卡比如常见的 Ralink、Realtek 芯片方案那要用lsusb在输出列表里找带有“Wireless”、“Bluetooth”、“Network”字样的条目。这里有个容易被忽视的细节很多 USB 蓝牙适配器用的是 CSR 芯片比如 CSR8510 A10它的 USB Vendor ID 是 0x0A12如果你在lsusb输出里看到ID 0a12:0001 Cambridge Silicon Radio Ltd Bluetooth Dongle那基本可以确定是 CSR 方案。还有一个高频问题硬件在lspci/lsusb里能看到但系统功能列表里不显示。这时候十有八九是rfkill把无线功能锁住了。我遇到过好几次笔记本的飞行模式开关或者硬件无线开关导致 Wi-Fi 和蓝牙同时被 block。检查方法rfkill list如果看到Soft blocked: yes或Hard blocked: yes执行rfkill unblock all这个命令会解锁所有射频设备。注意这里有个坑如果网卡本身有硬件开关一般是笔记本侧面的物理开关或 Fn 组合键rfkill unblock是解不掉Hard blocked的必须手动拨动开关或者按 Fn 键。我最初调试一台老 ThinkPad 时就卡在这软件层面折腾半天结果发现是 FnF5 没开。1.2 确认驱动与系统识别状态确认硬件枚举成功之后第二步是确认驱动是否加载。Wi-Fi 驱动常用的查看命令是dmesg | grep -i wifi # 或者更精确地 dmesg | grep -i iwlwifiIntel 网卡对应的驱动模块是iwlwifiRealtek 网卡常见的是rtl8xxxu或rtw88/rtw89。如果dmesg里出现 “failed to load firmware” 之类的报错说明固件文件缺失或版本不匹配这种情况在网络热词里对应的就是 “Ubuntu 系统没有 Wi-Fi” 这类问题。蓝牙方面的驱动确认稍微麻烦一点。先看蓝牙服务是否在运行systemctl status bluetooth再检查蓝牙设备是否被 bluez 识别bluetoothctl list # 或者老一点的工具 hciconfig -a如果hciconfig输出为空而lsusb又能看到蓝牙适配器大概率是驱动与固件问题。常见的有Broadcom BCM 系列需要专有固件需要通过linux-firmware包安装Realtek 8821CE/8852BE 在部分内核版本上存在兼容性问题。这也就是为什么网上有大量“8852be 蓝牙”“ar5b22 蓝牙 4.0 驱动 win10”之类的搜索词——驱动问题确实是无线测试的第一道门槛。我在实际测试中会先跑一段“链路自检”脚本把上述信息一次性收集齐#!/bin/bash echo Network Hardware lspci | grep -i network lsusb | grep -i bluetooth echo Wi-Fi Interfaces iw dev echo Bluetooth Adapters bluetoothctl list echo RF Kill Status rfkill list echo Bluetooth Service systemctl is-active bluetooth这段脚本的输出基本就是整个测试环境的体检报告。后续所有测试如果出现异常先回看这份报告定位是硬件层、驱动层还是服务层的问题。1.3 测试环境的电磁与干扰控制无线性能测试最容易被忽略的就是环境因素而这恰恰是决定测试数据可重复性的关键。Wi-Fi 和蓝牙都工作在 2.4GHz 频段蓝牙甚至直接用 Wi-Fi 的 1、6、11 信道之间的空隙微波炉、USB 3.0 接口、隔壁的 AP、甚至是劣质电源适配器都会引入干扰直接影响测试结果。我自己的做法是正式测试前先做一次“频谱体检”。有条件的用频谱仪没条件就用iw dev wlan0 scan看看周围有多少个 AP 在抢信道再用iw dev wlan0 survey dump查看当前信道的忙闲比例。至少在测试前确认当前环境干扰可控或者确定在某个固定干扰水平下做对比测试。另外要特别注意两个频段的差异2.4GHz 穿墙好但干扰大实际吞吐经常被环境因素拉低5GHz 干扰小、吞吐高但衰减快隔一堵墙可能就少一半信号。所以测试结果一定要标注测试频段、信道、距离、环境遮挡情况否则数据完全无法参考。2. Wi-Fi 性能测试从信号强度到真实吞吐2.1 链路层指标信号强度与速率Wi-Fi 性能最直观的指标是 RSSIReceived Signal Strength Indicator和 PHY Rate物理层速率。在 Ubuntu 下用iw工具可以快速获取这两个值iw dev wlan0 link输出里的signal: -45 dBm就是当前信号强度tx bitrate: 866.7 MBit/s是当前实际协商的物理层速率。这里必须多说一句很多人只看信号格数实际上 “信号格数” 是驱动根据 RSSI 映射出来的不同厂商的映射算法完全不同完全没有可比性。只有 dBm 值才是可量化的标准。关于 dBm 数值我整理了一个经验参考表信号强度评价典型场景-30 ~ -50 dBm极好近距离无遮挡可跑满协商速率-50 ~ -60 dBm良好隔一堵墙吞吐稍有下降-60 ~ -70 dBm一般隔两堵墙速率可能掉档-70 ~ -80 dBm较差连接不稳定吞吐大幅下降低于 -80 dBm极差可能频繁断连基本不可用注意上面这个表只是经验值实际跟网卡灵敏度、天线增益、环境干扰都有关系。但方向性参考没问题。RSSI 是瞬时值会随着人体走动、门开关等微小变化波动。所以做链路测试时不要只看一秒钟的数据建议连续采样一段时间watch -n 1 iw dev wlan0 link | grep -E signal|bitrate用watch命令每秒刷新一次观察 30 秒以上看信号和速率的波动范围。如果波动超过 10 dBm说明环境不稳定测试数据要打问号。2.2 吞吐量测试iperf3 是无线性能的照妖镜链路层指标好不代表实际速度快。RSSI 和 PHY Rate 只是物理层协商出来的上限真实的用户体感要靠 TCP/UDP 吞吐来验证这就轮到 iperf3 上场了。iperf3 采用 C/S 架构。假设我有两台机器A 是 Ubuntu 测试机Wi-Fi 连接B 是千兆有线连接的服务器在 B 上启动服务端iperf3 -s在 A 上运行客户端测 TCP 下行iperf3 -c 192.168.1.100 -t 30 -i 5参数解释-t 30表示测试时长 30 秒-i 5表示每 5 秒打印一次实时结果。30 秒是为了避免 TCP 慢启动阶段的干扰数据让吞吐跑到稳态。如果测 Wi-Fi 5 的 80MHz 频宽且信号良好866 Mbps 的 PHY Rate 下TCP 吞吐大概能跑到 600~700 MbpsWi-Fi 6 的 AX210 在 160MHz 频宽下吞吐能到 1.2~1.5 Gbps。但注意TCP 吞吐受协议开销、重传、拥塞控制等因素影响实际值一般是 PHY Rate 的 60%~80% 左右这是正常的。如果你测出来只有 PHY 速率的一两成那链路肯定有问题。UDP 测试更偏向带宽极限测试iperf3 -c 192.168.1.100 -u -b 800M -t 30-b 800M指定目标码率。UDP 测试会返回丢包率和抖动值这对判断链路质量非常有帮助。在无线链路上TCP 的速率下降往往是因为丢包触发拥塞控制而 UDP 测试能直接暴露底层丢包率。我习惯两个都测TCP 看实际可用带宽UDP 看链路本身的可靠度。这里还有一个实用技巧iperf3 可以测反向-R和双向--bidir。Wi-Fi 是半双工介质上行和下行性能可能有明显差异尤其是多天线方案中收发链路的差异。实际测试建议分别测上行、下行、双向各一轮。2.3 延迟与丢包测试ping 和 mtr 的正确用法吞吐再高如果延迟抖动大、丢包频繁用起来照样难受。延迟测试我用的是pingmtr的组合。快速测延迟ping -c 100 192.168.1.1看的是三个指标平均延迟、延迟抖动最大最小差、丢包率。在 Wi-Fi 情况下ping 延迟在 2-5ms 算优秀10ms 内算正常。如果出现超过 50ms 的延迟尖峰或者超过 1% 的丢包率链路多半有问题。mtr这个工具适合看路径上每一跳的质量mtr -rw 192.168.1.1 # 或者持续跟踪 mtr -r -c 100 192.168.1.1它能展示每一跳的丢包率和延迟帮你区分是无线链路的问题还是上游网络的问题。我最常用它来排查“Wi-Fi 打游戏为什么会卡顿”之类的场景——如果第一跳无线路由器就丢包说明问题出在无线连接本身如果第一跳正常、后面丢包那就要看核心网络了。延迟还有一个隐藏杀手Wi-Fi 省电模式。很多网卡默认开启省电会导致延迟周期性飙升。测试时最好先关闭省电sudo iw dev wlan0 set power_save off这个命令的效果立竿见影我实测关掉省电后延迟稳定性提升非常明显。顺带一提Ubuntu 的 NetworkManager 有时会在休眠后重新开启省电所以如果做长时间延迟监测记得在 NetworkManager 的配置文件里把wifi.powersave设为 2禁用。3. 蓝牙性能测试从连接稳定性到实际速率3.1 蓝牙协议栈基础与测试准备蓝牙测试比 Wi-Fi 复杂一些因为涉及两套完全不同的协议体系经典蓝牙BR/EDR和低功耗蓝牙BLE。经典蓝牙面向音频传输、文件传输这类持续数据流BLE 面向传感器、遥控器等低功耗间歇通信。在 Ubuntu 上这两者的测试工具和测试方法是完全不同的。蓝牙测试的统一入口是bluetoothctlbluez 提供的最核心管理工具。测试前的准备bluetoothctl # 进入交互模式后依次执行 power on scan onscan on开始扫描周围的蓝牙设备扫描结果会显示设备的 MAC 地址和名称。这里有个细节经典蓝牙和 BLE 的扫描模式不同。bluetoothctl scan on默认扫描双模设备对于 BLE 设备来说如果你希望看到广播包里的服务 UUID还需要额外的ble-scan或者用btmon抓 HCI 日志。我测试蓝牙的习惯是先确认本地适配器的能力btmgmt info输出里会显示manufacturer、version、supported settings等关键信息。对于测试来说最重要的是确认适配器支持的蓝牙版本——是 4.0、4.2、5.0 还是 5.2这直接决定了最大传输速率和功能特性比如 BLE 5.0 的 2M PHY 和长距离模式。3.2 经典蓝牙性能测试RSSI 与传输速率经典蓝牙的连接测试通常需要一个对端设备。以最常见的蓝牙音箱或 HC-05/HC-06 模块为例连接流程是bluetoothctl power on agent on default-agent scan on # 扫描到设备后记录 MAC 地址 pair 00:15:83:00:00:00 trust 00:15:83:00:00:00 connect 00:15:83:00:00:00连接成功后查看链路质量hcitool con hcitool rssi 00:15:83:00:00:00hcitool rssi输出的是 RSSI 值注意经典蓝牙的 RSSI 单位是 dBm 还是非标准计数不同芯片驱动结果含义有差异。实测时我更看重的是hcitool lqLink Quality链路质量取值为 0-255数值越高越好。如果能稳定保持在 200 以上说明链路状态不错低于 100 基本可以断定信道质量很差容易出现音频断断续续或者数据传输出错。传输速率测试方面经典蓝牙最常用的是通过 RFCOMM 建立串口服务然后走/dev/rfcomm0设备做数据吞吐测试。如果你的对端设备支持 SPP串口配置文件流程是# 先加载 rfcomm 模块 sudo modprobe rfcomm # 绑定设备到 rfcomm0 sudo rfcomm connect 0 00:15:83:00:00:00 1 # 最后参数 1 表示使用 channel 1 # 建立后 /dev/rfcomm0 就是串口设备 # 可以用 dd 或自写脚本测吞吐这里有一个实测经验经典蓝牙 2.0EDR 的理论速率是 3 Mbps但实际 SPP 传输吞吐能有 100-200 KB/s约 0.8-1.6 Mbps就算不错。因为蓝牙协议栈的各层都有额外开销加上 SPP 本身是面向串口的协议效率并不高。蓝牙 3.0 HS 和 4.x 的经典模式虽然理论速率高了很多但实际吞吐依然受限因为 HS 模式依赖额外的 Wi-Fi 承载AMP而 4.0 之后的产品大多默认走 BLE 通道。如果你测试的是 CSR 芯片模组比如 CSR8510 A10 蓝牙适配器配对 HC-05/HC-06 模块后出现连接不稳定的情况我遇到过的最大嫌疑是电源问题。蓝牙模块的射频部分对供电电压波动非常敏感3.3V 供电稍有跌落就会表现为 AT 指令无响应、连接频繁断开。这种情况下直接 USB 取电给 HC-05要求 3.3V往往不行最好用单独稳压模块供电并并联一个 10uF 以上的滤波电容。3.3 BLE 性能测试扫描、连接与广播测距BLE 测试是目前最常用的场景毕竟 ESP32、泰凌微、杰理这些 SoC 方案已经把 BLE 推到了各种智能硬件里。BLE 的核心测试指标有两个连接稳定性时延和掉线率和通信速率。BLE 连接交互的经典工具是gatttool虽然有点老但在脚本化和快速验证时非常方便# 扫描 BLE 设备 sudo hcitool lescan # 连接并交互 gatttool -b 00:AA:BB:CC:DD:EE -I # 进入交互模式后 connect primary char-read-hnd 0x000f如果hcitool lescan能扫描到设备但gatttool连接不上最常见的两个原因一是设备端连接参数过于严格连接间隔窗口太小二是本机蓝牙适配器的连接参数配置不合适。可以通过sudo btmgmt conn-info和btmon抓包进一步定位。BLE 速率测试不像经典蓝牙那样有现成的 SPP 通道通常的做法是测“通知”Notification的吞吐。也就是对端设备通过 GATT 的 Notify 属性连续上报数据本机统计接收速率。举例如果你在一块 ESP32 上配置了连续上报 20 字节的 Notify通过btmon抓 HCI 日志每秒钟收到的NumberOfCompletedPackets事件数量乘以单包字节数就能估算出实际吞吐。我实测的结果BLE 4.0 的 1M PHY连接间隔 7.5ms 时单连接实测吞吐大概能到 40-60 KbpsBLE 5.0 用 2M PHY 且连接间隔配置最优时单连接可以跑到 200 Kbps 以上。注意这是单连接的极限实际产品为了省电通常不会跑满常见的传感器上报场景在 1-10 Kbps 就够用了。BLE 还有一个火到不行的应用场景——蓝牙测距/定位。这就是基于 RSSI 的测距原理接收端通过 RSSI 值反向估算距离。2026 年的热搜词里 “蓝牙测距”“蓝牙水控器” 都和这个相关。在 Linux 下测试 BLE 设备的 RSSI 可以用sudo btmgmt find # 或者 sudo hcitool rssi 00:AA:BB:CC:DD:EE注意 BLE 的 RSSI 测距有一个关键问题室内多径效应导致 RSSI 波动剧烈单次采集的 RSSI 完全不可靠。工程上必须做滤波常见方案是取多次采样的滑动平均或者用卡尔曼滤波。这个在后续博文里我可以单独展开。3.4 蓝牙音频与其他常见功能验证蓝牙音频是消费产品里用得最多的场景但其性能测试和前面说的数据通道完全两码事。音频传输走的是 A2DP 或 SCO 通道测试的痛点在于“延迟”和“卡顿”。Ubuntu 下测 A2DP 播放延迟可以用pulseaudio的环回模式做近似评估。方法将蓝牙音箱设为默认输出录一段包含时间戳的音频再通过蓝牙音箱的录音回放如果支持的话比对延迟。不专业的做法是用手机秒表计时看声音和画面的延迟差。如果遇到 A2DP 切 SCO 模式的问题也就是蓝牙协议栈里经典蓝牙音频的两个通道来回切换通常在通话和音乐切换时会触发。实测中表现就是耳机连上后播放音乐正常一来电话出现“沙沙”声或者无声。这一般不是硬件问题而是 PCM 采样率和 SCO 链路协商的兼容性问题。在 Ubuntu 上可以通过配置/etc/bluetooth/main.conf里的[General]段调整# 强制使用 mSBC 编码宽频语音 EnableSource,Sink,Media,Socket # 在部分蓝牙 5.0 耳机上可以尝试提高 SCO 路由优先级 FastConnectable true音频延迟测试还有一个专业工具ble-heart-rate之类的就不展开了但 A2DP 延迟的体感参考是高质量蓝牙耳机在 aptX LL低延迟编码下延迟在 40ms 左右普通 SBC 编码在 100-200ms明显能感觉到音画不同步。4. 常见问题与排查技巧实录4.1 Ubuntu 没有 Wi-Fi 信号驱动与固件双排查“Ubuntu 系统没有 Wi-Fi” 这个话题在热搜里出现了极多次我几乎每周都会碰到一次。典型症状任务栏没有 Wi-Fi 图标ip addr下只有 lo 和有线网口iw dev输出为空。我的标准排查流程是# 第一步硬件是否被系统看到 lspci -k | grep -iA2 network # 如果这里显示 “Kernel driver in use: iwlwifi”说明驱动已加载 # 如果显示 “Kernel modules: iwlwifi”说明驱动存在但未加载 # 第二步设备是否被系统禁用 rfkill list # 第三步看驱动报错 dmesg | grep -i firmware dmesg | grep -i iwl根据这三步基本能定位 80% 的问题。最常见的原因内核默认没有加载对应固件或者固件文件被命名空间改动影响。解决办法是安装linux-firmwaresudo apt install linux-firmware sudo reboot如果是 Realtek 芯片很多新款的笔记本 Wi-Fi 6 网卡都是 Realtek 方案linux-firmware里可能缺少新版本固件。这时候需要确认网卡型号然后到 Realtek 开源驱动仓库拉取对应固件。比如 RTL8852BE需要将rtl8852befw.bin放到/lib/firmware/rtl_bt/目录下。4.2 蓝牙设备删不掉、连不上bluez 状态机的问题Windows 上“蓝牙设备删除不掉” 是高频搜索词Ubuntu 上也同样存在类似的粘连问题。Linux 下的典型场景蓝牙设备已经物理断电了但bluetoothctl devices里还挂着记录重新配对时提示 “Device already exists“。解决办法bluetoothctl # 先尝试删除设备 remove 00:AA:BB:CC:DD:EE # 如果提示失败直接删掉系统级别的设备存储文件 sudo rm /var/lib/bluetooth/XX:XX:XX:XX:XX:XX/cache/* sudo systemctl restart bluetooth另外HC-05/HC-06 这类模块“AT 无响应”是我见到的最多的模块类问题。AT 模式进不去九成是引脚时序问题。标准流程是按住模块上的按键或者把 EN/KEY 引脚拉高再上电让模块进入 AT 模式此时模块的指示灯慢闪1 秒一次再发 AT 指令。很多人失败是因为用了 USB 转 TTL 的板载 5V 供电——HC-05 的 RXD 不兼容 5V 电平TTL 板子的 TXD 输出 5V 电平会把模块打坏或导致通信异常。给 RXD 加个分压电阻1K 串联 2K 对地是稳妥做法。4.3 测试结果偏差大回看环境与配置的隐藏变量很多时候测试数据不稳定不是设备不行而是测试方法有漏洞。我踩过几个典型的坑第一个坑没有固定天线的位置和朝向。笔记本的 Wi-Fi 天线藏在屏幕边框里屏幕开合角度不同天线的极化方向就不同信号可能差 3-5 dB。所以我固定测试时笔记本放在固定支架上屏幕开合角度也固定。第二个坑没有关闭测试机的 Wi-Fi 漫游和自适应功能。NetworkManager 默认开启了 Wi-Fi 漫游某些场景下会自动切换到信号更好的 AP导致测试过程中数据出现断崖式变化。测试前在 NetworkManager 里关闭漫游nmcli connection modify 连接名 802-11-wireless.ap-random-mac-addressdisable nmcli connection modify 连接名 802-11-wireless.mac-address-randomizationdisable # 并将自动切换关闭 nmcli connection modify 连接名 connection.autoconnect no第三个坑蓝牙测试时没有考虑同频干扰。蓝牙和 Wi-Fi 都在 2.4GHz我测试蓝牙吞吐时 Wi-Fi 最好连 5GHz否则 Wi-Fi 的流量会严重抢占 2.4GHz 信道导致蓝牙数据严重丢失。这也是为什么很多蓝牙鼠标在 Wi-Fi 环境里发飘——2.4GHz 信道拥塞了。4.4 从测试线到量产常见调试组合拳最后聊一下从实验室测试到实际产品调试的场景。做嵌入式或者硬件的小伙伴经常会遇到这些热词里的问题HC-05 模块连不上、ESP32 蓝牙开发、杰理蓝牙烧录、均匀显示方案蓝牙像素屏、蓝牙台秤校准、蓝牙水控器调试等等。其实这些表面不同的场景底层逃不出几个核心测试点场景主要验证项常用工具HC-05/06 模块AT 指令链路、SPP 数据通道串口工具 hcitoolESP32 BLE 连接GATT 服务、Notify 速率gatttool / btmon杰理/泰凌微模组固件烧录、广播参数专用烧录器 hcitool lescan蓝牙台秤称重数据传输、连接稳定性手机端 App hcitool蓝牙像素屏广播解析、图片传输吞吐gatttool / nRF Connect我的建议是所有测试都尽量从终端命令行工具开始先把协议层的连通性和稳定性验证完再上应用层 UI 测试。因为命令行工具能直观暴露协议层的问题避免应用层包装掩盖真实故障点。拿 ESP32 BLE 开发举例很多人上来就用手机 App 调试连不上就一脸懵。但如果用sudo hcitool lescan能看到广播再用gatttool -b XX:XX -I能连上就说明 ESP32 的 BLE 协议栈工作正常问题指向手机 App 的兼容性——比如 iOS 对蓝牙权限的限制、Android 对 BLE 扫描的过滤参数等等。这个排查思路能帮你快速划分问题范围节省大量时间。5. 一个完整的测试流程模板与自检清单为了方便直接上手我整理了一份在实际项目中反复使用的测试流程。准备两台设备一台 Ubuntu 测试机被测设备Wi-Fi/蓝牙在这台机器上一台有线网络服务器对端设备。第一步环境准备。确认硬件识别、驱动加载、rfkill 解锁关闭省电模式固定天线方向和位置。第二步Wi-Fi 链路层测试。iw dev wlan0 link记录 RSSI、PHY Rate、信道、频宽持续观察 30 秒记录波动范围。第三步Wi-Fi 延迟与丢包测试。ping -c 100对网关进行测试记录平均延迟、抖动、丢包率。异常时用mtr定位问题点。第四步Wi-Fi 吞吐测试。iperf3 分别测 TCP 下行、上行、双向各 30 秒取三次结果的中位数。第五步蓝牙链路检查。bluetoothctl配对被设备hcitool lq和hcitool rssi检查链路质量。第六步蓝牙数据传输测试。经典蓝牙用 RFCOMM 通道 dd或串口工具测吞吐BLE 用 GATT Notify/Write 测实际速率结合btmon抓 HCI 日志确认数据包速率。第七步稳定性长测。Wi-Fi 用 iperf3 持续压测 30 分钟蓝牙用长时间数据流测试记录掉线时间和次数。第八步数据整理。所有数据填写到统一的测试表格注明环境参数信道、距离、遮挡、温度、是否开启省电便于组间比较和问题追溯。这套流程跑下来基本能覆盖 Wi-Fi 蓝牙性能测试的大部分场景。做产品测试或者帮朋友排查无线问题都可以直接拿来套用。这几年的实际经验让我最大的体会是无线性能测试与其说是在测设备不如说是在测环境和方法是否可控。同样的设备换个房间数据就可能差一半同样的数据用的测试工具不同解读也可能完全不同。掌握了标准化的测试流程再回头去看那些“Wi-Fi 慢”“蓝牙断”的问题你会发现大部分问题的根源其实是信道干扰、供电不稳定、驱动版本不匹配或者测试方法不严谨。先解决这些基础问题再谈性能指标这才是无线调试的正道。
Ubuntu 无线性能测试实战：Wi-Fi 与蓝牙全流程指南
搞无线性能这块也有七八年了平时最常被问到的问题就是我这 Wi-Fi 信号到底好不好蓝牙怎么老断连其实“好不好”这件事光靠感觉是不行的必须有数据支撑。这篇就完整梳理一下在 Ubuntu 系统上测试 Wi-Fi、蓝牙性能的整套思路和实操方法从环境准备、工具选型到参数解读、踩坑排查一次说透。1. 测试前的环境准备与设备识别1.1 先搞清楚你的无线硬件到底长什么样很多人一上来就装 iperf3、开 bluetoothctl结果发现工具全都正常就是找不到设备这时候八成是第一步就没做对——没确认硬件是否被系统正确识别。Linux 下查看无线网卡和蓝牙适配器最核心的命令是lspci和lsusb这两个命令一个管 PCIe 接口设备一个管 USB 总线设备。举个例子我手上这台测试机用的是 Intel AX210 网卡通过 PCIe 接口连接Wi-Fi 和蓝牙功能都在这张卡上。运行lspci | grep -i network输出里会出现类似“Network controller: Intel Corporation Wi-Fi 6 AX210”这行这就说明系统 PCIe 枚举阶段已经看到了网卡。如果用的是 USB 接口的无线网卡比如常见的 Ralink、Realtek 芯片方案那要用lsusb在输出列表里找带有“Wireless”、“Bluetooth”、“Network”字样的条目。这里有个容易被忽视的细节很多 USB 蓝牙适配器用的是 CSR 芯片比如 CSR8510 A10它的 USB Vendor ID 是 0x0A12如果你在lsusb输出里看到ID 0a12:0001 Cambridge Silicon Radio Ltd Bluetooth Dongle那基本可以确定是 CSR 方案。还有一个高频问题硬件在lspci/lsusb里能看到但系统功能列表里不显示。这时候十有八九是rfkill把无线功能锁住了。我遇到过好几次笔记本的飞行模式开关或者硬件无线开关导致 Wi-Fi 和蓝牙同时被 block。检查方法rfkill list如果看到Soft blocked: yes或Hard blocked: yes执行rfkill unblock all这个命令会解锁所有射频设备。注意这里有个坑如果网卡本身有硬件开关一般是笔记本侧面的物理开关或 Fn 组合键rfkill unblock是解不掉Hard blocked的必须手动拨动开关或者按 Fn 键。我最初调试一台老 ThinkPad 时就卡在这软件层面折腾半天结果发现是 FnF5 没开。1.2 确认驱动与系统识别状态确认硬件枚举成功之后第二步是确认驱动是否加载。Wi-Fi 驱动常用的查看命令是dmesg | grep -i wifi # 或者更精确地 dmesg | grep -i iwlwifiIntel 网卡对应的驱动模块是iwlwifiRealtek 网卡常见的是rtl8xxxu或rtw88/rtw89。如果dmesg里出现 “failed to load firmware” 之类的报错说明固件文件缺失或版本不匹配这种情况在网络热词里对应的就是 “Ubuntu 系统没有 Wi-Fi” 这类问题。蓝牙方面的驱动确认稍微麻烦一点。先看蓝牙服务是否在运行systemctl status bluetooth再检查蓝牙设备是否被 bluez 识别bluetoothctl list # 或者老一点的工具 hciconfig -a如果hciconfig输出为空而lsusb又能看到蓝牙适配器大概率是驱动与固件问题。常见的有Broadcom BCM 系列需要专有固件需要通过linux-firmware包安装Realtek 8821CE/8852BE 在部分内核版本上存在兼容性问题。这也就是为什么网上有大量“8852be 蓝牙”“ar5b22 蓝牙 4.0 驱动 win10”之类的搜索词——驱动问题确实是无线测试的第一道门槛。我在实际测试中会先跑一段“链路自检”脚本把上述信息一次性收集齐#!/bin/bash echo Network Hardware lspci | grep -i network lsusb | grep -i bluetooth echo Wi-Fi Interfaces iw dev echo Bluetooth Adapters bluetoothctl list echo RF Kill Status rfkill list echo Bluetooth Service systemctl is-active bluetooth这段脚本的输出基本就是整个测试环境的体检报告。后续所有测试如果出现异常先回看这份报告定位是硬件层、驱动层还是服务层的问题。1.3 测试环境的电磁与干扰控制无线性能测试最容易被忽略的就是环境因素而这恰恰是决定测试数据可重复性的关键。Wi-Fi 和蓝牙都工作在 2.4GHz 频段蓝牙甚至直接用 Wi-Fi 的 1、6、11 信道之间的空隙微波炉、USB 3.0 接口、隔壁的 AP、甚至是劣质电源适配器都会引入干扰直接影响测试结果。我自己的做法是正式测试前先做一次“频谱体检”。有条件的用频谱仪没条件就用iw dev wlan0 scan看看周围有多少个 AP 在抢信道再用iw dev wlan0 survey dump查看当前信道的忙闲比例。至少在测试前确认当前环境干扰可控或者确定在某个固定干扰水平下做对比测试。另外要特别注意两个频段的差异2.4GHz 穿墙好但干扰大实际吞吐经常被环境因素拉低5GHz 干扰小、吞吐高但衰减快隔一堵墙可能就少一半信号。所以测试结果一定要标注测试频段、信道、距离、环境遮挡情况否则数据完全无法参考。2. Wi-Fi 性能测试从信号强度到真实吞吐2.1 链路层指标信号强度与速率Wi-Fi 性能最直观的指标是 RSSIReceived Signal Strength Indicator和 PHY Rate物理层速率。在 Ubuntu 下用iw工具可以快速获取这两个值iw dev wlan0 link输出里的signal: -45 dBm就是当前信号强度tx bitrate: 866.7 MBit/s是当前实际协商的物理层速率。这里必须多说一句很多人只看信号格数实际上 “信号格数” 是驱动根据 RSSI 映射出来的不同厂商的映射算法完全不同完全没有可比性。只有 dBm 值才是可量化的标准。关于 dBm 数值我整理了一个经验参考表信号强度评价典型场景-30 ~ -50 dBm极好近距离无遮挡可跑满协商速率-50 ~ -60 dBm良好隔一堵墙吞吐稍有下降-60 ~ -70 dBm一般隔两堵墙速率可能掉档-70 ~ -80 dBm较差连接不稳定吞吐大幅下降低于 -80 dBm极差可能频繁断连基本不可用注意上面这个表只是经验值实际跟网卡灵敏度、天线增益、环境干扰都有关系。但方向性参考没问题。RSSI 是瞬时值会随着人体走动、门开关等微小变化波动。所以做链路测试时不要只看一秒钟的数据建议连续采样一段时间watch -n 1 iw dev wlan0 link | grep -E signal|bitrate用watch命令每秒刷新一次观察 30 秒以上看信号和速率的波动范围。如果波动超过 10 dBm说明环境不稳定测试数据要打问号。2.2 吞吐量测试iperf3 是无线性能的照妖镜链路层指标好不代表实际速度快。RSSI 和 PHY Rate 只是物理层协商出来的上限真实的用户体感要靠 TCP/UDP 吞吐来验证这就轮到 iperf3 上场了。iperf3 采用 C/S 架构。假设我有两台机器A 是 Ubuntu 测试机Wi-Fi 连接B 是千兆有线连接的服务器在 B 上启动服务端iperf3 -s在 A 上运行客户端测 TCP 下行iperf3 -c 192.168.1.100 -t 30 -i 5参数解释-t 30表示测试时长 30 秒-i 5表示每 5 秒打印一次实时结果。30 秒是为了避免 TCP 慢启动阶段的干扰数据让吞吐跑到稳态。如果测 Wi-Fi 5 的 80MHz 频宽且信号良好866 Mbps 的 PHY Rate 下TCP 吞吐大概能跑到 600~700 MbpsWi-Fi 6 的 AX210 在 160MHz 频宽下吞吐能到 1.2~1.5 Gbps。但注意TCP 吞吐受协议开销、重传、拥塞控制等因素影响实际值一般是 PHY Rate 的 60%~80% 左右这是正常的。如果你测出来只有 PHY 速率的一两成那链路肯定有问题。UDP 测试更偏向带宽极限测试iperf3 -c 192.168.1.100 -u -b 800M -t 30-b 800M指定目标码率。UDP 测试会返回丢包率和抖动值这对判断链路质量非常有帮助。在无线链路上TCP 的速率下降往往是因为丢包触发拥塞控制而 UDP 测试能直接暴露底层丢包率。我习惯两个都测TCP 看实际可用带宽UDP 看链路本身的可靠度。这里还有一个实用技巧iperf3 可以测反向-R和双向--bidir。Wi-Fi 是半双工介质上行和下行性能可能有明显差异尤其是多天线方案中收发链路的差异。实际测试建议分别测上行、下行、双向各一轮。2.3 延迟与丢包测试ping 和 mtr 的正确用法吞吐再高如果延迟抖动大、丢包频繁用起来照样难受。延迟测试我用的是pingmtr的组合。快速测延迟ping -c 100 192.168.1.1看的是三个指标平均延迟、延迟抖动最大最小差、丢包率。在 Wi-Fi 情况下ping 延迟在 2-5ms 算优秀10ms 内算正常。如果出现超过 50ms 的延迟尖峰或者超过 1% 的丢包率链路多半有问题。mtr这个工具适合看路径上每一跳的质量mtr -rw 192.168.1.1 # 或者持续跟踪 mtr -r -c 100 192.168.1.1它能展示每一跳的丢包率和延迟帮你区分是无线链路的问题还是上游网络的问题。我最常用它来排查“Wi-Fi 打游戏为什么会卡顿”之类的场景——如果第一跳无线路由器就丢包说明问题出在无线连接本身如果第一跳正常、后面丢包那就要看核心网络了。延迟还有一个隐藏杀手Wi-Fi 省电模式。很多网卡默认开启省电会导致延迟周期性飙升。测试时最好先关闭省电sudo iw dev wlan0 set power_save off这个命令的效果立竿见影我实测关掉省电后延迟稳定性提升非常明显。顺带一提Ubuntu 的 NetworkManager 有时会在休眠后重新开启省电所以如果做长时间延迟监测记得在 NetworkManager 的配置文件里把wifi.powersave设为 2禁用。3. 蓝牙性能测试从连接稳定性到实际速率3.1 蓝牙协议栈基础与测试准备蓝牙测试比 Wi-Fi 复杂一些因为涉及两套完全不同的协议体系经典蓝牙BR/EDR和低功耗蓝牙BLE。经典蓝牙面向音频传输、文件传输这类持续数据流BLE 面向传感器、遥控器等低功耗间歇通信。在 Ubuntu 上这两者的测试工具和测试方法是完全不同的。蓝牙测试的统一入口是bluetoothctlbluez 提供的最核心管理工具。测试前的准备bluetoothctl # 进入交互模式后依次执行 power on scan onscan on开始扫描周围的蓝牙设备扫描结果会显示设备的 MAC 地址和名称。这里有个细节经典蓝牙和 BLE 的扫描模式不同。bluetoothctl scan on默认扫描双模设备对于 BLE 设备来说如果你希望看到广播包里的服务 UUID还需要额外的ble-scan或者用btmon抓 HCI 日志。我测试蓝牙的习惯是先确认本地适配器的能力btmgmt info输出里会显示manufacturer、version、supported settings等关键信息。对于测试来说最重要的是确认适配器支持的蓝牙版本——是 4.0、4.2、5.0 还是 5.2这直接决定了最大传输速率和功能特性比如 BLE 5.0 的 2M PHY 和长距离模式。3.2 经典蓝牙性能测试RSSI 与传输速率经典蓝牙的连接测试通常需要一个对端设备。以最常见的蓝牙音箱或 HC-05/HC-06 模块为例连接流程是bluetoothctl power on agent on default-agent scan on # 扫描到设备后记录 MAC 地址 pair 00:15:83:00:00:00 trust 00:15:83:00:00:00 connect 00:15:83:00:00:00连接成功后查看链路质量hcitool con hcitool rssi 00:15:83:00:00:00hcitool rssi输出的是 RSSI 值注意经典蓝牙的 RSSI 单位是 dBm 还是非标准计数不同芯片驱动结果含义有差异。实测时我更看重的是hcitool lqLink Quality链路质量取值为 0-255数值越高越好。如果能稳定保持在 200 以上说明链路状态不错低于 100 基本可以断定信道质量很差容易出现音频断断续续或者数据传输出错。传输速率测试方面经典蓝牙最常用的是通过 RFCOMM 建立串口服务然后走/dev/rfcomm0设备做数据吞吐测试。如果你的对端设备支持 SPP串口配置文件流程是# 先加载 rfcomm 模块 sudo modprobe rfcomm # 绑定设备到 rfcomm0 sudo rfcomm connect 0 00:15:83:00:00:00 1 # 最后参数 1 表示使用 channel 1 # 建立后 /dev/rfcomm0 就是串口设备 # 可以用 dd 或自写脚本测吞吐这里有一个实测经验经典蓝牙 2.0EDR 的理论速率是 3 Mbps但实际 SPP 传输吞吐能有 100-200 KB/s约 0.8-1.6 Mbps就算不错。因为蓝牙协议栈的各层都有额外开销加上 SPP 本身是面向串口的协议效率并不高。蓝牙 3.0 HS 和 4.x 的经典模式虽然理论速率高了很多但实际吞吐依然受限因为 HS 模式依赖额外的 Wi-Fi 承载AMP而 4.0 之后的产品大多默认走 BLE 通道。如果你测试的是 CSR 芯片模组比如 CSR8510 A10 蓝牙适配器配对 HC-05/HC-06 模块后出现连接不稳定的情况我遇到过的最大嫌疑是电源问题。蓝牙模块的射频部分对供电电压波动非常敏感3.3V 供电稍有跌落就会表现为 AT 指令无响应、连接频繁断开。这种情况下直接 USB 取电给 HC-05要求 3.3V往往不行最好用单独稳压模块供电并并联一个 10uF 以上的滤波电容。3.3 BLE 性能测试扫描、连接与广播测距BLE 测试是目前最常用的场景毕竟 ESP32、泰凌微、杰理这些 SoC 方案已经把 BLE 推到了各种智能硬件里。BLE 的核心测试指标有两个连接稳定性时延和掉线率和通信速率。BLE 连接交互的经典工具是gatttool虽然有点老但在脚本化和快速验证时非常方便# 扫描 BLE 设备 sudo hcitool lescan # 连接并交互 gatttool -b 00:AA:BB:CC:DD:EE -I # 进入交互模式后 connect primary char-read-hnd 0x000f如果hcitool lescan能扫描到设备但gatttool连接不上最常见的两个原因一是设备端连接参数过于严格连接间隔窗口太小二是本机蓝牙适配器的连接参数配置不合适。可以通过sudo btmgmt conn-info和btmon抓包进一步定位。BLE 速率测试不像经典蓝牙那样有现成的 SPP 通道通常的做法是测“通知”Notification的吞吐。也就是对端设备通过 GATT 的 Notify 属性连续上报数据本机统计接收速率。举例如果你在一块 ESP32 上配置了连续上报 20 字节的 Notify通过btmon抓 HCI 日志每秒钟收到的NumberOfCompletedPackets事件数量乘以单包字节数就能估算出实际吞吐。我实测的结果BLE 4.0 的 1M PHY连接间隔 7.5ms 时单连接实测吞吐大概能到 40-60 KbpsBLE 5.0 用 2M PHY 且连接间隔配置最优时单连接可以跑到 200 Kbps 以上。注意这是单连接的极限实际产品为了省电通常不会跑满常见的传感器上报场景在 1-10 Kbps 就够用了。BLE 还有一个火到不行的应用场景——蓝牙测距/定位。这就是基于 RSSI 的测距原理接收端通过 RSSI 值反向估算距离。2026 年的热搜词里 “蓝牙测距”“蓝牙水控器” 都和这个相关。在 Linux 下测试 BLE 设备的 RSSI 可以用sudo btmgmt find # 或者 sudo hcitool rssi 00:AA:BB:CC:DD:EE注意 BLE 的 RSSI 测距有一个关键问题室内多径效应导致 RSSI 波动剧烈单次采集的 RSSI 完全不可靠。工程上必须做滤波常见方案是取多次采样的滑动平均或者用卡尔曼滤波。这个在后续博文里我可以单独展开。3.4 蓝牙音频与其他常见功能验证蓝牙音频是消费产品里用得最多的场景但其性能测试和前面说的数据通道完全两码事。音频传输走的是 A2DP 或 SCO 通道测试的痛点在于“延迟”和“卡顿”。Ubuntu 下测 A2DP 播放延迟可以用pulseaudio的环回模式做近似评估。方法将蓝牙音箱设为默认输出录一段包含时间戳的音频再通过蓝牙音箱的录音回放如果支持的话比对延迟。不专业的做法是用手机秒表计时看声音和画面的延迟差。如果遇到 A2DP 切 SCO 模式的问题也就是蓝牙协议栈里经典蓝牙音频的两个通道来回切换通常在通话和音乐切换时会触发。实测中表现就是耳机连上后播放音乐正常一来电话出现“沙沙”声或者无声。这一般不是硬件问题而是 PCM 采样率和 SCO 链路协商的兼容性问题。在 Ubuntu 上可以通过配置/etc/bluetooth/main.conf里的[General]段调整# 强制使用 mSBC 编码宽频语音 EnableSource,Sink,Media,Socket # 在部分蓝牙 5.0 耳机上可以尝试提高 SCO 路由优先级 FastConnectable true音频延迟测试还有一个专业工具ble-heart-rate之类的就不展开了但 A2DP 延迟的体感参考是高质量蓝牙耳机在 aptX LL低延迟编码下延迟在 40ms 左右普通 SBC 编码在 100-200ms明显能感觉到音画不同步。4. 常见问题与排查技巧实录4.1 Ubuntu 没有 Wi-Fi 信号驱动与固件双排查“Ubuntu 系统没有 Wi-Fi” 这个话题在热搜里出现了极多次我几乎每周都会碰到一次。典型症状任务栏没有 Wi-Fi 图标ip addr下只有 lo 和有线网口iw dev输出为空。我的标准排查流程是# 第一步硬件是否被系统看到 lspci -k | grep -iA2 network # 如果这里显示 “Kernel driver in use: iwlwifi”说明驱动已加载 # 如果显示 “Kernel modules: iwlwifi”说明驱动存在但未加载 # 第二步设备是否被系统禁用 rfkill list # 第三步看驱动报错 dmesg | grep -i firmware dmesg | grep -i iwl根据这三步基本能定位 80% 的问题。最常见的原因内核默认没有加载对应固件或者固件文件被命名空间改动影响。解决办法是安装linux-firmwaresudo apt install linux-firmware sudo reboot如果是 Realtek 芯片很多新款的笔记本 Wi-Fi 6 网卡都是 Realtek 方案linux-firmware里可能缺少新版本固件。这时候需要确认网卡型号然后到 Realtek 开源驱动仓库拉取对应固件。比如 RTL8852BE需要将rtl8852befw.bin放到/lib/firmware/rtl_bt/目录下。4.2 蓝牙设备删不掉、连不上bluez 状态机的问题Windows 上“蓝牙设备删除不掉” 是高频搜索词Ubuntu 上也同样存在类似的粘连问题。Linux 下的典型场景蓝牙设备已经物理断电了但bluetoothctl devices里还挂着记录重新配对时提示 “Device already exists“。解决办法bluetoothctl # 先尝试删除设备 remove 00:AA:BB:CC:DD:EE # 如果提示失败直接删掉系统级别的设备存储文件 sudo rm /var/lib/bluetooth/XX:XX:XX:XX:XX:XX/cache/* sudo systemctl restart bluetooth另外HC-05/HC-06 这类模块“AT 无响应”是我见到的最多的模块类问题。AT 模式进不去九成是引脚时序问题。标准流程是按住模块上的按键或者把 EN/KEY 引脚拉高再上电让模块进入 AT 模式此时模块的指示灯慢闪1 秒一次再发 AT 指令。很多人失败是因为用了 USB 转 TTL 的板载 5V 供电——HC-05 的 RXD 不兼容 5V 电平TTL 板子的 TXD 输出 5V 电平会把模块打坏或导致通信异常。给 RXD 加个分压电阻1K 串联 2K 对地是稳妥做法。4.3 测试结果偏差大回看环境与配置的隐藏变量很多时候测试数据不稳定不是设备不行而是测试方法有漏洞。我踩过几个典型的坑第一个坑没有固定天线的位置和朝向。笔记本的 Wi-Fi 天线藏在屏幕边框里屏幕开合角度不同天线的极化方向就不同信号可能差 3-5 dB。所以我固定测试时笔记本放在固定支架上屏幕开合角度也固定。第二个坑没有关闭测试机的 Wi-Fi 漫游和自适应功能。NetworkManager 默认开启了 Wi-Fi 漫游某些场景下会自动切换到信号更好的 AP导致测试过程中数据出现断崖式变化。测试前在 NetworkManager 里关闭漫游nmcli connection modify 连接名 802-11-wireless.ap-random-mac-addressdisable nmcli connection modify 连接名 802-11-wireless.mac-address-randomizationdisable # 并将自动切换关闭 nmcli connection modify 连接名 connection.autoconnect no第三个坑蓝牙测试时没有考虑同频干扰。蓝牙和 Wi-Fi 都在 2.4GHz我测试蓝牙吞吐时 Wi-Fi 最好连 5GHz否则 Wi-Fi 的流量会严重抢占 2.4GHz 信道导致蓝牙数据严重丢失。这也是为什么很多蓝牙鼠标在 Wi-Fi 环境里发飘——2.4GHz 信道拥塞了。4.4 从测试线到量产常见调试组合拳最后聊一下从实验室测试到实际产品调试的场景。做嵌入式或者硬件的小伙伴经常会遇到这些热词里的问题HC-05 模块连不上、ESP32 蓝牙开发、杰理蓝牙烧录、均匀显示方案蓝牙像素屏、蓝牙台秤校准、蓝牙水控器调试等等。其实这些表面不同的场景底层逃不出几个核心测试点场景主要验证项常用工具HC-05/06 模块AT 指令链路、SPP 数据通道串口工具 hcitoolESP32 BLE 连接GATT 服务、Notify 速率gatttool / btmon杰理/泰凌微模组固件烧录、广播参数专用烧录器 hcitool lescan蓝牙台秤称重数据传输、连接稳定性手机端 App hcitool蓝牙像素屏广播解析、图片传输吞吐gatttool / nRF Connect我的建议是所有测试都尽量从终端命令行工具开始先把协议层的连通性和稳定性验证完再上应用层 UI 测试。因为命令行工具能直观暴露协议层的问题避免应用层包装掩盖真实故障点。拿 ESP32 BLE 开发举例很多人上来就用手机 App 调试连不上就一脸懵。但如果用sudo hcitool lescan能看到广播再用gatttool -b XX:XX -I能连上就说明 ESP32 的 BLE 协议栈工作正常问题指向手机 App 的兼容性——比如 iOS 对蓝牙权限的限制、Android 对 BLE 扫描的过滤参数等等。这个排查思路能帮你快速划分问题范围节省大量时间。5. 一个完整的测试流程模板与自检清单为了方便直接上手我整理了一份在实际项目中反复使用的测试流程。准备两台设备一台 Ubuntu 测试机被测设备Wi-Fi/蓝牙在这台机器上一台有线网络服务器对端设备。第一步环境准备。确认硬件识别、驱动加载、rfkill 解锁关闭省电模式固定天线方向和位置。第二步Wi-Fi 链路层测试。iw dev wlan0 link记录 RSSI、PHY Rate、信道、频宽持续观察 30 秒记录波动范围。第三步Wi-Fi 延迟与丢包测试。ping -c 100对网关进行测试记录平均延迟、抖动、丢包率。异常时用mtr定位问题点。第四步Wi-Fi 吞吐测试。iperf3 分别测 TCP 下行、上行、双向各 30 秒取三次结果的中位数。第五步蓝牙链路检查。bluetoothctl配对被设备hcitool lq和hcitool rssi检查链路质量。第六步蓝牙数据传输测试。经典蓝牙用 RFCOMM 通道 dd或串口工具测吞吐BLE 用 GATT Notify/Write 测实际速率结合btmon抓 HCI 日志确认数据包速率。第七步稳定性长测。Wi-Fi 用 iperf3 持续压测 30 分钟蓝牙用长时间数据流测试记录掉线时间和次数。第八步数据整理。所有数据填写到统一的测试表格注明环境参数信道、距离、遮挡、温度、是否开启省电便于组间比较和问题追溯。这套流程跑下来基本能覆盖 Wi-Fi 蓝牙性能测试的大部分场景。做产品测试或者帮朋友排查无线问题都可以直接拿来套用。这几年的实际经验让我最大的体会是无线性能测试与其说是在测设备不如说是在测环境和方法是否可控。同样的设备换个房间数据就可能差一半同样的数据用的测试工具不同解读也可能完全不同。掌握了标准化的测试流程再回头去看那些“Wi-Fi 慢”“蓝牙断”的问题你会发现大部分问题的根源其实是信道干扰、供电不稳定、驱动版本不匹配或者测试方法不严谨。先解决这些基础问题再谈性能指标这才是无线调试的正道。
