CN110784830B - 数据处理方法、蓝牙模块、电子设备与可读存储介质 - Google Patents

Abstract

本申请提供了一种数据处理方法、蓝牙模块、电子设备与可读存储介质。本申请实施例中，当第一设备接收到第一应用的启动蓝牙扫描指示时，接收第二设备发送的第二广播数据，并向所述第二设备发送扫描请求，并接收扫描响应；从而，当所述第二广播数据为指定类型数据包时，将所述第二广播数据上报至所述第一应用，并丢弃所述扫描响应。本申请所提供的技术方案能够在一定程度上降低蓝牙扫描过程中的丢包率，提高通信安全。

Description

数据处理方法、蓝牙模块、电子设备与可读存储介质

技术领域

本申请涉及计算机领域，尤其涉及数据处理方法、蓝牙模块、电子设备与可读存储介质。

背景技术

目前，超过10亿的智能设备为用户提供了语音助手服务，例如，Google Assistant(谷歌助手)、Siri(苹果公司提供的语音助手)、Cortana(联想公司出品的一种语音助手)、小爱(小米公司出品的一种语音助手服务)、华为小艺(华为公司出品的一种语音助手)。智能设备可以被用户发出的唤醒词而唤醒，例如，用户发出声音“小艺小艺”，搭载有华为小艺的智能设备就可以被唤醒。智能设备被唤醒后，可以接收用户的语音命令，并执行语音命令对应的功能，例如，根据采集到的用户声音打开相机、播放视频、打开某一应用程序(Application，APP)等。

当用户身边有多个智能设备时，若其中存在至少两个智能设备的唤醒词相同，那么，这些智能设备都会被唤醒，这会造成用户困扰，导致语音服务体验较差。例如，图1示出了这样一种情况。用户所在的环境中，存在4个智能设备：手机100、智能电视200、智能手环300与智能音箱400，这些智能设备中都搭载有语音助手服务，可以根据用户发出的声音而被唤醒。例如，用户发出唤醒词“小艺小艺”，这4种智能设备都可以接收到该唤醒词，如此，手机100、智能电视200与智能音箱400都可以响应该唤醒词，导致后续语音交互环境复杂，用户还需要执行操作以关闭部分电子设备。这种情况下，智能设备可以通过蓝牙模块来与其他智能设备进行数据同步，但在蓝牙扫描过程中，经常会发生丢包问题，导致语音响应速度较慢或响应失误，语音操控体验较差。

发明内容

本申请提供了一种数据处理方法、蓝牙模块、电子设备与可读存储介质，用以降低蓝牙扫描过程中的丢包率，提高语音操控体验。

第一方面，本申请提供了一种数据处理方法。本申请实施例中，当第一设备接收到第一应用的启动蓝牙扫描指示时，接收第二设备发送的第二广播数据，向所述第二设备发送扫描请求，并接收扫描响应，从而，当所述第二广播数据为指定类型数据包时，将所述第二广播数据上报至所述第一应用，并丢弃所述扫描响应。如此，避免了第一设备无法接收到广播数据或无法接收到扫描响应，就无法合并上报的问题，能够在一定程度上降低丢包率，从而，当指定类型数据包为协同数据包时，也有利于缩短协同响应的时长，提高第一设备的语音响应速度，提升用户的语音操控体验。

此外，本申请中，当所述第二广播数据不是所述指定类型数据包时，合并所述第二广播数据与所述扫描响应，得到合并数据；将所述合并数据上报至所述第一应用。如此，根据数据包的类型，采取不同的扫描手段，具备较高的灵活性。

在本申请的一种具体的应用场景中，当所述第一应用为语音助手应用时，所述启动蓝牙扫描指示为所述第一应用采集到声音信号后发送的。如图6或图7所示，当智能设备采集到声音信号，需要进行协同响应时，启动蓝牙模块进行扫描。

在协同响应的场景中，当所述第二广播数据为所述指定类型数据包时，所述第二广播数据携带所述第二设备的协同信息。如此，第一设备可以获取到第二设备的协同信息。此外，第一设备除获取其他智能设备，例如第二设备，的协同信息之外，还可以对外广播自己的协同信息。具体而言，当接收到第一应用的启动蓝牙扫描指示时，第一设备还可以广播第一广播数据，所述第一广播数据携带所述第一设备的协同信息。

本申请实施例中，所述协同信息用于确定所述声音信号的响应设备；所述协同信息可以包括但不限于：设备类型、最近一次蓝牙唤醒时刻、最近一次蓝牙响应时刻与声音信号的声强中的至少一种。对于任意一个唤醒词而言，该唤醒词的响应设备的协同信息需要满足预设的响应规则。例如，满足声音信号的强度最强；又例如，满足前述各协同信息的总分值最高。

在一具体实施例中，如图6所示，所述启动蓝牙扫描指示为所述第一应用采集到所述声音信号后，并识别出所述声音信号为所述第一设备的唤醒词时发送的。协同响应过程与语音识别过程串行实现。

在另一实施例中，如图7所示，所述启动蓝牙扫描指示为所述第一应用采集到所述声音信号后，且在得到语音识别结果之前发送的。此时，协同响应过程与语音识别过程存在重叠，可视作“并行”实现。

当以图7所示方式进行协同响应时，第一设备在广播自己的协同信息时，可能并不确定当前采集到的声音信号是否为自己的唤醒词，这种情况下，若第一设备的协同信息满足预设的响应规则，但是，识别出所述声音信号不是所述第一设备的唤醒词时，第一设备可以广播第三广播数据，所述第三广播数据用于指示与所述声音信号不是所述第一设备的唤醒词。从而，其他智能设备可以另外确定该声音信号的响应设备。

本申请实施例中，还可以提前预配置第一应用的扫描环境。具体的，当检测到所述第一设备中的蓝牙开关开启时，为所述第一应用配置第一过滤器与第一扫描参数。如此，当接收到第一应用的启动蓝牙扫描指令时，可以直接进行扫描，而无需花费时间配置过滤器与扫描参数，节省了扫描花费的时长，有利于提高扫描响应速度。

在这种情况下，当接收到所述第一应用发送的关闭蓝牙扫描指示，停止收发数据，并保留所述第一过滤器与所述第一扫描参数。此时，第一过滤器并未被释放，而是被保留。而第一扫描参数也被保留。从而，若第一应用需要启动新的扫描，可以直接进入扫描过程，无需再配置扫描环境。

在一种可能的实施例中，在提前配置了第一过滤器与第一扫描参数的前提下，若第一设备接收到第二应用的启动蓝牙扫描指示，则第一设备可以为所述第二应用配置第二过滤器，并将所述第一扫描参数修改为第二扫描参数。此时，第一设备中具备两个过滤器，而第一设备所使用的扫描参数由第一扫描参数变更为第二扫描参数，此时，第二扫描参数还可以被存储在其他位置，以便于第二应用的扫描结束后恢复第二扫描参数。经过前述配置之后，第一设备可以利用第二过滤器与第二扫描参数实现对第二应用的扫描。

那么，当第一设备接收到所述第二应用发送的关闭扫描指示时，停止收发数据，释放所述第二过滤器，并将所述第二扫描参数恢复为所述第一扫描参数。此时，第一设备中具备第一过滤器，而蓝牙模块所采用的扫描参数又恢复为第一扫描参数，第二扫描参数被删除或丢弃。

另一种可能的情况中，第一设备已经上报了第二应用的扫描结果，但并未接收到第二应用发送的关闭扫描指示时，第一设备又接收到所述第一应用的启动蓝牙扫描指示。这种情况下，第一设备可以终止或暂停第二应用的扫描，为所述第一应用配置所述第一扫描参数。如此，第一设备可以采用第一过滤器与第一扫描参数为第一应用进行扫描。

本申请实时中，所述第一扫描参数采用第一占空比，所述第二扫描参数使用第二占空比，所述第一占空比大于所述第二占空比。

本申请实施例中，当所述第一应用调用蓝牙扫描广播接口时，接收到所述第一应用发送的启动蓝牙扫描指示。

第二方面，本申请提供了一种蓝牙模块，包括：一个或多个处理器；一个或多个存储器；以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如第一方面任一实施例所述的方法。

第三方面，本申请提供了一种电子设备，包括：一个或多个处理器；一个或多个存储器；一个或多个蓝牙模块；以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如第一方面任一实施例所述的方法。

第四方面，本申请实施例还提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行前述任一实现方式所述的方法。

第五方面，本申请实施例还提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如前述任一实现方式所述的方法。

综上，本申请所提供的一种数据处理方法、电子设备与可读存储介质，能够降低蓝牙扫描过程中的丢包率，一定程度上，也有利于提高数据同步效率，从而，提高了智能设备的响应速度，有利于提高语音操控体验。

附图说明

图1为现有技术中的一种语音唤醒的响应场景的示意图；

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

图3为本申请实施例所提供的一种电子设备的显示界面示意图；

