蓝牙智能设备数据采集平台化方案
技术背景
随着人们生活水平的提升，对健康的关注意识也随之提高；另外人口结构的老龄化，慢性病发病率升高，以及新冠疫情持久广泛的影响，进一步提高了大众对疾病早期预防、身体数据定期自测、慢性病持续关注等各个层面的重视程度；典型的，比如体温、血氧、血压、体重等高频、普遍使用的自测参数，在一些医疗器械和智能手机APP中实现可独立操作性、实时监测性及便捷性；市场上可穿戴式医疗器械日益种类多样、形态各异，根据功能不同可以分为运动健身类、生活娱乐类、健康医疗类、远程控制类、智能开关类、信息资讯类以及多功能穿戴式医疗器械。
在技术层面近年来，无线通信技术、传感器、柔性电子、生物遥测、体域网等技术的发展，可穿戴医疗器械也早已不局限于智能手环、智能手表等形式，我国国家药品监督管理局批准上市的医疗级可穿戴设备有ECG心电信号测量设备、血压测量设备、血氧测量设备、血糖测量设备；与可穿戴设备兼容的智能手机医疗保健应用程序越来越多，医疗服务供应商对无线连接青睐越来越明显，低功耗蓝牙（BLE）由于其低功耗在智能穿戴终端中应用广泛，智能手表、智能手环，以及其它智能相关的设备，几乎都是依靠这个技术与手机进行无线连接和数据交互的。另外，低功耗蓝牙技术，可以实现短距离通信的最低功耗，这也大大延长可穿戴设备的工作时间。
与国外相比，我国可穿戴式医疗器械相对于较晚，当前市场上的可穿戴式医疗器械主要偏向于运动/睡眠监测功能，其可长时间与人体接触，是理想的监测设备，具有广阔的市场空间。随着我国云计算、大数据和5G的高速发展，医疗器械可穿戴化必是大势所趋，可穿戴式医疗器械必将迎来良好的市场机遇。
然而由于医疗数据具有产品多样化、平台差异性和数据高密度的特点，所以对数据进行有效储存、交互、传递以及跨平台读取就十分有必要，通过可穿戴式医疗器械与医疗数据云平台相联，实现数据的互通共享，将采集到的患者数据通过云平台处理，不仅患者自己可以通过云平台了解相关的诊断结果、治疗方案，医疗机构也同样可以利用云平台的数据制定治疗措施，对患者进行跟踪和交流。
目前穿戴设备几乎都兼容三种平台Android APP， IOS APP， 微信小程序，各自同步实现方式（如图1）：
1. Android app 基于Android平台JAVA作为开发语言构建。蓝牙设备数据采集需要根据系统提供的Native BLE SDK 来实现 手机与 外设直接 命令与数据交互； 手机获取到的采集数据需要采用JAVA语言来实现后续处理逻辑； 网络传输，以及传输过程中失败处理 也一并需要考虑在内 等上述提供的6个步骤。
2. IOS APP 基于IOS平台ObjectC作为开发语言构建。 蓝牙设备数据采集需要基于IOS蓝牙开发规范 实现上述提供的6个步骤。 处理流程同Android APP
3. 微信小程序 基于JavaScript语言。 蓝牙设备数据采集，需要基于微信小程序 提供蓝牙API 使用规范实现上述提供的6个步骤，处理流程同以上两者 ；
图1：平台数据采集流程图
存在如下痛点：
-
蓝牙交互程序内置于用户APP端
-
适配更多开发平台， 就需要重复实现上述6个步骤，代码不具有可移植性和跨平台能力；
-
如果有支持新类型蓝牙设备的需求，只能发布新版APP， 提示用户升级安装。蓝牙协议的代码是打包APP中，这种方式通过代码静态分析工具，容易被破解；用户即使只使用一款蓝牙设备，也需要下载一个庞大的APP 。
-
修复bug困难（热修复），只能通过版本更新（需要用户介入）才能实现，频繁更新影响用户体验。尤其是 Android平台由于大量企业安卓的系统是自身定制，软件系统之间兼容也存在困难；
总体上来说，由于Android APP/IOS APP平台和开发语言的差异，对开发端和用户端来说，在系统兼容适配、外接蓝牙的安装更新，以及不同平台之间的移植都有不同程度的制约。
新技术的功能特点
基于蓝牙的智能设备数据采集平台化方案，在三种平台（Android APP/ IOS APP/微信小程序）使用同一套蓝牙设备采集代码，应具备以下特点：
-
蓝牙交互及控制程序与用户APP解耦， 由云端控制
-
可移植和跨平台性：一种蓝牙设备同步程序在其中一个平台开发、调试，正常运行，移植到其他平台依然可以正常运行支持动态加入新类型蓝牙设备，绑定新类型蓝牙设备后立即生效。而不是用户频繁卸载安装新版的APP方式
-
具备蓝牙功能模块的热修复能力：一种快速、低成本修复APP缺陷的地方
-
解决蓝牙协议静态打包在APP， 保护智能设备厂商知识版权
方案的整体架构
经过大量调研，和多种类型蓝牙设备接入代码实战应用发现， 三种平台在接入蓝牙设备读取到的数据之后，后面的数据处理，算法逻辑是相同，只是在 Native BLE SDK部分差异较大。从这个角度来讲，蓝牙同步功能可以抽象为：①手机与蓝牙设备交互部分；②获取蓝牙数据后续处理。
我们引入中间层设计思想：主要目的屏蔽底层差异性，并给上层提供一致的接口；中间层主要是对上层负责，屏蔽底层无规则、无协议、环境复杂的问题；如果把不同平台的差异给屏蔽掉，那么上层就可以专注于解决业务，而不再需要耗费精力去解决差异性。
蓝牙同步架构方案有以下三层（如图2）：
原生层: Native BLE SDK部分：与蓝牙设备直接交互，不同平台实现方式，开发语言不同，实现方式也可能不同。抽象大致相同蓝牙通信能力（如表1）
中间层：用于解耦业务层与原生层强依赖，屏蔽平台，语言的差异。位于原生层与业务层之间，对上层提供统一、一致的JS BLE API
业务层：处理蓝牙数据操作，可以认为是对于APP功能中属于业务部分，不同类型蓝牙设备存在不用数据处理规则. 但是不同平台同一类型蓝牙设备notify数据格式是相同的，所以处理逻辑在不同平台是共用的。 改造之后统一业务层使用JavaScript语言开发，运行在JavaScript引擎
表1：实现蓝牙常用的API（18个）
图2：蓝牙同步架构方案
可移植和跨平台的实现
根据面向对象思想，Native BLE SDK部分：与蓝牙设备直接交互，不同平台实现方式，开发语言不同， 实现方式也可能不同；考虑到Native BLE SDK在三种不同平台实现，蓝牙实现方式通过以下三种方式解决：
-
Android APP 加入JavaScript引擎，实现Java和JavaScript的相互调用。并对Android平台提供支持。 通过JavaScript API接口采用原生平台JAVA代码实现蓝牙18个API， 对上层提供 JavaScript BLE API
-
IOS APP 加入 JavaScriptCore引擎， JavaScriptCore是Safari的JavaScript引擎，在iOS7之后苹果开放了JavaScriptCore框架，开发者可以通过其提供的OC接口来使用JavaScriptCore。 通过JavaScriptCore接口采用原生平台ObjectC实现蓝牙18个API， 对上层提供 JavaScript BLE API
-
微信小程序运行环境JavaScript。只需封装微信提供同Android/IOS相同的JS BLE API即可。仅列举其中初始化蓝牙流程，如图3：
图 3 微信小程序 初始化蓝牙流程
经过以上3种方式，三个平台业务代码都可以运行在各自的 JavaScript引擎中（如图11）， 通过调用统一的JS BLE API就可以和蓝牙设备进行命令，数据交互。只需在任意一个平台编写、调试，之后无需任何变动就可以运行在其他平台。一种代码（JavaScript）即可通用，内容为：
-> 连接指定设备
-> 连接成功后，发送交互命令
-> 同步并收集设备通知数据
-> 校验、解析蓝牙数据协议
-> 数据转化业务数据， 业务数据解析，清洗，合并等处理
-> 数据上传云端
蓝牙平台工作流程（如图4）：
所有支持的蓝牙设备类型及其对应蓝牙同步程序存储于后台服务端， 当用户绑定对应类型蓝牙设备后。动态获取蓝牙设备程序； 当检测到同步程序版本发生变动后重新获取新的蓝牙同步程序。同步程序下发到APP过程 采用压缩，动态加密，传输加密，多次校验客户端合法性方式保证蓝牙协议安全性。
图4 蓝牙同步数据流程
预期收益
基于蓝牙的智能设备数据采集平台化方案：
a) 蓝牙设备接入效率倍增及平台高扩展性
b) 明确人员职责，数据接入人员与APP研发可以并行研发
c) 多平台只需维护一套代码，降低开发后期维护成本， 提升程序稳定性
d) 不同设备类型之间同步程序物理隔离，其中一个出现错误不影响其他设备正常使用，每个设备都可以自由配置日志信息，方便开发人员快速定位解决问题
e) 用户角度，提升用户体验。不用经常更新APP， 就可以接入新设备，使用新功能
蓝牙厂商角度：保护了蓝牙协议安全性，自身知识产权和利益；
结语
这种基于蓝牙的智能设备数据采集平台化方案，只需一套JavaScript代码方案，实现蓝牙同步可移植，通用；蓝牙同步程序从客户端静态编码在APP转换为后端控制方式，极大降低了蓝牙同步与平台强耦合，提升扩展能力。同时保证了APP快速适用新设备的能力，以及热修复能力。支持APP内蓝牙后台运行， 解决心电贴等设备数据量大场景；
帮助开发者过滤了平台差异，以及开发语言差异方面的顾虑，并且减轻了后期的更新、错误修复等方面维护的工作量和成本；另外，不同平台之间的程序的兼容，稳定能更好的提升用户体验；减少开发端和用户精力投入的基础上，更好的帮助用户实现功能和解决不同场景的问题。
作者：京东健康 于震江
来源：京东云开发者社区