CN105407146A - 一种从手环到app再到服务器的数据同步方法 - Google Patents

Abstract

本发明公开了一种从手环到APP再到服务器的数据同步方法，按报文格式组装报文数据，并触发notify事件；APP端接收并解析报文头Header，按当前报文内容字节数长度接收对应的字节数，放入缓存中，并整体校验解析，回写接收成功的内容字节数；手环端接收到回写数据与上一次报文发送内容字节数比较，校验通过，删除存储器数据，发起下一次数据同步；根据APP本地记录的上传时间以戳获和上传最大ID值取上传数据，执行上传；连接服务器上传接口，解析上传数据内容，处理成功返回成功标识；通过采用该数据同步方法，实现手环、APP与服务器的数据同步过程中数据的正确和完整性，有效解决在下载和上传过程中数据的丢失和不完整性。

Description

一种从手环到APP再到服务器的数据同步方法

技术领域

本发明涉及一种佩戴在用户手腕上的手环，具体涉及该手环与服务器的数据同步方法，更具体的涉及一种从手环到APP再到服务器的数据同步方法，属于可穿戴设备技术领域。

背景技术

App运行在IPhone或者IPad等移动设备上，通过蓝牙4.0的Bluetoothlowenergy(BLE)协议与手环进行连接和通讯，手环采集到的体征数据分两步同步到服务器，第一步手环采集到的体征原始数据在报文机制保证数据完整性下通过蓝牙BLE上传到APP，第二步APP在时间戳和最大ID值机制保证数据完整性下通过网络与服务器进行数据同步。

Android对BLE协议的支持，在连续大数据量读取会有延迟响应，数据丢包，数据包乱序现象，目前苹果公司手环因为对ble协议支持较早，协议支持较成熟稳定，其他公司手环在连续大数据量读取会有较明显延迟响应，数据丢包，数据包乱序现象。

因此，有必要提出一种技术方案，能够有效解决读取数据时延迟响应，数据丢包，数据包乱序现象等问题，方便用户使用，成为了一种新的技术需求。

发明内容

针对现有技术存在的上述不足，本发明提出了一种从手环到APP再到服务器的数据同步方法，APP内置对应特征项的notify事件监听并保持数据同步；按报文格式组装报文数据，并触发notify事件；APP端接收并解析报文头Header，按当前报文内容字节数长度接收对应的字节数，放入缓存中，并整体校验解析，回写接收成功的内容字节数；手环端接收到回写数据与上一次报文发送内容字节数比较，校验通过，删除存储器数据，发起下一次数据同步；根据APP本地记录的上传时间戳和最大ID值获取上传数据，执行上传；连接服务器上传接口，解析上传数据内容，处理成功返回成功标识；通过采用该数据同步方法，实现手环、APP与服务器的数据同步过程中数据的正确和完整性，有效解决在下载和上传过程中数据的丢失和不完整性。

本发明解决其技术问题，所采用的技术方案是：一种从手环到APP再到服务器的数据同步方法，所述方法包括以下步骤：

步骤100：APP内置对应特征项的notify事件监听并保持数据同步，事件监听周期为APP连接上手环到与手环断开；

步骤200：手环端查询存储器是否存在数据，若存在数据，按报文格式组装报文数据，并触发notify事件；

步骤300：APP端接收并解析报文头Header，计算出当前报文内容字节数和剩余字节数和报文内容CRC16值，按当前报文内容字节数长度接收对应的字节数，放入缓存中，并整体字节CRC16校验，若校验通过，回写接收成功的内容字节数；

步骤400：手环端接收到回写字节数，与上次发送字节数对比，若成功删除存储器对应数据字节数，并发起下一次数据同步；

步骤500：根据APP本地记录的上传时间戳和上传记录最大ID值获取上传数据，具体根据时间戳标识是否有更新以及最大ID值标识数据上传点执行上传；连接服务器上传接口，解析上传数据内容，在每条数据记录中注入当前毫秒值operateTime字段和insertignoreinto数据表，处理成功返回成功标识；APP解析接口成功返回数据内容，更新APP本地数据上传时间戳和上传记录最大ID值；

步骤600：账户登录APP成功后，根据APP本地记录服务器下载时间戳和服务器下载数据最大ID值申请下载，服务器根据时间戳和最大ID值获取数据库记录，处理成功，返回数据和数据中最大时间戳和数据中最大ID值；APP解析接口成功返回数据内容，注入-1的operateTime字段用来区别为下载数据，更新APP本地服务器下载时间戳和下载数据最大ID值。

