OpenHarmony WiFi配置持久化问题分析与解决

1. 问题现象与背景分析

最近在调试OpenHarmony 5.0.3（简称OH5.0.3）系统时，发现一个奇怪的WiFi功能异常：当通过系统设置界面对WiFi模块执行断电重启操作后，之前配置的WiFi连接状态无法保存。每次重启后都需要重新手动连接网络，这给用户体验带来了明显不便。

这个问题在智能家居、工业物联网等需要持久化网络连接的场景中尤为突出。想象一下，每次设备断电重启后，智能摄像头都需要重新配网，或者车间里的传感器设备重启后丢失网络配置，这显然不符合产品化要求。

通过日志分析发现，问题出在wpa_supplicant（WiFi连接管理后台服务）与系统配置存储模块的交互流程上。当执行硬重启操作时，系统未能正确触发配置保存机制，导致运行时配置与持久化配置不同步。

2. 技术原理深度解析

2.1 OpenHarmony的WiFi管理架构

OH5.0.3的WiFi子系统采用分层设计：

• 上层：设置应用（JS/ETS界面）
• 中间层：WiFi服务（C++实现）
• 底层：HAL驱动 + wpa_supplicant

配置保存的正常流程应该是：

1. 用户通过界面修改配置
2. WiFi服务调用wpa_supplicant的CTRL_IFACE接口
3. wpa_supplicant更新运行时配置并触发SAVE_CONFIG
4. 配置写入/etc/wifi/wpa_supplicant.conf

2.2 问题根因定位

通过strace跟踪发现，断电重启操作直接调用了：

bash复制killall -9 wpa_supplicant

这种强制终止进程的方式导致：

1. wpa_supplicant没有机会执行清理操作
2. 内存中的配置变更未刷写到磁盘
3. 下次启动时读取的是旧配置文件

3. 解决方案与实现步骤

3.1 正确重启流程实现

修改WiFi服务层的重启逻辑，增加优雅终止流程：

cpp复制// 原错误实现
void RestartWifiService() {
    system("killall -9 wpa_supplicant");
    StartWifiService();
}

// 修正后实现
void RestartWifiService() {