1. 从一份配置文件说起WCNSS_qcom_cfg.ini 到底管什么搞高通平台 Android 底层的兄弟大概率都在/vendor/etc/wifi/或者/system/etc/firmware/这类路径下见过WCNSS_qcom_cfg.ini这个文件。它不像build.prop那样天天被人翻也不像init.rc那样一改就开机炸但只要你碰过 Wi-Fi 连不上、热点开不了、吞吐上不去、功耗下不来这类问题最后十有八九会绕回到这个文件上。WCNSS 全称是 Wireless Connectivity SubSystem是高通 SoC 里专门负责无线连接的那块子系统涵盖 Wi-Fi、蓝牙、FM 这些模块。而WCNSS_qcom_cfg.ini就是给 WCNSS 固件和驱动读取的运行时配置里面是一堆keyvalue形式的参数。它决定了 Wi-Fi 从初始化、扫描、连接、漫游到省电的整套行为。你可以把它理解成 Wi-Fi 模块的“性格设定表”——同样一颗芯片配置不同表现可能天差地别。这个系列我打算分几篇把常用参数捋一遍这是第三篇。前两篇聊了基础连接和扫描相关的参数这篇重点放在功耗控制、漫游行为、吞吐调优、以及一些容易被忽略但很关键的调试开关上。适合谁看做 Android 系统集成、Wi-Fi 驱动调试、ROM 定制的工程师以及那些被“Wi-Fi 待机耗电高”“信号弱时死连不放”“测速跑不满”折磨过的朋友。我会尽量把每个参数为什么这么设、设了会怎样、不设又会怎样讲清楚而不是甩一张参数表让你自己猜。需要先说明一点不同高通平台比如 SDM660、SM8250、SM8550的固件版本差异不小同一个参数在不同版本上可能默认值不同甚至有的参数在新固件里已经被废弃。所以下面讲的内容你落地前一定要结合自己平台的WCNSS_qcom_cfg.ini原始文件和固件 release note 核对别直接照抄。2. 功耗相关参数待机耗电的锅往往在这里Wi-Fi 待机耗电是 Android 设备最常被用户投诉的问题之一。很多人第一反应是去查 wakelock但实际上一大半的 Wi-Fi 待机功耗问题根源在 WCNSS 的省电策略配置上。这一章把几个核心的功耗参数拆开讲。2.1 gEnablePowerSaveOffload 与省电卸载机制先看gEnablePowerSaveOffload。这个参数控制的是省电模式是否卸载到固件层处理。早期的高通方案里省电决策由 host 侧驱动做CPU 需要频繁唤醒去判断什么时候该进省电、什么时候该醒来收 beacon。后来高通把这块逻辑下沉到 WCNSS 固件里也就是所谓的 offload。取值一般是0关闭 offload省电逻辑在 host 驱动侧1开启 offload省电逻辑在固件侧2部分平台支持的增强模式固件侧做更激进的省电决策为什么建议开成1或2因为 host 侧做省电意味着 AP应用处理器要参与每一次省电状态切换CPU 没法深度睡眠待机功耗自然下不来。卸载到固件后WCNSS 自己就能决定何时进入 DTIM 监听、何时休眠AP 可以安心睡大觉。但这里有个坑offload 开启后某些老平台的固件对特定 AP 的兼容性会变差表现为连上某些路由器后频繁掉线。我遇到过一台基于 SDM660 的设备开gEnablePowerSaveOffload1后连某品牌 mesh 路由会周期性断流改回0就正常。所以这个参数不是无脑开要结合实测。注意改这个参数后必须重启 WCNSS 子系统通常重启设备即可单纯重启 wpa_supplicant 不生效因为固件配置是在子系统启动时加载的。2.2 gEnableSuspend 与 gEnableRuntimePM 的配合gEnableSuspend控制的是系统进入 suspend挂起时 Wi-Fi 是否跟随进入低功耗状态。这个参数和内核的 runtime PM 机制是联动的。gEnableRuntimePM则是控制运行时电源管理也就是设备亮屏但 Wi-Fi 空闲时是否允许 WCNSS 进入低功耗。这两个参数的组合行为可以这样理解gEnableSuspendgEnableRuntimePM行为00Wi-Fi 始终全功率功耗最高但延迟最低10仅系统挂起时省电亮屏空闲不省11挂起和亮屏空闲都省电推荐日常配置01挂起不省但亮屏省比较少见实际项目里我一般建议gEnableSuspend1gEnableRuntimePM1。但如果你做的是需要低延迟的场景比如云游戏、实时投屏可以把gEnableRuntimePM关掉牺牲一点功耗换稳定性。这里有个经验gEnableRuntimePM开启后如果驱动里的 idle 超时设得太短会导致 Wi-Fi 频繁进出低功耗反而增加功耗每次切换都有开销。这个超时通常在驱动代码里不在 ini 里但你可以通过观察dmesg里 WCNSS 的 PM 状态切换频率来判断是否过于频繁。2.3 gDTIMPeriod 与 beacon 监听周期gDTIMPeriod这个参数直接决定 STA 在省电模式下多久醒一次来收 beacon。DTIM 是 AP 告诉客户端“我缓存了组播/广播帧你该醒来收了”的机制。设成1意味着每个 beacon 都醒功耗高但延迟低设成3意味着每 3 个 beacon 醒一次。beacon 间隔通常是 100ms所以gDTIMPeriod3就是每 300ms 醒一次。这个值设大了省电但会增加下行延迟设小了费电但响应快。日常设备我一般用2或3。但要注意这个值不能超过 AP 实际广播的 DTIM period否则会漏收组播帧表现为某些依赖组播的应用比如 mDNS 发现、某些投屏协议工作不正常。实操心得调试待机功耗时可以用adb shell dumpsys wifi配合抓包工具观察实际 DTIM 行为。如果发现设备醒来的频率远高于gDTIMPeriod设定值说明有别的因素在阻止进入省电比如某个应用持有 wakelock 或者有持续的组播流量。3. 漫游行为控制信号弱时该不该死连漫游是 Wi-Fi 体验里最玄学的部分。用户拿着手机从客厅走到卧室明明卧室的路由器信号更强但手机就是死连着客厅那个弱信号 AP 不放网速卡成 PPT。这背后就是漫游决策参数在作祟。3.1 gRoamTriggerRssi 与漫游触发门限gRoamTriggerRssi定义的是当前连接 AP 的 RSSI 低于多少时固件开始考虑漫游。单位是 dBm是个负值。比如设成-75意思是当前 AP 信号弱于 -75dBm 时固件会启动扫描寻找更好的 AP。设成-80就更“恋旧”信号很差了才肯动设成-70就更“花心”信号稍弱就想换。这个值怎么定要看你的使用场景家庭/办公单 AP 环境设低一点比如-80避免无意义的扫描耗电多 AP mesh 环境设高一点比如-70到-72保证及时切换运营商热点/公共 Wi-Fi通常设-75左右但光有这个还不够因为“考虑漫游”不等于“真的漫游”。还得看下面这个参数。3.2 gRoamDelta 与候选 AP 的筛选gRoamDelta定义的是候选 AP 要比当前 AP 强多少 dB 才值得切换。比如设成5意思是找到的新 AP 至少要比当前 AP 强 5dBm固件才会发起漫游。这个参数是防止“乒乓漫游”的关键。如果设成0或很小的值两个信号相近的 AP 之间会反复横跳用户体验极差还费电。设成5到8是比较稳妥的范围。gRoamTriggerRssi和gRoamDelta要配合看。举个例子当前 AP 是 -76dBmgRoamTriggerRssi-75已经触发漫游扫描扫到另一个 AP 是 -73dBmgRoamDelta5那么 -73 比 -76 只强了 3dB不够 5dB 的门槛不会切换。只有扫到 -70dBm 或更强的 AP 才会切。3.3 gRoamScanPeriod 与扫描节奏gRoamScanPeriod控制的是漫游扫描的间隔单位通常是毫秒。设得太短扫描频繁费电设得太长信号已经烂了还没找到新 AP断流时间长。我一般设30000到6000030 到 60 秒。但这个值要结合gRoamTriggerRssi一起调。如果触发门限设得高容易触发扫描周期可以长一点如果门限设得低不容易触发一旦触发说明情况已经比较紧急扫描周期就该短一点。踩过的坑有次把gRoamScanPeriod设成10000结果设备在弱信号区域疯狂扫描待机功耗直接翻倍。后来改成45000功耗正常了漫游体验也没明显变差。所以这个参数别贪快。3.4 gEnableFTM 与 802.11r 快速漫游gEnableFTM这个参数在不同平台含义可能不同有的指 Fast Transition Management对应 802.11r有的指 Fine Timing Measurement用于定位。在 WCNSS 配置语境下多数是指前者即是否启用 802.11r 快速漫游。802.11r 的价值在于传统漫游需要重新做四次握手认证耗时几百毫秒期间语音通话会断、视频会卡。802.11r 通过预认证机制把这段时间压缩到几十毫秒基本无感。但开启 802.11r 有个前提AP 侧必须支持并正确配置。如果 AP 不支持而 STA 强行开可能导致连不上。所以这个参数我一般建议先确认 AP 能力再开。企业级部署里 802.11r 是标配家庭路由则要看型号。4. 吞吐与性能调优测速跑不满的排查方向“为什么我的手机连 Wi-Fi 测速只有别人一半”这个问题背后可能有一堆原因但 WCNSS 配置里确实有几个参数直接影响吞吐表现。4.1 gEnableBmps 与 广播/组播过滤gEnableBmps全称是 Broadcast/Multicast Power Save控制的是广播和组播帧的省电过滤策略。开启后固件会过滤掉大部分广播/组播帧只把关键的传给 host减少 CPU 唤醒。这个参数对吞吐的影响是间接的广播/组播帧少了CPU 被唤醒的次数少了留给数据通路的资源就多了。但过滤太激进会漏掉一些必要的发现协议帧。取值通常是0或1。日常建议开1但如果你的设备要跑 mDNS、SSDP 这类依赖组播的发现协议可能需要关掉或者配合白名单机制。4.2 gEnableMuBformee 与 多用户 MIMOgEnableMuBformee控制的是是否作为 MU Beamformee 参与多用户 MIMO。这是 Wi-Fi 5802.11ac引入的特性Wi-Fi 6 里进一步演进成 OFDMA。简单说MU-MIMO 让 AP 能同时给多个设备发数据而不是排队一个一个来。作为 Beamformee你的设备要能正确反馈信道信息给 APAP 才能做波束成形。这个参数开启的前提是 AP 支持 MU-MIMO 且你的设备天线配置够。单天线设备开这个意义不大。多天线旗舰机建议开。4.3 gEnableTxBf 与 波束成形gEnableTxBf控制发送波束成形。和上面的接收侧对应这个是设备作为 Beamformer 向 AP 发数据时能否做波束成形。波束成形通俗讲就是“把信号能量集中对准对方”而不是全向散射。理论上能提升信号强度和吞吐尤其在距离较远时效果明显。但实测中波束成形的增益受环境影响很大。在反射多的室内环境波束成形可能反而不如全向。所以这个参数我一般建议开启但如果遇到吞吐异常可以试着关掉对比。4.4 gChannelBondingMode 与 信道绑定gChannelBondingMode控制的是信道绑定模式也就是是否把两个 20MHz 信道绑成 40MHz 用或者 80MHz。常见取值0不绑定始终 20MHz1允许 40MHz2允许 80MHzWi-Fi 5 及以上信道绑定能直接翻倍甚至翻四倍理论带宽但代价是占用更多频谱在拥挤环境里更容易受干扰。2.4GHz 频段我一般建议不绑定设0因为 2.4G 本来就挤绑定后干扰更严重。5GHz 频段可以开1或2。实操心得测速跑不满时先别急着改 ini。用adb shell iw wlan0 link看实际协商速率用抓包看实际用的带宽。很多时候问题在 AP 侧或者干扰不在 STA 配置。确认是 STA 侧限制后再动gChannelBondingMode。5. 调试与日志出问题时怎么快速定位前面讲的都是功能参数这一章讲调试相关的。WCNSS 出问题时如果没有合适的日志开关排查起来就是盲人摸象。5.1 gDebugLevel 与日志级别gDebugLevel控制 WCNSS 固件输出日志的详细程度。取值从0到5甚至更高数字越大越详细。0几乎不输出生产环境用1只输出错误2错误 警告3加上关键流程信息4详细流程5最详细包含每个帧的收发调试时开到3或4比较合适。开到5会产生海量日志可能影响性能甚至把日志缓冲区冲爆反而看不到关键信息。日志输出位置通常在/d/wlan/或者通过dmesg查看。不同平台路径不同可以用find / -name *wlan* -type d找一下。5.2 gEnablefwprint 与 固件打印gEnablefwprint控制是否把固件侧的打印输出到 host 侧。这个和gDebugLevel是配合的gDebugLevel决定固件产生多少日志gEnablefwprint决定这些日志是否传出来。调试固件行为比如漫游决策、省电状态切换时这个必须开。但生产环境要关掉因为固件打印走的是共享内存通道会占用资源。5.3 gEnableLogp 与 性能日志gEnableLogp控制性能相关日志比如吞吐统计、重传率、丢包率这些。做吞吐调优时很有用能看到底层实际发生了什么。这个参数开启后可以通过特定工具如高通的 QXDM 或者开源的 nl80211 统计接口读取性能计数器。对于定位“为什么吞吐上不去”这类问题比看应用层测速结果有用得多。5.4 常见问题速查表把这一篇涉及的参数和典型问题对应起来方便排查时快速定位现象可能相关的参数排查方向待机耗电高gEnablePowerSaveOffload, gEnableSuspend, gEnableRuntimePM, gDTIMPeriod确认省电是否开启DTIM 是否合理信号弱不死连gRoamTriggerRssi, gRoamDelta, gRoamScanPeriod检查漫游门限是否过低漫游乒乓gRoamDelta增大 delta 值语音漫游断流gEnableFTM确认 802.11r 是否开启且 AP 支持测速跑不满gChannelBondingMode, gEnableMuBformee, gEnableTxBf检查带宽绑定和 MIMO 配置组播应用异常gEnableBmps尝试关闭组播过滤问题无法定位gDebugLevel, gEnablefwprint, gEnableLogp提高日志级别抓取信息6. 参数修改的正确姿势与避坑指南讲完具体参数最后说说怎么改、怎么验证、怎么避免把自己坑了。这部分是纯经验文档里不会写。6.1 修改流程与生效方式WCNSS_qcom_cfg.ini的修改不是改完就生效的。正确流程是找到当前生效的 ini 文件。注意可能有多个副本/vendor/etc/wifi/、/system/etc/firmware/要确认驱动实际读的是哪个。可以用adb shell ls -l /vendor/etc/wifi/看或者查驱动的加载日志。修改参数。建议先备份原文件。重启 WCNSS 子系统。最简单是重启设备如果平台支持可以用adb shell stopstart重启相关服务但不一定彻底。验证。用adb shell dumpsys wifi、adb shell iw wlan0 link、抓包、看日志等方式确认参数生效。注意有些参数是固件启动时一次性读取的运行中改 ini 再重启服务也不生效必须重启设备。所以调试时别嫌麻烦该重启就重启。6.2 参数冲突与优先级不同来源的配置可能有冲突。比如build.prop里可能有 Wi-Fi 相关属性驱动代码里可能有硬编码默认值ini 文件里又有配置。优先级通常是ini 文件 驱动默认值但某些属性可能覆盖 ini。遇到改了 ini 不生效的情况先确认有没有别的地方在覆盖。可以用adb shell getprop | grep -i wifi看看有没有相关属性。6.3 平台差异与版本兼容前面反复强调过不同高通平台、不同固件版本参数行为可能不同。我建议的做法是拿到新平台先把原始 ini 完整备份对照高通 release note 确认哪些参数有效、哪些废弃每次只改一个参数改完验证别一次改一堆出了问题都不知道是哪个引起的建立自己的参数配置表记录每个平台每个参数的实际效果6.4 生产环境与调试环境的配置分离调试时开的日志、关的省电绝对不能带到生产环境。我见过有项目把调试配置直接打包出货结果用户投诉待机耗电爆炸。正确做法是维护两套配置一套调试用日志全开、省电关闭一套生产用日志关闭、省电开启通过编译变体或者运行时判断来切换。6.5 一个真实的排查案例最后分享一个我实际遇到的案例。某设备用户反馈连上 Wi-Fi 后锁屏待机一晚上掉电 15%而同型号其他设备只掉 3%。排查过程先看dumpsys batterystats发现 Wi-Fi 相关的唤醒次数异常高。抓dmesg看到 WCNSS 频繁进出低功耗状态每秒好几次。查 ini 配置发现gEnableRuntimePM1但gDTIMPeriod1。分析DTIM1 意味着每个 beacon100ms都要醒来而 runtime PM 又想让它睡两者打架导致频繁切换每次切换都有开销反而比不睡还费电。把gDTIMPeriod改成3唤醒频率降到 300ms 一次待机功耗恢复正常。这个案例说明省电参数之间是有关联的不能孤立地看。gEnableRuntimePM想省电但gDTIMPeriod1让它根本睡不踏实结果适得其反。6.6 验证参数是否生效的实用命令最后给几个我常用的验证命令都是实测有效的# 查看当前 Wi-Fi 连接状态和协商速率 adb shell iw wlan0 link # 查看 Wi-Fi 详细统计信息 adb shell dumpsys wifi # 查看 WCNSS 相关内核日志 adb shell dmesg | grep -i wcnss # 查看 Wi-Fi 唤醒锁情况 adb shell dumpsys power | grep -i wifi # 查看当前生效的 Wi-Fi 属性 adb shell getprop | grep -i wifi这些命令配合前面讲的参数基本能覆盖大部分 Wi-Fi 底层问题的排查。关键是要养成“改前备份、改后验证、一次一个”的习惯别想着一步到位。我个人在实际项目里的体会是WCNSS 配置调优这件事七分靠理解原理三分靠实测验证。参数表网上一搜一大把但每个参数在你具体平台上的实际表现只有自己动手试过才知道。尤其是功耗和漫游这两块跟硬件设计、天线布局、甚至外壳材质都有关系别人的最优配置搬到你这儿可能完全不适用。所以别迷信任何一份“万能配置”包括我这篇里给的推荐值都只是起点不是终点。