图4为本申请实施例所提供的另一种电子设备的显示界面示意图；

图5为本申请实施例所提供的一种语音唤醒的响应场景的示意图；

图6为本申请实施例中一种智能设备之间进行协同响应的示意图；

图7为本申请实施例中另一种智能设备之间进行协同响应的示意图；

图8为本申请实施例所提供的另一种电子设备的结构示意图；

图9为本申请实施例所提供的一种数据处理方法的数据交互示意图；

图10为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图11为本申请实施例所提供的占空比的示意图；

图12为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图13为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图14为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图15为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图16为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图17为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图18为本申请实施例所提供的另一种数据处理方法的数据交互示意图；

图19为现有技术中的一种语音指令的响应场景的示意图；

图20为本申请所提供的一种语音指令的响应场景的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

本申请实施例提供的技术方案，可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)、智能家居设备等任意可以响应用户语音命令的电子设备上，本申请实施例对此不作任何限制。

示例性的，图2示出了电子设备的结构示意图。

电子设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在本申请另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。例如，当电子设备为智能电视时，智能电视无需设置SIM卡接口195、摄像头193、按键190、受话器170B、麦克风170C、耳机接口170D、传感器模块180、充电管理模块140，电池142中的一个或多个。图示的部件可以以硬件，软件，或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。在一些实施例中，电子设备也可以包括一个或多个处理器110。其中，控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据命令操作码和时序信号，产生操作控制信号，完成取命令和执行命令的控制。处理器110中还可以设置存储器，用于存储命令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的命令或数据。如果处理器110需要再次使用该命令或数据，可从所述存储器中直接调用。这就避免了重复存取，减少了处理器110的等待时间，因而提高了电子设备的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。其中，USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备充电，也可以用于电子设备与***设备之间传输数据，也可以用于连接耳机，通过耳机播放音频。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本申请另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks，WLAN)，蓝牙，全球导航卫星***(global navigation satellitesystem，GNSS)，调频(frequency modulation，FM)，NFC，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括GSM，GPRS，CDMA，WCDMA，TD-SCDMA，LTE，GNSS，WLAN，NFC，FM，和/或IR技术等。上述GNSS可以包括全球卫星定位***(global positioning system，GPS)，全球导航卫星***(global navigation satellite system，GLONASS)，北斗卫星导航***(beidounavigation satellite system，BDS)，准天顶卫星***(quasi-zenith satellitesystem，QZSS)和/或星基增强***(satellite based augmentation systems，SBAS)。

电子设备通过GPU，显示屏194，以及应用处理器等可以实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行命令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备可以通过ISP，一个或多个摄像头193，视频编解码器，GPU，一个或多个显示屏194以及应用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐、照片、视频等数据文件保存在外部存储卡中。