进一步地，所述APP与手环实时连接时，且APP已经触发手环数据上传功能，手环采集到的数据会存储到存储器中并实时通过BLE协议与APP同步数据；若APP不在实时连接时，手环采集到的数据会存储到存储器中，在下次APP连接状态并触发同步数据流程时开始同步数据。

进一步地，所述APP接收到体征数据，判断APP与服务器网络接口是否通畅，若通畅则上传到服务器；若APP不能实时连接到服务器，在网络恢复情况下执行上传，APP启动时运行定时周期的检测服务，按时间戳和最大ID值机制检测未上传数据进行上传。

进一步地，建立手环上传报文数据传输机制，机制内容包括：APP与手环连接并触发同步流程时，硬件手环端查询存储器中数据，通过数据报文格式组装，组装过程中需要保证每个体征数据单元完整，以20个字节为数据单元字节流形式，NOTIFY到APP端，对数据报文头Header解析，APP端接收到完整报文数据流，若解析成功回写成功接收内容字节数，手环端会从存储器中删除数据报文中体征数据；若还有数据，再发起一次新数据的数据报文，以此循环。

进一步地，所述报文头Header格式定义：当前报文数据内容长度字段为2字节十六进制表达，报文数据内容长度保持在256个字节以内，剩余数据总长度字段为4字节十六进制表达，当前报文数据内容CRC16值2字节十六进制表达，所述报文数据内容不包括header自身的长度；当对数据报文头Header处理异常：APP端解析失败或者传输过程异常，APP端直接发起再次同步命令，并丢弃数据，手环不做删除操作并发起新一次数据报文交互。

进一步地，在报文头Header扩展两字节为当前所有内容字节crc16校验值，在一次报文接收完成后，APP端对所有内容字节校验crc16值，app校验crc16值保证数据完整性，APP回写两字的成功接收内容字节数,手环端保证删除与上次发送内容相同字节数。

进一步地，建立APP与服务器数据时间戳和最大ID值上传下载同步机制，所述机制内容包括：当APP需要操作大量本地时间连续的离线数据，需要保证与服务器数据完整一致，当有新手环采集数据产生时，需要及时上传服务器，保证数据一致。

进一步地，所述机制出现异常：上传时发生异常接口不能成功返回时，APP端开启定时周期***，启动上传数据遗留检测执行上传；上传接口在接口返回环节出现异常，APP没有成功记录上传时间戳和最大ID值时，会再次执行上传，服务端会收到重复数据，再使用INSERTIGNORE消除重复数据。

进一步地，所述机制完善扩展：APP登录服务器时,服务器返回是否与上一次登录的APP为同一个APP，不相同时APP才执行下载操作。

进一步地，所述APP本地记录表与服务端数据表设有自增ID，APP端在上传成功返回时，更新上传时间戳和本地最大数据库表记录自增唯一ID值，以上传时间戳和上传数据表最大ID值为过滤条件，执行下一次上传，上传接口返回成功后，更新本地上传时间戳和上传记录最大ID值；APP端在下载数据时，初始默认下载时间戳参数为一个月前时间点，最大ID值为0，下载接口成功返回服务端数据表记录自增唯一最大ID值，APP端更新本地记录下载时间戳和最大ID值，并在下一次下载数据时，回传此两个参数，服务端接口以此参数条件过滤。

更进一步地，所述蓝牙芯片采用nRF51822芯片。

更进一步地，BLEProfile配置：对应特征项具备NOTIFY能力；BLE协议能力：NOTIFY通讯每个数据包大小限制为20byte。

更进一步地，对应特征项使能开关配置：0x01为启动，0x00为停止。

更进一步地，所述APP表示APP运行在支持BLE功能的移动手环硬件及软件***。

更进一步地，手环时间设置：APP每次与手环连接时，先写入APP当前时间到手环。

更进一步地，APP本地存储功能：APP支持体征数据本地结构化SQLITE数据库存储。

更进一步地，同步数据类型定义：硬件手环采集到的体征数据。

更进一步地，服务端能力配置：体征数据表int自增ID值支持按时间戳和最大ID值机制上传下载接口，返回当前服务端时间接口。

与现有技术相比，本发明的有益效果是：

1、通过采用该数据同步方法，实现手环、APP与服务器的数据同步过程中数据的正确和完整性，有效解决在下载和上传过程中数据的丢失和不完整性；

2、改善数据同步方法，方便了上传或下载数据的便捷性和准确性，节约了时间和资源，方便了客户的使用。

附图说明

下面结合附图对本发明的具体实施方案作详细说明。

图1是本发明优选实施例的一种从手环到APP再到服务器的数据同步方法的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面结合具体实施方式并参照附图，对本发明进一步详细说明。应该理解，这些描述只是示例性的，而并非要限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

