60 · 总览与学习地图 — CachedBluetoothDevice 精讲系列导航

这个系列是什么

CachedBluetoothDevice.java(f3dif 版,2719 行)做逐字段、逐方法、逐流程的解剖——蓝牙设置模块的心脏类。

CachedBluetoothDevice represents a remote Bluetooth device. It contains attributes of the device (such as the address, name, RSSI, etc.) and functionality that can be performed on the device (connect, pair, disconnect, etc.). —— 类头注释(:87-92)

车机蓝牙页列表里的每一个条目,背后都是一个 CachedBluetoothDevice 对象。读懂这一个类 ≈ 读懂蓝牙设置的半壁江山。

与既有知识库的分工(不重复造轮子)

既有文档覆盖本系列的关系
10-16 基础概念篇蓝牙协议地基(bond/ACL/UUID/SSP/profile 角色)前置阅读,概念不重复讲
20-Android蓝牙框架全景五层架构、日志 tag互补:它讲全景,本系列聚焦单类
21-settingslib架构与事件流七姐妹聚合、广播总线、connect 链三 flavor交叉引用:connect 链 flavor 对照引它 §3/§8
22-双flavor差异三 flavor 机制交叉引用:差异细节引它
03 模块流程发现/配对/详情 业务流程互补:它们按用户旅程,本系列按代码解剖
31-34 模块流程篇连接策略/上限/CarPlay/摘要状态机交叉引用:34 篇与 65 章互为表里
40-43 排障篇日志取证、案例方法论68 章延续其案例传统
51 速查卡术语/类职责/广播清单本系列是其中”CBD 一行”的展开

学习路径

flowchart LR
    A[61 身份地基<br/>三层状态模型] --> B[62 字段精讲<br/>40个成员变量]
    B --> C[63 对象的一生<br/>谁建谁删]
    C --> D[64 连接与断开]
    D --> E[65 属性刷新与回调]
    E --> F[66 bond与自动回连]
    F --> G[67 active与多设备]
    G --> H[68 实战案例走读<br/>8条真实JIRA]
    H -.反复对照.-> B
    style A fill:#e1f5ff
    style H fill:#fff4e1

零基础:61 → 62,卡住就回 10-16 概念篇 补课。只想快速建立全貌、或在 dcd(骁龙)平台干活:先读 69 dcddif 版全览(自成一体,f3dif 细节再回来补)。 有蓝牙基础:直接 62 → 63 → 68(案例驱动)。 排障救急:直奔 68 案例矩阵 + 40 篇取证速查改代码前:62 §10 惊喜点 + 63 §5(clearNonBondedDevices 三宗案)+ 22 flavor 检查清单

各章一句话

一句话核心知识点
61 一台蓝牙设备的 Android 身份bond/ACL/profile 三层状态独立,字段按此骨架生长8 种合法状态组合;透传 vs 缓存两类 getter
62 字段逐个精讲41 个实例字段分 9 组:是什么、谁写谁读、坑在哪mProfiles 主写入者是外部类;mConnectAttempted 注释骗人;60s 看门狗用 profileId 当 what;裸 HashSet
63 对象的一生四个诞生入口 → addDevice → 主表/挂组 → 连坐全清三类共享同一 List;单例永不销毁;clearNonBondedDevices 无通知
64 连接与断开用户点击 → 三道门卫 → mDevice.connect() 整机连接mProfiles 空放弃等 UUID;PBAP 兜底教训;setEnabled=改策略
65 属性刷新与回调分发一个字段变了到像素变化共 5 跳一张表两本账;双通道派发;UI 三层回调注册
66 bond 状态与自动回连状态机三分支 + ACL 记账 + 耐心窗口isBondingInitiatedLocally 闸门;f3dif 黑名单缺失(H6);窗口优先级敏感
67 active 设备与多设备四维 active、CSIP 组、换壳、电量三源单/双 active 并存;换壳 hash 陷阱;组最小电量
68 实战案例走读8 条已定案 JIRA 逐条对着代码讲知识点×案例矩阵;修复状态台账
69 dcddif 版全览dcddif 1456 行自成一体的小白导览 + 三方改动对照AOSP/高通/小米三血统;60s 看门狗;UUID 晚到补连;黑名单;改 dcddif 前必读

本系列的核心方法论(带走这三句)

  1. 字段 = 缓存的事件痕迹。读每个字段先问”哪个广播事件写它”——字段就活起来了;事件链断掉,缓存就永远陈旧(2960/3492)。
  2. getter 分两类:透传 vs 缓存。透传在时机不对时骗你(2403 的 OFF 窗口),缓存在事件丢了时骗你(3492 的分发盲区)。排障第一步先分类。
  3. 临界区里不做 bindersynchronized 里每一行都要问”这行会不会出进程”(134132 的 3.136 秒;2026-09-10 BtTrace 复测峰值 4.3 秒)。

事实基线声明

  • 所有行号基于 f3dif(A17 主线,base/settingsLibAndroid/src/f3dif/,文件 2719 行;该文件在 src/main/java 不存在,三 flavor 各一份独立副本)。
  • f3dif 的 CBD 无 MICAR-PORTING 标记(xcddif 33 行/dcddif 10 行),但含 MIUI MOD: BT_MIUIBluetoothFrame 块(:1152-1182)——纯上游 AOSP + 少量 MIUI 标记改动的最新基线。
  • git 历史仅 1 个提交触及该文件(5c4b19f85 一次性导入+A17 编译适配)。
  • 案例行号摘自 jira-data/{KEY}/analysis/root-cause.md 落笔时点(2026-07~08),复核以当前分支为准。
  • 本系列经对抗审查(3 个红队 Agent 逐章核对源码),审查记录见 _对抗审查记录

维护约定

  • 与本库一致:每篇事实带 file:line 锚点;新发现的事实冲突以 _已核实事实基准 为准。
  • 代码演进后(如 mDevice.connect() API 再变)请同步更新对应章节与本章基线声明。