CN117336702A - 蓝牙数据的处理方法、终端设备和可读存储介质 - Google Patents

Abstract

本申请实施例涉及蓝牙技术领域，提供一种蓝牙数据的处理方法、终端设备和可读存储介质。终端设备包括主处理单元、辅助处理单元和蓝牙芯片。蓝牙数据的处理方法应用于终端设备，包括：蓝牙芯片接收第一蓝牙数据；若蓝牙芯片确定第一蓝牙数据满足预设条件，则将第一蓝牙数据发送至辅助处理单元；辅助处理单元处理第一蓝牙数据。在本申请实施例中，部分蓝牙服务部署在辅助处理单元上处理，蓝牙芯片具有过滤蓝牙数据的能力，将满足预设条件的蓝牙数据发送给辅助处理单元处理，缩短了主处理单元的工作时间，从而降低了终端设备的耗电。

Description

蓝牙数据的处理方法、终端设备和可读存储介质

技术领域

本申请实施例涉及蓝牙技术领域，尤其涉及一种蓝牙数据的处理方法、终端设备和可读存储介质。

背景技术

随着终端技术的发展，智能终端设备越来越趋于多样化，数据处理能力越来越强。比如，从初期的手机、平板电脑等形态，逐步演进到手表、音箱、智慧屏等各类形态。以智能手机为例，智能手机包括有2核手机、4核手机、8核手机等等。而且，随着通信技术的发展，智能终端设备的通信能力也越来越强。这其中，蓝牙(bluetooth，BT)通信已经成为智能终端设备支持的一种基本通信方式。

目前，在蓝牙通信的实现上，通常将蓝牙协议栈和蓝牙服务实现的开放接口(Framework接口)同时部署在智能终端设备的应用处理器(application processor，AP)上，由AP处理相关的蓝牙数据。这样，当两个进行蓝牙通信的终端设备之间需要频繁的传输数据时，AP将一直处于工作状态，而AP的工作电流通常较大，导致终端设备耗电严重。

发明内容

本申请实施例提供一种蓝牙数据的处理方法、终端设备和可读存储介质，降低了终端设备的耗电。

第一方面，提供了一种蓝牙数据的处理方法，应用于终端设备，终端设备包括主处理单元、辅助处理单元和蓝牙芯片；蓝牙数据的处理方法包括：蓝牙芯片接收第一蓝牙数据；若蓝牙芯片确定第一蓝牙数据满足预设条件，则将第一蓝牙数据发送至辅助处理单元；辅助处理单元处理第一蓝牙数据。

第一方面提供的蓝牙数据的处理方法，部分蓝牙服务部署在终端设备的辅助处理单元上处理，蓝牙芯片具有过滤蓝牙数据的能力，将满足预设条件的蓝牙数据发送给辅助处理单元处理，对原本需要由终端设备的主处理单元处理的蓝牙数据形成了分流，从而缩短了主处理单元的工作时间，从而降低了终端设备的耗电，提高了终端设备的续航时间。

一种可能的实现方式中，蓝牙芯片确定第一蓝牙数据满足预设条件，包括：蓝牙芯片解析第一蓝牙数据，得到第一设备标识和第一逻辑通道索引；若第一设备标识和第一逻辑通道索引在信息列表中，蓝牙芯片确定第一蓝牙数据满足预设条件；信息列表用于存储目标设备的设备标识和目标服务的逻辑通道信息，辅助处理单元用于处理目标服务的蓝牙数据。

在该实现方式中，蓝牙芯片中存储有信息列表，信息列表中存储有部署在辅助处理单元上处理的蓝牙服务的相关信息和目标设备的设备标识。蓝牙芯片具有解析、过滤蓝牙数据的能力。蓝牙芯片解析第一蓝牙数据得到第一设备标识和第一逻辑通道索引。如果第一设备标识和第一逻辑通道索引在信息列表中，说明第一蓝牙数据需要在辅助处理单元上处理。通过将部分蓝牙服务部署在终端设备的辅助处理单元上处理，缩短了主处理单元的工作时间，降低了终端设备的耗电。

一种可能的实现方式中，蓝牙数据的处理方法还包括：若第一设备标识或第一逻辑通道索引不在信息列表中，蓝牙芯片将第一蓝牙数据发送至主处理单元；主处理单元处理第一蓝牙数据。

在该实现方式中，如果第一设备标识或者第一逻辑通道索引不在信息列表中，说明第一蓝牙数据不需要在辅助处理单元上处理，还是由主处理单元处理。

一种可能的实现方式中，蓝牙数据的处理方法还包括：辅助处理单元生成目标服务的第二蓝牙数据；辅助处理单元将第二蓝牙数据发送至蓝牙芯片；蓝牙芯片对第二蓝牙数据进行封装，得到待发送数据；蓝牙芯片向目标设备发送待发送数据。

在该实现方式中，终端设备作为数据发送端，向目标设备发送目标服务的数据。通过辅助处理单元处理目标服务的数据，降低了终端设备的能耗，延长了续航时间。

一种可能的实现方式中，蓝牙芯片接收第一蓝牙数据之前，还包括：主处理单元向辅助处理单元发送目标设备的第一MAC地址和目标服务的第一服务信息；目标设备为和终端设备蓝牙通信的设备，第一服务信息用于辅助处理单元处理目标服务的蓝牙数据；辅助处理单元向蓝牙芯片发送第一MAC地址和第二服务信息；第二服务信息为第一服务信息中的部分或全部信息；蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息；目标设备的设备标识和目标服务的逻辑通道信息用于蓝牙芯片处理目标服务的蓝牙数据。

在该实现方式中，将部分蓝牙服务从主处理单元下沉到辅助处理单元上处理。主处理单元和辅助处理单元之间同步目标设备的MAC地址目标服务的第一服务信息，辅助处理单元和蓝牙芯片之间传输目标设备的MAC地址目标服务的第二服务信息，从而，辅助处理单元和蓝牙芯片获知目标服务是在辅助处理单元上处理。后续，辅助处理单元和蓝牙芯片可以处理目标服务的蓝牙数据，对原本需要由终端设备的主处理单元处理的蓝牙数据形成了分流，从而缩短了主处理单元的工作时间，从而降低了终端设备的耗电，提高了终端设备的续航时间。

一种可能的实现方式中，目标设备的设备标识包括ACL标识。

一种可能的实现方式中，终端设备和目标设备支持GATT协议，目标服务包括至少一个特征；第一服务信息、第二服务信息和目标服务的逻辑通道信息，包括：至少一个特征中目标特征的逻辑通道索引和特征属性；第一服务信息还包括：目标服务的UUID，第一服务信息用于辅助处理单元处理目标特征的蓝牙数据。

一种可能的实现方式中，目标特征需要被使能；第一服务信息、第二服务信息和目标服务的逻辑通道信息，还包括：目标特征的描述符的逻辑通道索引。

在该实现方式中，目标特征的描述符的逻辑通道索引用于目标特征的使能，主处理单元和/或辅助处理单元可以使能目标特征。

一种可能的实现方式中，目标特征没有被主处理单元使能。

在该实现方式中，主处理单元没有使能目标特征，需要由辅助处理单元完成目标特征的使能。所以，第一服务信息、第二服务信息和目标服务的逻辑通道信息中需要包括目标特征的描述符的逻辑通道索引，从而使得辅助处理单元使能目标特征。

一种可能的实现方式中，蓝牙芯片接收第一蓝牙数据之前，还包括：主处理单元和/或辅助处理单元使能目标特征。

一种可能的实现方式中，终端设备和目标设备支持RFCOMM协议；第一服务信息和第二服务信息，包括：目标服务的逻辑通道信道号和目标服务的角色；其中，角色为客户端或服务端。

一种可能的实现方式中，第一服务信息还包括目标服务的UUID。

一种可能的实现方式中，蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息之前，还包括：主处理单元向蓝牙芯片发送通道信息；通道信息包括目标设备的第二MAC地址和目标服务的DLCI；相应的，蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息，包括：蓝牙芯片根据第一MAC地址、第二服务信息、第二MAC地址和DLCI，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息。

一种可能的实现方式中，蓝牙芯片根据第一MAC地址、第二服务信息、第二MAC地址和DLCI，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息，包括：若第一MAC地址和第二MAC地址相同，蓝牙芯片根据第一MAC地址或第二MAC地址确定目标设备的设备标识；蓝牙芯片根据DLCI得到待比对逻辑通道信道号和待比对角色；若待比对逻辑通道信道号和目标服务的逻辑通道信道号相同，且待比对角色和目标服务的角色相同，则蓝牙芯片将DLCI确定为目标服务的逻辑通道信息；在信息列表中增加目标设备的设备标识和DLCI。

一种可能的实现方式中，蓝牙数据的处理方法还包括：主处理单元向辅助处理单元发送第一信息；第一信息用于指示主处理单元处理目标服务的蓝牙数据；辅助处理单元根据第一信息删除第一服务信息；辅助处理单元向蓝牙芯片发送第二信息；第二信息用于指示主处理单元处理目标服务的蓝牙数据；蓝牙芯片根据第二信息在信息列表中删除目标服务的逻辑通道信息。

在该实现方式中，目标服务可以重新部署在主处理单元上。因此，主处理单元、辅助处理单元和蓝牙芯片之间需要删除目标服务的相关信息，从而使得主处理单元可以处理目标服务的蓝牙数据。

一种可能的实现方式中，信息列表包括设备列表和下沉业务列表；设备列表包括目标设备的设备标识，下沉业务列表包括目标设备的设备标识和目标服务的逻辑通道信息。

一种可能的实现方式中，终端设备为目标服务的客户端，目标设备为目标服务的服务端。

第二方面，提供了一种蓝牙数据的处理装置，可以应用于终端设备。蓝牙数据的处理装置包括：接收模块，用于接收第一蓝牙数据；第一处理模块，用于在确定第一蓝牙数据满足预设条件时，将第一蓝牙数据发送至第二处理模块；第二处理模块，用于处理第一蓝牙数据。

一种可能的实现方式中，第一处理模块用于：解析第一蓝牙数据，得到第一设备标识和第一逻辑通道索引；若第一设备标识和第一逻辑通道索引在信息列表中，则确定第一蓝牙数据满足预设条件；信息列表用于存储目标设备的设备标识和目标服务的逻辑通道信息，第二处理模块用于处理目标服务的蓝牙数据。

一种可能的实现方式中，第一处理模块还用于：若第一设备标识或第一逻辑通道索引不在信息列表中，则将第一蓝牙数据发送至第三处理模块；第三处理模块，用于处理第一蓝牙数据。

一种可能的实现方式中，第二处理模块还用于：生成目标服务的第二蓝牙数据，将第二蓝牙数据发送至第一处理模块；第一处理模块还用于：对第二蓝牙数据进行封装，得到待发送数据；蓝牙数据的处理装置还包括发送模块，用于向目标设备发送待发送数据。