图1是本发明优选实施例的一种从手环到APP再到服务器的数据同步方法的结构示意图；

如图1所示，所述方法包括以下步骤：

步骤100：APP开起对应特征项的notify事件监听并使能数据同步，事件监听周期为APP连接上手环到与手环断开。

步骤200：手环端查询存储器是否存在数据，若存在数据，按报文格式组装报文数据，并触发notifyevent事件。

步骤300：APP端接收并解析报文头，计算出当前报文内容字节数，剩余字节数，按当前报文内容字节数长度接收对应的字节数，放入缓存中，并整体校验解析，检验条件包括以下两条：a)按当前报文内容字节数，b)按具体的体征数据内容解析；若校验通过，回写接收成功的内容字节数。

步骤400：手环端接收到回写数据与上一次报文发送内容字节比较，若校验通过，删除存储器数据，发起下一次数据同步。

步骤500：根据APP本地记录的上传时间以戳获取上传数据，执行上传；服务器上传接口，解析上传数据内容，注入operateTime字段为当前毫秒值，replace数据表，处理成功返回成功标识；APP解析接口成功返回数据内容，更新APP本地数据上传时间戳。

步骤600：在帐户登录APP成功后，根据APP本地记录服务器下载时间戳申请下载；服务器根据APP上传时间戳获取数据库记录，处理成功，返回数据与数据中最大时间戳；APP解析接口成功返回数据内容，注入operateTime字段为-1，更新APP本地服务器下载时间戳。

数据同步时机：

当APP与手环实时连接时，且APP已经触发手环数据上传功能，手环采集到的数据会存储到存储器中并实时通过BLE协议与APP同步数据；若APP不在实时连接时，手环采集到的数据会存储到存储器中，在下次APP连接状态并触发同步数据流程时开始同步数据。

APP与服务器接收到体征数据，及时判断与服务器网络接口是否通畅，若通畅则上传到服务器。若APP不能实时连接到服务器，在网络恢复情况下执行上传，APP启动时运行定时周期的检测服务，按时间戳机制检测未上传数据进行上传。

所述体征数据为手环传感器能采集的数据值，目前已发布手环硬件版本能采集心率值bpm、血氧值％和腕温值℃。

当用户登录APP，需要操作大量连续体征数据源时，在登录时按时间戳机制下载数据。

手环上传报文数据传输机制：

需求定义：手环采集数据完整一致地上传到APP。

机制原理：APP与手环连接并触发同步流程时，硬件手环端查询存储器中数据，通过{数据报文}格式组装，组装过程中需要保证每个体征数据单元完整，以20个字节为数据单元字节流形式，NOTIFY到APP端，按{数据报文头Header}解析，APP端接收到完整报文数据流，若解析成功回写{成功接收内容字节数}。手环端会从存储器中删除{数据报文}中体征数据，若还有数据，再发起一次新数据的{数据报文}，以此循环；

机制说明：报文头Header格式定义：2字节十六进制表达的当前报文数据内容长度字段(报文数据内容长度控制在256个字节以内；不包括header自身的长度)+4字节十六进制表达的剩余数据总长度字段(包括当前数据包，不包括header自身的长度)；

机制异常处理及恢复能力：数据报文头Header若APP端解析失败或者传输过程异常，APP端不回写报文，并丢弃数据；手环端会在等待超时或者有新数据产生时，或者被APP触发时，发起新一次{数据报文}交互。

机制缺陷：当回写环节失败时，APP端可能会接收到重复上传数据，需要做重复数据处理；当异常发生后，机制的恢复速度根据出现问题相关，如果执行方案，跟采集频率配置有关；如果出现连接断开，跟重连速度有关；

在APP端把解析出来的体征数据的每条数据，手环生成数据带有{数据采集时间}和{体征数据的类型}，app在入库前检查本地数据重复性，以{数据采集时间}和{体征数据的类型}为条件过滤重复。

机制完善扩展：在报文头Header扩展两字节当前所有内容字节crc16校验值，在一次报文接收完成后，APP回写两字节{成功接收内容字节数}+两字节APP端对所有内容字节校验出来的crc16值，手环端校验保证数据完整性。

在传输之前计算出校验值，APP端接收完成，回写APP计算出的校验值，手环端根据回写校验值判断是否完整的传输至APP，是否重复发送上一次发送的内容。

APP与服务器数据时间戳上传下载同步机制：

需求定义：当APP需要操作大量本地时间连续的离线数据时，需要保证与服务器数据完整一致；当有新手环采集数据产生时，需要及时上传服务器，保证数据一致。