内部存储器121可以用于存储一个或多个计算机程序，该一个或多个计算机程序包括命令。处理器110可以通过运行存储在内部存储器121的上述命令，从而使得电子设备执行本申请一些实施例中所提供的语音切换方法，以及各种功能应用以及数据处理等。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作***；该存储程序区还可以存储一个或多个应用程序(比如图库、联系人等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如照片，联系人等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。在一些实施例中，处理器110可以通过运行存储在内部存储器121的命令，和/或存储在设置于处理器110中的存储器的命令，来使得电子设备执行本申请实施例中所提供的语音切换方法，以及各种功能应用及数据处理。

电子设备可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。其中，音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备可以通过扬声器170A收听音乐，或收听免提通话。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备可以设置至少一个麦克风170C。在另一些实施例中，电子设备可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，还可以是美国蜂窝电信工业协会(cellular telecommunications industry association ofthe USA，CTIA)标准接口。

传感器180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

其中，压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备根据压力传感器180A检测所述触摸操作强度。电子设备也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作命令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的命令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的命令。

陀螺仪传感器180B可以用于确定电子设备的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定电子设备围绕三个轴(即，x，y和z轴)的角速度。陀螺仪传感器180B可以用于拍摄防抖。示例性的，当按下快门，陀螺仪传感器180B检测电子设备抖动的角度，根据角度计算出镜头模组需要补偿的距离，让镜头通过反向运动抵消电子设备的抖动，实现防抖。陀螺仪传感器180B还可以用于导航，体感游戏场景等。

加速度传感器180E可检测电子设备在各个方向上(一般为三轴)加速度的大小。当电子设备静止时可检测出重力的大小及方向。还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

距离传感器180F，用于测量距离。电子设备可以通过红外或激光测量距离。在一些实施例中，拍摄场景，电子设备可以利用距离传感器180F测距以实现快速对焦。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。电子设备通过发光二极管向外发射红外光。电子设备使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时，可以确定电子设备附近有物体。当检测到不充分的反射光时，电子设备可以确定电子设备附近没有物体。电子设备可以利用接近光传感器180G检测用户手持电子设备贴近耳朵通话，以便自动熄灭屏幕达到省电的目的。接近光传感器180G也可用于皮套模式，口袋模式自动解锁与锁屏。

环境光传感器180L用于感知环境光亮度。电子设备可以根据感知的环境光亮度自适应调节显示屏194亮度。环境光传感器180L也可用于拍照时自动调节白平衡。环境光传感器180L还可以与接近光传感器180G配合，检测电子设备是否在口袋里，以防误触。

指纹传感器180H(也称为指纹识别器)，用于采集指纹。电子设备可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。另外，关于指纹传感器的其他记载可以参见名称为“处理通知的方法及电子设备”的国际专利申请PCT/CN2017/082773，其全部内容通过引用结合在本申请中。

触摸传感器180K，也可称触控面板。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称触控屏。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备的表面，与显示屏194所处的位置不同。

骨传导传感器180M可以获取振动信号。在一些实施例中，骨传导传感器180M可以获取人体声部振动骨块的振动信号。骨传导传感器180M也可以接触人体脉搏，接收血压跳动信号。在一些实施例中，骨传导传感器180M也可以设置于耳机中，结合成骨传导耳机。音频模块170可以基于所述骨传导传感器180M获取的声部振动骨块的振动信号，解析出语音信号，实现语音功能。应用处理器可以基于所述骨传导传感器180M获取的血压跳动信号解析心率信息，实现心率检测功能。

按键190包括开机键，音量键等。按键190可以是机械按键，也可以是触摸式按键。电子设备可以接收按键输入，产生与电子设备的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以通过***SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备的接触和分离。电子设备可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时***多张卡。所述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。电子设备通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在电子设备中，不能和电子设备分离。

现以手机为例，对语音助手功能进行说明。

图3示出了一种开启语音唤醒服务的方法。图3所示的a界面，为手机桌面的图形用户界面(Graphical User Interface，GUI)。在该手机桌面GUI上可以呈现至少一个APP的图标，部分图标仅由图像构成，如联系人图标301、信息图标302，部分图标由图像和文字构成，如设置图标303、邮件图标304等，不作赘述。在图3所示的a界面上，还包括时间栏305与顶栏306，其中，时间栏305可以显示当前时刻，示例性的，可以展示当前时刻为几月几日，周几，几点几分等；除此之外，时间栏305中还可以包含地点信息与天气信息(另一实施例中，天气栏可以单独设置，不赘述)。而顶栏306可用于展示手机的当前通信状态、通信服务商、时刻信息、电量信息等，除此之外，还可以展示蓝牙连接状态、无线网络连接状态、个人热点连接状态等信息，对此无特别限定。

用户可以点击a界面上的设置图标303，响应于该触控操作，手机显示如图3所示的b界面。在图3所示的b界面上，可以展示各种设置信息，用户可以对各设置信息进行触控操作，来进入相应内容的设置。例如，用户可以点击电池307，来设置手机进省电模式，或者，查看手机的耗电状态。

用户可以点击b界面上的智能辅助308，响应于该触控操作，手机显示如图3所示的c界面。智能辅助308可用户实现各种辅助功能，例如旅行助手309、单手模式310、语音控制311等，如图c界面所示，不作赘述。

用户可以点击c界面上的语音控制311，使得手机显示如图3所示的d界面。在图3的d界面上，用户可以点击语音唤醒312右侧对应的箭头，来开启或关闭语音唤醒功能。除此之外，用户还可以根据需要开启或关闭熄屏快呼13、来电语音控制314、来电语音播报315等功能，不作赘述。图3所示d界面上，还显示提示信息316，用于提示用户“以上语音控制功能将使用麦克风来识别您的命令”。

当语音唤醒功能开启后，用户就可以通过唤醒词唤醒手机。图4示出了这种情况。

如图4所示的a界面上，仍为手机桌面的GUI，假设该手机的唤醒词为“小艺小艺”(示例性的，无特别限制，其他场景中，还可以为“嗨，Siri”、“小爱小爱”、“小度小度”等)。若用户发出声音，就可以在当前的显示界面上显示文字提示栏401、语音提示栏402与放大按钮403中的至少一种。

其中，文字提示栏401用于以文字提示用户当前正在为用户提供语音服务。例如，当用户说“小艺小艺”时，可唤醒手机的语音助手服务，此时，可以在文字提示栏401中显示“嗨，我在听…”；又例如，当用户说“打开微博”时，处于唤醒状态的语音助手服务可以识别出该语音命令，此时，可以在文字提示栏401中显示“打开微博”。在文字提示栏401处显示的文字可以是实时的。例如，当用户说“打开微博”时，语速较慢，文字提示栏401可逐个显示当前识别出的语音命令，其显示的内容一开始可能为“打开…”，随后用户说完“打开微博”这句话，此处显示的内容可能随后变更为“打开微博”。此外，语音助手服务还可以通过声音对用户发出的语音命令进行回复。例如，若接收并识别出用户说“打开微博”，则手机喇叭可以输出“好的，正在为您打开微博”的声音，对用户进行回复。

语音提示栏402用于表明当前是否在采集用户声音，和/或，当前采集到的用户声音的强弱。例如，手机可以持续采集当前环境的声音信号，在一个较为安静的环境中，用户未发声时，手机采集不到声音信号，此时，语音提示栏402可以不显示波形，或者显示静止不动的波形；若用户发出声音，手机能够采集到声音信号，语音提示栏402可以展示动态变化的波形，以此来提示用户当前采集到了声音。

若用户点击图4中a界面上的放大按钮403，响应于该触控操作，手机可以显示如图4所示的b界面，b界面为语音助手的放大展示界面。如图4所示的b界面上，也可以展示语音提示栏402。而基于采集到的用户的语音命令，b界面上展示了语音命令列表404，该语音命令列表404可以是通过对用户发出的声音进行采集分析得到的。例如，用户说“打开手电筒”，则手机采集声音信号，并对采集到的声音信号进行语音识别，得到该语音命令，则将识别出的该命令展示在语音命令列表404中。除此之外，b界面上还进一步为用户提供了文字输入方式：键盘按钮405，用户可以点击键盘按钮405，来调出键盘，并通过在键盘上进行触控操作，来对语音命令列表404中的内容进行修改、删除或添加。在图4所示的b界面上，还进一步显示了一个语音设置图标406与帮助图标407。

若用户点击了图4所示b界面上的语音设置图标404，则手机随之展示图4所示的c界面。在c界面上，可以显示用户信息，例如用户头像、用户名(可以为手机号)、“我的信息”，用户可以点击这些栏目右侧的箭头来对用户信息进行修改或完善。图4的c界面上，还进一步展示了语音助手服务的可设置内容。用户可以点击语音唤醒408，来开启或关闭语音唤醒功能。电源键唤醒功能类似，不作赘述。用户还可以设置当前场景，若用户在开车等行驶场景，可以选择“驾驶场景”，对语音助手服务作个性化设计。以及，用户还可以在“我的技能”处，来编排自定义语音命令以完成对应操作，为用户提供更加人性化与个性化的语音助手服务。除此之外，用户还可以参与用户体验改进计划，以供开发者进一步改善和提升产品体验。

本申请实施例中，用户可以在智能设备中进行设置，以开启或关闭智能设备的语音唤醒服务。智能设备的语音唤醒服务被开启后，即可采集声音信号，并对其进行语音识别，进而对识别出的唤醒词或语音命令进行响应。例如，若手机的唤醒词为“嗨，小艺”，那么，若手机对采集到的声音进行语音识别，识别出用户说的就是“嗨，小艺”，则手机中搭载的语音助手服务被唤醒。此时，还可以通过手机的喇叭输出响应语“在呢”。又例如，智能电视中搭载的语音服务助手处于唤醒状态时，可以采集声音信号并识别语音命令，若识别出用户说的是“播放琅琊榜”，则智能电视可以在显示屏上播放琅琊榜(电视剧，示例性的)，实现对用户发出的语音命令的响应。

如前述图1所示，针对存在多个智能设备，且至少两个智能设备具备同样的唤醒词时，若智能设备识别出唤醒词后，就直接对唤醒词进行响应，可能会导致多个智能设备对同一个唤醒词进行响应的情况，语音操控体验较差。

这种情况下，多个智能设备可以进行协同响应。也就是，多个智能设备之间进行数据同步，并在数据同步的基础上，按照预设的规则，确定出一个合适的智能设备，来对用户发出的唤醒词进行应答。图5示出了这种情况。图5所示场景与图1类似，用户说出唤醒词，当前环境中的手机100、智能电视200、智能手环300、智能音箱400都可以采集到该声音信号，并识别出该唤醒词。此时，这些智能设备可以进行协同响应，最终确定出智能音箱400作为该唤醒词的响应设备，由此，如图5所示，智能音箱400响应该唤醒词，例如，输出语音响应语“在呢”，实现对该唤醒词的响应。

需要说明的是，本申请实施例，对于同一个环境中的多个智能设备的类型是否相同无特别限定。例如，一个可能的场景中，可能有3部手机，2个智能音箱，以及一个扫地机器人。又例如，用户所在场景中可能仅有两台智能电视。

此外，本申请实施例中，同一场景中的多个智能设备的语音助手类型，可以相同或不同无特备限定。例如，一种场景中，仅有三部手机，其中一部手机的语音助手可以为华为公司出品的“小艺”，另一部手机的语音助手可以为小米公司出品的“小爱”，另一部手机的语音助手可以为苹果公司出品的“Siri”。又例如，另一种可能的场景中，也仅有三部手机，且这些手机的语音助手均为华为公司的“小艺”。如前所述，各公司出品的语音助手的唤醒词可能不同，这种情况下，若多个设备的语音助手相同，则会被同一唤醒词唤醒，此时，也需要协同响应以确定响应设备。

请参考图6，图6示出了一种智能设备之间进行协同响应的示意图。示例性的，图6以手机100与智能手环300之间的协同响应为例。手机100与智能手环300的语音唤醒服务都已经被用户开启，因此，手机100与智能手环300都能够采集声音信号并对采集到的声音信号作语音识别。并且，假设手机100与智能手环300的唤醒词相同，假设为“小艺小艺”。

由此，若用户说“小艺小艺”，则手机100与智能手环300都可以采集到该声音信号，并各自对采集到的声音信号进行语音识别。基于处理器、语音识别方式、声音采集方式等的不同，手机100与智能手环300在这些阶段的处理时长可能不同。语音识别后，手机100与智能手环300进行协同响应处理，在该过程中，手机100可以将自己的协同信息发送给智能手环300，智能手环300也可以将自己的协同信息发送给手机100，实现各自协同信息的同步，并基于同步后的协同信息与预设的响应规则，来确定出响应设备。如图6所示，确定出的响应设备为手机100，则手机100在协同响应后，对该唤醒词进行响应。而智能手环300则无需对该唤醒词进行响应。

在如图6所示的实施例中，智能设备在识别出唤醒词后，再进行协同响应，进而，当确定自己为响应设备时响应应答(或若自己不是响应设备时则不应答)，这种串行工作方式，使得智能设备对唤醒词的响应速度，受到协同响应的较大影响。

图7示出了另一种智能设备之间进行协同响应的示意图。如图7所示，手机100在对采集到的声音信号进行语音识别时，就开始进行协同响应，协同响应过程与语音识别过程存在一定重叠，二者接近于“并行”执行。相较于图6所示的串行方案，图7所示方案能够较大程度的缩短手机100的应答时长，这有利于提升声音操控体验，用户感受较好。

本申请实施例所示的协同响应场景中，至少两个智能设备参与协同响应。而各智能设备所采用的工作方式(串行或并行)可以相同也可以不同。例如，图6所示实施例中，手机100与智能手环300均采用串行模式进行工作；而如图7所示的实施例中，手机100采用“并行”模式进行协同响应，而智能手环300采用串行方式工作。可以理解，还有一种可能的实施例：手机100与智能手环300均采用并行模式进行工作，不作赘述。

本申请实施例中，智能设备如何响应唤醒词，可以由语音助手默认设置。例如，手机在识别出唤醒词后，可以默认输出语音应答语“在呢，您有什么需要？”。又例如，智能手表在响应唤醒词时，可以点亮屏幕，但无语音输出。又例如，智能音箱在响应唤醒词时，可以输出一段预设音频，以对用户进行提示。又例如，智能温控设备在响应唤醒此时，可以以预设方式进行闪烁来提示用户。前述方式还可以结合。例如，手机在响应唤醒词时，可以点亮屏幕并输出应答语音，不作穷举。

除默认设置之外，智能设备对声音命令的响应方式，还可以由用户自定义设计。例如，用户可以对手机进行个性化设置，取消识别出唤醒词后的默认应答语，如此，手机在识别出唤醒词后，不会再输出“在呢，您有什么需要？”的应答语。除针对默认设置的自定义更改之外，用户还可以从声音(应答语与响铃中的至少一种)、屏幕显示(文字，或播放指定图像等)、灯光闪烁、震动、温度(温度变化)等至少一个方面，来自定义设计智能设备的响应方式。例如，用户可以对智能手表进行设计，使得智能手表在识别出唤醒词后，进行震动，以对唤醒词进行响应。又例如，用户可以对智能电视进行自定义设计，使得智能电视在接收到唤醒词时，指定信号灯都进行一次或多次闪烁，以实现对唤醒词的响应。不作穷举。

现对协同响应过程进行说明。

如前所述，智能设备在与其他智能设备进行协同响应时，需要同步各自的协同信息，并基于协同信息与预设的响应规则，来确定当前唤醒词的响应设备。可以理解，声音信号的响应设备需要满足预设的响应规则。而智能设备在进行前述协同信息的同步时，可以对外广播自己的协同信息，以及，还需要获取其他智能设备广播的协同信息。

本申请实施例中，协同信息可以包括但不限于如下至少一种：设备类型、最近一次唤醒时刻、最近一次响应时刻、声音信号的声强。其中，设备类型可用于指示智能设备的种类和型号；最近一次唤醒时刻(或最近一次响应时刻)越接近当前时刻，用户可能在连续使用该智能设备，因此，越有可能作为响应设备；而声音信号的声强可用于反映智能设备与用户之间的距离，声强越高，智能设备距离用户越近。

一种可能的实施例中，可以将距离用户最近的一个智能设备作为响应设备。仍以图5所示举例。用户说出唤醒词，例如“小艺小艺”，此时，手机100、智能电视200、智能手环300与智能音箱400都采集到该声音信号，各智能设备开始语音识别，以及在语音识别之后或并行的，开始与其他智能设备进行协同响应。首先，各智能设备进行数据同步，经数据同步后，各智能设备都获取到当前场景中各智能设备采集到的声音信号的声强。由此，对于手机100而言，自己的声强并非最大的一个，自己并非该声音信号的响应设备，不作响应处理。类似的，智能电视200与智能手环300也不作响应处理。而智能音箱400在同步数据后，确定自己采集到的声音信号的声强最大，符合距离用户最近的预设的响应规则，则智能音箱400响应该唤醒词，可以播放预设音频，以提示用户由智能音箱400开始进行响应。

另一种可能的实施例中，还可以将最近一次唤醒的时刻最接近当前时刻的智能设备，作为响应设备。仍以图5为例，各智能设备采集声音信号、进行语音识别并进行协同响应。协同响应时，首先同步各自协同数据，其中，至少包括：同步各设备最近一次唤醒的时刻。那么，若当前时刻为19:25，而手机100最近一次唤醒的时刻为19:00，智能电视200最近一次唤醒的时刻为9:00，智能手环300最近一次被唤醒的时刻为15:30，而智能音箱400最近一次被唤醒的时刻为19:15，由此，智能音箱400最近一次被唤醒的时刻更接近当前时刻，符合预设的响应规则，则由智能音箱400开始播放预设音频，以响应该唤醒词。其他设备可以不作响应。

另一种实施例中，还可以将最近一次响应唤醒词的时刻更接近当前时刻的智能设备，作为响应设备。实现方式与前一实施例类似，不作赘述。

另一种可能的实施例中，还可以综合前述至少一种协同信息，来确定响应设备。

一种可能的设计中，可以将至少一种协同信息进行数值化处理，然后，将各协同信息的数值进行加权(加权和，或加权平均值等)处理，得到各协同设备的分值。分值越高，越有可能是用户希望语音操控的设备，因此，将分值最高的一个智能设备作为响应设备即可。其中，在将各协同信息数值化处理时，最近一次唤醒时刻、最近一次响应时刻越接近当前时刻，数值越高；采集到的声音信号的声强越高，则数值越高。本申请实施例对具体的数值化过程无特别限定。

在该实施例中，还可以进一步有如下设计：各智能设备可以与其他智能设备同步自己的协同信息(例如，设备类型、最近一次唤醒时刻、最近一次响应时刻、声音信号的声强中的至少一种)，从而，在数据同步之后，由各智能设备再分别计算各智能设备的分值，并进而根据分值确定自己是否为响应设备。或者，各智能设备在获取到自己的协同信息后，可以直接按照前述方式，计算自己的分值，然后，与其他智能设备交互自己的分值即可，交互的数据量较小，有利于加快数据交互速度，缩短数据交互时长；并且，由于直接同步了各智能设备的分值，各智能设备无需再次计算，又进一步缩短了计算时长，能够更快速的响应用户，提升用户的语音操控体验。

另一种可能的情况中，可以将设备类型、最近一次唤醒时刻、最近一次响应时刻、声音信号的声强中的至少一种进行比对，并以此来确定响应设备。例如，若用户说出唤醒词后，当前环境中的手机A与手机B进行协同响应，此时，手机A与手机B的设备类型相同，采集到的声音信号的声强相同，而手机A在当前时刻之前的30内响应过用户，而手机B并未在最近的30s内响应过用户，则可以将手机A作为响应设备，来对唤醒词进行响应应答。又例如，用户说出唤醒词后，当前环境中的手机A与手机B进行协同响应，此时，按照前述方式，获得到的手机A与手机B的分值相同，在这种情况下，手机A的最近一次响应时刻更接近当前时刻，则可以将手机A作为响应设备，来对唤醒词进行响应应答。

此外，需要注意的是，实际参与协同响应的智能设备中，可能存在与该唤醒词不匹配的智能设备。例如，一种可能的场景中，有一部苹果手机，该苹果手机的唤醒词为“嗨，Siri”；该环境中还有2部华为手机，这两部华为手机的唤醒词为“小艺”，那么，用户说出“小艺”时，只能唤醒两部华为手机，而无法唤醒苹果手机。但用户说出唤醒词后，两部华为手机与一部苹果手机，都可以采集声音信号，并进行语音识别。

此时，基于前述协同响应的工作方式不同，还可以有如下情况：

一种实现场景中，智能设备可以以串行方式进行语音识别与协同响应。那么，在该场景下，用户说出唤醒词“小艺”，则苹果手机基于语音识别，可以确定这不是自己的唤醒词，也就是，声音信号语义与自己的唤醒词不匹配，此时，苹果手机可以不参与协同响应。具体的，苹果手机可以不接收其他智能设备同步的协同信息，和/或，也可以不向其他智能设备发送自己的协同信息。如此，只有两部华为手机参与协同响应。

另一种实现场景中，智能设备以“并行”方式进行语音识别与协同响应。此时，由于协同响应过程与语音识别过程存在重叠，因此，智能设备很有可能在未识别出声音信号中的唤醒词之前，就已经开始协同响应，也即，在确定声音信号是否有自己的唤醒词之前，智能设备有可能就已经向其他智能设备广播自己的协同信息了。可以理解，这时候，协同信息里可能不包含唤醒词是否匹配的信息。

仍以前述场景为例。在该场景中，三部手机各自采集到声音信号，由于还未得到语音识别结果，因此，并不确定该声音信号是否与自己的唤醒词相匹配，那么，三部手机可能都会参与协同响应。此时，可以有多种设计。

在一种可能的实施例中，可以进行两次协同响应。在第一次协同响应时，电子设备可以对外广播自己的协同信息，具体可以包括但不限于：设备类型、最近一次唤醒时刻、最近一次响应时刻、声音信号的声强中的至少一种。以及，在电子设备得到自己的语音识别结果时，还可以对外广播语音识别结果，以通知其他电子设备唤醒词是否匹配。例如，在前述举例中，三部手机可以各自广播自己的协同信息；之后，还会进行第二轮协同响应，三部手机各自广播自己是否与唤醒词相匹配。可以理解，苹果手机与唤醒词“小艺”不匹配，因此，即便苹果手机距离用户最近，且用户刚刚唤醒过苹果手机，苹果手机也不会作为“小艺”的响应设备。

另一种可能的实施例中，可以进行一次协同响应，电子设备各自对外广播自己的协同信息，具体可以包括但不限于：设备类型、最近一次唤醒时刻、最近一次响应时刻、声音信号的声强中的至少一种。各电子设备可以由此确定响应设备，此时，若确定的响应设备根据语音识别结果，确定该语音信号与自己的唤醒词不匹配，则发出广播，以通知其他电子设备进行响应。例如，在前述举例中，三部手机可以各自广播自己的协同信息；之后，由此确定苹果手机的分数最高；但是，苹果手机经过语音识别，确定苹果手机与唤醒词“小艺”不匹配，因此，苹果手机可以发出广播，以通知另外两部手机自己与语音信号不匹配。由此，可以将两部华为手机中分数较高的一个华为手机，作为唤醒词“小艺”的响应设备。

各智能设备在进行协同响应时，需要在各智能设备之间同步各自的协同信息。该过程可以通过安卓(Android)***提供的低功耗蓝牙(Bluetooth low energy，BLE)扫描广播接口来实现。

换言之，本申请实施例通过蓝牙来实现协同响应。因此，本申请实施例所提供的协同方案中，智能设备需要开启蓝牙功能，以参与协同响应。

图8示出了一种智能设备的***框架图。如图8所示，智能设备的前台应用，包括第二应用与第一应用，可以通过应用程序编程接口(Application Programming Interface，API)接口，例如BLE扫描广播接口，来调用蓝牙进程，从而，能够使用蓝牙芯片提供的能力。而蓝牙进程与蓝牙芯片之间通过驱动连接。本申请实施例所涉及到的驱动可以包括但不限于：安全数字输入输出卡(Secure Digital Input and Output Card，SDIO)驱动、通用异步收发传输器(Universal Asynchronous Receiver/Transmitter，UART)驱动(又称为串口驱动)。

本申请实施例中，可以将智能设备中的应用区分为第二应用与第一应用，其中，第一应用需要较短的扫描时长，因此，本申请实施例为第二应用与第一应用采取不同的扫描策略，使得第一应用可以采取较短的扫描时长进行扫描，从而提高第一应用的响应速度。

一种可能的实施例中，第一应用可以为语音助手应用，第二应用可以为除语音助手应用之外的其他应用。例如，第二应用可以为运动健康应用，运动健康应用可以通过蓝牙与智能手环(或智能手表)进行通信，以从智能手环中获取用户的心率、体温、睡眠情况、运动情况中的至少一种数据。又例如，第二应用可以为微信，具体可以为微信摇一摇，用户可以通过摇晃手机，来触发蓝牙扫描周围的设备或其他数据。又例如，第二应用还可以为智能单车APP，用户可以通过蓝牙来搜索周围是否有智能单车。

对于第二应用而言，扫描时长的长短对第二应用运行、使用的影响较小，因此，可以在第二应用有扫描需求时，再进行扫描。而第一应用对扫描时长的要求较高，若扫描时长较长，则可能会影响第一应用的使用或用户体验，因此，第一应用进行扫描时，需要采用较短的扫描时长，因此，可以提前为第一应用配置扫描环境，以便于在第一应用有扫描需求时，无需再配置扫描环境，可以直接进行扫描，节省扫描时长。

图9和图10分别示出了这两种情况。其中，图9示出了第二应用利用蓝牙芯片进行扫描时的数据交互策略；而图10示出了的第一应用利用蓝牙芯片进行扫描时的数据交互策略。

一方面，可以参考图9。第二应用调用蓝牙芯片进行扫描时，可以包括但不限于如下步骤：

S901，第二应用发起扫描。

具体而言，智能设备的前台应用可以利用API接口，例如BLE扫描广播接口，来发起扫描。

如前所述，第二应用可以在有扫描需求时，调用API接口，以使得蓝牙进程开始配置扫描环境，并启动扫描。

S902，蓝牙进程将扫描注册到协议栈。

协议栈(Protocol stack)，又称协议堆叠，是计算机网络协议套件的一种具体的软件实现。

S903，蓝牙进程指示蓝牙芯片配置第二过滤器。

该步骤具体包含但不限于以下几个方面：

S9031，蓝牙进程指示蓝牙芯片使能过滤器。

如此，使得蓝牙芯片中的过滤器可以工作。

S9032，蓝牙进程指示蓝牙芯片新建一个第二过滤器。

可以为每个业务，分别建立对应的过滤器，一个过滤器可用于对一个业务进行过滤，由此，也可以通过过滤器来区分不同的业务。例如，微信摇一摇的业务可以对应过滤器A，智能单车的业务可以对应另一个过滤器B；如此，当前台应用为微信，用户使用微信摇一摇来扫描周围设备时，采用过滤器A进行设备扫描。

当智能设备的前台应用调用蓝牙进程时，可能对应不同的业务，因此，可以为当前业务新建一个过滤器，以与其他业务进行区分。

S9033，蓝牙进程添加第二过滤器的条件。

其中，过滤器的条件用于在扫描过程中对扫描到的信息进行过滤。过滤器的条件可以包括但不限于厂商信息、物理地址(例如，MAC地址)、服务信息(例如，当前蓝牙服务是打印机应用还是投屏应用)、蓝牙搜索的设备名称中的至少一种。本申请实施例中，第二过滤器的条件的数目可以为至少一个，本申请对其数目与具体内容无特别限定。

例如，第二过滤器的条件为厂商信息，例如，华为的厂商信息为0101，那么，当第二过滤器以此为条件进行扫描时，可以自动滤除厂商信息不是0101的设备，如此，可以将其他厂商的智能设备进行滤除，实现来自于同一厂商的多个智能设备的数据交互。

S904，蓝牙进程为蓝牙芯片设置第二扫描参数。

具体而言，该步骤用于为蓝牙芯片设置第二过滤器的扫描参数。本申请实施例所涉及到的扫描参数可以包括但不限于：占空比(duty cycle)。

图11示出了占空比的示意图。如图11所示，蓝牙芯片可以每间隔(interval)T1时长开始进行扫描，在进行扫描时，扫描窗口(window)对应的扫描时长为T2，其中，T2的值小于或等于T1。而占空比即为扫描窗口(window)所对应时长在扫描间隔(interval)时长中所占的比例，换言之，占空比＝T2/T1。例如，若蓝牙芯片按照100ms的间隔进行周期式扫描，而扫描窗口对应的扫描时长为10ms，则该蓝牙芯片进行扫描时的占空比为10％。又例如，若蓝牙芯片按照100ms的间隔进行周期式扫描，而扫描窗口对应的扫描时长为100ms，则该蓝牙芯片进行扫描时的占空比为100％。

针对不同的业务，可以采用不同的过滤器，任意两个过滤器所采用的占空比，可能相同也可能不同。例如，微信摇一摇业务对应的过滤器A，与智能单车业务对应的过滤器B，过滤器A与过滤器B可以采用相同的占空比，也可以采用不同的占空比。

基于前述S902～S904，蓝牙进程完成对第二应用的扫描环境的配置。

S905，蓝牙进程指示蓝牙芯片启动扫描。

如此，蓝牙芯片开始工作，向周围智能设备进行扫描，并获得扫描结果。后续详述扫描过程。

如前所述，第二应用是在有扫描需求时，触发S901，因此，无需第二应用再向蓝牙进程发送启动扫描命令，蓝牙进程即可自动在配置好扫描环境后，启动扫描。

S906，蓝牙芯片向蓝牙进程上报扫描结果。

S907，蓝牙进程向智能设备的第二应用上报扫描结果。

S908，智能设备的第二应用向蓝牙进程发送关闭扫描命令。

具体实现时，第二应用可以停止调用蓝牙进程的API接口。

S909，蓝牙进程指示蓝牙芯片关闭扫描。

蓝牙芯片接收到该命令后，即停止扫描，不再接收或主动获取其他设备的数据。

S910，蓝牙进程解注册协议栈。

当蓝牙进程接收到关闭扫描命令时，即可解注册协议栈。此时，该第二应用业务对应的第二过滤器被释放，第二扫描参数也不再保留。如此，当第二应用再次调用蓝牙模块进行扫描时，需要再次新建过滤器，并配置扫描参数，也就是，需要重新执行如图9所示的全部过程。

相比之下，图10所示的第一应用，例如语音助手应用，利用蓝牙芯片进行扫描时，可以提前为第一应用进行扫描配置，以便于有业务需求时，可以直接启动扫描，以节省扫描时长，从而，节省协同相应的时长。

另一方面，可以参考图10。第一应用调用蓝牙芯片进行扫描时，可以包括但不限于如下步骤：

S1001，第一应用向蓝牙进程注册高优先级扫描。

具体而言，智能设备的前台应用可以利用API接口，例如BLE扫描广播接口，以指示蓝牙进程提前配置第一应用的扫描环境。

由此，一种可能的实施例中，S1001可以在智能设备的蓝牙被开启时，即触发执行。蓝牙可以被用户手动开启，也可以自动启动。例如，蓝牙可以定时启动和关闭。又例如，蓝牙还可以被配置为开机自动启动。

另一种可能的实施例中，S1001可以在智能设备的语音助手服务被开启时，即触发执行。语音助手服务也可以由用户手动启动或自动启动，不赘述。

另一种可能的实施例中，S1001可以在智能设备被启动时，即触发执行。

实际场景中，前述至少两种实施例可以组合使用。例如，S1001可以在蓝牙被开启时，和/或，语音助手服务被开启时，触发执行。

S1002，蓝牙进程将扫描注册到协议栈。

S1003，蓝牙进程指示蓝牙芯片配置第一过滤器。

类似的，该步骤具体包含但不限于以下几个方面：

S10031，蓝牙进程指示蓝牙芯片使能过滤器，使得过滤器可以工作。

S10032，蓝牙进程指示蓝牙芯片新建一个第一过滤器。

本申请实施例中，第一过滤器与第二过滤器不同。第二过滤器用于为优先级较低的业务，例如微信摇一摇，进行过滤扫描；第一过滤器用于为优先级较高的业务，如语音助手业务，进行过滤扫描。

S10033，蓝牙进程指示蓝牙芯片添加第一过滤器的条件。

第一过滤器的条件可以包括但不限于厂商信息、物理地址(例如，MAC地址)、服务信息(例如，当前蓝牙服务是打印机应用还是投屏应用)、蓝牙搜索的设备名称中的至少一种。此外，第一过滤器的条件可以为至少一个，本申请实施例对其数目与内容均为无特别限制。

S1004，蓝牙进程指示蓝牙芯片设置第一扫描参数。

本申请实施例中，第一扫描参数也可以包括占空比。

为便于区分，将第一应用所采用的占空比记为第一占空比，将第二应用所采用的占空比称为第二占空比。本申请实施例中，第一占空比大于第二占空比。例如，语音助手服务可以按照80％的占空比进行扫描；而微信摇一摇则可以按照40％的占空比进行扫描。

一种可能的实施例中，第一扫描参数中的第一占空比，可以为硬件所支持的最大占空比。

如图11所示，若占空比较高，则扫描窗口在扫描间隔中所占的比例更高，硬件工作的更加频繁，也更有利于及时收发数据。

通过前述S1001～S1004，可以实现对第一应用的扫描环境的配置。在此基础上，语音助手服务采集到用户的声音信号，并需要进行协同响应时，就可以按照S1005～S1008所示方式进行处理，即可快速得到扫描结果。

S1005，当第一应用有扫描需求时，第一应用向蓝牙进程发起扫描。

也就是，当语音助手服务需要进行协同响应时，语音助手服务可以调用API接口向蓝牙进程发送启动扫描命令，以使得蓝牙进程接收到该命令后触发蓝牙芯片工作。

S1006，蓝牙进程指示蓝牙芯片启动扫描。

如此，蓝牙芯片开始工作，向周围智能设备进行扫描，并获得扫描结果。后续详述扫描过程。

S1007，蓝牙芯片向蓝牙进程上报扫描结果。

S1008，蓝牙进程向第一应用上报扫描结果。

如此，即可快速完成第一应用的扫描。相对于图9所示的第二应用的扫描方式(S901～S910)，这种扫描方式能够有效缩短扫描时长。

可以理解，若第一应用有多次扫描需求，只需要多次执行S1005～S1008步骤即可。示例性的，图10仅示出一个扫描过程，但这不应构成对本申请的限定。

S1009，扫描任务完成后，第一应用向蓝牙进程发送关闭扫描命令。

具体实现时，第一应用可以停止调用蓝牙进程的API接口。

S1010，蓝牙进程指示蓝牙芯片关闭扫描。

蓝牙芯片接收到该命令后，即停止扫描，不再接收或主动获取其他设备的数据。

需要说明的是，在图10所示的第一应用的扫描方式中，在当第一应用发送关闭扫描命令后，蓝牙进程并未对第一应用的高优先级扫描作“解注册”处理，如此，第一应用的扫描环境仍然被保留，第一过滤器并未被释放，第一扫描参数也可以存储在蓝牙进程或蓝牙芯片中。如此，若后续第一应用又有新的扫描需求时，也无需再重新创建第一过滤器或第一扫描参数，只需要按照前述S1005～S1010所示方式，直接启动扫描即可。对比来看，如图9所示的第二应用的扫描过程(S901～S907之间的过程)的扫描耗时大约在100ms左右，而如图10所示的第一应用的扫描过程(S1005～S1008之间的过程)的扫描耗时只需要40ms左右，有效地缩短了扫描时长；从而，也有效缩短了协同响应的时长，提高了语音助手服务的响应速度。

除此之外，在图10的另一种实施例中，蓝牙进程也可以在接收到关闭扫描命令后，对第一应用的高优先级扫描作“解注册”处理。这种实现方式中，会在检测到满足前述S1001的触发条件时，再提前预配置第一应用的扫描环境。相较于图10所示实施例，这种处理方式有利于节省***资源。

在智能设备的实际使用场景中，可能在智能设备的蓝牙被打开时，就提前预配置了第一应用的扫描环境，但还未接收到第一应用的启动扫描命令，就可能接收到第二应用的启动扫描命令。图12即示出了这种情况。

如图12所示，可以预先执行S1001～S1004，已提前预配置第一应用的扫描环境。但智能设备中，用户使用了第二应用，第二应用可以在S1004后执行S901～S910，也就是，配置第二应用的扫描环境(新建第二过滤器，并将第一扫描参数重新配置为第二扫描参数)，并进行扫描，得到扫描结果，在第二应用接收到蓝牙线程上报的扫描结果之后，即可关闭当前扫描。关闭时，释放第二过滤器。而第二应用的扫描过程导致预先配置的第一扫描参数发生变更，在关闭第二应用的扫描时，蓝牙芯片的扫描参数可以有不同的设计。例如，在S901～S910的实现过程中，蓝牙芯片所采用的扫描参数由预先配置的第一扫描参数，变更为第二扫描参数。在第二应用扫描结束之后，蓝牙芯片可能继续采用第二扫描参数；或者，蓝牙芯片也可能恢复默认设置(初始化)；或者，也有可能由第二扫描参数变更为预先配置的第一扫描参数。

基于前述情况，本申请实施例中，可以在第二应用扫描结束后，执行S1200。也就是，在第二应用扫描结束之后，蓝牙线程自动将蓝牙芯片所采用的扫描参数恢复成第二扫描参数。在一实施例中，蓝牙线程可以直接按照S1004的方式，在蓝牙芯片中进行第二扫描参数的配置，此时，可以利用蓝牙芯片或蓝牙进程中记录的第一扫描参数的数据实现配置和恢复。另一实施例中，蓝牙线程可以获取当前蓝牙芯片所采用的扫描参数，若蓝牙芯片当前采用的扫描参数为第一扫描参数，则蓝牙线程可不作处理；或者，若蓝牙芯片当前采用的扫描参数不是第一扫描参数，则设置第一扫描参数。在另一个实施例中，蓝牙线程可以仅配置多个扫描参数中的部分扫描参数，或者，也可以配置全部扫描参数。例如，若蓝牙芯片当前的扫描参数所采用的占空比为10％，而第一扫描参数中的第一占空比为50％，其他扫描参数均相同，则可以仅对扫描参数中的占空比进行配置；或者，直接按照第一扫描参数的预配置数值，对蓝牙芯片所使用的各扫描参数都进行重新配置。

如前所述，本申请实施例中，第一应用对应的第一过滤器在第二应用扫描期间，并未被释放，仍可以继续使用，因此，无需再配置第一过滤器。

基于前述配置，若第一应用有扫描需求，只需要按照S1005～S1008所示方式进行扫描即可。其中，S1005～S1008所示方式可以执行多次，多次扫描对应的扫描对象可以相同，也可以不同。扫描结束后，按照S1009～S1010来关闭扫描。此时，第一过滤器仍未被释放，第一扫描参数被保留，但蓝牙芯片所使用的扫描参数为第一扫描参数。

举例而言。当手机的蓝牙打开时，即可按照S1001～S1004所示方式，为语音助手APP提前配置扫描环境。也就是，提前预配置语音助手业务的第一过滤器与第一扫描参数。

之后，用户打开了智能单车APP，该智能单车APP需要调用蓝牙芯片来扫描周围车辆或用户，此时，蓝牙线程开始配置该蓝牙业务的第二过滤器(新建)与第二扫描参数(配置，此时，蓝牙芯片使用的扫描参数由第一扫描参数变更为第二扫描参数)，而蓝牙芯片可以利用配置好的第二过滤器与第二扫描参数，进行扫描并上报扫描结果。如此，智能单车APP在获取到扫描结果后，停止调用蓝牙扫描广播接口，蓝牙进程关闭本次扫描，释放第二过滤器，第二扫描参数被变更、沿用或初始化，并解注册本次扫描到协议栈。

随后，蓝牙进程将蓝牙芯片中的扫描参数恢复为第二扫描参数。具体的，可以按照蓝牙芯片或蓝牙进程中存储的，预配置第二扫描参数时的数值，来重新配置以恢复第二扫描参数。恢复后，蓝牙芯片采用第二扫描参数进行扫描。

后来，用户说出该手机的唤醒词，启动了手机的语音助手APP。此时，语音助手APP需要与其他智能设备协同响应，因此，语音助手APP调用API接口，向蓝牙进程发出启动扫描命令。此时，蓝牙芯片中已经配置好了第一过滤器与第一扫描参数，蓝牙进程无需再配置过滤器或扫描参数，可直接将启动扫描命令发送给蓝牙芯片，蓝牙芯片进行扫描，并上报扫描结果。扫描结束后，关闭扫描。

在图12所示实施例中，若进行了第二应用发起的扫描，则在关闭该扫描后，可以自动恢复第一应用的第二扫描参数，以降低第一应用的扫描启动时延，提高响应速度。

图13示出了另一种场景。以第二应用为微信摇一摇，第一应用为语音助手APP为例。

在蓝牙开启时或手机启动时，可以触发S1001，并按照S1001～S1004所示方式，为语音助手APP预配置扫描环境。

蓝牙打开后，用户打开微信，并点击微信摇一摇来检测周边设备。在该过程中，按照S901～S907进行扫描。

在该扫描未结束时，用户又说出了语音助手APP的唤醒词，则语音助手APP需要与其他智能设备协同响应，因此，语音助手APP调用API接口，向蓝牙进程发出启动扫描命令。

此时，可以参考图13中的第1次扫描过程。虽然微信摇一摇的扫描业务还未完成，但为了保证语音助手APP能够及时响应用户，因此，蓝牙进程在接收到启动扫描命令后，执行S1300，设置第一扫描参数，使得蓝牙芯片能够按照更高的占空比进行扫描。随后，执行S1006～S1010，语音助手APP可以及时根据该扫描过程，得到其他智能设备的协同信息，并在确定自身为响应设备时，及时响应用户。

随后，用户又说了语音助手APP的唤醒词，此时，可以参考图13中的第2次扫描过程。由于蓝牙芯片中的扫描参数未发生变化，无需再恢复或额外配置第一扫描参数，而第一过滤器也并未被释放，因此，当语音助手APP再次发起扫描任务时，可以直接按照S1011～S1016所示方式执行即可。

需要说明的是，在该实施例中，电子设备优先进行第一应用的扫描，此时，虽然未收到第二应用的关闭扫描指示，也暂停或终止第二应用的扫描。

此时，在一种可能的实施例中，在执行S1300时，电子设备可以释放第二过滤器，并无需保留第二扫描参数。那么，第二应用的扫描被终止。

另一种可能的实施例中，在执行S1300时，电子设备可以保留第二过滤器，并将第二扫描参数缓存在蓝牙芯片或其他位置，如此，当电子设备完成第一应用的扫描时，还可以重新配置第二应用的第二扫描参数，并完成第二应用的扫描过程。直至第二应用的扫描结束，再释放第二过滤器，并将第二扫描参数恢复为第一扫描参数。

如图12、图13所示，本申请所提供的技术方案具备较高的兼容性，在不影响其他业务流程的前提下，有效提高了智能设备的响应速度。

需要说明的是，本申请实施例中，语音服务类APP都可以作为第一应用，按照前述图10～图13所示出的任意一种方式，来实现数据同步，并实现协同响应。

本申请实施例中，可以对智能设备中的APP进行分类，针对其中的部分第一应用，通过提前预配置扫描环境的方式，实现对第一应用的快速扫描，以提高智能设备的响应速度。

除此之外，还可以将智能设备中的所有APP都作为第一应用，通过提前预配置扫描环境的方式，实现各APP的快速扫描，以提高智能设备的响应速度。

现以第一设备扫描第三设备，以获取第三设备的协同信息的场景为例，对智能设备的扫描方式进行具体说明。

图14示出了一种可能的实施例，该扫描过程可以包括如下步骤：

S1401，第一设备的应用调用扫描接口。

为便于理解，假设第一设备为手机，第三设备为智能电视。在一种可能的场景中，用户在一个包含手机和智能电视的环境中，说出唤醒词“小艺小艺”，手机可以采集到该声音信号，并对该声音信号进行语音识别。以及，手机还可以以并行或串行的方式，与其他设备进行协同响应。此时，手机前台的语音助手APP调用扫描接口，以指示蓝牙进程的协议栈工作。

S1402，第一设备的协议栈指示链路层A配置扫描环境。

该步骤具体可以包括：S14021，协议栈向蓝牙芯片的链路层发送设置扫描环境的命令。以使得蓝牙芯片设置当前应用对应业务的扫描环境。S14022，链路层A反馈命令完成的通知消息。

具体而言，S14021在具体实现时，包含两方面内容：设置过滤器与设置扫描参数。例如，在如图9所示的实施例中，该步骤可以细化为S903～S904，S903包含S9031～S9033，不赘述。又例如，在如图10所示的实施例汇总，该步骤可以细化为S1003～S1004，S1003包含S10031～S10033，不赘述。

由于S14021在不同的实施例中，可以分解为多个步骤，因此，与该步骤对应命令完成通知也可以有多个。以图9为例，协议栈执行S9031～S904的过程中，可以收到4个命令完成通知。

一种可能的设计中，协议栈可以在收到当前命令的命令完成通知，例如收到ACK时，表示命令完成，此时再发送下一个步骤的命令。例如，图9的一种实施例中，协议栈执行S9031，只有在收到ACK后，才会执行S9032。那么，若协议栈收到的是命令未完成通知，例如，收到NCK即表示命令未完成。那么，协议栈可以再次发送当前指令，直至收到ACK。例如，协议栈执行S9031，收到NCK时，可以再次向链路层发送“使能过滤器”的命令，直至接收到ACK。或者，协议栈可以重复多次发送当前指令，若一直收到NCK，且收到NCK的次数达到预设的指定数目，则不再发送当前指令。此时，协议栈还可以向前台应用进行反馈，以通知前台应用扫描失败。例如，协议栈执行S9031，收到NCK时就重复发送S9031，若连续收到5个NCK且一直没有收到ACK，则不再重复发送S9031，而是上报前台应用扫描失败。

另一种可能的设计中，协议栈发送命令时，可以不受到蓝牙芯片发送的命令响应的影响。例如，协议栈可以发送S9031，在未收到ACK时，即可以再次向蓝牙芯片发送S9032，以在蓝牙芯片中新建过滤器。这种实现方式更节省时间。

而扫描参数的设置，则可以按照第一设备前台应用的类型确定。例如，手机前台为语音助手APP，则蓝牙进程的协议栈可以指示链路层A设置第二扫描参数，以使得扫描芯片能够以较高的占空比进行扫描工作。

S1403，协议栈指示链路层A启动扫描。

具体也可以包含两个步骤：

S14031，协议层指示链路层A使能扫描。

这可以对应于图9所示的S905，此时，启动扫描的命令可以是由蓝牙进程的协议栈自动发送的。

或者，也可以对应于图10所示的S1006，此时，该启动扫描的命令是协议栈接收到第一应用的请求后，发送的。

S14032，链路层A反馈命令完成的通知消息。

如此，协议栈可以收到ACK或NCK的指示，以确定蓝牙芯片是否启动扫描。可以理解，若接收到NCK，则协议栈可以重复发送S14031，直至接收到ACK，或直至收到指定数目个NCK后停止。

S1404，第一设备的链路层A接收第三设备的链路层B的广播数据。

基于前述配置，蓝牙芯片启动扫描，因此，可以接收到其他设备的广播数据。本申请实施例中，广播数据中可以包括但不限于设备的协同信息。该步骤中的广播数据具体可以包括第三设备的协同信息

S1405，链路层A上报广播数据。

S1406，链路层A向链路层B发送扫描请求。

S1407，链路层A接收链路层B发送的扫描响应。

S1408，链路层A上报扫描响应。

S1409，蓝牙进程的协议栈合并广播数据与扫描响应。

S1410，协议栈上报扫描结果。

可以理解，此时协议栈上报的扫描结果即为合并后的广播数据与扫描响应。

S1411，第一设备的前台应用停止调用扫描接口。

S1412，协议栈指示链路层A关闭扫描。

此时，包括S14121和S14122两个子步骤。也就是，协议栈指示链路层A关闭扫描，并在接收到命令完成指令，例如ACK时，确定扫描已关闭。

在如图14所示场景中，第三设备对外广播的广播报文，可能受限于报文格式或其他原因，其中，可能并未携带全第三设备参与协同响应的协同信息，因此，可以通过第一设备主动发送扫描请求，并接收扫描响应的方式，将扫描响应与广播数据进行合并，就可以获取到第三设备的协同信息。例如，第三设备的广播报文可能只有32byte，扫描响应也只有32byte，而协同信息需要64byte，因此，将广播报文与扫描响应合并起来，即可得到完整的协同信息。基于这种设计，图14中，若协议栈未收到广播数据，或者，未收到扫描响应，协议栈就无法执行S1409中合并得到扫描结果的步骤。

如图14所示的扫描方式，可以适用于目前大部分安卓设备的蓝牙接口，普适性较高。

图15示出了一种可能的实施例。该扫描过程与图14所示实施例相比，少了两个几个步骤：S1406～S1409，也就是，胜省略了其中链路层A主动向链路层B发送扫描请求，并与扫描响应合并以得到扫描结果的步骤。这种情况下，协议栈再接收到链路层A上报的广播数据后，即将广播数据作为扫描结果，上报给前台应用。

可以理解，在图15所示实施例中，S1404～S1405可以执行至少一次。例如，若广播报文可能只有32byte，那么，协同信息可能也使用32byte，则可以如图15所示，协议栈上报一次广播数据，即可得到第三设备的协同信息。又例如，广播报文为32byte，若需要传输的数据为64byte，则可以通过至少两次广播数据来携带这些信息，此时，可以执行至少两次S404～S1405。这种情况下，协议栈可以将至少两次广播数据合并后，再上报给前台应用；或者，协议栈收到广播数据就上报给前台应用，由前台应用根据接收到的广播数据来获取协同信息。如图15所示的扫描方式，实现方式较为简便。

此外，本申请实施例还提供了另一种实现方式：前台应用调用BLE扫描广播接口进行扫描(接收广播并发送扫描请求的方式)，而协议栈在接收到广播数据时，根据广播数据的类型，采取不同处理。

请参考图16所示出的一种实施例。图16所示实施例适用于智能设备的协同响应场景。

如图16所示，第一设备前台应用调用扫描接口(S1401)，并执行S14021～S14032，完成对当前业务的扫描环境配置。蓝牙芯片开始工作，能够接收到第三设备对外广播的广播数据，并上报给协议栈(S1404～S1405)。

协议栈可以判断当前广播数据是否为协同数据包。本申请实施例中，协同数据包可以为语音助手APP参与协同响应时，同步给其他智能设备的数据包，其中可以携带设备的协同信息。协同数据包可以具备特定的格式或标识。例如，若接收到的数据包(或报文)中的指定字段具备预设标识，则可以将当前数据包(或报文)作为协同数据包。预设标识可以自定义设计。例如，数据包中Value字段的起始一个byte为0x10。又例如，数据包的包名中携带指定字符。此外，本申请的一种实施例中，协同数据包可以为短报文，例如，可以为32byte长度的报文。

从而，若协议栈确定S1405中上报的广播数据为协同数据包时，就可以直接将该广播数据作为扫描结果，上报给前台应用(S1410)。

在该实施例中，蓝牙芯片还会主动发送扫描请求，并在接收到扫描响应时上报给协议栈(S1406～S1408)。此时，协议栈确定该扫描响应为协同数据包，由于已经上报了扫描结果，则协议栈丢弃该扫描响应，无需上报给前台应用。

而前台应用在得到协议栈上报的扫描结果后，可以停止调用扫描接口，并关闭扫描(S1411～S14122)。

本申请实施例中，语音助手APP的协同响应场景仅为示例性的，图16所示实现方式可以适用于任意第一应用，不作赘述。

另一方面，协议栈收到的广播数据可能不是协同数据包。例如，微信摇一摇以发现周围设备的场景中，协议栈收到的数据包并非用于智能设备的协同响应，此时，该数据包不具备协同数据包的预设标识。

此时，如图17所示，协议栈在接收到广播数据后，确定不是协同响应包，则等待扫描响应，直至接收到扫描响应，再将广播数据与扫描响应合并，并将合并后的扫描结果上报即可。

如图16、图17所示的实现方式能够适用于安卓智能设备，并且，针对协同响应的数据包，可以不用等待扫描响应的结果，直接上报广播数据，一定程度上能够降低由于需要等待扫描响应而可能导致前台应用无法收到扫描结果的发生几率。

需要说明的是，如图15～图17所示的扫描方式，可以与图9～图13所示的配置方式结合使用。

示例性的图18示出一种可能的场景。如图18所示，可以在蓝牙被启动(举例，不应作为限定)时，提前预配置语音助手APP的扫描环境，如S1001～S1004步骤所示，实现方式可以参考前述图10所示方式，在此不作赘述。在S1004之后，语音助手APP采集到声音信号，需要与其他智能设备协同响应，则语音助手向协议栈发起扫描(S1801)，随后，协议栈也指示链路层A启动扫描(S1802)。如此，链路层A开始工作，按照S1404～S14122所示方式完成协同信息的同步，并进而实现协同响应。这种实现方式能够有效提高智设备的响应速度，有利于提高用户体验。

除此之外，需要说明的是，本申请实施例所提供的技术方案，不仅可应用于智能设备协同响应以响应唤醒词的场景，还可以应用于多个智能设备在唤醒状态下，对用户说出的语音指令进行响应的场景。

请参考图19。在图19所示场景中，手机100、智能电视200、智能手环300与智能音箱400都可以对用户说出的语音指令进行响应。若用户未说唤醒词，而直接发出一个语音指令“播放音乐”，则手机100、智能电视200、智能手环300与智能音箱400都可以响应该语音指令，并播放音乐，如此，也会导致环境嘈杂，影响语音操控体验。

这种情况下，可以利用本申请实施例所提供的前述方案来实现语音响应。各智能设备可以采集声音信号，对声音信号进行语音识别，并通过协同响应，来确定该语音指令的响应设备。如此，只需要由响应设备来对该语音指令进行响应即可。

此时，可以参考图20，当用户说出“播放音乐”，则手机100、智能电视200、智能手环300与智能音箱400可以采用图9～图18所示的至少一种方式，进行协同响应。如此，确定出智能音箱400为该语音指令的响应设备，则由智能音箱400播放音乐，其他智能设备则不作响应。

本申请的各实施方式可以任意进行组合，以实现不同的技术效果。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid StateDisk)等。

