2、Android WiFi架构概览：Android WiFi子系统分层
说到Android WiFi，很多人第一反应就是「打开设置，点一下连接」。但作为一个系统工程师，我看到的是一整套精密的软件栈。今天我们就来拆解一下，这个WiFi子系统到底是怎么分层协作的。
我个人习惯把Android WiFi架构想象成一栋楼。每一层各司其职，上层只管发号施令，下层负责具体干活。你想想看，如果每一层都要管底层细节，那代码早就乱成一锅粥了。
2.1 四层架构总览
Android WiFi子系统从上到下分为四层：
- App层：用户直接接触的界面，比如设置里的WiFi开关、扫描列表。
- Framework层：Java写的核心逻辑，管理状态机、处理扫描结果、协调连接流程。
- HAL层：硬件抽象层，屏蔽芯片差异，给上层提供统一接口。
- Driver层：内核里的驱动，直接跟WiFi芯片打交道。
嗯，这里要注意：每一层之间都有明确的接口定义。上层不关心下层怎么实现，下层也不关心上层要做什么。这种解耦设计，说白了就是为了方便各厂商定制。
核心观点：Android WiFi架构的精髓在于「分层隔离」。每一层只做自己的事，通过标准接口通信。这样Google可以升级Framework，芯片厂商可以改HAL和Driver，互不干扰。
2.2 App层：用户看到的只是冰山一角
App层其实没什么好说的，就是调用Framework提供的API。比如你点一下「扫描」，系统会调用WifiManager.startScan()。但真正干活的是下层。
我在项目中遇到过一个问题：某个App频繁调用扫描，导致WiFi模块发热严重。后来发现是App层没有做扫描间隔限制。所以啊，App层虽然简单，但也要注意不要滥用API。
2.3 Framework层：WiFi的大脑
Framework层是WiFi子系统的核心。它包含几个关键组件：
- WifiService：系统服务，管理所有WiFi相关的操作。
- WifiStateMachine：状态机，处理连接、断开、扫描等状态切换。
- WifiNative：JNI层，桥接Java和C++代码。
说白了，Framework层就是一个大管家。App说「我要连接这个WiFi」，管家就去查密码、找网络、发指令。我曾经调试过一个连接超时的问题，最后发现是状态机在某个状态下卡住了，没有正确处理超时事件。
避坑指南：我曾经在调试WiFi连接问题时，发现Framework层的日志特别重要。建议打开adb logcat -s WifiStateMachine，可以看到状态机每一步的切换。很多连接问题都能从这里找到线索。
2.4 HAL层：wpa_supplicant与WiFi HAL
HAL层是连接Framework和Driver的桥梁。这里有两个关键角色：
| 组件 | 作用 | 通信方式 |
|---|---|---|
| wpa_supplicant | 处理WiFi认证、加密、扫描等 | 通过socket与Framework通信 |
| WiFi HAL | 提供硬件抽象接口，控制芯片行为 | AIDL（Android 11+）或 HIDL |
wpa_supplicant 是一个独立的守护进程。它负责处理802.11协议中的认证、关联、4次握手等。你想想看，如果没有它，Framework就得自己实现这些复杂的协议，那代码量就太大了。
WiFi HAL 是Android 8.0之后引入的。它把硬件相关的操作抽象成标准接口。比如打开WiFi、设置信道、获取信号强度等。芯片厂商只需要实现这些接口，上层代码完全不用改。
我记得有一次，某款芯片的WiFi扫描总是返回空列表。排查了半天，发现是HAL层实现中，扫描回调没有正确触发。这就是HAL层出问题时的典型症状——上层看起来一切正常，但就是拿不到数据。
注意事项：wpa_supplicant和WiFi HAL是分开的进程。Framework通过socket与wpa_supplicant通信，通过Binder/AIDL与WiFi HAL通信。如果其中一个进程挂了，整个WiFi功能都会异常。我曾经遇到过wpa_supplicant崩溃导致WiFi无法打开的情况，重启一下就好了。
2.5 Driver层：最底层的硬核
Driver层运行在Linux内核中。它直接操作WiFi芯片的寄存器，处理中断、DMA传输等。Android WiFi驱动通常基于cfg80211和nl80211框架。
- cfg80211：内核中的无线配置框架，提供统一的API。
- nl80211：用户空间和内核空间通信的netlink协议。
说白了，Driver层就是那个真正干活的人。上层说「扫描一下」，Driver就去控制芯片发射探测帧、监听信道、收集结果。如果驱动有bug，那上层再怎么调也没用。
嗯，这里要注意：Driver层的调试是最困难的。因为一旦内核崩溃，整个系统都会挂掉。我建议在开发阶段打开内核的WiFi调试选项，比如CONFIG_CFG80211_DEBUGFS，可以查看很多底层信息。
2.6 各层之间的协作流程
我们以「连接一个WiFi」为例，看看各层是怎么协作的：
- App层：用户点击网络，调用
WifiManager.connect()。 - Framework层：WifiStateMachine收到指令，通过WifiNative下发连接请求。
- HAL层：wpa_supplicant处理认证（比如WPA2的4次握手），WiFi HAL控制芯片切换到目标信道。
- Driver层：驱动发送关联请求，等待AP响应，然后上报连接结果。
整个过程看起来简单，但每一步都可能出问题。我遇到过最奇葩的一个案例：连接成功但马上断开，最后发现是Driver层上报的RSSI值异常，导致Framework认为信号太差主动断开了。
总结一下：Android WiFi架构的四层设计，本质上是为了「分工明确、各司其职」。App层只管UI，Framework层管逻辑，HAL层管抽象，Driver层管硬件。每一层都通过标准接口通信，这样Google、芯片厂商、设备厂商可以各自迭代，互不影响。
好了，这一章的内容就到这里。下一章我们会深入Framework层，看看WifiStateMachine这个状态机到底是怎么工作的。到时候我会分享一些实际调试中的经验，保证让你少走弯路。