机制原理：每一条体征数据记录与登录帐户进行绑定，且数据记录有时间戳且时间轴正方向记录为基础。APP与服务端体征数据表都需要添加operateTime字段，分别记录数据APP端和服务端操作数据的时间戳。当APP解析完手环上传的体征数据，解析出每一条记录并存储到本地SQLITE数据库，每条记录写入当前APP的操作时间的毫秒值到operateTime字段，存储一个报文内的体征数据并实时触发上传接口；在APP本地记录了{上一次APP上传到服务器的时间戳}，以{上一次APP上传到服务器的时间戳}过滤operateTime字段为条件，查询APP本地SQLITE数据库，获取未上传数据。按接口定义执行上传。在接口返回成功后，更新本地{上一次APP上传到服务器的时间戳}为上传数据中最大operateTime值。当APP需要下载数据到本地SQLITE数据库时，在下载接口中，APP本地记录了{上一次APP下载服务器数据的时间戳}为接口参数，以{上一次APP下载服务器数据的时间戳}做为接口参数值过滤服务端数据。下载接口返回成功时，APP把返回数据中每条记录中的operateTime字段修改为-1，存入本地SQLITE数据库；并{上一次APP下载服务器数据的时间戳}赋值为此次下载数据的最大的服务器端时间戳。

机制说明：APP端需要对不同数据表不同、用户区别登录{上一次APP上传到服务器的时间戳}{上一次APP下载服务器数据的时间戳}两个值，{上一次APP上传到服务器的时间戳}初始值可赋值为0L，{上一次APP下载服务器数据的时间戳}初始值为服务器返回的时间值且向减去一个月时间段为基础，减去时间段由业务需求决定。

由于APP支持多用户登录，而在APP端的各用户数据都放在同一个数据库表中，各用户数据以用户名区分。故不同用户切换登录时，需要记录{不同用户：M}的上传下载情况。如果不同用户只是对{体征数据表}进行同步。则需要记录M*2*1(app本地上传和服务端下载时间戳)个记录。同理在同一个用户下面会有{不同数据表：N}，则需要记录M*2*N个记录。

机制异常及恢复能力：若上传时发生异常接口不能成功返回时，APP端开启定时周期***，启动上传数据遗留检测执行上传。

启动上传数据遗留检测执行上传，上传过程支持断点续传的功能，即数据没上传完时，下一次上传无需从头开始，从上一次未完成的地方继续上传。

机制缺陷：如果APP***为多帐户多条数据同步流，APP记录的时间戳会成倍增加；当上传接口在接口返回环节出现异常，APP没有成功记录上传时间戳时，会再次执行上传，服务端会收到重复数据，服务端需要通过replace方式处理重复数据问题；由于数据库处理能力较强，operateTime毫秒值有可能会重复。导致执行上传下载中，丢失operateTime毫秒值重复的数据。

机制完善扩展：若APP上传数据完成后，下一次执行下载时，因为本地的{上一次APP下载服务器数据的时间戳}并未更新，会导致数据段重复下载问题，消耗流量。可在帐户登录时，传入APP唯一标识例如deviceID等。服务器记录APP此帐户是否与上一次登录在同一个APP，若相同在上传成功返回时返回服务器最新的{上一次APP下载服务器数据的时间戳}，APP并更新本地记录。

对于APP与服务端时间戳可能性重复问题，若APP与服务端数据表有自增ID的情况下，APP端可在上传接口成功返回时，更新{上传时间戳}为{本地最大数据库表记录自增唯一ID值}，以数据库记录ID为过滤条件，执行下一次上传，下载接口成功返回{服务端数据库记录自增唯一ID值}，APP端更新本地记录{上一次APP下载服务器数据的时间戳}，并在下一次载数据时，回传此参数，服务端接口以此条件过滤。

对于登录成功后，申请一次数据下载接口，若服务端没有新数据产生，会浪费一次下载数据接口集调用，消耗资源问题。可在APP所有的数据下载接口集全部执行并成功返回后，APP本地对这次下载操作记录一个下载成功标识，再借助登录时服务接口返回同步手环登录标识位，即上一次完成下载成功并且是同一手环登录，则不执行下载操作，否则执行下载接口。

应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种从手环到APP再到服务器的数据同步方法，其特征在于，所述方法包括以下步骤：

步骤100：APP内置对应特征项的notify事件监听并保持数据同步，事件监听周期为APP连接上手环到与手环断开；

步骤200：手环端查询存储器是否存在数据，若存在数据，按报文格式组装报文数据，并触发notify事件；

