高级专项扩展与加分项 (Specialized Topics)

一句话定位

这一模块是 P2 级加分项：不影响主线能力，但在物联网 / 实时音视频 / 鸿蒙生态三个特定业务方向拉开差距。每个专题都按“协议/模型怎么工作 → 端上怎么落地 → 常见事故怎么排障”展开，可独立复习。

优先级声明：只有当 01~08 主线模块已建立稳定骨架后，才建议投入本模块；它不是抢主线篇幅的内容。

模块成熟度与推进策略

当前模块可视为：BLE 已进入文档 + 最小实验闭环，WebRTC / Harmony 先完成边界收口。

• 已有：BLE / WebRTC / Harmony 三篇成文专题
• 新增：BLE Android host 最小样板 + docs ↔ labs 双向跳转
• 缺口：WebRTC 与 Harmony 仍未进入真实宿主实验阶段

因此，本模块的推进策略不是三条线并行摊大，而是：

1. 先做 BLE：最贴近 Android 主线，也最容易做成稳定最小实验
2. 再做 WebRTC：价值高，但工程链条长，先把状态机与承载模型收清楚
3. 最后做 Harmony：更偏生态理解与适配判断，短期先把迁移边界与后续宿主计划讲透

先记住一个原则：专项是“少而精”，不是“多而散”

例子：为什么 BLE 应该先于 WebRTC 和 Harmony？

• BLE：可以直接复用 Android 侧能力，最容易把“权限 → 扫描 → GATT → 队列 → 重连”做成最小可运行实验
• WebRTC：除了端上媒体，还涉及信令服务、ICE、TURN、弱网策略，实验链路更长
• Harmony：对理解生态很有价值，但短期更偏“认知型专题”，不如 BLE 容易先形成 L3 资产

本模块要回答的问题

• BLE 设备连接为什么容易“连上又掉”？
  • 一句话答：GATT 操作必须串行、连接有 MTU/间隔约束、系统扫描/连接竞争激烈；用操作队列 + 断线指数退避重连才能稳（详见 01 与 BLE Lab）。
• WebRTC 为什么需要信令服务器，P2P 又怎么穿透 NAT？
  • 一句话答：媒体流走 P2P（STUN/ICE 打洞），但双方发现与 SDP 交换需要信令服务器；打洞失败时降级 TURN 中继（详见 02）。
• HarmonyOS NEXT 和 Android 的本质差异是什么？
  • 一句话答：NEXT 移除 Android 兼容层，必须按 ArkTS + ArkUI 宿主重建；Flutter 侧能复用 Dart，但插件和平台桥接不能偷懒（详见 03）。

子主题清单

序号	主题	文档	当前状态	核心判断
01	蓝牙与 BLE 硬件交互	01. 蓝牙与 BLE 硬件交互	已有 Android host 最小实验	GATT 状态机 + 操作队列 + 断线重连
02	音视频与 WebRTC 实时通信	02. 音视频与 WebRTC 实时通信	先收边界，不造空实验	信令 + ICE 穿透 + 编解码选型
03	鸿蒙开发（HarmonyOS / ArkTS）	03. 鸿蒙开发（HarmonyOS / ArkTS）	先收边界，不造空实验	Stage 模型 + ArkUI 响应式 + Flutter 适配路径

---

01. 蓝牙与硬件交互 (Bluetooth)

→ 详见 01. 蓝牙与 BLE 硬件交互

核心要点：

• BLE (Bluetooth Low Energy) 概念与传统蓝牙区别
• 设备扫描、过滤与连接生命周期（权限 Android 12+ 拆分）
• GATT 服务 (Service)、特征 (Characteristic) 读写与 Notification 订阅
• 操作队列解决 GATT 串行问题（status=133 排障）
• 蓝牙断线重连指数退避策略
• 已落地最小样板：ble-gatt-playground

02. 音视频与 WebRTC 实时通信

→ 详见 02. 音视频与 WebRTC 实时通信

核心要点：

