智能手表与 App 蓝牙低功耗(BLE)实战指南
DemoApplication — 智能手表与 App 蓝牙低功耗BLE实战指南文档主题智能手表与手机 App 之间的通信常采用蓝牙低功耗BLE。相比经典蓝牙BLE 更省电、适合周期性小数据同步心率、步数、通知、固件升级进度等是穿戴设备的主流方案。大文件如MP3 音频若必须走 BLE需按分包与断点续传设计见下文第四章第 6 节。本仓库当前为Jetpack Compose示例工程minSdk 24/compileSdk 34可作为在此基础上接入 BLE 的起点。一、BLE 在手表场景中的常见用法能力说明GATT 客户端手机 App 通常作为Central中心设备手表作为Peripheral外设App 连接后读写特征值Characteristic。通知 / 指示手表主动上报数据使用Notify或IndicateIndicate 带应用层确认。写入指令App 向手表下发控制或配置对可写特征执行Write / Write Without Response。MTU 与分包数据量大时需协商MTU或在上层做分包与粘包协议。配对与绑定涉及敏感数据或防重放时可能依赖系统配对纯明文广播连接则未必每次配对。常见协议形态厂商自定义GATT Service/Characteristic UUID或基于标准服务如 Heart Rate、Battery 等再扩展私有特征。二、开发环境与本项目运行Android Studio建议 Hedgehog 及以上自带 JDK 与 Android SDK。设备真机推荐用于 BLE模拟器对蓝牙支持有限。运行用 Android Studio 打开工程根目录同步 Gradle 后选择设备运行app模块。当前入口MainActivity使用 Compose已实现BLE Demo权限门闸、扫描列表、连接、服务枚举、requestMtu、尝试读标准电量、WatchProtocol本地分包演示见ble与ui/BleDemoScreen包。三、Android 端实战步骤推荐顺序1. 声明权限随 Android 版本组合使用大致规律Android 12API 31起位置权限与蓝牙权限拆分扫描场景常需精确位置或新蓝牙权限组合具体以目标targetSdk与官方文档为准。清单中常见项名称以你最终 targetSdk 为准核对官方表BLUETOOTH/BLUETOOTH_ADMIN低版本BLUETOOTH_SCAN、BLUETOOTH_CONNECTAPI 31若扫描需满足「旧策略」ACCESS_FINE_LOCATION等BLUETOOTH_ADVERTISE若 App 需作为外设广播一般手表 App 较少实战要点在运行时请求危险权限连接前检查BluetoothAdapter是否可用、蓝牙是否开启。2. 扫描附近外设使用BluetoothLeScannerstartScan/stopScan。过滤按厂商提供的Service UUID或设备名前缀过滤减少列表噪音。节流避免长时间全量扫描耗电找到目标后及时stopScan。3. 建立 GATT 连接device.connectGatt(context, false, callback)在BluetoothGattCallback中处理onConnectionStateChange已连接 / 断开onServicesDiscovered发现服务后枚举Service → Characteristic → DescriptoronCharacteristicRead/onCharacteristicWrite/onCharacteristicChangedNotify 数据4. 打开 Notify / Indicate对 CCCDClient Characteristic Configuration Descriptor写入ENABLE_NOTIFICATION_VALUE或ENABLE_INDICATION_VALUE。在onDescriptorWrite中确认成功后再认为「订阅就绪」。5. 读写业务数据读readCharacteristic注意队列部分机型不宜连续无等待地堆叠操作。写根据固件约定选择Write With Response或Without Response。协议与手表固件约定好字节序、命令字、长度、校验CRC 等及错误码。6. 断开与释放disconnect()后close()避免泄漏页面销毁或退后台策略要与产品一致部分场景需保持连接。7. 前台服务可选但常见长时间同步或 OTA 时使用Foreground Service 类型合适的foregroundServiceType避免被系统强杀并符合后台限制。四、大量数据如走路步数怎么传BLE 单次 ATT 载荷受MTU限制步数若按「每分钟/每小时一条」累积成几天历史很容易超过单包长度必须在应用层协议和产品形态上一起设计。1. 能少传就少传摘要优先实时连接期间只推「当前会话增量」或「今日累计」字节很少。历史不要传原始传感器流用按天/按小时聚合的结构时间戳 步数 可选距离/卡路里必要时再支持「拉取某一天明细」。二进制紧凑定长记录或小端整数数组避免 JSON/XML 占满 MTU。2. 必须传大包时MTU 分包 确认协商 MTU连接建立后调用requestMtu()具体上限因手机与手表协议栈而异常见在约 185247 字节有效 ATT 载荷量级以实测为准。自定义分包帧例如「命令字 总长度 分片序号/总分片数 载荷 CRC」。手表按序发 Notify或 App 读长数据App 侧重组缓冲区丢包则重传某片。流控每发 N 包等一层 ACK或 Indicate避免手表 RAM 与控制器队列溢出导致断连。Indicate vs Notify大批量若要求可靠可对关键片用Indicate有确认或仍用 Notify 但在应用层发 ACK 包。3. 传输路径选择Notify 推流手表主动推适合「同步历史」会话注意 Android 端串行化 GATT 操作不要无脑并发写。Read 分块固件把历史放在「逻辑块」里App 发「读第 k 块」命令再readCharacteristic或走私有「块特征」便于断点续传。Prepare Write / Long Write标准上适合较长写入穿戴里更常见仍是厂商自定义分包实现简单、两端一致即可。4. 吞吐与体验连接间隔主要由系统与对端协商App 能控制的有限大批量同步时保持屏幕常亮、前台服务减少被限速或杀后台。PHY若双方支持2M PHY在可接受距离内有利于提高速率仍远低于经典蓝牙。失败重试超时、CRC 错误、只收到部分分片时从最后成功序号续传。5. 与「经典蓝牙」的取舍若手表同时支持经典蓝牙SPP 等且产品允许配对两套栈大批量文件类同步可走经典通道纯 BLE 手表则按上文分包与聚合设计即可。6. MP3 / 音频文件传输MP3 属于已压缩的二进制大文件常见数 MB与步数不同不能靠「聚合摘要」缩小只能整文件按字节搬运技术本质与固件 OTA 分包相同只是落盘路径与格式校验不同。能力预期BLE 实际吞吐受连接间隔、PHY、对端实现影响常见在每秒数十 KB 量级以双端实测为准。一首 5MB 的 MP3 纯 BLE 可能要数分钟甚至更久且耗电、占连接需有明确 UI进度、取消、后台策略。不要再压一层「通用压缩」MP3 本身已压缩gzip 等收益很小徒增 CPU。协议层面与上文「分包 流控」一致定义文件会话fileId或路径 token、总长度、分片大小建议与协商 MTU 对齐留出帧头/CRC 空间、分片序号、载荷、CRC32/SHA256整文件校验。断点续传持久化「已确认收到的最大连续偏移」重连后从该偏移继续避免用户反复全量传。方向通常是手机 → 手表下发铃声、离线播客片段若手表回传录音 MP3思路相同但注意手表侧存储空间与写闪存寿命。存储与格式固件约定写入路径如「音乐分区」、单文件上限可选先写到临时文件再rename做原子提交避免半截文件被播放器打开。产品形态上的更优解优先评估手表带 WiFi / 配套手机热点大文件走 HTTP(S) 或厂商私有 WiFi 通道体验远好于纯 BLE。经典蓝牙A2DP/SPP 或厂商大通道适合「传歌到表」类场景若硬件支持应优先考虑。只做短音频闹钟、提示音可用几十数百 KB 的短片段甚至降级为低码率或专用提示音格式显著缩短 BLE 传输时间。Android 实现注意读本地 MP3 用顺序流式读取FileInputStream/MappedByteBuffer分块避免一次性readBytes()整文件进内存。传输会话放在前台服务中执行并处理系统杀进程、蓝牙断开后的恢复与重试。五、与手表固件协作的检查清单UUID 表主服务 UUID、各特征 UUID、属性读/写/Notify、字节布局文档。连接参数是否要求指定 PHY、连接间隔偏好由固件与主机协商但需知预期。安全是否加密、是否必须配对、密钥与证书流程。OTA分包大小、断点续传、校验与回滚策略。调试工具手机端可用nRF Connect等 App 对真实手表 GATT 做探查与 Android 日志对照。六、常见问题与排查现象可能原因扫描不到设备权限未授予、蓝牙关闭、手表未处于可发现模式、过滤条件过严连接立刻断开UUID 不匹配、固件只允许单连接、RSSI 过弱、固件侧拒绝Notify 无数据CCCD 未写成功、订阅错特征、固件未推数据写入无响应特征不可写、需 Write Without Response、MTU/长度超限调试时打开HCI snoop或使用厂商抓包工具可快速区分是 App 层还是协议/固件层问题。七、在本项目中落地的建议结构Kotlin便于维护的拆分方式示例思路非强制目录名BlePermissions统一请求与解释权限文案BleScanner扫描生命周期与回调转换GattClient封装BluetoothGatt、队列化读写、重连策略WatchProtocol纯 Kotlin 的组包/解包与 UI 解耦UI 层Compose只观察状态已连接 / 扫描列表 / 最新心率等不直接操作 GATT 细节依赖上可逐步引入Kotlin 协程MutableStateFlow向界面层推送状态若后续需要蓝牙相关 Jetpack API再按官方文档添加对应依赖版本。点击跳转代码链接https://gitcode.com/qq_33495943/watchesBLEAPP
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2598894.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!