43 · 经典案例:蓝牙「慢」分段定位(MANNPROB-3187)

方法论首案:凡”蓝牙慢”,先画调用流程、再量日志时序、分段标注、按段定责。 配套手册:jira-analyze skill references/bt-latency-playbook.md(基准表持续累积)。

1. 现象与误区

• 现象:双设备关开蓝牙,列表先「已保存」数秒再「正在连接」「已连接」;测试反馈”提测包依旧复现”
• 误区 1(测试侧):复现视频录于装包前 2 分钟(车钟 09:54:48 < installPackageLI 09:57:07),证据链不成立
• 误区 2(分析侧):初期把窗口笼统写成”栈层启动延迟 1.5~5s”——后被实测修正:启动(广播)很快,慢在建链

2. 调用流程(代码侧)

协议栈 → 广播 ACTION_CONNECTION_STATE_CHANGED
 → Settings BluetoothEventManager → CachedBluetoothDevice 状态机
 → ①设备自身 refresh→getDeviceSummary 三分支
 → ②Controller 回调→setConnecting(362953 PS3 起按设备过滤)
摘要判据:isConnected→已连接 / isBusy&&mIsConnectingState→正在连接 / else→已保存

3. 日志时序实测(三周期互证,ON 后偏移)

里程碑	08-11 周期A(旧包)	08-11 周期B(PS3包)	07-29(田子豪日志)
ON→栈发起建链(Connecting)	+55ms	+40ms	+63ms
ON→首 CONNECTING 广播到车机侧	+77ms	+67ms	+64ms
第一台 HFP 建链	3.83s	1.23s	1.13s
第二台 HFP(串行)	+3.92s 起,1.52s	+1.33s 起,3.36s	+1.21s 起,1.82s
双设备全连完	+5.45s	+4.70s	+3.12s

4. 分段标注

flowchart LR
    ON[Adapter ON] -->|40~77ms ✅快| BC[广播段]
    BC -->|07-29 实测 +37ms ✅快| APP[App 接收段]
    ST[建链段] -->|HFP 1.2~3.8s/台<br/>串行 4~5.5s ❌慢| DONE[全连完]
    APP --> UI[UI 映射段]
    UI -.->|旧包 bug:跨设备污染/置灰波动<br/>✅已修 362953 PS3| FIXED[已修]
    ST -.->|同 App:A14 快/A17 fermi 慢<br/>差集=平台栈| STACK[协议栈责任]

5. 结论与定责

1. 广播段不慢(40~77ms 三周期互证)——“广播回调慢”的写法会被栈侧打回,务必写成”建链慢”
2. 建链段慢 = 协议栈责任:A17 fermi 双设备串行全连完 4~5.5s;测试同学用同 App 逻辑在 XCD A14 复测明显更快 → 差集只剩平台栈 → 转协议栈团队,附打点建议(ON→首个 ACL Create Connection 时延 / 串行调度间隔 / HFP SLC 耗时)
3. UI 映射段 bug(3187 跨设备污染 / 3205 置灰波动)已修,装包后日志摘要计算全对
4. 「已保存」等待文案 = 语义项(AOSP 原生此处空白),乐观标记方案待产品裁决,非阻塞

6. 可复用要点

• 录屏时刻 vs 装包时刻两查(抽帧读车钟 + grep installPackageLI)——先证被测件是被测件
• 每段必须实测,无打点的段标”未观测”,禁止估算冒充实测
• 双设备串行回连是设计,总时长长≠异常;异常=单台建链超基线
• 同 App 跨平台一快一慢是最强定责证据