一种可能的实现方式中，第三处理模块还用于：在接收模块接收第一蓝牙数据之前，向第二处理模块发送目标设备的第一MAC地址和目标服务的第一服务信息；目标设备为和终端设备蓝牙通信的设备，第一服务信息用于第二处理模块处理目标服务的蓝牙数据；第二处理模块还用于：向第一处理模块发送第一MAC地址和第二服务信息；第二服务信息为第一服务信息中的部分或全部信息；第一处理模块还用于：根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息；目标设备的设备标识和目标服务的逻辑通道信息用于第一处理模块处理目标服务的蓝牙数据。

一种可能的实现方式中，目标设备的设备标识包括ACL标识。

一种可能的实现方式中，终端设备和目标设备支持GATT协议，目标服务包括至少一个特征；第一服务信息、第二服务信息和目标服务的逻辑通道信息，包括：至少一个特征中目标特征的逻辑通道索引和特征属性；第一服务信息还包括：目标服务的UUID，第一服务信息用于第二处理模块处理目标特征的蓝牙数据。

一种可能的实现方式中，目标特征需要被使能；第一服务信息、第二服务信息和目标服务的逻辑通道信息，还包括：目标特征的描述符的逻辑通道索引。

一种可能的实现方式中，目标特征没有被第三处理模块使能。

一种可能的实现方式中，第三处理模块和/或第二处理模块，还用于：在接收模块接收第一蓝牙数据之前，使能目标特征。

一种可能的实现方式中，终端设备和目标设备支持RFCOMM协议；第一服务信息和第二服务信息，包括：目标服务的逻辑通道信道号和目标服务的角色；其中，角色为客户端或服务端。

一种可能的实现方式中，第一服务信息还包括目标服务的UUID。

一种可能的实现方式中，第三处理模块还用于：向第一处理模块发送通道信息；通道信息包括目标设备的第二MAC地址和目标服务的DLCI；第一处理模块用于：根据第一MAC地址、第二服务信息、第二MAC地址和DLCI，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息。

一种可能的实现方式中，第一处理模块用于：若第一MAC地址和第二MAC地址相同，根据第一MAC地址或第二MAC地址确定目标设备的设备标识；根据DLCI得到待比对逻辑通道信道号和待比对角色；若待比对逻辑通道信道号和目标服务的逻辑通道信道号相同，且待比对角色和目标服务的角色相同，则将DLCI确定为目标服务的逻辑通道信息；在信息列表中增加目标设备的设备标识和DLCI。

一种可能的实现方式中，第三处理模块还用于：向第二处理模块发送第一信息，第一信息用于指示第三处理模块处理目标服务的蓝牙数据；第二处理模块还用于：根据第一信息删除第一服务信息，并向第一处理模块发送第二信息，第二信息用于指示第三处理模块处理目标服务的蓝牙数据；第一处理模块还用于：根据第二信息在信息列表中删除目标服务的逻辑通道信息。

一种可能的实现方式中，信息列表包括设备列表和下沉业务列表；设备列表包括目标设备的设备标识，下沉业务列表包括目标设备的设备标识和目标服务的逻辑通道信息。

一种可能的实现方式中，终端设备为目标服务的客户端，目标设备为目标服务的服务端。

第三方面，提供了一种终端设备，包括处理器和蓝牙芯片，处理器包括主处理单元和辅助处理单元，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现第一方面提供的方法。

第四方面，提供一种程序，该程序在被处理器执行时用于执行第一方面提供的方法。

第五方面，提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当指令在计算机或处理器上运行时，实现第一方面提供的方法。

第六方面，提供一种程序产品，所述程序产品包括计算机程序，所述计算机程序存储在可读存储介质中，设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得该设备实施第一方面提供的方法。

附图说明

图1A～图1C为本申请实施例适用的应用场景的一组示意图；

图2为本申请实施例提供的终端设备的一种结构示意图；

图3为本申请实施例提供的蓝牙协议栈的一种结构示意图；

图4为本申请实施例提供的GATT数据结构的一种示意图；

图5为本申请实施例提供的速率计服务的逻辑通道管理信息的一种示意图；

图6为本申请实施例提供的终端设备处理蓝牙数据的一种原理示意图；

图7为本申请实施例提供的BLE通信中终端设备处理蓝牙数据的一种原理示意图；

图8为本申请实施例提供的经典蓝牙中终端设备处理蓝牙数据的一种原理示意图；

图9为本申请实施例提供的终端设备处理蓝牙数据的另一种原理示意图；

图10为本申请实施例提供的蓝牙数据的处理方法的一种流程图；

图11为本申请实施例提供的BLE通信中的一种数据结构；

图12为本申请实施例提供的经典蓝牙通信中的一种数据结构；

图13为本申请实施例提供的蓝牙数据的处理方法的另一种流程图；

图14为本申请实施例提供的BLE通信中终端设备处理蓝牙数据的另一种原理示意图；

图15为本申请实施例提供的蓝牙数据的处理方法的又一种流程图；

图16为本申请实施例提供的经典蓝牙中终端设备处理蓝牙数据的另一种原理示意图；

图17为本申请实施例提供的蓝牙数据的处理方法的又一种流程图；

图18为本申请实施例提供的蓝牙数据的处理装置的一种结构示意图。

具体实施方式

下面结合附图描述本申请实施例。

本申请实施例提供的蓝牙数据的处理方法，适用于多核终端设备处理蓝牙数据的场景。

示例性的，图1A～图1C示出了三种应用场景，但图1A～图1C并不对本申请实施例的应用场景形成限定。

在一个场景中，如图1A所示，用户使用运动单车健身，并且佩戴智能手表。运动单车和智能手表均支持蓝牙功能。智能手表上安装了具有运动管理功能的应用程序(application，APP)。本申请实施例对APP的名称不做限定，例如，运动健康APP。运动单车和智能手表进行蓝牙通信后，在用户运动的过程中，运动单车通过蓝牙通信将相关数据持续的上报给智能手表。相应的，智能手表通过蓝牙通信接收相关数据，处理后在运动健康APP的界面中显示运动信息，以便于用户查看运动过程中的运动详情，及时调整运动状态。例如，如图1A所示，通过智能手表的显示，用户当前已经运动10分32秒，心率为102次/分钟(bpm)，消耗热量100千卡(kcal)，运动单车的配速为27千米/小时(km/h)。在该示例中，运动单车和智能手表进行蓝牙低功耗(bluetooth low energy，BLE)通信。

在另一个场景中，如图1B所示，手机和智能手表均支持蓝牙功能。手机和智能手表上安装有具有消息通知功能的APP，例如为设备自带的系统应用程序，称为消息通知APP。手机和智能手表进行蓝牙通信。手机收到一条提示信息，如图1B所示，手机当前界面中弹出提示框11，提示框11中包括提示信息，内容为“小明：今天晚上吃什么？”。手机通过蓝牙通信将提示信息发送给智能手表。相应的，智能手表接收提示信息，处理后进行显示，参见图1B中智能手表的显示内容。用户看到后，知道小明在询问，今天晚上吃什么。用户通过佩戴的智能手表可以方便的查看手机上的实时提示信息，避免了用户必须随时携带手机，解放了用户双手。在该示例中，手机和智能手表进行经典蓝牙通信。

在又一个场景中，如图1C所示，手机和智能手表均支持蓝牙功能。手机和智能手表上安装有具有运动管理功能的应用程序，例如，运动健康APP。手机和智能手表进行蓝牙通信。智能手表完成运动健康数据的采集后，通过蓝牙通信发送给手机。相应的，手机通过蓝牙通信接收运动健康数据，处理后在运动健康APP的相关界面中进行显示，具体参见图1C中手机的当前显示内容。通过手机的显示，弥补了智能手表因为屏幕狭小导致的用户观感差的缺点，提升了用户感受。在该示例中，手机和智能手表进行经典蓝牙通信。

本申请实施例中的多核终端设备，是指终端设备的处理器包括至少2个处理单元。本申请实施例对处理单元的数量、名称和类型不做限定。例如，处理器可以包括但不限于下列的处理单元：应用处理器(AP)，微控制单元(microcontroller unit，MCU)，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，数字信号处理器(digital signal processor，DSP)，或神经网络处理器(neural-networkprocessing unit，NPU)等。不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，至少1个处理单元可以称为主处理单元，除主处理单元之外的至少1个处理单元可以称为辅助处理单元。本申请实施例对主处理单元和辅助处理单元的数量、名称和类型不做限定。例如，主处理单元也可以称为主处理器或主核，辅助处理单元也可以称为辅助处理器、从处理单元、从处理器或者从核。

示例性的，图2为本申请实施例提供的终端设备的一种结构示意图。如图2所示，终端设备包括：主处理单元21、辅助处理单元22、蓝牙(BT)芯片23、存储器24、传感器25、电源模块26和显示器27。

主处理单元21，用于运行终端设备的操作系统，部署蓝牙协议栈、蓝牙服务以及蓝牙开放接口等。

辅助处理单元22，用于与传感器25通信，采集传感器25的数据并处理。相比于主处理单元21，辅助处理单元22还可以运行轻量级的操作系统。在本申请实施例中，辅助处理单元22还用于处理下沉(offload)业务的蓝牙数据。下沉(offload)业务是指部署在辅助处理单元上处理的蓝牙服务。

BT芯片23，用于与其他设备进行蓝牙连接和数据传输。在本申请实施例中，BT芯片23接收蓝牙数据后，可以针对下沉业务对蓝牙数据进行区分并加以过滤，将下沉业务的蓝牙数据发送给辅助处理单元22。BT芯片23还用于对辅助处理单元22发送的下沉业务的蓝牙数据进行协议封装，发送给目标设备。

存储器24，用于存储可执行的程序代码和/或数据，可执行的程序代码可以包括指令。存储器23可以包括存储程序区和存储数据区。存储器23可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，硬盘(hard disk drive，HDD)，固态硬盘(solid-state drive，SS)，闪存器件，通用闪存存储器(universal flashstorage，UFS)等，还可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。

传感器25，可以包括但不限于下列中的至少一项：压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，或者，骨传导传感器。

电源模块26，用于连接电源(例如电池)为终端设备中的模块或元器件供电，还可以监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。

需要说明的是，图2并不对终端设备的结构形成限定，终端设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或软件和硬件的组合实现。例如，终端设备还可以包括下列中的至少一项：移动通信模块、音频模块、摄像头、麦克风、耳机接口、天线等。

需要说明的是，本申请实施例对终端设备的名称和类型不做限定。例如，终端设备也可以称为终端、电子设备、通信设备或用户设备等。一些终端设备的举例为：手机、平板电脑、掌上电脑、可穿戴设备、移动互联网设备(mobile internet device，MID)、虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备，或智慧家庭(smarthome)中的终端等。

