蓝牙连接扫描这件事Page Scan寻呼扫描是我这些年被问得最多、也最容易被一句扫描参数没配好糊弄过去的部分。蓝牙连接扫描在协议栈里其实分两段完全不同的活儿Inquiry Scan 负责被搜到Page Scan 负责被连上。很多人调不通连接第一反应去查射频、查天线、查配对密钥绕一大圈回来才发现真正的问题是被叫方压根没在正确的窗口里睁眼。这篇东西讲的就是 Page Scan 这一段的参数配置逻辑、延迟估算方法以及我这些年在台架上反复踩过的坑。Page Scan的参数看起来只有 Interval 和 Window 两个数字但这两个数字背后牵着时隙粒度、跳频序列训练周期、时钟漂移、共存分片和功耗预算五条线任何一条没算清表现出来都是偶尔能连、偶尔连不上这种最难查的随机故障。适合正在做蓝牙产品固件、协议栈移植、产线测试或者单纯的连接稳定性排查的读者从完全不了解基带细节的新手到想给自己的参数表找一套可验证推导过程的熟手都能从里面拿走点东西。1. 把Page Scan放回连接建立的时间轴上1.1 三个阶段的分工Inquiry、Page、Connection要理解 Page Scan 的参数为什么这么设计得先把它在整条连接链路里的位置摆正。蓝牙经典BR/EDR从两个陌生设备到建立 ACL 链路走的是三步Inquiry、Page、Connection。第一步 Inquiry发起方在 32 个唤醒频率上按 inquiry hopping sequence 跳频周期性地发出 ID 包被叫方如果开着 Inquiry Scan就在自己的扫描窗口里监听听到 ID 包后等待一个随机退避然后回一个 FHS 包把自己的蓝牙地址、时钟、设备类别这些信息交出去。这一步的产物是一份设备清单主机层拿到的就是那个熟悉的搜索结果列表。第二步 Page才是真正建立链路的动作。发起方已经知道对方的蓝牙地址也拿到了一个时钟估计值于是切到 page hopping sequence —— 这个序列是由被叫的地址和时钟共同决定的跟 inquiry 序列不是一回事。发起方持续发 ID 包被叫方如果开着 Page Scan在窗口里收到 ID 包就回一个 ID 包双方对上暗号紧接着发起方发 FHS 包把主时钟信息同步过去再发 POLL被叫回包链路进入 Connection 状态。第三步 Connection 之后就简单了跳频由主设备的时钟统一驱动Page Scan 这个动作本身直接停止。所以 Page Scan 是一个只在未连接状态才工作的机制这也意味着它的参数配置只在待连阶段有意义一旦连上就完全不参与功耗和延迟的计算了。很多人算功耗时把扫描占空比乘到整机功耗上这是典型的算错账后面第 4 节会细说。两段扫描的差别还体现在失败表现上。Inquiry 失败用户看到的是搜不到设备Page 失败用户看到的是搜到了点连接转圈圈最后提示失败。这两种现象在售后和测试报告里是完全不同的关键词排查路径也完全不同。我个人的经验是只要现象是能搜到但连不上八成以上的概率问题出在 Page Scan 这一侧而不是配对、密钥或者射频链路质量。1.2 为什么能搜到连不上几乎总是Page Scan的锅搜得到说明 Inquiry Scan 是开着的射频收发通路、天线、晶振都是好的协议栈的 HCI 通道也是通的。那么剩下的差异点就只有几个Page Scan 使能位没打开、Page Scan 参数配得过于稀疏、被叫方在两次扫描之间睡得太死唤不醒、或者基带时间片被别的活动抢走了。最常见的一种情况是设备进入了可发现但不可连接的状态。这在很多产品里是有意为之的设计配网模式下只开 Inquiry Scan 让手机能搜到用户点了绑定之后固件才把 Page Scan 打开。如果这一步的状态切换逻辑写漏了或者切换之后没有正确下发使能命令就会出现列表里能看到点连接永远超时的现象。还有一种更隐蔽的设备从连接态断开后没有回到 Page Scan 状态而是停在了 Standby 或者 Sniff 之类的低功耗状态这时候连广播都发不出来搜索列表里会时有时无。第二种常见情况是参数太稀疏。Page Scan Interval 设成 2.56 秒、Window 只有 11.25 毫秒占空比不到 0.5%而发起方的 Page Timeout 默认是 5.12 秒。理论上两轮窗口能覆盖但只要训练周期相位没对齐或者发起方在这 5.12 秒里刚好有一次重传退避就会直接超时。表现出来就是十次里能连上七八次这种随机性最折磨人因为你在实验室里试三次都成功一到用户手里就开始投诉。第三种是时钟和定时器精度问题。低功耗产品为了省电待机时主晶振是关掉的Page Scan 靠低频时钟定时唤醒。低频时钟的精度可能只有百分之几累计到 1.28 秒的间隔上就是几十毫秒的抖动窗口边缘直接被推出去。这种故障的特点是温度一低就变差电池电压一降就变差因为 RC 振荡器的频率跟温度和电压都强相关。2. Page Scan的四个可调旋钮2.1 Interval与Window一对必须成比例的账这两个参数是所有配置的核心单位都是 0.625 毫秒也就是蓝牙基础时隙 625 微秒的倍数。合法范围是 0x0012 到 0x1000换算过来就是 11.25 毫秒到 2.56 秒而且必须满足 Interval 大于等于 Window。这两个约束不是建议是硬性的很多协议栈在收到不合法的值时直接返回 Invalid HCI Command Parameters有些则悄悄截断到边界值后者更坑因为你以为配了 5 毫秒的窗口实际跑的是 11.25 毫秒功耗账全错。Window 是被叫方每次醒来监听多长时间。这个时间的下限为什么卡在 11.25 毫秒而不是更小因为 page hopping sequence 一个完整循环是 32 个频率每个频率停留 312.5 微秒一圈下来正好 10 毫秒。窗口必须至少覆盖一整圈才能保证在任意相位下都能撞上发起方当前所在的频率。11.25 毫秒就是 10 毫秒加上一点余量这个数字是算出来的不是拍脑袋定的。理解这一点很关键如果你把窗口压到 10 毫秒以下理论上就存在永远撞不上的频率相位表现出来就是连接成功率永远上不去。Interval 是两次窗口之间的间隔从窗口开始时刻算起。占空比就是 Window 除以 Interval这个比值直接决定了平均功耗和平均连接延迟。举个具体的账Interval 1.28 秒、Window 11.25 毫秒占空比是 0.88%Interval 2.56 秒、Window 11.25 毫秒占空比降到 0.44%功耗减半但平均连接延迟翻倍。这里有一个很实用的取舍原则连接延迟对用户是秒级感知功耗对用户是天级感知。一个耳机如果连接慢 0.5 秒用户每次用都会骂但如果待机功耗从 0.5 毫安降到 0.3 毫安用户可能一个月才感知到一次充电频率的变化。所以在电池容量允许的前提下我一般倾向于把 Interval 压在 1.28 秒以内把省电的功夫花在别的地方。2.2 Scan Type标准扫描和交错扫描的路线差异Scan Type 这个参数只有两个取值标准扫描和交错扫描但它对最大连接延迟的影响是成倍的而且是最容易被忽略的一个。标准扫描的工作方式是每个扫描窗口都固定落在跳频序列的同一个半区上。而 Page 的跳频序列被分成两个训练周期trainA train 和 B train各持续 1.28 秒发起方在这两个 train 之间来回切换。如果被叫方的窗口总是落在 A train 上而发起方正好在 B train 里那就得等发起方切回 A train 才有机会。一次完整的 A/B 循环是 2.56 秒所以标准扫描的最坏延迟能达到 2.56 秒加上等待下一个窗口的时间。交错扫描改的就是这一点相邻两个扫描窗口分别落在 A train 和 B train 上。这样一来无论发起方在哪个 train 里最多两个窗口之内必然撞上最坏延迟基本砍半。代价是什么规范里对交错扫描有个额外约束窗口不能超过间隔的一半因为要把一个间隔切成两半分别安排到两个 train 上。这意味着在同样的功耗预算下你用交错扫描时单个窗口的时间会更短或者说同样窗口长度下占空比会更高。我的建议很直接只要协议栈支持一律开交错扫描。除非你的产品对功耗敏感到每一微安都要抠否则标准扫描省下来的那点功耗换来的是连接成功率和延迟的双重恶化完全不划算。而且标准扫描有一个很隐蔽的坑当 Interval 恰好是 1.28 秒或者 2.56 秒这种训练周期的整数倍时窗口和 train 的相位会被锁死如果锁在错误的那一侧就会变成永远连不上而不是偶尔连不上。这种故障在实验室里极难复现因为换个设备、换个时钟起点相位就变了。2.3 RepetitionR0/R1/R2被规范写死但影响延迟分类R0、R1、R2 这三个代号在文档里经常出现但它们不是可以直接写的寄存器值而是按 Interval 的取值区间划分出来的三档扫描重复模式。R0 指的是连续扫描也就是 Interval 等于 Window设备一直睁着眼R1 指的是 Interval 不超过 1.28 秒R2 指的是 Interval 不超过 2.56 秒。这三档的意义在于规范里给的最大寻呼时间表格是按这三档分别列出的你在查表估算延迟时必须先把自己的配置归类到对应的档位。R0 连续扫描的场景其实很常见就是配对模式。用户按下配对键设备进入一个限时窗口比如 30 秒这 30 秒里把 Interval 和 Window 都设成 11.25 毫秒占空比 100%这时候连接延迟可以压到几十毫秒以内用户体验就是秒连。30 秒之后自动退回 R1 或 R2 的省电配置。这套临时提占空比的做法我强烈建议每个做配对流程的产品都加上成本几乎为零体验提升非常明显。需要提醒一句有些老文档里还在讲 Page Scan Period Mode 和 Page Scan Modemandatory/optional那套东西那是很早版本规范里的机制后来的版本已经废弃了。如果你照着老文档去配会发现协议栈根本不认那些命令。看到这类内容直接跳过别浪费时间。2.4 Page Timeout最容易被忽略的第五个参数严格说 Page Timeout 是发起方的参数不属于被叫方的 Page Scan 配置但它跟 Page Scan 是绑在一起看的因为它是等待的上限。这个参数的默认值是 0x2000乘 0.625 毫秒等于 5.12 秒。发起方在这个时间内没收到被叫的回应就上报 Page Timeout 错误连接流程直接失败。为什么要把这两个参数放一起算因为最大 Page Scan Interval 是 2.56 秒标准扫描下最坏情况需要覆盖两个完整训练周期也就是 5.12 秒正好卡在默认超时的边界上。也就是说如果你的被叫方配了 2.56 秒的间隔又没开交错扫描理论上存在刚好超时失败的组合。这不是理论推演我在台架上实测过这种边缘失败成功率大概在 90% 上下浮动换个时钟起点结果就变。规避方法有两个要么把发起方的 Page Timeout 调大到 8 秒或 10 秒要么把被叫方的配置改成 1.28 秒间隔加交错扫描。前者的问题是用户要等更久才看到失败提示后者更好因为它同时改善了成功时的连接速度。如果两个都改不了那就只能在产品文档里写清楚连接可能需要重试这是最差的选择。3. 从延迟预算反推参数三组场景的算法3.1 寻呼延迟的估算模型与手算过程我不太喜欢直接抄规范里的表格因为那些数字是在特定假设下算出来的换个芯片、换个共存策略就不准了。更有用的是自己建立一个估算模型能解释清楚每一项的来历实测的时候也知道该往哪个方向调。我的模型分三步。第一步算命中条件前面说过窗口长度只要不小于 11.25 毫秒就能覆盖一整个 32 频率循环所以窗口内频率对齐这件事基本是必然的真正的不确定性在训练周期上。第二步算相位概率发起方在 A、B 两个 train 之间各待 1.28 秒被叫的窗口落在哪个 train 上是随机的标准扫描下命中概率大约五成交错扫描下两个窗口之内必中。第三步算等待时间平均要等半个 interval 才轮到下一个窗口。把这三步串起来标准扫描的平均延迟大概是 0.5 乘 interval 加上 0.64 秒半个训练周期最坏是 2 乘 interval 加 2.56 秒交错扫描的平均延迟大概是 0.5 乘 interval最坏是 2 乘 interval。拿 1.28 秒间隔举例标准扫描平均约 1.28 秒最坏约 5.12 秒交错扫描平均约 0.64 秒最坏约 2.56 秒。这个差距是很实在的。必须说明这是我自己的工程估算模型不是规范原文它给出的量级是对的但绝对值会有偏差因为实际实现里还有重传、退避、时钟漂移这些因素。用它来做方案选型和参数排序足够做验收指标就得靠实测数据了。另外提醒一个时钟精度的边界情况。发起方拿到的时钟估计是有误差的page 阶段靠 train 覆盖来吸收这个误差。如果被叫方自己用的低频时钟精度很差比如 ±5%那在 2.56 秒的间隔上就是 ±128 毫秒的抖动窗口实际出现的位置可能偏出去一大截训练周期覆盖不住。这种情况在低温或者电池电量低的时候会恶化表现出来就是新电池能连、旧电池连不上。遇到这种故障别急着改参数先查时钟源。3.2 三组典型场景配置对照表下面这张表是我在几个不同类型产品上反复调过之后沉淀下来的起点值拿去做第一版配置基本不会出大错后面再按实测微调。场景类型IntervalWindowScan Type占空比平均连接延迟量级说明手柄、键鼠插电或大电池11.25 ms11.25 ms交错100%几十毫秒连续扫描体验优先功耗可接受耳机、音箱常态待连1.28 s11.25 ms交错0.88%0.6 秒量级延迟与功耗的平衡点最常用传感器、标签电池供电2.56 s11.25 ms交错0.44%1.3 秒量级功耗优先要求发起方超时够大配对窗口按键触发限时11.25 ms11.25 ms标准100%秒级以内只在配对模式下临时启用表格里有个细节值得说配对窗口那一行我写的是标准扫描因为在 100% 占空比的情况下窗口和间隔相等设备一直在监听两个 train 都能覆盖到交错扫描带来的收益几乎为零反而多一层配置复杂度。这是 R0 连续扫描的一个特性占空比拉满之后 scan type 就不重要了。实际产品里通常是这套组合拳常态用第二行或第三行的省电配置用户按下配对键后临时切到第四行的连续扫描 30 秒超时自动退回。这个状态机要写清楚尤其是配对成功后和配对超时后两个分支都要正确回到省电配置否则设备会一直高功耗扫描电池一周就没了。3.3 配置怎么下发HCI命令与配置文件两套写法参数下发有两个层面协议栈上层通过 HCI 命令下发给控制器或者控制器固件里直接写死默认值。两种方式我都在项目里用过各有各的坑。HCI 层面的写法是这样的先关扫描使能改参数再打开使能。顺序很重要很多协议栈在扫描使能状态下修改参数会直接返回 Command Disallowed。/* 第一步关闭扫描使能。HCI_Write_Scan_Enable, OGF 0x03, OCF 0x001A */ uint8_t scan_enable 0x00; /* 0x00 都关0x01 仅 Inquiry Scan0x02 仅 Page Scan0x03 两者都开 */ hci_send_cmd(0x03, 0x001A, scan_enable, 1);/* 第二步写 Page Scan 活动参数。HCI_Write_Page_Scan_Activity, OGF 0x03, OCF 0x001C 参数单位0.625 ms 合法范围0x0012 (11.25ms) ~ 0x1000 (2560ms)且 interval window */ uint16_t page_scan_interval 0x0800; /* 2048 * 0.625ms 1280ms */ uint16_t page_scan_window 0x0012; /* 18 * 0.625ms 11.25ms */ uint8_t payload[4]; payload[0] page_scan_interval 0xFF; payload[1] page_scan_interval 8; payload[2] page_scan_window 0xFF; payload[3] page_scan_window 8; hci_send_cmd(0x03, 0x001C, payload, 4);/* 第三步写扫描类型。HCI_Write_Page_Scan_Type, OGF 0x03, OCF 0x0046 0x00 Standard Scan0x01 Interlaced Scan */ uint8_t page_scan_type 0x01; hci_send_cmd(0x03, 0x0046, page_scan_type, 1);/* 第四步重新打开 Page Scan 使能 */ uint8_t enable 0x02; hci_send_cmd(0x03, 0x001A, enable, 1);发起方那边如果要调超时对应的是 HCI_Write_Page_TimeoutOGF 0x03OCF 0x0018单位同样是 0.625 毫秒默认 0x2000 即 5.12 秒。如果是写在固件配置文件里形式各家不同但本质都是这几个字段。关键检查点是配置里 interval 和 window 的值是原始寄存器单位还是毫秒这两者混用是低级但高频的错误。我见过不止一次把 1280 毫秒直接填进字段结果控制器按 1280 乘 0.625 等于 800 毫秒处理参数表对不上排查半天。还有一个实操细节改完参数后不要马上判定生效中间至少留几个毫秒的间隔让控制器有时间重载定时器。有些控制器在连续下发的 HCI 命令之间处理不过来第二条会被静默丢弃表现出来就是改了没反应。稳妥的做法是每条命令都等 Command Complete 事件回来再发下一条别用流水线方式连发。4. 排查实录连不上、连得慢、耗电异常4.1 连不上先排除扫描没开和状态机没回来排查顺序我一般这么走从最傻的地方开始因为最傻的地方出错概率最高。第一层设备到底在不在 Page Scan 状态。这个不能靠猜得从协议栈里把状态机的当前状态打出来或者用调试口读控制器的状态寄存器。很多芯片厂商的调试工具能看到当前基带状态是 Standby、Page Scan 还是 Connection这一眼就能定位问题。如果状态不对往上追是谁把它改掉的通常是连接断开事件的处理函数漏了状态回退。第二层Scan Enable 的位有没有正确设置。注意这个参数是位掩码bit0 管 Inquiry Scanbit1 管 Page Scan。如果固件里为了省事写了 0x01那就只有 Inquiry ScanPage Scan 关着现象就是前面说的能搜到连不上。这个错误太常见了我几乎每次接手别人的代码都会先看一眼这一行。第三层参数有没有被控制器拒绝。发完命令一定要检查 Command Complete 事件里的 status 字段0x00 才是成功0x12 是参数越界。有些协议栈封装得比较厚把错误吞掉了你需要打开 HCI 层日志才能看到。第四层物理层。天线匹配、射频功率、灵敏度这些如果 Inquiry 能搜到通常说明没问题但如果搜索距离很近而连接距离更近就有可能是 page 阶段的发射功率配置跟 inquiry 阶段不同。这种情况少见但确实存在尤其在那些分阶段配置射频功率的产品里。第五层也是容易被误判的一层连接其实建立了但在链路层握手阶段失败比如认证、加密、服务发现超时。HCI 日志里会看到 Connection Complete 事件成功但随后马上又收到 Disconnect Complete。这时候问题不在 Page Scan别再往扫描参数上找。4.2 连得慢窗口被谁吃掉了延迟异常排查的核心思路是先确认参数算出来的理论值是多少再测实际值差值就是被吃掉的部分然后去找谁吃的。第一个嫌疑人是 Inquiry Scan 和 Page Scan 同时开启。两个扫描都要占用基带的时间片控制器需要在同一个射频上分时处理。如果两者的间隔和窗口没有对齐好Page Scan 的窗口可能会被 Inquiry Scan 挤掉一部分甚至整段被跳过。我的做法是进入可连接状态后就把 Inquiry Scan 关掉只在需要被搜索的短暂窗口里开启。这个改动在很多产品上直接把连接成功率从 80% 拉到了接近 100%。第二个嫌疑人是无线共存。2.4G 频段上同时跑 Wi-Fi 和蓝牙的产品射频前端要通过分时机制共享天线。Wi-Fi 有大流量的时候蓝牙的扫描窗口可能被整体推迟几十毫秒正好错过频率对齐的时刻。这个靠改 Page Scan 参数解决不了必须从共存策略入手比如给扫描窗口预留保护时间或者在检测到 Wi-Fi 空闲时加大扫描优先级。第三个嫌疑人是低功耗定时器的精度。前面提过用低频时钟定时唤醒的设备窗口位置会有抖动。测量方法是把实际窗口出现的时间戳打出来跟理论时刻做差如果差值随温度或电压漂移那就是时钟问题。解决方向是换高精度时钟源或者在窗口前后加保护带。第四个嫌疑人比较隐蔽主机层的 HCI 流量太大。如果设备同时在跑别的蓝牙活动比如定期读 RSSI、维持多个低功耗链路控制器内部的任务队列会积压扫描窗口的调度被延后。这个用 HCI 日志的时间戳能看出来命令下发和事件返回之间有异常延迟。4.3 耗电高占空比只是明面账算扫描功耗的时候很多人只算占空比这是不完整的。占空比算的是射频真正开着的时间但实际耗电还要加上唤醒开销。一次扫描的动作序列是定时器到期唤醒处理器使能射频等待频率合成器锁定开始监听超时关闭射频处理器回睡。这中间射频启动和锁定的时间可能是几百微秒处理器唤醒和回睡又是几百微秒。当窗口只有 11.25 毫秒时这些固定开销占比可能达到百分之十以上当窗口被压缩到更短时开销占比会更高甚至出现窗口越短越费电的反直觉现象。所以省电的优化方向不只是拉长间隔还要看唤醒成本。有些芯片支持在低功耗状态下直接由硬件定时器触发射频监听主处理器完全不参与这种架构下的功耗曲线会好很多。选型阶段如果功耗指标卡得紧这个特性值得作为评估项。还有一个容易忽略的点扫描期间的发射活动。Page Scan 收到 ID 包之后要回包这个回包是发射动作发射功耗远高于接收。如果设备处在干扰严重的环境里误触发回包的次数会增加功耗也跟着上去。这种故障的特点是实验室里功耗正常现场部署后电池掉得飞快因为实验室里没有那么多同频干扰。4.4 常见问题速查表现象高概率原因验证方法处理方向能搜到连接必超时Scan Enable 只开了 bit0读 HCI 命令参数或抓日志改为 0x02 或 0x03连接时好时坏成功率 70%~90%Interval 过长且未开交错扫描统计 100 次连接成功率与延迟分布降到 1.28 s 并开交错特定设备永远连不上换设备正常间隔与训练周期相位锁定改用交错扫描后是否立即恢复开交错或改非整数倍间隔低温或低电量时连不上低频时钟精度不足高低温箱和可调电源复测加保护带或换时钟源连接延迟比理论值大几百毫秒Inquiry Scan 抢占时间片关闭 Inquiry Scan 后复测状态切换时关掉 Inquiry现场部署后电池续航骤降干扰导致误触发回包现场抓包统计回包次数优化共存和天线匹配改参数不生效扫描使能状态下写参数被拒检查 Command Complete 的 status先关使能再改这张表里的每一条都是我在实际项目里遇到过的不是从文档里抄的。其中相位锁定和时钟精度这两条最值得记住因为它们的表现特别像随机故障一旦按常规思路去调参数往往会越调越乱。5. 验证闭环抓包、日志与时序对齐5.1 空口抓包怎么看Train与Window参数改完之后必须有验证手段光看连接成功率是不够的得能看到窗口到底出现在什么时候。空口抓包是最直接的方式一个简单的蓝牙嗅探器就能看到 page 序列的频率跳变和 ID 包的收发。看抓包记录时我的关注点有三个。一是窗口的周期是不是配置的 interval这个最容易验证量两次窗口起始的时间差就行。二是窗口出现的位置落在哪个训练周期里交错扫描应该看到窗口在 A、B 之间交替。三是 ID 包的交互有没有正常的往返如果只有发起方在发、被叫方完全不回说明窗口没开到或者射频没起来。需要注意嗅探器本身也有采样精度限制它报告的包到达时间会有几十微秒的误差。所以对比参数时看毫秒级的趋势就好别纠结微秒级的偏差。5.2 HCI日志时间戳对齐与计数器佐证空口抓包看的是外部视角HCI 日志看的是内部视角两者时间戳对齐之后能定位很多问题。具体做法是记录发起方发出 Page 命令的时刻以及收到 Connection Complete 事件的时刻这个差值就是端到端的连接延迟。同时看被叫方那边的唤醒记录如果被叫方的窗口时刻比预期晚了超过一个窗口长度那问题就在被叫侧。有条件的话再读一下控制器内部的状态计数器很多芯片会统计扫描窗口的总次数、实际完成的次数、因为冲突被跳过的次数。这三个数字一对比就能知道窗口有没有被吃掉。跳过次数占比高就去查共存和时间片总次数本身就不对就回去查参数下发。5.3 一套可复用的回归测试流程参数调好之后要固化下来我一般会建一个简单的回归流程每次固件改动都跑一遍。第一步固定测试环境。距离固定、姿态固定、周围干扰源固定最好放在屏蔽箱里做基线再做开放环境对比。第二步跑连接成功率。连续发起 100 次连接每次连接后主动断开统计成功率目标是 100%。第三步跑延迟分布。记录每次连接的端到端延迟看 P50 和 P95 两个分位值P95 是用户体验的真实感受。第四步跑边界条件。高低温、低电压、Wi-Fi 满负载、多设备并发这些场景下的参数表现才是产品的真实水平。这套流程跑下来大概半天时间但它能提前发现 90% 的现场问题。我吃过太多实验室能连、客户现场连不上的亏后来就学乖了参数改动一律跑完这四步再合入。最后分享一点个人体会。Page Scan 这套参数看着简单真正难的地方不在于记住几个数字而在于建立参数—延迟—功耗—成功率这条因果链知道动了哪个旋钮会往哪个方向漂漂多少。上面那张场景表和那个估算模型就是我自己用来做快速判断的工具实际项目里它们帮我省下的调试时间比任何一份文档都多。至于具体的取值每个产品的天线、结构、功耗预算都不一样起点值抄过去剩下的一定要拿实测数据说话。