总之，以上所述仅为本发明技术方案的实施例而已，并非用于限定本发明的保护范围。凡根据本发明的揭露，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (19)

1.一种数据处理方法，其特征在于，应用于第一设备中，所述方法包括：

当接收到第一应用的启动蓝牙扫描指示时，接收第二设备发送的第二广播数据，向所述第二设备发送扫描请求，并等待接收扫描响应；

当所述第二广播数据为指定类型数据包时，将所述第二广播数据上报至所述第一应用，所述指定类型数据包为指定字段具备预设标识的数据包；

丢弃所述扫描响应。

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

当所述第二广播数据不是所述指定类型数据包时，接收所述扫描响应，合并所述第二广播数据与所述扫描响应，得到合并数据；

将所述合并数据上报至所述第一应用。

3.根据权利要求1或2所述的方法，其特征在于，当所述第一应用为语音助手应用时，所述启动蓝牙扫描指示为所述第一应用采集到声音信号后发送的。

4.根据权利要求3所述的方法，其特征在于，当所述第二广播数据为所述指定类型数据包时，所述第二广播数据携带所述第二设备的协同信息。

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

当接收到第一应用的启动蓝牙扫描指示时，广播第一广播数据，所述第一广播数据携带所述第一设备的协同信息。

6.根据权利要求4或5所述的方法，其特征在于，所述协同信息用于确定所述声音信号的响应设备；所述协同信息包括：设备类型、最近一次蓝牙唤醒时刻、最近一次蓝牙响应时刻与声音信号的声强中的至少一种。