为了方便说明，本申请实施例以主处理单元和辅助处理单元均为1个，主处理单元为AP，辅助处理单元为MCU，终端设备为智能手表，与智能手表进行蓝牙通信的设备为运动单车或手机为例进行说明。

下面，为了方便理解本申请实施例提供的技术方案，对蓝牙通信的相关概念进行说明。

1、经典蓝牙、BR&EDR、BLE

根据蓝牙通信的发展，蓝牙通信可以包括经典蓝牙部分和BLE部分。通常，蓝牙协议标准4.0以下主要是经典蓝牙部分，BLE对应蓝牙协议标准4.0或更高协议版本。BLE是建立在经典蓝牙基础上而发展的。经典蓝牙通常用于数据量比较大的传输，例如，语音、音乐等。BLE相比于经典蓝牙，具有成本低、功耗低、实时性要求高的特点。

经典蓝牙又包括基础速率(basic rate，BR)和增强速率(enhanced data rate，EDR)。EDR相比于BR，具有更高的传输速率，比如，可以达到BR速率的8倍。

2、蓝牙协议栈

示例性的，图3为本申请实施例提供的蓝牙协议栈的一种结构示意图。如图3所示，蓝牙协议栈包括主机(Host)、控制器(Controller)和主机控制器接口(host controllerinterface，HCI)。HCI用于规范主机与控制器之间的通信协议和通信命令等。

通常，主机部署在主处理单元(例如AP)上，控制器部署在BT芯片上。

对于经典蓝牙和BLE，涉及的具体协议有所不同。

(1)经典蓝牙的蓝牙协议栈

在经典蓝牙中，控制器可以表示为BR/EDR Controller，包括：射频层(RF)、基带层(Baseband)和链路管理层(link management protocol，LMP)。射频层用于发送或接收数据等。基带层用于对数据进行调制解调等。链路管理层用于对链路进行管理和控制等。

主机中的高层协议包括但不限于：逻辑链路控制与适配协议(logic linkcontrol and adaptation protocol，L2CAP)、无线电频率通信协议(radio frequencycommunication，RFCOMM)、服务发现协议(service discovery protocol，SDP)等，具体参见蓝牙协议中的相关说明。

(2)BLE的蓝牙协议栈

在BLE中，控制器可以表示为LE Controller或BLE Controller，包括：物理层(physical layer，PHY)和链路层(link layer，LL)。物理层用于选择无线频段、调制解调方式、收发数据等。链路层用于对链路进行管理和控制、确定数据包的发送时间、选择射频通道、实现数据包的反馈和重传等。

主机中的高层协议可以包括但不限于：L2CAP、属性协议(attribute protocol，ATT)、通用属性协议(generic attribute profile，GATT)等，具体参见蓝牙协议中的相关说明。

还可以将BR/EDR Controller和LE Controller合并到一个Controller中，也就是通常所说的双模蓝牙。

3、角色、客户端、服务端

在蓝牙通信中，蓝牙服务由两种类型(或者角色)构成，包括：客户端(client)和服务端(server)。

客户端和服务端通信时，需要首先建立连接。通常，发起连接请求的一方称为客户端，接收连接请求的一方称为服务端。建立连接后，服务端可以提供数据服务。在客户端发起连接请求之前，服务端需要处于侦听状态，侦听是否有客户端要求建立连接。当服务端侦听到客户端的连接请求时，服务端可以选择建立连接或者拒绝连接。

举例说明。比如，在图1A所示的场景中，运动单车提供的蓝牙服务包括功率计、踏频计、速率计等。以速率计为例，速率计的两种角色包括速率数据服务端和速率数据读取客户端。运动单车和智能手表进行蓝牙通信时，智能手表作为速率数据读取客户端，向运动单车发起连接请求。运动单车作为速率数据服务端，接受连接请求，建立蓝牙连接。之后，运动单车可以向智能手表发送速率数据。相应的，智能手表处理后进行速率信息的显示。

再比如，在图1B所示的场景中，手机和智能手表均支持消息通知服务。消息通知服务的两种角色包括消息通知服务端和消息通知客户端。智能手表作为消息通知客户端，向手机发起连接请求；相应的，手机作为消息通知服务端，接受连接请求，建立蓝牙连接。之后，手机可以向智能手表发送通知信息；相应的，智能手表接收通知信息并处理，进行通知信息的显示。

又比如，在图1C所示的场景中，手机和智能手表均安装有运动健康APP。运动健康服务的两种角色包括运动健康服务端和运动健康客户端。手机作为运动健康客户端，向智能手表发起连接请求；相应的，智能手表作为运动健康服务端，接受连接请求，和手机建立蓝牙连接。

需要说明的是，在蓝牙通信中，一个设备可以仅作为客户端，或者仅作为服务端，或者作为客户端和服务端，这与蓝牙服务的软件开发、设备的类型等因素相关。

客户端和服务端建立连接后，服务端可以作为数据发送方向客户端发送数据，相应的，客户端作为数据接收方接收服务端发送的数据；或者，客户端作为数据发送方向服务端发送数据，相应的，服务端作为数据接收方接收客户端发送的数据。

4、蓝牙服务的逻辑通道管理信息

客户端和服务端建立连接后，终端设备作为客户端或者服务端，可以获知自身支持的蓝牙服务。终端设备作为客户端，可以通过服务发现、服务查询或设备查询等流程获知服务端提供的蓝牙服务。服务发现、服务查询或设备查询等流程可以参见蓝牙协议。

蓝牙服务具有逻辑通道管理信息，用于区分不同的蓝牙服务。

蓝牙通信方式不同时，采用的蓝牙协议有所不同，蓝牙服务的逻辑通道管理信息也有所不同。

(1)经典蓝牙中，蓝牙服务的逻辑通道管理信息

在经典蓝牙中，蓝牙服务的客户端和服务端之间采用Socket(套接字)连接，也称为BluetoothSocket连接。BluetoothSocket的连接过程是通过RFCOMM协议实现的。在客户端和服务端建立连接的过程中，涉及蓝牙服务对应的逻辑通道的逻辑通道信道(channel)号。RFCOMM通道具有数据链路连接标识(data link connection identifier，DLCI)。

经典蓝牙中，蓝牙服务的逻辑通道管理信息可以包括但不限于：蓝牙服务的通用唯一标识符(universally unique identifier，UUID)、蓝牙服务的逻辑通道信道(channel)号、蓝牙服务的角色，以及，蓝牙服务的DLCI。

其中，角色包括客户端和服务端。

DLCI与逻辑通道信道号和角色具有转换关系。基于该转换关系，根据逻辑通道信道号和角色可以计算得到DLCI，相应的，通过DLCI可以得到该DLCI对应的逻辑通道信道号和角色。DLCI可以参见蓝牙相关协议。

在本申请实施例中，DLCI可以被蓝牙芯片使用，用于过滤、区分不同的蓝牙服务，从而可以将不同的蓝牙服务的数据发送至主处理单元或者辅助处理单元处理。

可选的，若终端设备作为蓝牙服务的客户端，终端设备可以从蓝牙服务的服务端获取蓝牙服务的逻辑通道信道号。若终端设备作为蓝牙服务的服务端，终端设备可以直接获取蓝牙服务的逻辑通道信道号。

举例说明。在图1B所示的场景中，蓝牙服务为消息通知服务。智能手表为消息通知服务的客户端，手机为消息通知服务的服务端。智能手表接收手机发送的消息通知服务的逻辑通道信道号。对于智能手表来说，角色为客户端，根据消息通知服务的逻辑通道信道号和角色(客户端)可以计算得到DLCI。消息通知服务的逻辑通道管理信息包括：消息通知服务的逻辑通道信道号，智能手表在消息通知服务中的角色(客户端)，和DLCI。

(2)BLE中，蓝牙服务的逻辑通道管理信息

BLE支持GATT协议，蓝牙服务的客户端和服务端之间采用GATT连接。在GATT协议中，蓝牙服务通过数据分层结构进行描述。

示例性的，图4为本申请实施例提供的GATT数据结构的一种示意图。如图4所示，service(服务)为至少一个，每个service(服务)包括至少一个character(特征)。character(特征)可以包括至少一个descriptor(描述符或描述信息)；或者，character(特征)不包括descriptor(描述符)。

character(特征)具有特征属性(property)，例如，广播(broadcast)、读(read)、写(write)、通知(notify)、指示(indicate)，等等。假设，设备A和设备B进行蓝牙通信。对于设备B来说，通过读(read)和写(write)，可以通知设备A向设备B请求数据。设备B可以通过通知(notify)的方式向设备A发送数据，相应的，设备A接收设备B通过通知(notify)的方式上报的数据。

一些特征属性(property)需要使能后才能生效，例如，通知(notify)和指示(indicate)，此时，可以描述为character(特征)需要被使能。因此，如果character(特征)的特征属性需要被使能，或者说，character(特征)需要被使能，那么，character(特征)一定包括descriptor(描述符)，用于客户端使能或者禁止character(特征)。

BLE中，蓝牙服务的逻辑通道管理信息包括但不限于：蓝牙服务的UUID、蓝牙服务包括的character(特征)的逻辑通道索引和特征属性(property)。如果character(特征)包括descriptor(描述符)，蓝牙服务的逻辑通道管理信息还包括：character(特征)的descriptor(描述符)的逻辑通道索引。其中，在一些实施方式中，逻辑通道索引也表示为value handle(值索引、值句柄等)或者instance id(实例标识)。

下面结合图1A所示场景和图5，对蓝牙服务的逻辑通道管理信息进行示例性说明，但并不形成限定。

在图1A所示的场景中，智能手表上安装有运动健康APP。运动健康APP具备处理3种service(服务)数据的能力，3种service(服务)分别为：速率计服务(服务1、service1)、功率计服务(服务2、service2)和踏频计服务(服务3、service3)。

以速率计服务为例，图5为本申请实施例提供的速率计服务的逻辑通道管理信息的一种示意图。速率计服务包括2个特征，标识为特征1和特征2，特征1不包括描述符，特征2包括描述符。在图5中，包括两种索引值，分别为：属性索引(attribute handle)和valuehandle(值索引)。service(服务)、character(特征)、descriptor(描述符)均具有属性索引(attribute handle)，取值不同，可以唯一区分不同的服务、特征或描述符。例如，速率计服务的属性索引取值为22、速率计服务中特征1的属性索引取值为23、速率计服务中特征2的属性索引取值为25、速率计服务中特征2的描述符的属性索引取值为27。character(特征)具有value handle(值索引)，是指特征的取值对应的索引值。通过属性索引(attributehandle)可以匹配到是速率计的一个特征，通过value handle(值索引)可以匹配到速率计特征的取值。举例说明。假设，特征1表示速率计服务的速度数值。速率计上报数据时，如果携带的value handle值为24，通过解析数据可以得知速率计的速度数值的具体取值，例如为27km/h。可选的，在一些实施方式中，descriptor(描述符)具有value handle(值索引)，descriptor(描述符)的value handle(值索引)和属性索引(attribute handle)相同。

