19、Wi-Fi 6/6E 新特性：OFDMA、MU-MIMO、6GHz 频段支持
说实话，Wi-Fi 6 和 6E 是我这几年在 Android 开发中遇到的最有意思的升级。以前我们调 Wi-Fi，无非就是信号好不好、连接快不快。但到了 Wi-Fi 6 时代，事情变得复杂了，也更有趣了。
我记得第一次在项目中适配 Wi-Fi 6 时，客户要求「多设备同时在线不卡顿」。我心想，这不就是 OFDMA 和 MU-MIMO 的活儿吗？但真正落地时才发现，光知道概念远远不够。你得懂底层怎么调度，上层怎么配合。
今天我就把 Wi-Fi 6/6E 的三个核心特性掰开揉碎了讲。嗯，咱们一个一个来。
19.1 OFDMA：正交频分多址
OFDMA 的全称是 Orthogonal Frequency Division Multiple Access。名字挺长，但说白了就是「把一条车道分成多个小车道，让多辆车同时跑」。
在 Wi-Fi 5 时代，一个信道一次只能服务一个设备。哪怕你只发一个字节的数据包，也得占满整个信道。这就像一条单车道，一次只能过一辆车。设备多了就得排队，延迟自然就上来了。
OFDMA 不一样。它把信道切分成多个子载波（Resource Unit，简称 RU）。每个 RU 可以分配给不同的设备。这样一来，多个设备可以同时发送小数据包，互不干扰。
核心价值：OFDMA 主要优化的是「低带宽、多设备」场景。比如智能家居里一堆传感器同时上报状态，或者会议室里几十个人同时连 Wi-Fi 刷网页。这些场景下，OFDMA 能显著降低延迟，提升网络效率。
我在项目中遇到过一个问题：某款 IoT 设备上报数据时，总是比其他设备慢一拍。后来抓包发现，它用的是 Wi-Fi 5 的旧协议，不支持 OFDMA。在 Wi-Fi 6 路由器下，它只能等别的设备发完才能轮到自己。换成支持 OFDMA 的芯片后，延迟直接降了 60%。
Android 侧的 OFDMA 支持
在 Android 里，OFDMA 的开关通常由 Wi-Fi HAL 层控制。我们作为上层开发者，主要关注的是 WifiManager 中的相关 API。
// 检查设备是否支持 OFDMA
WifiManager wifiManager = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
WifiInfo wifiInfo = wifiManager.getConnectionInfo();
// 通过 WifiInfo 获取当前连接的 Wi-Fi 标准
int wifiStandard = wifiInfo.getWifiStandard();
if (wifiStandard == WifiInfo.WIFI_STANDARD_11AX) {
// 设备已连接到 Wi-Fi 6 网络，OFDMA 由底层自动启用
Log.d("WiFi6Demo", "当前连接为 Wi-Fi 6，OFDMA 已启用");
} else {
Log.d("WiFi6Demo", "当前连接非 Wi-Fi 6，OFDMA 不可用");
}你可能会问：为什么上层不提供直接开关 OFDMA 的 API？嗯，这里有个设计原则——OFDMA 是物理层的调度机制，交给芯片厂商去优化更合适。Android 只负责告诉你「当前是否支持」。
小提示：如果你想在测试中验证 OFDMA 是否生效，可以用 adb shell dumpsys wifi 查看连接信息。里面会显示当前使用的 Wi-Fi 标准（802.11ax）和 RU 分配情况。
19.2 MU-MIMO：多用户多输入多输出
MU-MIMO 全称是 Multi-User Multiple-Input Multiple-Output。它和 OFDMA 经常被放在一起说，但两者解决的问题不同。
OFDMA 解决的是「小数据包并发」问题。MU-MIMO 解决的是「大数据吞吐」问题。你想想看，OFDMA 就像把车道分成多条小道，适合跑自行车。MU-MIMO 则是同时修了多条高速公路，适合跑卡车。
Wi-Fi 5 支持的是 SU-MIMO（单用户 MIMO），一次只能跟一个设备通信。Wi-Fi 6 把 MU-MIMO 从下行扩展到了上行，也就是说，路由器可以同时跟多个设备收发数据。
关键区别：
- OFDMA：频域上的并行，适合小包、低延迟场景
- MU-MIMO：空间上的并行，适合大包、高吞吐场景
- 两者互补：实际场景中，OFDMA 和 MU-MIMO 可以同时工作，互不冲突
我曾经在调试一个视频会议应用时，发现多人同时开启摄像头后，上行吞吐量急剧下降。查了半天，原来是路由器不支持上行 MU-MIMO。所有设备的上行数据只能排队发送，导致视频卡顿。后来换了一台支持上行 MU-MIMO 的 Wi-Fi 6 路由器，问题迎刃而解。
Android 侧的 MU-MIMO 支持
MU-MIMO 的支持情况，可以通过 WifiInfo 的 isMultiUserMimoSupported() 方法来检测。不过要注意，这个方法在 Android 11 之后才引入。
// 检查当前连接是否支持 MU-MIMO
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
WifiInfo wifiInfo = wifiManager.getConnectionInfo();
if (wifiInfo.isMultiUserMimoSupported()) {
Log.d("WiFi6Demo", "当前连接支持 MU-MIMO");
} else {
Log.d("WiFi6Demo", "当前连接不支持 MU-MIMO");
}
}注意：MU-MIMO 需要路由器端和客户端同时支持。即使你的手机支持，如果路由器不支持，也无法生效。另外，MU-MIMO 在 2.4GHz 频段上通常不可用，因为信道太窄，空间流数有限。
19.3 6GHz 频段支持（Wi-Fi 6E）
Wi-Fi 6E 是 Wi-Fi 6 的扩展版本，核心变化就是增加了 6GHz 频段。为什么需要 6GHz？说白了，2.4GHz 和 5GHz 太挤了。
2.4GHz 只有 3 个不重叠的信道，还要跟蓝牙、微波炉抢资源。5GHz 虽然信道多，但 DFS 信道经常被雷达占用，实际可用信道也不多。6GHz 就不一样了，它提供了 1200MHz 的连续频谱，相当于 59 个 20MHz 信道，或者 29 个 40MHz 信道。
我记得第一次在 Android 上调试 6GHz 频段时，遇到了一个坑：系统默认不会扫描 6GHz 频段。你需要显式地调用 startScan() 并传入特定的扫描参数。
// 在 Android 12+ 上扫描 6GHz 频段
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
ScanRequest scanRequest = new ScanRequest.Builder()
.setBand(ScanRequest.WIFI_BAND_6_GHZ)
.build();
wifiManager.startScan(scanRequest, executor, callback);
}另外，6GHz 频段还有一个重要的特性：它强制要求 WPA3 加密。也就是说，不支持 WPA3 的老设备无法连接 6GHz 网络。这一点在兼容性测试中要特别注意。
避坑指南：我曾经在测试中发现，某些国产手机虽然宣称支持 Wi-Fi 6E，但实际扫描 6GHz 频段时返回空列表。后来查了芯片文档才知道，这些设备在「低功耗模式」下会关闭 6GHz 射频。解决方案是在扫描前先唤醒设备，或者设置扫描间隔不要太短。
19.4 知识体系总览
下面这张图是我自己整理的 Wi-Fi 6/6E 核心特性关系图。你可以看到，OFDMA 和 MU-MIMO 是并行关系，6GHz 频段则是独立的硬件升级。
19.5 实际开发中的注意事项
讲了这么多理论，最后说几个我在实际开发中踩过的坑。
- 兼容性测试不能省。 不是所有 Wi-Fi 6 路由器都支持完整的 OFDMA 和 MU-MIMO。有些廉价路由器只支持下行 MU-MIMO，不支持上行。测试时一定要用多台设备同时压测。
- 6GHz 频段的扫描策略要调整。 6GHz 信号衰减比 5GHz 还快，穿墙能力更差。如果你的应用需要频繁扫描，建议把扫描间隔拉长到 10 秒以上，否则设备会频繁切换频段，反而影响体验。
- WPA3 的兼容性问题。 6GHz 强制 WPA3，但有些老设备不支持。如果你的应用需要兼容这些设备，建议在连接 6GHz 网络前先检测设备能力。
- 功耗问题。 Wi-Fi 6 的芯片通常比 Wi-Fi 5 更耗电。特别是在 6GHz 频段下，射频功耗会更高。如果你的应用是后台服务，建议在低功耗模式下回退到 2.4GHz 或 5GHz。
重要提醒：Wi-Fi 6E 的 6GHz 频段在中国大陆尚未完全开放。目前只有部分试点城市可以使用。如果你的应用面向国内市场，建议先确认目标地区的法规是否允许 6GHz 频段使用。否则，强行开启 6GHz 扫描可能会导致设备无法通过入网认证。
好了，关于 Wi-Fi 6/6E 的三个核心特性就讲到这里。这些东西说起来简单，真正落地时细节很多。我建议你在自己的项目里先跑一遍扫描和连接流程，看看实际效果。遇到问题别慌，抓包分析一下，基本都能找到原因。