• 音视频编解码 (AAC / H.264 / H.265 / AV1) 选型
• WebRTC 架构原理 (MediaStream / PeerConnection)
• 信令服务器 (Signaling Server) + SDP Offer/Answer 交换逻辑
• P2P 穿透机制 (STUN / TURN / ICE) 与 TURN 中继成本
• 弱网保障：BWE / FEC / NACK / Simulcast
• 当前只收承载计划，不创建空实验目录

03. 鸿蒙开发 (HarmonyOS)

→ 详见 03. 鸿蒙开发（HarmonyOS / ArkTS）

核心要点：

• HarmonyOS NEXT：完全移除 Android 兼容层，必须用 ArkTS + ArkUI 重写
• Stage 模型 UIAbility 生命周期与 Android Activity 对比
• ArkTS 语法特性（严格 TypeScript + 响应式装饰器）
• ArkUI 状态管理：@State / @Prop / @Link / @ObjectLink
• Flutter 应用跨端适配鸿蒙（flutter_harmony）最低成本路径
• 当前只收宿主模型与插件边界，不创建空实验目录

---

推荐阅读路径：按业务方向走

路径 A：接物联网 / 穿戴硬件

1. 01. 蓝牙与 BLE 硬件交互（BLE 扫描 → GATT → 操作队列 → 重连）
2. 对照最小实验：ble-gatt-playground
3. 前置补位：Android 权限与后台限制见 ../03-background-tasks/README.md

路径 B：做音视频 / 通话 / 直播

1. 02. 音视频与 WebRTC 实时通信（编解码 → 信令 → ICE → 弱网保障）
2. 前置补位：弱网与长连接治理见 ../06-backend-data/08-weak-network-websocket-grpc-reconnect.md
3. 记住：本仓库当前先不伪造 WebRTC 实验，后续优先补状态机回环样板

路径 C：适配鸿蒙生态

1. 03. 鸿蒙开发（HarmonyOS / ArkTS）（Stage 模型 → ArkUI 响应式 → Flutter 适配）
2. 前置补位：Flutter 引擎与线程模型见 ../01-runtime-concurrency/14-flutter-engine-threads.md
3. 记住：先盘插件与宿主成本，再谈 Dart 复用率

对应 labs 规划

• ble-gatt-playground — BLE 设备扫描 + GATT 读写 + 操作队列 Android Demo（已落地，第一优先级完成第一步）
• labs/flutter/host/topics/specialized-topics/webrtc-signaling-loopback/ — Flutter 端 WebRTC 最小状态机样板（第二优先级，尚未创建，先收边界）
• labs/harmony/host/topics/specialized-topics/arkts-state-routing-basics/ — ArkUI 基础组件 + 状态管理 Demo（第三优先级，尚未创建，先收边界）

BLE 样板最少应包含什么

1. Android 12+ 权限申请分支
2. 扫描 → 连接 → discoverServices → read/write/notify 的完整时序
3. 操作队列
4. status=133 与 gatt.close() 的排障示例
5. 断线重连与资源清理

当前已经补到：最小状态机样板 + 回链说明 + 主文档三处链接闭环。

复习检查题

1. 为什么 BLE 优先于 WebRTC 和 Harmony 成为本模块第一个真正落地的实验？

   答：因为 BLE 更贴近 Android 主线，依赖链更短，最容易做成“权限 → 扫描 → GATT → 队列 → 重连”的最小稳定样板；WebRTC 和 Harmony 的宿主与外部依赖更长，先补边界更可信。

2. 为什么本模块强调“少而精”，而不是三条线一起铺实验目录？

   答：因为专项模块的价值在于形成少量高质量、可复习、可验证的样板；如果先铺很多空 README 或空目录，只会制造已落地假象，维护成本高且复习价值低。

3. WebRTC 和 Harmony 当前为什么只做边界收口，不硬造实验？

   答：因为两者都缺少足够稳定的宿主承载与真实代码样板；此时强行创建实验只会停留在概念重复，无法形成真正可运行、可验证的资产。

速记

• 专项模块先做离 Android 主线最近的 BLE。
• BLE 已有最小实验闭环，WebRTC / Harmony 先收边界。
• 不要为了“看起来完整”去造空实验。
• P2 的目标是形成少量高质量样板，不是铺目录。