如图5所示，速率计服务的属性索引取值22。速率计服务包括2个特征。特征1的属性索引取值23，值索引取值24。特征2的属性索引取值25，值索引取值26。特征2的特征属性包括通知(notify)，具有描述符。特征2的描述符的属性索引(或值索引)取值27。

速率计服务的逻辑通道管理信息可以包括：速率计服务的UUID、特征1的逻辑通道索引(取值24)和特征属性、特征2的逻辑通道索引(取值26)和特征属性，以及，特征2的描述符的逻辑通道索引(取值27)。

相关技术中，蓝牙服务部署在终端设备的主处理单元(例如AP)上。终端设备和其他设备进行蓝牙通信时，由AP处理蓝牙服务的蓝牙数据。示例性的，图6为本申请实施例提供的终端设备处理蓝牙数据的一种原理示意图。参见图6中的粗实线，终端设备作为数据接收方时，BT芯片接收蓝牙数据后，发送给AP处理；终端设备作为数据发送方时，AP对蓝牙数据进行协议封装后发送给BT芯片，BT芯片将接收到的数据发送出去。可见，AP一直处于工作状态。而AP的工作电流较大，会加剧终端设备的耗电。尤其对于蓝牙数据频繁传输的场景，终端设备长时间维持在高耗电的状态，终端设备的电池容量有限，造成终端设备的续航时间明显下降。

下面，结合图1A～图1B所示的应用场景，针对BLE和经典蓝牙的不同蓝牙通信方式，对终端设备处理蓝牙数据进行详细说明。

在一种实现方式中，结合图1A，为BLE通信。图7为本申请实施例提供的BLE通信中终端设备处理蓝牙数据的一种原理示意图。需要说明，图7并不对运动单车和智能手表的结构形成限定。

如图7所示，运动单车包括：BT芯片、蓝牙协议栈、传输模块、蓝牙服务、传感器和显示屏。其中，传感器示出了速率计传感器和功率计传感器。蓝牙服务部署在应用层，包括速率计服务和功率计服务。具体的，运动单车作为蓝牙服务的服务端，蓝牙服务包括：速率数据服务端和功率数据服务端。传输模块用于传输数据，可以包括但不限于：Commu模块、通用异步收/发器(universal asynchronous receiver/transmitter，UART)、串行外设接口(Serial Peripheral Interface，SPI)等。Commu模块可以实现业务数据的分发。UART是一种通用的串行数据总线，用于异步通信，可以双向通信，实现全双工传输和接收。SPI是一种高速的、全双工的、同步的通信总线。蓝牙协议栈示出了部分蓝牙协议和逻辑通道管理信息。在BLE中，蓝牙协议包括但不限于GATT、ATT、L2CAP和HCI。在逻辑通道管理信息中，速率计服务对应的逻辑通道管理信息标识为UINT1，功率计服务对应的逻辑通道管理信息标识为UINT2。

如图7所示，智能手表包括：BT芯片、MCU、AP和显示屏。BT芯片中包括RF模块和基带层/LL模块，“/”表示或者的关系，可以参见上述蓝牙协议栈的相关说明。MCU中包括：传输模块、传感器、定位模块和其他模块。传输模块用于传输数据，可以包括但不限于：Commu模块、UART、SPI等。AP中包括：蓝牙协议栈、BT Framework(接口)、蓝牙服务和运动健康APP。其中，运动健康APP位于应用层，即第三方应用，可以提供多种蓝牙服务，例如，速率计服务、功率计服务。在本示例中，智能手表作为蓝牙服务的客户端，包括：速率数据读取客户端和功率数据读取客户端。BT Framework用于提供API，供上层应用调用，从而实现蓝牙能力。例如，提供的API包括BluetoothGATT。蓝牙协议栈示出了部分蓝牙协议和逻辑通道管理信息。在BLE中，蓝牙协议包括但不限于GATT、ATT、L2CAP和HCI。在逻辑通道管理信息中，速率计服务对应的逻辑通道管理信息标识为UINT1，功率计服务对应的逻辑通道管理信息标识为UINT2。

在该实现方式中，运动单车开机后，先注册BLE GATT SERVER服务端，用于监听客户端的连接。随后，运动单车发起BLE的可连接广播。智能手表运行运动健康APP后，运动健康APP通过调用BT Framework提供的BLE扫描接口，开始扫描周围的BLE设备。BT芯片启动扫描，获得扫描结果，将扫描结果发送给AP。蓝牙协议栈解析扫描结果，通过回调通知到运动健康APP。运动健康APP获得扫描结果，得到运动单车的设备广播名称和设备的媒体访问控制(media access control，MAC)地址等信息。用户可以在运动健康APP的相关界面中操作，发起对运动单车的连接。相应的，运动健康APP调用BT Framework提供的connectGATT，发起逻辑通道的连接。运动健康APP等到连接的状态回调之后，通过BT Framework提供的discovery service，查询运动单车提供的蓝牙服务，获得蓝牙服务的逻辑通道管理信息。运动健康APP使能运动单车的数据上报服务后，运动单车可以向智能手表上报相关的数据。

如图7中的粗实线所示，智能手表作为数据接收方时，智能手表的BT芯片接收到运动单车发送的蓝牙数据后，直接发送给AP处理。AP对蓝牙数据处理后，可以发送给显示屏，实现屏幕送显。智能手表作为数据发送方时，AP对蓝牙数据进行处理后发送给BT芯片，BT芯片将从AP接收到的数据发送给运动单车。

在实际的应用场景中，用户使用运动单车锻炼时，运动单车会不停的生成运动数据并上报给智能手表，导致智能手表的AP一直处于工作状态，耗电较大，降低了智能手表的续航时间。

在另一种实现方式中，结合图1B，为经典蓝牙通信。图8为本申请实施例提供的经典蓝牙中终端设备处理蓝牙数据的一种原理示意图。需要说明，图8并不对手机和智能手表的结构形成限定。

如图8所示，手机包括：BT芯片、蓝牙协议栈、BT Framework、蓝牙服务和显示屏。其中，蓝牙服务部署在应用层，示出了消息通知服务和运动健康服务。手机作为消息通知服务的服务端，包括：消息通知服务端。手机还可以作为运动健康服务的客户端或者服务端，包括：运动健康客户端/服务端。BT Framework用于提供API，供上层应用调用，从而实现蓝牙通信能力。例如，提供的API包括BluetoothSocket。蓝牙协议栈示出了部分蓝牙协议和逻辑通道管理信息。在经典蓝牙中，蓝牙协议包括但不限于RFCOMM、L2CAP和HCI。在逻辑通道管理信息中，消息通知服务对应的逻辑通道管理信息标识为UINT1，运动健康服务对应的逻辑通道管理信息标识为UINT2。

图8和图7提供的智能手表的结构相似，此处不再赘述，区别在于：蓝牙通信方式不同、使用的蓝牙协议不同，BT Framework提供的API不同，实现的蓝牙服务不同。在图8中，支持经典蓝牙通信，蓝牙协议包括RFCOMM、L2CAP和HCI，BT Framework提供的API包括BluetoothSocket等，蓝牙服务包括消息通知服务和运动健康服务。智能手表作为消息通知服务的客户端，包括：消息通知客户端。智能手表还可以作为运动健康服务的服务端或者客户端，包括：运动健康服务端/客户端。

在该实现方式中，手机上的消息通知服务端，使用BluetoothServerSocket创建侦听服务器socket，监听客户端的连接请求。当监听到客户端的连接请求并接受时，返回一个BluetoothSocket来管理连接。智能手表上的消息通知客户端，使用单个BluetoothSocket发起和管理连接。具体的，消息通知客户端通过调用BT Framework提供的bluetoothsocket connect接口，发起蓝牙RFCOMM通道的建立。手机上的消息通知服务端和智能手表上的消息通知客户端创建连接后，通过Bluetoothsocket收发消息和数据。

如图8中的粗实线所示，当手机上有通知消息时，手机将通知消息发送给智能手表，使得智能手表显示该通知消息。智能手表作为数据接收方，智能手表的BT芯片接收到手机发送的通知消息，直接发送给AP处理。AP对通知消息处理后，可以发送给显示屏，实现屏幕送显。

在实际的应用场景中，手机上会不定期的收到通知消息。手机不停的将通知消息上报给智能手表，导致智能手表的AP一直处于工作状态，耗电较大，降低了智能手表的续航时间。

本申请实施例提供一种蓝牙数据的处理方法，终端设备上的主处理单元(例如AP)可以将部分蓝牙服务下沉到辅助处理单元(例如MCU)上进行管理，该部分蓝牙服务可以称为下沉(offload)业务。主处理单元、辅助处理单元和BT芯片之间需要同步下沉业务的必要数据，蓝牙芯片具有解析、封装、过滤下沉业务的蓝牙数据的能力。这样，终端设备作为数据接收方时，BT芯片接收蓝牙数据后，对蓝牙数据进行解析，确定是下沉业务的数据时，发送给辅助处理单元处理；确定不是下沉业务的数据时，发送给主处理单元处理。终端设备作为数据发送方时，对于下沉业务，辅助处理单元可以将下沉业务的数据发送给BT芯片，BT芯片将数据封装后发送出去。可见，本申请实施例提供的蓝牙数据的处理方法，通过辅助处理单元处理部分蓝牙数据，对原本需要由主处理单元处理的蓝牙数据形成了分流，缩短了主处理单元的工作时间，降低了终端设备的耗电，提高了终端设备的续航时间。

示例性的，图9为本申请实施例提供的终端设备处理蓝牙数据的另一种原理示意图。如图9所示，终端设备包括AP91、MCU92和BT芯片93。其中，MCU92包括：下沉管理业务模块921和蓝牙业务模块922。BT芯片93包括：接口模块931、信息列表932和协议数据解析/封装模块933。

下沉管理业务模块921，用于和AP91通信，提供API接口供上层应用调用。比如，API接口可以包括数据同步接口、数据取消同步接口等。数据同步接口用于AP91和MCU92之间同步下沉业务的第一服务信息。数据取消同步接口用于AP91和MCU92之间取消同步下沉业务的第一服务信息。下沉管理业务模块921还用于和蓝牙业务模块922通信，可以调用蓝牙业务模块922提供的API。

蓝牙业务模块922，用于和下沉管理业务模块921、BT芯片93通信，从而实现MCU92和BT芯片93之间的通信。蓝牙业务模块922可以提供API接口供下沉管理业务模块921调用。比如，API接口包括但不限于下列中的至少一项：虚拟连接接口、注册接口、使能服务接口、读接口、写接口，或者，回调接口。当蓝牙通信方式不同时，比如经典蓝牙和BLE，蓝牙业务模块922提供的API接口有所不同，具体可以参见图15和图17所示实施例的说明。