步骤300：APP端接收并解析报文头Header，计算出当前报文内容字节数和剩余字节数和报文内容CRC16值，按当前报文内容字节数长度接收对应的字节数，放入缓存中，并整体字节CRC16校验，若校验通过，回写接收成功的内容字节数；

步骤400：手环端接收到回写字节数，与上次发送字节数对比，若成功删除存储器对应数据字节数，并发起下一次数据同步；

步骤500：根据APP本地记录的上传时间戳和上传记录最大ID值获取上传数据，执行上传；连接服务器上传接口，解析上传数据内容，在每条数据记录中注入当前毫秒值operateTime字段和insertignoreinto数据表，处理成功返回成功标识；APP解析接口成功返回数据内容，更新APP本地数据上传时间戳和上传记录最大ID值；

步骤600：账户登录APP成功后，根据APP本地记录服务器下载时间戳和服务器下载数据最大ID值申请下载，服务器根据时间戳和最大ID值获取数据库记录，处理成功，返回数据和数据中最大时间戳和数据中最大ID值；APP解析接口成功返回数据内容，注入-1的operateTime字段用来区别为下载数据，更新APP本地服务器下载时间戳和下载数据最大ID值。

2.根据权利要求1所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，所述APP与手环实时连接时，且APP已经触发手环数据上传功能，手环采集到的数据会存储到存储器中并实时通过BLE协议与APP同步数据；若APP不在实时连接时，手环采集到的数据会存储到存储器中，在下次APP连接状态并触发同步数据流程时开始同步数据。

3.根据权利要求1所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，所述APP接收到体征数据，判断APP与服务器网络接口是否通畅，若通畅则上传到服务器；若APP不能实时连接到服务器，在网络恢复情况下执行上传，APP启动时运行定时周期的检测服务，按时间戳和最大ID值机制检测未上传数据进行上传。

4.根据权利要求1所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，建立手环上传报文数据传输机制，机制内容包括：APP与手环连接并触发同步流程时，硬件手环端查询存储器中数据，通过数据报文格式组装，组装过程中需要保证每个体征数据单元完整，以20个字节为数据单元字节流形式，NOTIFY到APP端，对数据报文头Header解析，APP端接收到完整报文数据流，若解析成功回写成功接收内容字节数，手环端会从存储器中删除数据报文中体征数据；若还有数据，再发起一次新数据的数据报文，以此循环。

5.根据权利要求4所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，所述报文头Header格式定义：当前报文数据内容长度字段为2字节十六进制表达，报文数据内容长度保持在256个字节以内，剩余数据总长度字段为4字节十六进制表达，当前报文数据内容CRC16值2字节十六进制表达，所述报文数据内容不包括header自身的长度；当对数据报文头Header处理异常：APP端解析失败或者传输过程异常，APP端直接发起再次同步命令，并丢弃数据，手环不做删除操作并发起新一次数据报文交互。

6.根据权利要求4或5所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，在报文头Header扩展两字节为当前所有内容字节crc16校验值，在一次报文接收完成后，APP端对所有内容字节校验crc16值，app校验crc16值保证数据完整性，APP回写两字的成功接收内容字节数,手环端保证删除与上次发送内容相同字节数。

7.根据权利要求1所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，建立APP与服务器数据时间戳和最大ID值上传下载同步机制，所述机制内容包括：当APP需要操作大量本地时间连续的离线数据，需要保证与服务器数据完整一致，当有新手环采集数据产生时，需要及时上传服务器，保证数据一致。

8.根据权利要求7所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，所述机制出现异常：上传时发生异常接口不能成功返回时，APP端开启定时周期***，启动上传数据遗留检测执行上传；上传接口在接口返回环节出现异常，APP没有成功记录上传时间戳和最大ID值时，会再次执行上传，服务端会收到重复数据，再使用INSERTIGNORE消除重复数据。

9.根据权利要求7或8所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，所述机制完善扩展：APP登录服务器时,服务器返回是否与上一次登录的APP为同一个APP，不相同时APP才执行下载操作。

10.根据权利要求1所述的一种从手环到APP再到服务器的数据同步方法，其特征在于，所述APP本地记录表与服务端数据表设有自增ID，APP端在上传成功返回时，更新上传时间戳和本地最大数据库表记录自增唯一ID值，以上传时间戳和上传数据表最大ID值为过滤条件，执行下一次上传，上传接口返回成功后，更新本地上传时间戳和上传记录最大ID值；APP端在下载数据时，初始默认下载时间戳参数为一个月前时间点，最大ID值为0，下载接口成功返回服务端数据表记录自增唯一最大ID值，APP端更新本地记录下载时间戳和最大ID值，并在下一次下载数据时，回传此两个参数，服务端接口以此参数条件过滤。