7.根据权利要求6所述的方法，其特征在于，所述启动蓝牙扫描指示为所述第一应用采集到所述声音信号后，并识别出所述声音信号为所述第一设备的唤醒词时发送的。

8.根据权利要求6所述的方法，其特征在于，所述启动蓝牙扫描指示为所述第一应用采集到所述声音信号后，且在得到语音识别结果之前发送的。

9.根据权利要求8所述的方法，其特征在于，若所述第一设备的协同信息满足预设的响应规则，且识别出所述声音信号不是所述第一设备的唤醒词时，所述方法还包括：

广播第三广播数据，所述第三广播数据用于指示所述声音信号不是所述第一设备的唤醒词。

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

当检测到所述第一设备中的蓝牙开关开启时，为所述第一应用配置第一过滤器与第一扫描参数。

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

当接收到所述第一应用发送的关闭蓝牙扫描指示，停止收发数据，并保留所述第一过滤器与所述第一扫描参数。

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

当接收到第二应用的启动蓝牙扫描指示时，为所述第二应用配置第二过滤器，并将所述第一扫描参数修改为第二扫描参数。

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

当接收到所述第二应用发送的关闭扫描指示时，停止收发数据，释放所述第二过滤器，并将所述第二扫描参数恢复为所述第一扫描参数。

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

当接收到所述第一应用的启动蓝牙扫描指示，且未接收到所述第二应用发送的关闭扫描指示时，为所述第一应用配置所述第一扫描参数。

15.根据权利要求13或14所述的方法，其特征在于，所述第一扫描参数采用第一占空比，所述第二扫描参数使用第二占空比，所述第一占空比大于所述第二占空比。

16.根据权利要求1或2所述的方法，其特征在于，当所述第一应用调用蓝牙扫描广播接口时，接收到所述第一应用发送的启动蓝牙扫描指示。

17.一种蓝牙模块，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述蓝牙模块执行时，使得所述蓝牙模块执行如权利要求1-16中任一项所述的方法。

18.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

一个或多个蓝牙模块；

以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求1-16中任一项所述的方法。

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

Images