接口模块931，用于和蓝牙业务模块922通信，从而实现MCU92和BT芯片93之间的通信。接口模块931可以提供API接口。API接口包括但不限于下列中的至少一项：虚拟连接接口、注册接口、使能服务接口、读接口、写接口，或者，回调接口。当蓝牙通信方式不同时，接口模块931提供的API接口有所不同，具体可以参见图15和图17所示实施例的说明。

信息列表932，用于存储与终端设备进行蓝牙通信的目标设备的设备标识，以及存储下沉业务的逻辑通道信息。

协议数据解析/封装模块933，用于对BT芯片93接收的蓝牙数据进行解析，根据信息列表932中存储的设备标识和逻辑通道信息确定接收的蓝牙数据是否属于下沉业务；如果属于下沉业务，则发送给MCU92处理；如果不属于下沉业务，则发送给AP91处理。协议数据解析/封装模块933还用于对从MCU92接收的下沉业务的数据进行封装，之后发送给目标设备。

其中，AP91、MCU92和BT芯片93之间具有核间通信接口。AP91和BT芯片93之间的通信，可以通过AP91和BT芯片93之间的通信接口直接通信，或者，通过MCU92实现通信。

下面通过具体的实施例对本申请的技术方案进行详细说明。下面的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

本申请实施例中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

需要说明，在本申请实施例中，蓝牙服务和服务表示相同含义。

图10为本申请实施例提供的蓝牙数据的处理方法的一种流程图。本实施例提供的蓝牙数据的处理方法，执行主体可以为终端设备。终端设备包括主处理单元、辅助处理单元和蓝牙芯片。终端设备和目标设备已经建立蓝牙连接。本实施例对目标设备的名称和类型不做限定。示例性的，在图1A所示的场景中，终端设备为智能手表，目标设备为运动单车。在图1B所示的场景中，终端设备为智能手表，目标设备为手机。在图1C所示的场景中，终端设备为手机，目标设备为智能手表。终端设备和目标设备建立蓝牙连接后，蓝牙芯片记录有连接信息。连接信息包括但不限于：面向连接的异步链路(asynchronous connection-oriented link，ACL)标识和目标设备的MAC地址。终端设备还可以获知终端设备和目标设备支持的蓝牙服务。

如图10和图9所示，本实施例提供的蓝牙数据的处理方法，可以包括：

S1001、主处理单元向辅助处理单元发送目标设备的第一MAC地址和目标服务的第一服务信息。

相应的，辅助处理单元接收主处理单元发送的第一MAC地址和第一服务信息。

其中，第一服务信息用于辅助处理单元处理目标服务的蓝牙数据。

其中，本申请实施例提供的蓝牙数据的处理方法，主处理单元、辅助处理单元和蓝牙芯片之间传输的数据均包括目标设备的MAC地址。为了方便区分，主处理单元向辅助处理单元发送的目标设备的MAC地址，称为第一MAC地址。

具体的，终端设备或目标设备可以支持多种蓝牙服务。在多种蓝牙服务中，将部署在终端设备的辅助处理单元上处理的蓝牙服务称为目标服务，也可以称为下沉(offload)业务。可选的，目标服务为服务端提供的服务。可选的，终端设备作为客户端、目标设备作为服务端时，终端设备可以通过服务发现、服务查询或设备查询等流程获知目标设备支持的蓝牙服务，目标服务为目标设备支持的蓝牙服务。可选的，终端设备作为服务端时，目标服务为终端设备支持的蓝牙服务。

可选的，目标服务的全部蓝牙数据或者部分蓝牙数据可以部署在辅助处理单元上处理。比如，在BLE通信中，蓝牙服务包括至少一个character(特征)。可以将蓝牙服务包括的全部character(特征)都部署在辅助处理单元上；或者，可以将蓝牙服务中的部分character(特征)部署在辅助处理单元上。

终端设备和目标设备进行蓝牙通信的方式不同时，使用的蓝牙协议不同，第一服务信息也有所不同。

可选的，在BLE中，目标服务包括至少一个特征。第一服务信息包括：目标服务的UUID、至少一个特征中目标特征的逻辑通道索引和特征属性。可以参考本申请上述关于蓝牙服务的逻辑通道管理信息的相关说明。其中，第一服务信息用于辅助处理单元处理目标特征的蓝牙数据，也就是说，将目标服务中的目标特征部署在终端设备的辅助处理单元上进行处理。本实施例对目标特征的数量不做限定。

可选的，如果目标特征需要被使能。在一种实现方式中，如果目标特征没有被主处理单元使能，则第一服务信息还包括：目标特征的描述符的逻辑通道索引。目标特征的描述符的逻辑通道索引用于对目标特征进行使能。

在该实现方式中，目标特征需要被使能，主处理单元或者辅助处理单元均可以对目标特征使能。如果目标特征没有被主处理单元使能，那么，需要由辅助处理单元进行使能。第一服务信息需要包括目标特征的描述符的逻辑通道索引，使得辅助处理单元对目标特征使能。如果目标特征已经被主处理单元使能，那么，第一服务信息不需要包括目标特征的描述符的逻辑通道索引，从而避免了主处理单元和辅助处理单元对目标特征的重复使能。

可选的，如果目标特征需要被使能。在另一种实现方式中，第一服务信息还包括：目标特征的描述符的逻辑通道索引。

在该实现方式中，目标特征需要被使能。无论主处理单元是否已经对目标特征使能，第一服务信息都可以包括目标特征的描述符的逻辑通道索引。辅助处理单元可以根据目标特征的描述符的逻辑通道索引对目标特征使能。在该实现方式中，主处理单元和辅助处理单元可能对目标特征重复使能。

可选的，主处理单元可以向辅助处理单元发送使能信息，指示主处理单元是否对目标特征使能。通过使能信息，避免了主处理单元和辅助处理单元对目标特征的重复使能。

可选的，使能信息可以包含在第一服务信息中。减少了主处理单元和辅助处理单元之间传输数据的次数。

可选的，在经典蓝牙中，第一服务信息包括：目标服务的逻辑通道信道号和目标服务的角色。其中，角色为客户端或服务端。可以参考本申请上述关于蓝牙服务的逻辑通道管理信息的相关说明。

可选的，在经典蓝牙中，第一服务信息还可以包括目标服务的UUID。

需要说明，终端设备可以作为目标服务的客户端，也可以作为目标服务的服务端；相应的，目标设备作为目标服务的服务端，或者作为目标服务的客户端。比如，一种应用场景可以为：终端设备作为目标服务的客户端，目标设备作为目标服务的服务端，目标服务为目标设备支持的蓝牙服务。目标设备可以向终端设备发送目标服务的数据。终端设备也可以向目标设备发送目标服务的数据。又比如，一种应用场景可以为：终端设备作为目标服务的服务端，目标设备作为目标服务的客户端，目标服务为终端设备支持的蓝牙服务。终端设备可以向目标设备发送目标服务的数据。目标设备也可以向终端设备发送目标服务的数据。

可选的，结合图9，下沉管理业务模块921可以通过调用API接口，例如数据同步接口，实现主处理单元向辅助处理单元发送第一MAC地址和第一服务信息。

S1002、辅助处理单元向蓝牙芯片发送第一MAC地址和第二服务信息。

其中，第二服务信息为第一服务信息中的部分或全部信息。

相应的，蓝牙芯片接收辅助处理单元发送的第一MAC地址和第二服务信息。

可选的，在BLE中，第二服务信息包括：目标服务包括的至少一个特征中目标特征的逻辑通道索引和特征属性。

可选的，如果目标特征需要被使能，第二服务信息还可以包括：目标特征的描述符的逻辑通道索引。可以参见S1001中的说明，此处不再赘述。

可选的，第二服务信息还可以包括：目标服务的UUID。

可选的，在经典蓝牙中，第二服务信息包括：目标服务的逻辑通道信道号和目标服务的角色；其中，角色为客户端或服务端。

可选的，第二服务信息还可以包括：目标服务的UUID。需要说明的是，如果第一服务信息不包括目标服务的UUID，则第二服务信息不包括目标服务的UUID。如果第一服务信息包括目标服务的UUID，那么，第二服务信息可以包括目标服务的UUID，也可以不包括目标服务的UUID。

可选的，结合图9，下沉管理业务模块921、蓝牙业务模块922和接口模块931可以通过调用相关的API接口，实现辅助处理单元向蓝牙芯片发送第一MAC地址和第二服务信息。

S1003、蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息。目标设备的设备标识和目标服务的逻辑通道信息用于蓝牙芯片处理目标服务的蓝牙数据。

之后，蓝牙芯片和辅助处理单元可以处理目标服务的蓝牙数据。

具体的，设备标识供蓝牙芯片使用，可以唯一区分不同的设备。可选的，目标设备的设备标识包括：目标设备和终端设备之间蓝牙连接的ACL链路的标识。可选的，ACL链路标识可以表示为ACL handle(句柄)。

服务的逻辑通道信息，可以在一个设备支持的所有蓝牙服务中，唯一区分不同的蓝牙服务。对于目标服务的逻辑通道信息，如果目标服务是目标设备支持的蓝牙服务，通过目标服务的逻辑通道信息，可以在目标设备支持的所有蓝牙服务中唯一识别出目标服务；如果目标服务是终端设备支持的蓝牙服务，通过目标服务的逻辑通道信息，可以在终端设备支持的所有蓝牙服务中唯一识别出目标服务。

可选的，目标服务的逻辑通道信息和目标设备的设备标识具有关联关系。举例说明。在BLE通信中，蓝牙服务采用“应用-服务-特征-描述符”的分层结构进行描述，参见图4和图5所示。对于每个设备，服务、特征和描述符的属性索引(attribute handle)内部排序，这有可能导致不同设备支持的不同服务的逻辑通道信息相同。比如，设备1支持的速率计服务的属性索引(attribute handle)范围是21-30，功率计服务的属性索引(attributehandle)范围是31-40，速率计服务中特征1的value handle(值索引)取值为25。设备2支持的功率计服务的属性索引(attribute handle)范围是21-30，功率计服务中特征1的valuehandle(值索引)取值为25。可见，对于value handle(值索引)取值25，在设备1和设备2中对应的服务和特征是不同的，设备1对应速率计服务的特征1，设备2对应功率计服务的特征1。因此，目标服务的逻辑通道信息和目标设备的设备标识可以具有关联关系，通过目标设备的设备标识以及目标服务的逻辑通道信息，可以唯一区分不同设备的不同服务。

终端设备和目标设备进行蓝牙通信的方式不同时，使用的蓝牙协议不同，目标服务的逻辑通道信息有所不同。

