今年做完一款运动手环的量产项目产品定义里最重要的一条是“用户不用装App扫码就能看数据”这就把技术路线硬生生掰到了蓝牙SoC加微信小程序上。整条链路做下来我觉得最核心的决策就是选对Bluetooth Smart SoC并且把可穿戴设备的协议层、功耗模型和微信App侧的数据通道一次想清楚。这篇文章不聊虚的就复盘一下这个“蓝牙SoC把可穿戴设备连到微信”的项目选型怎么考虑、协议怎么定、小程序怎么写、联调踩了哪些坑给正在做类似智能手环、心率带、贴片传感器或者任何轻量级可穿戴项目的朋友一个可落地的参考。1. 项目整体设计与思路拆解1.1 为什么把SoC选型放在第一步可穿戴设备的核心芯片选型基本决定了整个产品的功耗天花板、成本空间和开发难度。市面上常见方案主要有三类第一类是Nordic nRF52系列SDK成熟资料多社区活跃做原型验证最快第二类是Dialog、Cypress现在叫Infineon这些老牌BLE SoC稳定性好但工具链上手需要时间第三类是国产的泰凌微、奉加微、杰理等芯片成本可以压到很低但SDK和文档的完善程度参差不齐。我这个项目选的是nRF52832理由很直接需要同时跑传感器采集、自定义GATT服务和较为复杂的应用层协议Flash和RAM要够用nRF52的GPIO和SPI外设够多接加速度计、心率传感器都不吃力网上案例多遇到问题搜得到答案对项目交付时间敏感的场景来说生态是硬指标。选型时还有一个容易忽略的点就是射频前端和天线匹配。很多SoC虽然标称-20dBm到4dBm输出功率但实际天线环境、PCB布局对信号影响很大。可穿戴设备为了体积会把天线区域做得很小如果匹配网络没调好发射功率再高也是白搭。所以选型阶段一定要留出射频调试的样品周期别等固件写完了才发现信号距离不够。1.2 微信小程序为什么够用刚开始我们也讨论过要不要做原生App。结论是对于非专业运动人群让人下载一个App再注册登录这个门槛足以劝退一多半用户。微信小程序的蓝牙API已经覆盖了从扫描、连接、服务发现到读写通知的完整流程而且用户本来就在微信里从扫码到看到数据只需要几秒体验完全不一样。更重要的是微信小程序天然解决了跨平台问题。Android和iOS的蓝牙权限模型差异很大用原生开发得维护两套代码而小程序把这层差异封装在微信的统一接口下虽然偶尔还会遇到平台差异的坑但比原生省太多事。当然小程序也不是万能它对后台运行限制很严页面切到后台后再想持续收蓝牙数据大概率会被回收大流量连续传数据也会受手机蓝牙协议栈和微信本身的限制。所以产品设计上要把数据同步做成“用户主动触发”而不是设备端拼命往外推。1.3 端到端数据流与整体架构整个系统的数据流向是这样设备端的加速度计和光学心率传感器采集原始数据经过滤波算法存在SoC内部Flash用户打开微信小程序触发同步时SoC把历史数据按照自定义协议分帧封装通过BLE Notify发给手机端小程序小程序解析出计步、心率、睡眠等指标后一边刷新本地页面一边通过HTTPS上传到云平台。设备端分成四层传感器驱动层、数据处理算法层、应用协议层和蓝牙协议栈层。蓝牙协议栈这一层我基本不自己写直接用SoC厂商的SDK把精力放在广播包、GATT服务和连接参数的配置上。小程序端则分成设备管理模块、协议解析模块和UI展示模块每个模块之间用清晰的数据结构解耦。2. 设备端固件设计与协议要点2.1 广播包里的学问BLE广播包是让手机找到设备的第一道门微信小程序扫描时看到的设备名、信号强度、服务UUID都来自这里。广播包格式遵循BLE标准由若干AD Structure组成每个AD Structure的第一个字节是长度第二个字节是类型后面才是真正的数据。我强烈建议在广播包里至少包含三类信息Flags标志设备可连接可扫描、Complete Local Name完整设备名、Service UUID自定义服务的128位UUID。如果想让设备名在扫描列表里稳定显示最好放到广播包里而不是扫描响应包里因为很多手机系统扫描响应包不一定每次都拿得到尤其是在设备密集的区域。一个容易踩的坑是设备名长度。BLE广播包最长31字节放进Flags、UUID和设备名之后经常超超长的结果不是丢字段就是整个包异常。我的习惯是设备名控制在10个字符以内UUID用128位完整广播这样Scan Response还能留出空间放厂商自定义数据比如设备固件版本、电池电量。2.2 GATT服务与特征定义连接建立后数据交换靠的是GATT通用属性协议里的Service和Characteristic。很多新手一上来就建一个自定义服务把所有数据塞在一个特征里这样后面扩展和排查都会很难受。可穿戴设备建议至少分四个服务GAP服务0x1800系统管理、设备信息服务0x180A厂家、型号、序列号、电池服务0x180F电量百分比、自定义数据服务0xFFF0业务数据。自定义数据服务里再按功能拆成多个Characteristic我试过把以下几个特征放在同一服务下比较顺手特征名称UUID属性数据方向用途实时数据通道0xFFF1Notify设备到手机实时心率、步数波形历史数据通道0xFFF2Notify设备到手机批量同步历史记录控制命令通道0xFFF3Write手机到设备校时、开始结束运动、清数据设备信息通道0xFFF4Read手机到设备版本号、硬件号、序列号每一个Characteristic的Notify属性背后要正确配置CCCD客户端特征配置描述符也就是手机订阅通知时实际写入的那个描述符。如果设备端固件没有把CCCD的读写权限配置好小程序调用notifyBLECharacteristicValueChange会一直失败这种问题查起来最磨人。2.3 连接参数、功耗和电池估算BLE连接建立后设备端和手机端通过一组连接参数通信核心有三个连接间隔Connection Interval、从机延迟Slave Latency和监督超时Supervision Timeout。连接间隔决定了主从两端多久交换一次数据间隔越小实时性越好但功耗越高。我的经验是实时心率传输用11.25ms到15ms的连接间隔同步大量历史数据时用7.5ms到10ms平时不传数据时把间隔拉长到100ms以上。从机延迟允许从设备跳过几次连接事件是省电的大杀器可以设置到4到9个事件这样设备可以睡得更久但首包响应会变慢。电池寿命可以粗略估算假设电池容量100mAh待机仅RTC和内存保持平均电流2uA广播平均电流50uA连接传输平均电流2mA如果用户每天连接两次每次10分钟其余时间待机那么一天消耗约0.7mAh理论上能撑100天以上。但实际上锂电池自放电、传感器常开、电压转换损耗都会吃掉电量所以设计目标我一般按理论值打五折。2.4 应用层协议设计BLE单包默认最多承载20字节MTU为23时就算协商到MTU 247单包也只有244字节传不了大块数据。所以设备端和小程序端必须约定一套应用层协议我的习惯是采用“帧头长度命令序号数据校验”的结构帧头固定0xAA 0x55用来快速对齐。长度表示数据和命令区的总字节数。命令区区分实时数据、历史数据、控制命令。序号用于解决分包乱序问题。校验用简单的累加和就够了如果对数据完整性要求高就换CRC16但对可穿戴设备场景累加和配合超时重传已经很稳。历史数据同步时设备端按固定时间片打包比如每包放10个计步采样点加一个2字节的采样时间戳小程序端收满一组再解析这样即使丢一两包也能通过序号补传不会导致整个数据流错乱。3. 微信小程序端从扫描到数据可视化3.1 权限配置和蓝牙初始化微信小程序连接BLE设备的第一步不是写代码而是配置权限。开发工具里如果发现调用蓝牙接口报错“api scope is not declared”多半是没在app.json里声明隐私接口。我的做法是直接在app.json的requiredPrivateInfos数组里把蓝牙相关的API全列上省得后面一次一次补{ requiredPrivateInfos: [ getBluetoothAdapterState, startBluetoothDevicesDiscovery, stopBluetoothDevicesDiscovery, createBLEConnection, getBLEDeviceServices, getBLEDeviceCharacteristics, readBLECharacteristicValue, writeBLECharacteristicValue, notifyBLECharacteristicValueChange ] }Android端还有一个特殊要求搜索蓝牙需要定位权限。小程序里需要在页面初始化时检查是否已授权位置信息没有的话通过wx.getSetting和wx.authorize引导用户授权。很多开发者在Android上搜不到设备不是蓝牙本身的问题而是定位权限没开。初始化蓝牙适配器的时机也值得注意。不要在用户进入页面时立刻openBluetoothAdapter而是等用户点击“开始连接”再初始化这样既符合用户预期也能减少不必要的权限弹窗干扰。3.2 扫描、过滤和连接初始化蓝牙后调用startBluetoothDevicesDiscovery开始扫描。这个接口有个services参数可以传入你关心的服务UUID数组系统会只回调广播中包含这些服务的设备。加上这层过滤能省很多事否则开放环境里到处都是耳机、音箱、手机设备UI上会显示一堆没用的设备。扫描结果通过wx.onBluetoothDeviceFound回调接收这个回调在扫描期间会持续多次触发同一个设备会重复出现所以前端要用deviceId做去重。设备列表中除了设备名和RSSI信号强度最好把广播数据里的厂商自定义数据也解析出来用来识别你是自家设备还是别家设备避免用户连到邻桌的同类手环。连接时调用createBLEConnection传入deviceId大约需要几十毫秒到几秒不等。遇到连接失败或超时不要马上重试最好间隔1秒以上再试。连接建立后也要监听wx.onBLEConnectionStateChange当蓝牙连接意外断开时提示用户并自动回退到扫描状态。3.3 服务发现、通知订阅和数据写入连接成功后要先调用getBLEDeviceServices拿到设备上的所有服务再根据目标服务UUID调用getBLEDeviceCharacteristics拿到特征列表。这一步是异步的需要等待回调返回才能继续。拿到特征后要接收设备主动推送的数据就必须调用notifyBLECharacteristicValueChange开启通知。这里我再强调一遍设备端固件里的CCCD配置、特征属性、service UUID和客户端代码必须完全对得上任何一个不一致都会导致打开通知失败。写数据到设备时最稳妥的做法是先调用writeBLECharacteristicValue写入命令等成功回调后再通过wx.onBLECharacteristicValueChange接收设备返回的数据。同一时刻不要连续多次发送写请求写完一条等一条这样能避免设备端的接收缓冲溢出。iOS平台对单次写入长度卡得很死超过20字节可能直接失败所以无论Android端能不能发更长数据我都按20字节分包发送等上一包的写入成功回调再发下一包。这样两平台表现一致设备端固件也只需要按20字节处理。3.4 数据解析与UI更新从onBLECharacteristicValueChange回调里拿到的是ArrayBuffer需要转成DataView或Uint8Array再按协议逐字节解析。我通常会在小程序里建一个ProtocolParser类专门负责从字节流里找帧头、剥长度、校验和重组成完整数据帧。解析出实时心率、步数后UI更新要做节流。蓝牙回调频率可以达到每20ms一包如果每包都setData整个页面会卡到没法看。我用的是简单节流每500ms到1秒统一更新一次当前心率值同时把过去10秒的心率曲线渲染到canvas上。曲线数据保留在内存数组里页面滚动和切换Tab时也不清空保证用户切回来看曲线还是连续的。历史数据同步的UI体验也要设计好。同步通常要持续几十秒如果只显示一个进度条用户会以为死机。我做了两层进度先是包计数进度已接收xx包/总xx包再是解析完成后的入库进度。每次收到一组完整历史数据就更新一次用户能明显感觉到画面在走。3.5 小程序生态的扩展点当设备数据在小程序里被解析出来后怎么利用微信生态是个值得多想的问题。我的项目里接了两个点一个是用户授权后把步数、心率、睡眠数据上传到自己的服务器生成每周运动报告通过公众号模板消息推送给用户。这个体验比在App里看报告轻很多用户点开消息就能看到完整报告。另一个是分享功能。小程序自带分享到好友、群聊的能力我做一个“心率挑战周榜”用户可以把设备绑定状态分享到群里群友点击卡片直接进入小程序查看排名。不过这类功能要格外注意隐私必须明确告知用户哪些数据会公开并且提供关闭公开的选项。4. 联调过程与关键参数实测4.1 调试工具矩阵联调BLE项目光靠微信开发者工具是不够的。我的工具清单是手机端装nRF Connect和LightBlue用来验证设备端的广播、连接、GATT服务是否正常电脑端用串口蓝牙终端PC上的BLE调试工具直接将数据打到设备端能让设备侧日志快速暴露问题如果还要查空中包和时序问题就上BLE Sniffer抓包配合Wireshark看连接事件、MTU协商和每包的RSSI。微信开发者工具本身不支持蓝牙模拟必须在真机上跑。建议准备一台Android一台iPhone因为两边对蓝牙权限和后台表现差异很大。我联调阶段几乎是左手Android右手iPhone同一时间两台手机分开测避免“在Android上好的、在iPhone上坏了”这种问题等到发布前才暴露。4.2 四步联调法我习惯按下面这个顺序联调每一步都验证通过再做下一步第一步先打开nRF Connect扫描设备确认设备名、广播服务和信号强度正常连接后逐个看服务、特征、通知、读写是否正常。这一步能排除掉一半的固件基础问题。第二步用电脑串口蓝牙终端发送和接收自定义协议数据验证设备端应用层协议的解析、校验、应答逻辑尤其是异常帧、半包、粘包的处理。这样在手机端出问题前先确保设备协议本身是好的。第三步在微信开发者工具里写一个最小demo只连接、开通知、收一包数据、打印数据验证微信API调用链路没问题。这一步跑通了再开始写完整业务逻辑。第四步把完整小程序和完整固件同时跑起来做长时间稳定性测试至少连续运行4小时观察内存、掉线和数据错误率。4.3 MTU与真实传输速率MTU是数据链路层一次能传的最大长度BLE默认ATT_MTU为23字节去掉3字节头有效载荷只有20字节。连接建立后客户端可以发起MTU协商请求如果设备端固件允许MTU可以升到247字节单包有效载荷变成244字节。微信小程序端的API虽然提供wx.requestBLEMTU但实际是否生效受基础库版本和手机系统影响较大。我遇到的情况是iPhone上连接后系统经常自动协商到185或247Android则取决于手机蓝牙芯片。所以客户端解析数据时不能假定固定包长必须每次按实际收到的字节长度来处理。理论速率可以这么算连接间隔15ms每个连接事件发一包20字节速率约为20/0.015≈1.33KB/s把MTU升到247、连接间隔压到7.5ms理论速率能到约32KB/s。但这只是理想值实际还要算上丢包重传、系统调度、手机蓝牙栈开销能跑到理论值的一半就很不错了。4.4 功耗实测和电池规划功耗不能只看芯片手册必须拿整机实测。我用万用表串联电池测量平均电流分别在待机、广播、连接传输三个状态持续记录。实测下来待机整机电流约2.5uA这个数值受传感器供电策略影响很大传感器不工作时必须彻底断电而不是留待机模式广播状态整机电流约60uA广播间隔设置为250ms连接实时传输时整机电流约1.8mA峰值电流到过6mA。按这个数据评估100mAh电池如果每天连接传输1小时其余时间待机一天电量消耗约1.9mAh理论待机约52天。但为了保险我在产品设计上留了30%的冗余把目标设定为40天并且加入低电量提醒。这里想提醒的一点是不少可穿戴设备翻车就翻在待机电流没做干净传感器没断电、LED在无谓地闪、DCDC在空载时没进入轻载模式这些都是隐藏耗电大户。5. 常见问题排查与避坑指南5.1 设备搜不到先查这几项“点击扫描什么都搜不到”是最高频的问题。我的排查顺序是先用nRF Connect扫描看设备是否在广播如果nRF Connect能搜到而小程序搜不到问题多半在小程序的过滤条件、权限声明或Android定位权限。现象可能原因排查动作完全无设备出现设备没在广播检查固件广播配置确认广播开关打开Android搜不到、iOS正常定位权限未开小程序授权位置信息或检查系统权限能搜到名字但点连接失败设备已连接其他手机断开其他设备或重启设备恢复广播搜索列表太乱找不到目标广播包过滤条件不对通过services参数过滤或解析广播厂商数据设备名显示为空广播包没有完整名字在广播包加Complete Local Name放Scan Response可能不稳定5.2 连接后频繁断开连接了但几秒钟就断开常见原因有三类连接参数不被手机接受、设备供电不足导致复位、信号质量差导致监督超时。监督超时是BLE的看门狗机制如果连接间隙内没收到对方的数据包连接就被判死。解决办法是把监督超时配置得足够长一般设为连接间隔的20倍以上避免偶尔一两包丢失就触发断开。还有一个很隐蔽的问题设备固件里如果在处理Flash写入或者复杂计算时把蓝牙中断block住太久也会导致手机认为设备失联。我的解决办法是尽量减少在蓝牙回调里做耗时操作所有Flash写入都放到后台任务里并且用信号量通知蓝牙线程避免抢占。5.3 数据丢失、错乱和写失败数据包收到但解析出来是乱的先检查帧同步。帧头0xAA 0x55有时会出现在数据区里如果对端只靠帧头找起始位置很容易错位。我的做法是在帧头之后加一个2字节的包长度校验并且对整个帧做CRC错3包自动恢复同步。写失败的问题多半是单包长度超限或发送间隔太密。iOS单次写入超过20字节大概率失败所以客户端不管Android是否支持一律按20字节切包。同时发送每包之间必须等待上一包写入成功回调如果连续发设备端缓冲区会被打满后面几包就会丢。调试阶段我的建议固件开发初期用nRF Connect先验证GATT和协议协议调试中期用PC串口蓝牙终端做高频率压力测试小程序联调前确保用手机验证过一遍核心流程稳定测试阶段双平台真机长时间跑加RSSI记录抓网络问题5.4 微信特有的坑小程序连接BLE和原生App有很大差别有些坑只会在微信生态里出现第一小程序必须在app.json里声明requiredPrivateInfos漏掉任何一个蓝牙API名称调用时直接报错。这个声明要提前做不要等代码写完再补因为优化缓存经常导致配置不生效。第二微信开发者工具的模拟器不支持蓝牙扫描和连接只能真机调试。开发时别忘了把基础库版本调到支持对应API的版本我通常选2.30.0以上。第三小程序切到后台后蓝牙连接可能还在但微信不保证持续收到通知数据回前台后socket状态也可能变了。我的处理是页面onShow时重新查询连接状态如果已经断开就自动重连如果还在但长时间没数据就提示用户重启小程序。第四用户在一台手机上同时打开多个小程序只有当前活跃的小程序能拿到蓝牙数据。如果用户打开另一个小程序导致当前小程序被挂起设备端感知到连接断开后要及时恢复广播状态等待下次连接。6. 复盘后的几点经验做完这个项目我最大的体会是可穿戴设备连微信真正的难点不是蓝牙本身而是把“设备端协议”和“小程序端逻辑”当作一个整体来设计。协议先行、文档先行先把每个特征、每条命令、每种异常响应写在纸上再动手写代码后面能少走很多回头路。另一点是工具投入值得。BLE Sniffer和串口蓝牙终端在联调阶段帮我省了大量时间很多看起来像“微信太烂”的问题抓到包后才发现是设备端广播包被系统过滤了或者是数据包在固件里就拼错了。再好的代码能力也抵不过一次真实的抓包定位。最后想说的是可穿戴设备最怕的是功耗和体验两头不讨好。蓝牙SoC选型、广播间隔、连接参数、休眠策略这些参数环环相扣一定要在量产前用真机、真电池、真实用户场景反复测别只看芯片参考设计里的理论值。这个项目做完后我把这套协议和代码整理成了内部模板下个产品从立项到原型跑通只用了三周说明前期的抽象和沉淀是值得的。