可选的，在BLE中，目标服务的逻辑通道信息包括：目标服务包括的至少一个特征中目标特征的逻辑通道索引和特征属性。

可选的，如果目标特征需要被使能，目标服务的逻辑通道信息还可以包括：目标特征的描述符的逻辑通道索引。可以参见S1001中的说明，此处不再赘述。

可选的，在经典通信中，目标服务的逻辑通道信息包括目标服务的DLCI。在该实现方式中，目标服务的DLCI也可以称为目标服务的逻辑通道索引。

在本实施例中，信息列表用于存储目标设备的设备标识和目标服务的逻辑通道信息。本实施例对信息列表的实现方式不做限定，可以为数据列表或者预设格式的文件，可以为一个数据列表或者多个数据列表，或者一个文件或者多个文件。

可选的，信息列表包括设备列表和下沉业务列表。设备列表包括目标设备的设备标识。下沉业务列表包括目标服务的逻辑通道信息。可选的，下沉业务列表还可以包括目标设备的设备标识，可以指示出目标设备的设备标识和目标服务的逻辑通道信息的关联关系。

可选的，在BLE中，蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息，可以包括：

蓝牙芯片根据第一MAC地址确定目标设备的设备标识。

蓝牙芯片根据第二服务信息确定目标服务的逻辑通道信息。

在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息。

具体的，在BLE中，主处理单元向辅助处理单元发送第一MAC地址和第一服务信息，辅助处理单元向蓝牙芯片发送第一MAC地址和第二服务信息。蓝牙芯片可以根据第一MAC地址得到目标设备的ACL handle，并且根据第二服务信息确定目标服务的逻辑通道信息。

可选的，在经典蓝牙通信中，蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息之前，还包括：

主处理单元向蓝牙芯片发送通道信息。通道信息包括目标设备的第二MAC地址和目标服务的DLCI。

相应的，蓝牙芯片根据第一MAC地址和第二服务信息，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息，包括：

蓝牙芯片根据第一MAC地址、第二服务信息、第二MAC地址和DLCI，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息。

可选的，蓝牙芯片根据第一MAC地址、第二服务信息、第二MAC地址和DLCI，在信息列表中增加目标设备的设备标识和目标服务的逻辑通道信息，包括：

若第一MAC地址和第二MAC地址相同，蓝牙芯片根据第一MAC地址或第二MAC地址确定目标设备的设备标识。

蓝牙芯片根据DLCI得到待比对逻辑通道信道号和待比对角色。

若待比对逻辑通道信道号和目标服务的逻辑通道信道号相同，且待比对角色和目标服务的角色相同，则蓝牙芯片将DLCI确定为目标服务的逻辑通道信息。

在信息列表中增加目标设备的设备标识和DLCI。

可选的，通道信息还可以包括目标服务的UUID。

具体的，在经典蓝牙中，蓝牙协议栈至少根据服务的逻辑通道信道号和角色计算得到服务的DLCI，也就是说，计算DLCI时还需要其他的信息，其他信息不同时，相同的逻辑通道信道号和角色对应的DLCI可能不同。主处理单元向蓝牙芯片发送目标设备的第二MAC地址和目标服务的DLCI。主处理单元向辅助处理单元发送目标设备的第一MAC地址和目标服务的第一服务信息，辅助处理单元向蓝牙芯片发送第一MAC地址和第二服务信息。为了方便区分，将主处理单元向辅助处理单元发送的目标设备的MAC地址称为第一MAC地址，将主处理单元向蓝牙芯片发送的目标设备的MAC地址称为第二MAC地址。当第一MAC地址和第二MAC地址相同时，说明对应同一个目标设备，蓝牙芯片根据第一MAC地址或第二MAC地址可以确定目标设备的ACL handle。蓝牙芯片根据从主处理单元接收到的DLCI计算得到待比对逻辑通道信道号和待比对角色。如果待比对逻辑通道信道号和从辅助处理单元接收到的目标服务的逻辑通道信道号相同，并且，待比对角色和从辅助处理单元接收到的目标服务的角色相同，那么，蓝牙芯片将从主处理单元接收的DLCI确定为目标服务的逻辑通道信息。

可见，本实施例提供的蓝牙数据的处理方法，终端设备的主处理单元可以将部分蓝牙服务下沉到辅助处理单元上处理。主处理单元和辅助处理单元之间同步目标设备的MAC地址目标服务的第一服务信息，辅助处理单元和蓝牙芯片之间传输目标设备的MAC地址目标服务的第二服务信息，从而，辅助处理单元和蓝牙芯片获知目标服务是在辅助处理单元上处理。后续，辅助处理单元和蓝牙芯片可以处理目标服务的蓝牙数据。本实施例提供的蓝牙数据的处理方法，将主处理单元处理的蓝牙服务的部分或者全部蓝牙数据转移到辅助处理单元处理，形成了数据分流，缩短了主处理单元的工作时间。由于辅助处理单元的耗电量相比于主处理单元较小，因此，降低了终端设备的耗电，延长了终端设备的续航时间。

可选的，本实施例提供的蓝牙数据的处理方法，还可以包括：

S1004、蓝牙芯片接收第一蓝牙数据。

S1005、蓝牙芯片解析第一蓝牙数据，得到第一设备标识和第一逻辑通道索引。判断第一设备标识和第一逻辑通道索引是否在信息列表中。

如果第一设备标识和第一逻辑通道索引在信息列表中，说明第一蓝牙数据为目标服务的蓝牙数据，需要由辅助处理单元处理，则执行S1006和S1007。

如果第一设备标识或第一逻辑通道索引不在信息列表中，说明第一蓝牙数据不是目标服务的蓝牙数据，需要由主处理单元处理，则执行S1008和S1009。

S1006、蓝牙芯片将第一蓝牙数据发送至辅助处理单元。

S1007、辅助处理单元处理第一蓝牙数据。

S1008、蓝牙芯片将第一蓝牙数据发送至主处理单元。

S1009、主处理单元处理第一蓝牙数据。

在该实现方式中，终端设备作为数据接收端，接收并处理目标设备发送的蓝牙数据。具体的，终端设备的蓝牙芯片具有协议数据解析能力，例如，图9中所示的协议数据解析/封装模块933，从第一蓝牙数据中解析出第一设备标识和第一逻辑通道索引，根据信息列表判断第一蓝牙数据是否属于目标服务的数据。如果是目标服务的数据，则由辅助处理单元处理，降低了终端设备的能耗，延长了续航时间。

下面，结合图11和图12对协议数据解析/封装进行示例性说明，但图11和图12并不对数据结构形成限定。

示例性的，图11为本申请实施例提供的BLE通信中的一种数据结构。如图11所示，GATT数据包括：类型(TYPE)、ACL句柄(ACL HANDLE)、ACL数据长度(ACL DATA LENGTH)、L2CAP数据长度(L2CAP DATA LENGTH)、L2CAP CID(communication identifier，通信标识符)、ATT操作码(ATT OPCODE)、ATT句柄(ATT Handle)、ATT数据(ATT DATA)。其中，类型具体为ACL。

图11中的4个箭头指示的位置，依次为：数据解析开始/数据封装结束的位置、设备标识所在的位置、逻辑通道信息所在的位置、数据解析结束/数据封装开始的位置。

示例性的，图12为本申请实施例提供的经典蓝牙通信中的一种数据结构。如图12所示，RFCOMM数据包括：类型(TYPE)、ACL句柄(ACL HANDLE)、ACL数据长度(ACL DATALENGTH)、L2CAP数据长度(L2CAP DATA LENGTH)、L2CAP CID、RFCOMM DLCI、RFCOMM控制(RFCOMM CONTROL)、RFCOMM数据(RFCOMM DATA)。其中，类型具体为ACL。

图12中的4个箭头指示的位置，依次为：数据解析开始/数据封装结束的位置、设备标识所在的位置、逻辑通道信息所在的位置、数据解析结束/数据封装开始的位置。

可选的，本实施例提供的蓝牙数据的处理方法，还可以包括：

S1010、辅助处理单元生成目标服务的第二蓝牙数据。

S1011、辅助处理单元将第二蓝牙数据发送至蓝牙芯片。

S1012、蓝牙芯片根据目标设备的设备标识和目标服务的逻辑通道信息，对第二蓝牙数据进行封装，得到待发送数据。

S1013、蓝牙芯片向目标设备发送待发送数据。

在该实现方式中，终端设备作为数据发送端，向目标设备发送目标服务的数据。具体的，辅助处理单元处理目标服务的数据后，将第二蓝牙数据发送给蓝牙芯片。蓝牙芯片具有协议数据封装能力，例如，图9中所示的协议数据解析/封装模块933，根据信息列表将第二蓝牙数据封装后发送给目标设备。由辅助处理单元处理目标服务的数据，降低了终端设备的能耗，延长了续航时间。

可选的，图13为本申请实施例提供的蓝牙数据的处理方法的另一种流程图。如图13所示，本实施例提供的蓝牙数据的处理方法，还可以包括：

S1301、主处理单元向辅助处理单元发送第一信息。第一信息用于指示主处理单元处理目标服务的蓝牙数据。

可选的，第一信息可以包括目标设备的第一MAC地址和目标服务的第一服务信息。

可选的，如图9所示，下沉管理业务模块921可以通过调用API接口，例如数据取消同步接口，实现主处理单元向辅助处理单元发送第一信息。

S1302、辅助处理单元根据第一信息删除第一服务信息。

可选的，辅助处理单元根据第一信息还删除第一MAC地址。

S1303、辅助处理单元向蓝牙芯片发送第二信息。第二信息用于指示主处理单元处理目标服务的蓝牙数据。

可选的，第二信息可以包括目标设备的第一MAC地址和目标服务的第二服务信息。

可选的，如图9所示，下沉管理业务模块921、蓝牙业务模块922和接口模块931可以通过调用相关的API接口，实现辅助处理单元向蓝牙芯片发送第二信息。

S1304、蓝牙芯片根据第二信息在信息列表中删除目标服务的逻辑通道信息。

可选的，蓝牙芯片根据第二信息还删除目标设备的设备标识。

在该实现方式中，目标服务可以重新部署在主处理单元上。因此，主处理单元、辅助处理单元和蓝牙芯片之间需要删除目标服务的相关信息，从而使得主处理单元可以处理目标服务的蓝牙数据。通过该实现方式，可以在主处理单元和辅助处理单元上灵活布置需要处理的蓝牙服务。

可选的，在上述实施例的基础上，结合图1A所示场景，本申请的另一个实施例提供了BLE通信中蓝牙数据的处理方法的一种实现方式。参见图14和图15，图14为本申请实施例提供的BLE通信中终端设备处理蓝牙数据的另一种原理示意图。图15为本申请实施例提供的蓝牙数据的处理方法的又一种流程图。

如图9和图14所示，在BLE通信中，下沉管理业务模块921对应图14中的下沉管理业务模块，蓝牙业务模块922对应图14中的GATT蓝牙业务模块，接口模块931对应图14中的GATT接口模块，信息列表932对应图14中的设备列表和下沉业务列表，协议数据解析/封装模块933对应图14中的协议数据解析/封装模块。其中，下沉管理业务模块、GATT蓝牙业务模块、GATT接口模块提供的API执行GATT协议。

图14和图7相比，图14中的粗实线和粗虚线，示出了蓝牙数据处理过程中的数据流向。在图7中，在智能手表中，由AP处理蓝牙服务的数据，BT芯片并不对数据进行解析/封装。而在图14中，在智能手表中，目标服务部署在MCU上。智能手表作为数据接收方时，智能手表的BT芯片接收到运动单车发送的蓝牙数据后，进行数据解析，判断是否属于目标服务的数据。如果属于目标服务的数据，则发送给MCU处理，由MCU实现目标服务数据的屏幕送显；如果不属于目标服务的数据，则发送给AP处理，由AP实现屏幕送显。智能手表作为数据发送方时，MCU对目标服务的蓝牙数据进行处理后发送给BT芯片，BT芯片对数据封装后发送给运动单车。

在本实施例中，终端设备为智能手表，目标设备为运动单车。目标服务为速率计服务。如图5所示，速率计服务包括特征1和特征2。特征1(character1)不需要使能，特征2(character2)需要使能。character1的逻辑通道索引为handle取值24。character2的逻辑通道索引为handle取值26，character2的descriptor的逻辑通道索引为handle取值27。

可选的，在一种实现方式中，目标特征为速率计服务的character1，不需要使能。如图15所示，蓝牙数据的处理方法包括：

S1501、AP向MCU发送运动单车的第一MAC地址和速率计服务的第一服务信息。

第一服务信息包括：速率计服务的UUID、character1的逻辑通道索引(handle取值24)和特征属性(property)。

S1502、MCU向BT芯片发送第一MAC地址和第二服务信息。

第二服务信息包括：character1的逻辑通道索引(handle取值24)和特征属性(property)。

可选的，第二服务信息还可以包括：速率计服务的UUID。

S1506、BT芯片根据第一MAC地址和第二服务信息，在信息列表中增加运动单车的设备标识和速率计服务的逻辑通道信息。

其中，速率计服务的逻辑通道信息包括：character1的逻辑通道索引(handle取值24)和特征属性(property)。

可选的，在另一种实现方式中，目标特征为速率计服务的character2，需要使能。AP已经使能character2，MCU不需要使能。如图15所示，蓝牙数据的处理方法包括：

S1501、AP向MCU发送运动单车的第一MAC地址和速率计服务的第一服务信息。

第一服务信息包括：速率计服务的UUID、character2的逻辑通道索引(handle取值26)和特征属性(property)。

S1502、MCU向BT芯片发送第一MAC地址和第二服务信息。

第二服务信息包括：character2的逻辑通道索引(handle取值26)和特征属性(property)。

可选的，第二服务信息还可以包括：速率计服务的UUID。

S1503、AP通知BT芯片使能速率计服务的特征2。

S1505、BT芯片使能速率计服务的特征2。

S1506、BT芯片根据第一MAC地址和第二服务信息，在信息列表中增加运动单车的设备标识和速率计服务的逻辑通道信息。

其中，速率计服务的逻辑通道信息包括：character2的逻辑通道索引(handle取值26)和特征属性(property)。

其中，本实施方式对S1503、S1505与S1501、S1502、S1506之间的执行顺序不作限定。

可选的，在又一种实现方式中，目标特征为速率计服务的character2，需要使能。AP没有使能character2，需要由MCU使能。如图15所示，蓝牙数据的处理方法包括：

S1501、AP向MCU发送运动单车的第一MAC地址和速率计服务的第一服务信息。

第一服务信息包括：速率计服务的UUID、character2的逻辑通道索引(handle取值26)和特征属性(property)、character2的descriptor的逻辑通道索引(handle取值27)。

S1502、MCU向BT芯片发送第一MAC地址和第二服务信息。

第二服务信息包括：character2的逻辑通道索引(handle取值26)和特征属性(property)、character2的descriptor的逻辑通道索引(handle取值27)。

可选的，第二服务信息还可以包括：速率计服务的UUID。

S1504、MCU通知BT芯片使能速率计服务的特征2。

S1505、BT芯片使能速率计服务的特征2。

S1506、BT芯片根据第一MAC地址和第二服务信息，在信息列表中增加运动单车的设备标识和速率计服务的逻辑通道信息。

其中，速率计服务的逻辑通道信息包括：character2的逻辑通道索引(handle取值26)和特征属性(property)、character2的descriptor的逻辑通道索引(handle取值27)。

其中，本实施方式对S1504、S1505与S1506之间的执行顺序不作限定。

可选的，在本实施例中，GATT蓝牙业务模块提供的API可以包括但不限于下列中的至少一项：GATT虚拟连接接口、写character&descripter接口、读characteristic接口、offload服务信息注册接口(需要offload业务的characteristic信息)、GATT回调接口(包含连接事件、characteristic变化事件、读取characterisc回调事件等)，或者，使能服务接口。BT芯片中的GATT接口模块可以包含相应的对等接口。

可选的，在S1502中，MCU向BT芯片发送第一MAC地址和第二服务信息，一种实现方式可以包括：下沉管理业务模块调用GATT蓝牙业务模块提供的GATT虚拟连接接口，发起虚拟连接，将运动单车的MAC地址通过核间通讯告知BT芯片，指示了MCU准备接收运动单车的offload业务的数据。需要说明，由于AP侧的运动健康APP已经完成了对运动单车的实际物理通道的连接，此处发起的连接，是要通知BT芯片将运动单车的设备标识加入设备列表中，以便于后续BT芯片可以过滤、识别运动单车的数据，所以称为虚拟连接。在MCU获取回调虚拟连接的结果(例如，可以指示运动单车的设备标识加入设备列表是否成功)后，下沉管理业务模块调用GATT蓝牙业务模块提供的offload服务信息注册接口，将速率计服务的characteric和descripter的handle、property等信息(第二服务信息)通知到BT芯片。

后续，BT芯片获得第二服务信息后，可以将第二服务信息加入到下沉业务列表中。

可选的，在S1504中，MCU通知BT芯片使能速率计服务的特征2，一种实现方式可以包括：下沉管理业务模块调用GATT蓝牙业务模块提供的使能服务接口，通知BT芯片对速率计服务的character进行使能。

可选的，在上述实施例的基础上，结合图1B所示场景，本申请的又一个实施例提供了经典蓝牙通信中蓝牙数据的处理方法的一种实现方式。参见图16和图17，图16为本申请实施例提供的经典蓝牙中终端设备处理蓝牙数据的另一种原理示意图。图17为本申请实施例提供的蓝牙数据的处理方法的又一种流程图。

如图9和图16所示，在经典蓝牙通信中，下沉管理业务模块921对应图16中的下沉管理业务模块，蓝牙业务模块922对应图16中的Socket蓝牙业务模块，接口模块931对应图16中的Socket接口模块，信息列表932对应图16中的设备列表和下沉业务列表，协议数据解析/封装模块933对应图14中的协议数据解析/封装模块。其中，下沉管理业务模块、Socket蓝牙业务模块、Socket接口模块提供的API执行RFCOMM协议。

可选的，在图16中，BT芯片还可以包括状态管理模块，用于维护BT芯片的状态，例如，芯片sniff状态、RFCOMM通道流控等。

在本实施例中，终端设备为智能手表，目标设备为手机。目标服务为消息通知服务。手机为消息通知服务的服务端。智能手表为消息通知服务的客户端，即角色为客户端。

如图17所示，蓝牙数据的处理方法可以包括：

S1701、AP向BT芯片发送通道信息。

其中，通道信息包括手机的第二MAC地址和消息通知服务的DLCI。

可选的，通道信息还可以包括消息通知服务的UUID。例如，如图16所示，AP通过MCU向BT芯片发送通道信息时，需要携带消息通知服务的UUID。

S1702、AP向MCU发送手机的第一MAC地址和消息通知服务的第一服务信息。

第一服务信息包括：消息通知服务的逻辑通道信道号和消息通知服务的角色(具体为客户端)。

可选的，第一服务信息还可以包括：消息通知服务的UUID。

S1703、MCU向BT芯片发送第一MAC地址和第二服务信息。

第二服务信息包括：消息通知服务的逻辑通道信道号和消息通知服务的角色(具体为客户端)。

可选的，第二服务信息还可以包括：消息通知服务的UUID。

S1704、BT芯片根据第一MAC地址、第二MAC地址、第二服务信息和DLCI，在信息列表中增加手机的设备标识和消息通知服务的逻辑通道信息。

需要说明，图14和图15所示的BLE通信方式，以及，图16和图17所示的经典蓝牙通信方式，对于本实施例提供的蓝牙数据的处理方法，终端设备中的新增模块和方法流程相似，相互间可以参考。区别在于，在BLE通信中，具有特征的使能过程。而在经典蓝牙中，BT芯片和AP需要传输通道数据，不需要服务使能。

可以理解的是，终端设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对终端设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个模块中。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。需要说明的是，本申请实施例中模块的名称是示意性的，实际实现时对模块的名称不做限定。

示例性的，图18为本申请实施例提供的蓝牙数据的处理装置的一种结构示意图。蓝牙数据的处理装置应用于终端设备。如图18所示，蓝牙数据的处理装置，可以包括：

接收模块1801，用于接收第一蓝牙数据；

第一处理模块1802，用于在确定所述第一蓝牙数据满足预设条件时，将所述第一蓝牙数据发送至第二处理模块1803；

所述第二处理模块1803，用于处理所述第一蓝牙数据。

可选的，所述第一处理模块1802用于：

解析所述第一蓝牙数据，得到第一设备标识和第一逻辑通道索引；

若所述第一设备标识和所述第一逻辑通道索引在信息列表中，则确定所述第一蓝牙数据满足所述预设条件；所述信息列表用于存储目标设备的设备标识和目标服务的逻辑通道信息，所述第二处理模块1803用于处理所述目标服务的蓝牙数据。

可选的，所述第一处理模块1802还用于：

若所述第一设备标识或所述第一逻辑通道索引不在所述信息列表中，则将所述第一蓝牙数据发送至第三处理模块1804；

所述第三处理模块1804，用于处理所述第一蓝牙数据。

可选的，所述第二处理模块1803还用于：

生成目标服务的第二蓝牙数据，将所述第二蓝牙数据发送至所述第一处理模块1802；

所述第一处理模块1802还用于：

对所述第二蓝牙数据进行封装，得到待发送数据；

还包括发送模块1805，用于向目标设备发送所述待发送数据。

可选的，所述第三处理模块1804，还用于：

在所述接收模块1801接收第一蓝牙数据之前，向所述第二处理模块1803发送目标设备的第一MAC地址和目标服务的第一服务信息；所述目标设备为和所述终端设备蓝牙通信的设备，所述第一服务信息用于所述第二处理模块1803处理所述目标服务的蓝牙数据；

所述第二处理模块1803，还用于：向所述第一处理模块1802发送所述第一MAC地址和第二服务信息；所述第二服务信息为所述第一服务信息中的部分或全部信息；

所述第一处理模块1802，还用于：根据所述第一MAC地址和所述第二服务信息，在信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息；所述目标设备的设备标识和所述目标服务的逻辑通道信息用于所述第一处理模块1802处理所述目标服务的蓝牙数据。

可选的，所述目标设备的设备标识包括ACL标识。

可选的，所述终端设备和所述目标设备支持GATT协议，所述目标服务包括至少一个特征；

所述第一服务信息、所述第二服务信息和所述目标服务的逻辑通道信息，包括：所述至少一个特征中目标特征的逻辑通道索引和特征属性；

所述第一服务信息还包括：所述目标服务的UUID，所述第一服务信息用于所述第二处理模块1803处理所述目标特征的蓝牙数据。

可选的，所述目标特征需要被使能；

所述第一服务信息、所述第二服务信息和所述目标服务的逻辑通道信息，还包括：所述目标特征的描述符的逻辑通道索引。

可选的，所述目标特征没有被所述第三处理模块1804使能。

可选的，所述第三处理模块1804和/或所述第二处理模块1803，还用于：

在所述接收模块1801接收第一蓝牙数据之前，使能所述目标特征。

可选的，所述终端设备和所述目标设备支持RFCOMM协议；

所述第一服务信息和所述第二服务信息，包括：所述目标服务的逻辑通道信道号和所述目标服务的角色；其中，所述角色为客户端或服务端。

可选的，所述第一服务信息还包括所述目标服务的UUID。

可选的，所述第三处理模块1804还用于：

向所述第一处理模块1802发送通道信息；所述通道信息包括所述目标设备的第二MAC地址和所述目标服务的DLCI；

所述第一处理模块1802用于：

根据所述第一MAC地址、所述第二服务信息、所述第二MAC地址和所述DLCI，在所述信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息。

可选的，所述第一处理模块1802用于：

若所述第一MAC地址和所述第二MAC地址相同，根据所述第一MAC地址或所述第二MAC地址确定所述目标设备的设备标识；

根据所述DLCI得到待比对逻辑通道信道号和待比对角色；

若所述待比对逻辑通道信道号和所述目标服务的逻辑通道信道号相同，且所述待比对角色和所述目标服务的角色相同，则将所述DLCI确定为所述目标服务的逻辑通道信息；

在所述信息列表中增加所述目标设备的设备标识和所述DLCI。

可选的，所述第三处理模块1804，还用于：

向所述第二处理模块1803发送第一信息；所述第一信息用于指示所述第三处理模块1804处理所述目标服务的蓝牙数据；

所述第二处理模块1803，还用于：

根据所述第一信息删除所述第一服务信息，并向所述第一处理模块1802发送第二信息；所述第二信息用于指示所述第三处理模块1804处理所述目标服务的蓝牙数据；

所述第一处理模块1802，还用于：

根据所述第二信息在所述信息列表中删除所述目标服务的逻辑通道信息。

可选的，所述信息列表包括设备列表和下沉业务列表；所述设备列表包括所述目标设备的设备标识，所述下沉业务列表包括所述目标设备的设备标识和所述目标服务的逻辑通道信息。

可选的，所述终端设备为所述目标服务的客户端，所述目标设备为所述目标服务的服务端。

本实施例提供的蓝牙数据的处理装置，用于执行本申请实施例提供的蓝牙数据的处理方法，技术原理和技术效果相似，此处不再赘述。

可选的，在一种实现方式中，参见图18和图9所示，第一处理模块可以包括接口模块931、信息列表932和协议数据解析/封装模块933；第二处理模块可以包括下沉管理业务模块921和蓝牙业务模块922。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在设备运行时，使得所述设备执行上述实施例中的技术方案，其实现原理和技术效果与上述相关实施例类似，此处不再赘述。

本申请实施例提供一种计算机可读存储介质，其上存储有程序指令，所述程序指令被设备执行时，使得所述设备执行上述实施例的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。

综上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (19)

1.一种蓝牙数据的处理方法，其特征在于，应用于终端设备，所述终端设备包括主处理单元、辅助处理单元和蓝牙芯片；所述方法包括：

所述蓝牙芯片接收第一蓝牙数据；

若所述蓝牙芯片确定所述第一蓝牙数据满足预设条件，则将所述第一蓝牙数据发送至所述辅助处理单元；

所述辅助处理单元处理所述第一蓝牙数据。

2.根据权利要求1所述的方法，其特征在于，所述蓝牙芯片确定所述第一蓝牙数据满足预设条件，包括：

所述蓝牙芯片解析所述第一蓝牙数据，得到第一设备标识和第一逻辑通道索引；

若所述第一设备标识和所述第一逻辑通道索引在信息列表中，所述蓝牙芯片确定所述第一蓝牙数据满足所述预设条件；所述信息列表用于存储目标设备的设备标识和目标服务的逻辑通道信息，所述辅助处理单元用于处理所述目标服务的蓝牙数据。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

若所述第一设备标识或所述第一逻辑通道索引不在所述信息列表中，所述蓝牙芯片将所述第一蓝牙数据发送至所述主处理单元；

所述主处理单元处理所述第一蓝牙数据。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述辅助处理单元生成目标服务的第二蓝牙数据；

所述辅助处理单元将所述第二蓝牙数据发送至所述蓝牙芯片；

所述蓝牙芯片对所述第二蓝牙数据进行封装，得到待发送数据；

所述蓝牙芯片向目标设备发送所述待发送数据。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述蓝牙芯片接收第一蓝牙数据之前，还包括：

所述主处理单元向所述辅助处理单元发送目标设备的第一媒体访问控制MAC地址和目标服务的第一服务信息；所述目标设备为和所述终端设备蓝牙通信的设备，所述第一服务信息用于所述辅助处理单元处理所述目标服务的蓝牙数据；

所述辅助处理单元向所述蓝牙芯片发送所述第一MAC地址和第二服务信息；所述第二服务信息为所述第一服务信息中的部分或全部信息；

所述蓝牙芯片根据所述第一MAC地址和所述第二服务信息，在信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息；所述目标设备的设备标识和所述目标服务的逻辑通道信息用于所述蓝牙芯片处理所述目标服务的蓝牙数据。

6.根据权利要求5所述的方法，其特征在于，所述目标设备的设备标识包括面向连接的异步链路ACL标识。

7.根据权利要求5所述的方法，其特征在于，所述终端设备和所述目标设备支持通用属性协议GATT，所述目标服务包括至少一个特征；

所述第一服务信息、所述第二服务信息和所述目标服务的逻辑通道信息，包括：所述至少一个特征中目标特征的逻辑通道索引和特征属性；

所述第一服务信息还包括：所述目标服务的通用唯一标识符UUID，所述第一服务信息用于所述辅助处理单元处理所述目标特征的蓝牙数据。

8.根据权利要求7所述的方法，其特征在于，所述目标特征需要被使能；

所述第一服务信息、所述第二服务信息和所述目标服务的逻辑通道信息，还包括：所述目标特征的描述符的逻辑通道索引。

9.根据权利要求8所述的方法，其特征在于，所述目标特征没有被所述主处理单元使能。

10.根据权利要求8或9所述的方法，其特征在于，所述蓝牙芯片接收第一蓝牙数据之前，还包括：

所述主处理单元和/或所述辅助处理单元使能所述目标特征。

11.根据权利要求5所述的方法，其特征在于，所述终端设备和所述目标设备支持无线电频率通信协议RFCOMM；

所述第一服务信息和所述第二服务信息，包括：所述目标服务的逻辑通道信道号和所述目标服务的角色；其中，所述角色为客户端或服务端。

12.根据权利要求11所述的方法，其特征在于，所述第一服务信息还包括所述目标服务的UUID。

13.根据权利要求11所述的方法，其特征在于，所述蓝牙芯片根据所述第一MAC地址和所述第二服务信息，在信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息之前，还包括：

所述主处理单元向所述蓝牙芯片发送通道信息；所述通道信息包括所述目标设备的第二MAC地址和所述目标服务的数据链路连接标识DLCI；

所述蓝牙芯片根据所述第一MAC地址和所述第二服务信息，在信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息，包括：

所述蓝牙芯片根据所述第一MAC地址、所述第二服务信息、所述第二MAC地址和所述DLCI，在所述信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息。

14.根据权利要求13所述的方法，其特征在于，所述蓝牙芯片根据所述第一MAC地址、所述第二服务信息、所述第二MAC地址和所述DLCI，在所述信息列表中增加所述目标设备的设备标识和所述目标服务的逻辑通道信息，包括：

若所述第一MAC地址和所述第二MAC地址相同，所述蓝牙芯片根据所述第一MAC地址或所述第二MAC地址确定所述目标设备的设备标识；

所述蓝牙芯片根据所述DLCI得到待比对逻辑通道信道号和待比对角色；

若所述待比对逻辑通道信道号和所述目标服务的逻辑通道信道号相同，且所述待比对角色和所述目标服务的角色相同，则所述蓝牙芯片将所述DLCI确定为所述目标服务的逻辑通道信息；

在所述信息列表中增加所述目标设备的设备标识和所述DLCI。

15.根据权利要求5所述的方法，其特征在于，所述方法还包括：

所述主处理单元向所述辅助处理单元发送第一信息；所述第一信息用于指示所述主处理单元处理所述目标服务的蓝牙数据；

所述辅助处理单元根据所述第一信息删除所述第一服务信息；

所述辅助处理单元向所述蓝牙芯片发送第二信息；所述第二信息用于指示所述主处理单元处理所述目标服务的蓝牙数据；

所述蓝牙芯片根据所述第二信息在所述信息列表中删除所述目标服务的逻辑通道信息。

16.根据权利要求5所述的方法，其特征在于，所述信息列表包括设备列表和下沉业务列表；所述设备列表包括所述目标设备的设备标识，所述下沉业务列表包括所述目标设备的设备标识和所述目标服务的逻辑通道信息。

17.根据权利要求5所述的方法，其特征在于，所述终端设备为所述目标服务的客户端，所述目标设备为所述目标服务的服务端。

18.一种终端设备，其特征在于，包括处理器和蓝牙芯片，所述处理器包括主处理单元和辅助处理单元，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1-17任一项所述的方法。

19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在设备上运行时，使得所述设备执行如权利要求1-17中任一项所述的方法。