一种蓝牙广播请求的处理方法及设备

技术领域

本申请涉及蓝牙技术，尤其涉及一种蓝牙广播请求的处理方法及设备。

背景技术

蓝牙广播是终端与终端之间自发现、自组网的核心，设备间的靠近发现以及各种上层业务都依赖于蓝牙广播。因此，蓝牙广播的高可靠性与高可用性，关系着能否为用户带来极致的近场设备间交互体验。

蓝牙对外提供了启动与停止的应用程序编程接口(Application ProgrammingInterface,API)。然而，在调用蓝牙广播启动API到蓝牙广播启动成功之间，以及调用蓝牙广播停止API到停止成功之间，仍存在着短暂的不可用状态。

相关技术中，在上述不可用状态下如果接收到蓝牙广播请求，由于当前蓝牙广播不可用，这部分蓝牙广播请求可能会被丢弃，导致部分蓝牙报文丢失的问题。

发明内容

本申请实施例提供一种蓝牙广播请求的处理方法及设备，用于解决蓝牙第一蓝牙广播状态下触发的蓝牙广播请求可能会被丢弃，导致部分蓝牙报文丢失的问题。

为达到上述目的，本申请的实施例采用如下技术方案：

第一方面，提供了一种蓝牙广播请求的处理方法，该方法应用于电子设备；该电子设备包括蓝牙和蓝牙监视器，电子设备通过蓝牙监视器调用蓝牙的接口，该方法包括：

响应于第一蓝牙广播请求，蓝牙监视器获取蓝牙监视器中保存的当前的蓝牙广播状态。在确定当前的蓝牙广播状态为第一蓝牙广播状态的情况下，表示当前蓝牙广播不可用，因此针对第一蓝牙广播请求蓝牙监视器进入第一等待状态；第一蓝牙广播状态包括启动中状态或者停止中状态。在第一等待状态下，蓝牙监视器监听蓝牙发送的调用信息。在监听蓝牙的调用成功信息时，蓝牙监视器将当前的蓝牙广播状态更新为第二蓝牙广播状态，表示当前蓝牙广播更新为可用状态了。此时，蓝牙监视器可以响应于第一蓝牙广播请求，执行蓝牙广播操作。其中。调用信息包括调用成功信息，调用成功信息用于指示蓝牙广播启动接口调用成功，或者蓝牙广播停止接口调用成功；第二蓝牙广播状态包括闲置状态或广播中状态。

在该方案中，针对在蓝牙广播不可用的状态下接收的第一蓝牙广播请求，不会直接丢弃，而是等待一段时间。等到接收到蓝牙反馈的调用成功信息，将蓝牙广播状态更新为可用状态(第二蓝牙广播状态)，即可执行上述第一蓝牙广播请求对应的蓝牙广播操作。这样，可以避免蓝牙广播请求因当前蓝牙广播不可用而被丢弃，减少蓝牙广播报文丢失的情况。

在一些可能的实施方式中，在蓝牙监视器进入第一等待状态之后，上述方法还包括：在第一等待状态下，蓝牙监视器获取蓝牙在第一蓝牙广播状态的第一停留时间；若第一停留时间未超出第一预设时间，则蓝牙监视器维持第一等待状态。这样，可以保证在第一等待状态下可以等待当前蓝牙广播状态更新为可用状态。

在一些可能的实施方式中，在蓝牙监视器进入第一等待状态之后，上述方法还包括：在第一等待状态下，若第一停留时间超出第一预设时间，则蓝牙监视器调用蓝牙的接口。其中，蓝牙广播状态在启动中状态的第一停留时间超出第一预设时间，可能蓝牙监视器未接收到调用反馈信息，或者蓝牙发生故障，此时蓝牙监视器可以直接调用蓝牙广播停止接口，以将蓝牙广播状态更新为准确的蓝牙广播状态。同理，蓝牙广播状态在停止中状态的第一停留是按超出第一预设时间时，蓝牙监视器可以直接调用蓝牙广播启动接口，以将蓝牙广播状态更新为准确的蓝牙广播状态。这样，可以避免第一蓝牙广播请求长时间无法通过蓝牙进行广播的问题。

在一些可能的实施方式中，上述方法还包括：蓝牙监视器如果监听到用于指示蓝牙广播启动接口调用成功的第一调用成功信息，则可以将当前的蓝牙广播状态更新为广播中状态。如果蓝牙监视器接收到用于指示蓝牙广播停止接口调用成功的第二调用成功信息，那么蓝牙监视器将当前的蓝牙广播状态更新为闲置状态。这样，在第一等待状态下，蓝牙广播状态仍会持续更新，因此，针对第一蓝牙广播请求可以等到当前的蓝牙广播状态更新为可用状态之后，再执行对应的蓝牙广播操作。

在一些可能的实施方式中，在响应于第一蓝牙广播请求，蓝牙监视器获取当前的蓝牙广播状态之后，上述方法还包括：在确定当前的蓝牙广播状态为闲置状态的情况下，表示当前蓝牙广播可以直接使用。此时，蓝牙监视器响应于第一蓝牙广播请求，调用蓝牙的蓝牙广播启动接口；并且，蓝牙监视器将当前的蓝牙广播状态由闲置状态更新为启动中状态。蓝牙监视器在接收到蓝牙反馈的第一调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态由启动中状态更新为广播中状态；第一调用成功信息用于指示蓝牙广播启动接口调用成功。蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文；更新后的广播报文用于蓝牙进行广播。如果在闲置状态下接收到第一蓝牙广播请求，则蓝牙监视器可以响应于第一蓝牙广播请求调用蓝牙广播启动接口，以对第一蓝牙广播请求对应的广播内容进行广播。

在一些可能的实施方式中，在蓝牙监视器响应于第一蓝牙广播请求，调用蓝牙的蓝牙广播启动接口之后，上述方法还包括：蓝牙监视器基于第一蓝牙广播请求对应的待广播时长设置第一计时器，第一计时器开始计时。这样，之后蓝牙监视器根据第一计时器的计时时间可以确定当前蓝牙广播的剩余广播时长。在该实施方式中，在蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文之后，上述方法还包括：在根据第一计时器的计时时间确定当前蓝牙的剩余广播时长为0时，表示当前的蓝牙广播已经完成，此时蓝牙监视器调用蓝牙的蓝牙广播停止接口，并将当前的蓝牙广播状态更新为停止中状态。并且在接收到蓝牙反馈的第二调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态由停止中状态更新为闲置状态；第二调用成功信息用于指示蓝牙广播停止接口调用成功。这样，在广播中状态下可以结合第一计时器的计时时间确定蓝牙广播是否完成，并且在蓝牙广播完成时，由蓝牙监视器调用蓝牙广播停止接口。从而可以避免蓝牙广播完成之后蓝牙广播仍处于广播中状态导致不必要的耗电的问题。

在一些可能的实施方式中，在蓝牙监视器响应于第一蓝牙广播请求，调用蓝牙的蓝牙广播启动接口之前，上述方法还包括：在确定当前的蓝牙广播状态为闲置状态的情况下，蓝牙监视器获取蓝牙在闲置状态的第二停留时间。在该实施方式中，蓝牙监视器响应于第一蓝牙广播请求，调用蓝牙的蓝牙广播启动接口，具体可以包括：蓝牙监视器在确定第二停留时间超出第二预设时间的情况下，响应于第一蓝牙广播请求，调用蓝牙的蓝牙广播启动接口。在该方案中，对于部分蓝牙广播状态刚刚由停止中状态变更为闲置状态的一小段时间内，蓝牙广播仍不可用的情况，蓝牙监视器也可以等待一段时间。等到蓝牙广播状态更新为闲置状态一段时间之后，再响应于第一蓝牙广播请求调用蓝牙广播启动接口。这样，可以避免蓝牙广播状态刚刚更新为闲置状态的一段时间内调用蓝牙广播启动接口失败的问题。

在一些可能的实施方式中，蓝牙监视器响应于第一蓝牙广播请求，调用蓝牙的蓝牙广播启动接口，具体可以包括：蓝牙监视器向蓝牙发送蓝牙广播启动接口的调用请求。该调用请求包括第三预设时间，第三预设时间用于指示蓝牙在从当前时间开始的第三预设时间对应的时间点关闭蓝牙广播。在该方案中，蓝牙监视器在调用蓝牙广播启动接口时，给蓝牙配置了一个时间值。在计时器发生故障或者其他情况，导致蓝牙监视器在蓝牙广播完成之后没有及时调用蓝牙广播停止接口关闭蓝牙广播时，可以由蓝牙控制在一段时间之后主动停止蓝牙广播。这样，可以避免不必要的耗电。

在一些可能的实施方式中，在响应于第一蓝牙广播请求，蓝牙监视器获取当前的蓝牙广播状态之后，上述方法还包括：在确定当前的蓝牙广播状态为广播中状态的情况下，蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文。其中，更新后的广播报文用于蓝牙进行广播。这样，蓝牙广播请求可以得到快速的响应。

在一些可能的实施方式中，在蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文之前，上述方法还包括：蓝牙监视器判断第一蓝牙广播请求对应的广播内容是否为预设周期性广播；预设周期性广播用于指示蓝牙监视器重启蓝牙广播。因此，如果第一蓝牙广播请求对应的是预设周期性广播，那么当前是蓝牙广播状态是处于广播中状态的情况下，蓝牙监视器需要重启蓝牙广播。在该实施方式中，蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文，具体可以包括：蓝牙监视器在确定第一蓝牙广播请求对应的广播内容不是预设周期性广播的情况下，基于第一蓝牙广播请求，更新蓝牙的广播报文。

在一些可能的实施方式中，在蓝牙监视器更新蓝牙的广播报文之前，上述方法还包括：蓝牙监视器获取第二计时器的计时时间；第二计时器的计时时间用于指示蓝牙的剩余广播时长。在该实施方式中，蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文，具体可以包括：在根据计时器的计时时间确定当前蓝牙的剩余广播时长超出第四预设时间时，蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文；第四预设时间用于指示蓝牙广播所需的广播时长最小值。在当前所处的广播中状态下蓝牙广播剩余的时长足够的情况下，才会基于第一蓝牙广播请求更新蓝牙的广播报文。这样，可以减少因蓝牙监视器响应于在先的第二蓝牙广播请求关闭蓝牙广播，导致第一蓝牙广播请求对应的广播内容无法被其他电子设备接收到的问题。确保在当前的广播中状态下，第一蓝牙广播请求对应的广播内容能够被其他电子设备接收。

在一些可能的实施方式中，在蓝牙监视器获取第二计时器的计时时间之后，上述方法还包括：在根据第二计时器的计时时间确定当前蓝牙的剩余广播时长未超出第四预设时间时，蓝牙监视器进入第二等待状态；在第二等待状态下，蓝牙监视器监听所述蓝牙反馈的调用信息。在接收到蓝牙反馈的调用成功信息，蓝牙监视器将当前的蓝牙广播状态更新为闲置状态，并且蓝牙监视器响应于第一蓝牙广播请求，执行蓝牙广播操作。如果当前的蓝牙广播状态为广播中状态，但是当前的剩余广播时长不足以满足蓝牙广播所需的最小时长，那么针对第一蓝牙广播请求需等待当前的蓝牙广播完成，并且蓝牙广播状态更新为闲置状态之后，再执行第一蓝牙广播请求所对应的蓝牙广播操作。这样，可以使第一蓝牙广播请求对应的广播内容更有可能被其他电子设备接收到，从而提高广播效果。

在一些可能的实施方式中，在响应于第一蓝牙广播请求，蓝牙监视器获取当前的蓝牙广播状态之后，上述方法还包括：在确定当前的蓝牙广播状态为广播中状态的情况下，蓝牙监视器基于第一蓝牙广播请求更新第三计时器的计时时间，第三计时器重新开始计时；第三计时器的计时时间用于指示当前蓝牙的剩余广播时长。其中，在蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文之后，上述方法还包括：在根据第三计时器的计时时间确定当前蓝牙的剩余广播时长为0时，蓝牙监视器调用蓝牙的蓝牙广播停止接口，并将当前的蓝牙广播状态更新为停止中状态；在接收到蓝牙反馈的第二调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态由停止中状态更新为闲置状态；第二调用成功信息用于指示蓝牙广播停止接口调用成功。在广播中状态下接收到第一蓝牙广播请求，在基于第一蓝牙广播请求更新蓝牙广播报文之后，还可以根据第一蓝牙广播请求续租蓝牙广播。这样，续租蓝牙广播可以确保在当前的广播中状态下，能够完整的广播第一蓝牙广播请求对应的广播内容，可以提高广播效果。

在一些可能的实施方式中，第三计时器为倒计时器，倒计时器的倒计时时间用于指示当前蓝牙的剩余广播时长。上述蓝牙监视器基于第一蓝牙广播请求更新第三计时器的计时时间，包括：蓝牙监视器获取第一蓝牙广播请求对应的待广播时长；蓝牙监视器比较倒计时时间与待广播时长的大小。如果待广播时长大于倒计时时间，那么蓝牙监视器将当前倒计时器的倒计时时间，更新为第一蓝牙广播请求对应的待广播时长。这样可以确保在当前的广播中状态下完整的广播第一蓝牙广播请求对应的广播内容。如果倒计时时间大于待广播时长，表示在当前的广播中状态下是能够完整的广播第一蓝牙广播请求对应的广播内容的，因此此时倒计时器的计时时间可以维持不变。

在一些可能的实施方式中，在蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文之后，上述方法还包括：在第三计时器失效时，蓝牙监视器调用蓝牙的蓝牙广播停止接口，并将当前的蓝牙广播状态更新为停止中状态。并且蓝牙监视器在接收到蓝牙反馈的第二调用成功信息时，将当前的蓝牙广播状态由停止中状态更新为闲置状态；第二调用成功信息用于指示蓝牙广播停止接口调用成功。这样，可以在第三计时器失效时，及时的关闭蓝牙广播，避免因第三计时器失效导致的不必要的耗电。

在一些可能的实施方式中，上述方法还包括：在确定第一蓝牙广播请求对应的广播内容为预设周期性广播时，表示需要重启蓝牙广播。因此此时蓝牙监视器调用蓝牙的蓝牙广播停止接口，并将当前的蓝牙广播状态由广播中状态更新为停止中状态。并且在接收到蓝牙反馈的第二调用成功信息时，蓝牙监视器将当前的蓝牙广播状态由停止中状态更新为闲置状态。在该方案中，通过设置预设周期性广播，每隔一段时间重启蓝牙广播。这样，可以避免蓝牙广播长时间连续的广播导致蓝牙可能出现的问题。

在一些可能的实施方式中，预设周期性广播还用于广播电子设备的当前设备状态信息。在该实施方式中，在蓝牙监视器将当前的蓝牙广播状态由停止中状态更新为闲置状态之后，上述方法还包括：蓝牙监视器通过调用蓝牙的接口，执行预设周期性广播对应的广播操作，以广播电子设备的当前设备状态信息。在该方案中，设置预设周期性广播，以每隔预设时间间隔广播手机最新的设备状态信息，这样，可以维持手机与其他电子设备之间的连接。

第二方面，提供了一种电子设备，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该电子设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该电子设备执行如上述第一方面中任一项所述的蓝牙广播请求的处理方法。

第三方面，提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面中任一项所述的蓝牙广播请求的处理方法。

第四方面，提供了一种包含指令的计算机程序产品，当其在电子设备上运行时，使得电子设备可以执行上述第一方面中任一项所述的蓝牙广播请求的处理方法。

第五方面，提供了一种装置(例如，该装置可以是芯片系统)，该装置包括处理器，用于支持电子设备实现上述第一方面中所涉及的功能。在一种可能的设计中，该装置还包括存储器，该存储器，用于保存电子设备必要的程序指令和数据。该装置是芯片系统时，可以由芯片构成，也可以包含芯片和其他分立器件。

其中，第二方面至第五方面中任一种设计方式所带来的技术效果可参见第一方面中不同设计方式所带来的技术效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种通信系统的结构示意图；

图2为本申请实施例提供的蓝牙广播状态的示意图；

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

图4A为本申请实施例提供的一种电子设备的软件架构示意图；

图4B为本申请实施例提供的一种电子设备的软件架构示意图；

图5A为本申请实施例提供的蓝牙监视器先后接收到两个蓝牙广播请求的处理时间顺序图；

图5B为本申请实施例提供的在闲置状态下接收到的一个蓝牙广播请求之后的执行的蓝牙广播操作的流程示意图；

图6A为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图6B为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图6C为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图7为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图8为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图9为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图10A为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图10B为本申请实施例提供的根据预设周期性广播(心跳广播)重启蓝牙广播的示意图；

图10C为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图11为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图12为本申请实施例提供的一种蓝牙广播请求的处理方法的流程示意图；

图13为本申请实施例提供的一种芯片系统的结构示意图。

具体实施方式

在支持蓝牙功能的电子设备中，底层蓝牙硬件对外提供了启动与停止的API。然而，在调用蓝牙广播启动API到蓝牙广播启动成功之间，以及调用蓝牙广播停止API到停止成功之间，仍存在着短暂的不可用状态。

相关技术中，在上述蓝牙广播不可用状态下如果接收到蓝牙广播请求，由于当前蓝牙广播不可用，这部分蓝牙广播请求可能会被丢弃，导致部分蓝牙报文丢失的问题。

在一些实施例中，如图1所示，手机1与平板电脑2、笔记本电脑3等电子设备之间可以进行自组网，在手机1与平板电脑2、笔记本电脑3建立自组网之后，手机1可以与平板电脑2、笔记本电脑3之间同步数据。相关技术中，在建立自组网之后，手机1与平板电脑2、笔记本电脑3之间的通信，如数据同步、设备状态信息的同步等等，均可以通过蓝牙广播的方式实现。在该场景下，例如手机1需要通知自组网中其他电子设备当前手机1的设备状态信息，将会向手机1的蓝牙监视器触发蓝牙广播请求。但是如果蓝牙监视器判断当前蓝牙硬件处于不可用状态，那么该蓝牙广播请求可能会被蓝牙监视器丢弃。这样就可能导致用于广播手机1当前的设备状态信息的蓝牙广播报文丢失，从而自组网中的其他电子设备无法获取到手机1最新的设备状态信息。

如图2所示为本申请一实施例中蓝牙几种不同的蓝牙广播状态。在本申请实施例中，蓝牙广播状态包括闲置(idle)状态21、启动中(starting)状态22、广播中(broadcasting)状态23以及停止中(stopping)状态24。如图2所示，上述四种蓝牙广播状态的更新顺序，通常可以按照以下顺序更新：由闲置状态21更新为启动中状态22，由启动中状态22更新为广播中状态23，由广播中状态23更新为停止中状态24，由停止中状态24更新为闲置状态21。通常情况下，蓝牙广播需按照上述顺序更新，不可跳过其中的状态，也不可以逆序更新。

其中，蓝牙广播状态为闲置状态表示蓝牙当前没有执行任何蓝牙广播操作，处于空闲状态。在闲置状态下，蓝牙监视器可以响应于蓝牙广播请求调用蓝牙广播启动接口。

启动中状态表示当前蓝牙正在启动，即将进行蓝牙广播。在一些实施例中，可以在闲置状态下，蓝牙监视器调用蓝牙广播启动接口之后，蓝牙监视器可以将蓝牙广播状态由闲置状态更新为启动中状态。

广播中状态表示当前蓝牙正在进行蓝牙广播。在一些实施例中，在启动中状态下接收到蓝牙广播启动接口调用成功的反馈信息之后，蓝牙监视器可以将蓝牙广播状态由启动中状态更新为广播中状态。

停止中状态表示当前蓝牙广播完成，蓝牙广播正在关闭。在一些实施例中，可以在广播中状态下，蓝牙监视器调用蓝牙广播停止接口之后，蓝牙监视器可以将蓝牙广播状态由广播中状态更新为停止中状态。

进一步的，在停止中状态下蓝牙监视器如果接收到蓝牙广播停止接口调用成功的反馈信息之后，由蓝牙监视器可以将蓝牙广播状态由停止中状态更新为闲置状态。应理解，在其他实施例中，上述几种蓝牙广播状态也可以命名为其他名称。

由上述说明可知，蓝牙广播状态处于启动中状态对应的是：从蓝牙监视器调用蓝牙广播启动接口开始，直至蓝牙监视器接收到蓝牙广播启动接口调用成功的反馈信息之间的时间段。蓝牙广播状态处于停止中状态对应的是：从蓝牙监视器调用蓝牙广播停止接口开始，直至蓝牙监视器接收到蓝牙广播停止接口调用成功的反馈信息之间的时间段。蓝牙处于正常状态下，调用接口到接收到调用反馈信息之间的时间通常是比较短的。也就是说，上述启动中状态和停止中状态通常持续时间较短。如果在接收到蓝牙广播请求时，判断当前蓝牙广播状态处于上述启动中状态和停止中状态这两个不可用状态，则表示蓝牙当前还在执行上一蓝牙广播请求对应的广播操作，并且当前时刻蓝牙广播不可用。由于蓝牙广播不可用，因此新接收到的蓝牙广播请求可能会被丢弃，从而导致蓝牙报文丢失的问题。

需要说明的是，上述蓝牙广播状态是保存在蓝牙监视器中，并由蓝牙监视器来更新的。蓝牙广播不可用具体表示的是蓝牙监视器在根据蓝牙监视器中保存的蓝牙广播状态，确定当前蓝牙广播状态是不可用的。在部分场景下，例如蓝牙向蓝牙监视器反馈了调用成功信息，但蓝牙监视器未能接收到该调用成功信息，则蓝牙监视器未能及时更新蓝牙监视器中保存的蓝牙广播状态。此时，有可能出现蓝牙监视器中保存的蓝牙广播状态与实际的蓝牙广播的状态不一致的情况。

基于此，本申请实施例提供一种蓝牙广播请求的处理方法，该方法可以应用于支持蓝牙功能的电子设备；如图1所示的手机1、平板电脑2或者笔记本电脑3等等。在本申请实施例提供的蓝牙广播请求的处理方法中，在接收到蓝牙广播请求时，蓝牙监视器先获取当前的蓝牙广播状态。如果当前的蓝牙广播状态为启动中状态或者停止中状态，那么蓝牙监视器将会进入等待状态。并且，在等待状态下，蓝牙监视器持续监听来自蓝牙反馈的调用信息。基于蓝牙反馈的调用信息可以更新蓝牙监视器中保存的的蓝牙广播状态。然后当蓝牙监视器接收到蓝牙反馈的调用成功信息，将当前蓝牙广播状态更新为闲置状态或者广播中状态之后，蓝牙监视器再响应于蓝牙广播请求执行对应的蓝牙广播操作。

这样，对于当前蓝牙处于不可用状态(启动中状态或者停止中状态)下接收到的蓝牙广播请求，将会等待蓝牙广播状态更新为可用状态(闲置状态或者广播中状态)之后，再执行相应的蓝牙广播操作。避免蓝牙广播请求因蓝牙广播不可用而被丢弃，减少蓝牙广播报文丢失的情况。

在一些实施例中，上述电子设备具体可以是手机、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、穿戴设备、增强现实(augmented reality，AR)虚拟现实(virtual reality，VR)设备、媒体播放器、电视机等设备，本申请实施例对该设备的具体形态不作特殊限制。

如图3所示为本申请一实施例提供的电子设备100的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serialbus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，传感器模块180，按键190，马达191，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中，传感器模块180可以包括压力传感器180A，触摸传感器180B等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，处理器110用于执行本申请实施例中的蓝牙广播请求的处理方法。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。

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

内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)。

此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。

在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。

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

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。

电子设备100可以通过音频模块170，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信号转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。

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

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

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。

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

显示屏194用于显示图像，视频等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

摄像头193用于捕获静态图像或视频。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。

以下实施例中的蓝牙广播请求的处理方法均可以在具备上述硬件结构的电子设备100中实现。

电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。图4A是本申请实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图4A所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图4A所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

Android Runtime包括核心库和虚拟机。Android Runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

如图4B所示为本申请实施例可能涉及的部分软件架构示意图。超级来电、超级接续、超级通知以及多屏协同表示上层应用的业务模块。自发现模块用于电子设备与其他电子设备进行自发现、自组网。账户认证模块用于对进行自组网的电子设备进行账户认证。蓝牙监视器用于执行本申请实施例提供的蓝牙广播请求的处理方法。

本申请实施例提出一种蓝牙广播请求的处理方法，可以应用于相邻两个蓝牙广播请求间隔时间较近的场景。其中，在接收到在后的第一蓝牙广播请求时，蓝牙监视器已经响应于在先的第二蓝牙广播请求在进行蓝牙广播操作，并且当前蓝牙正处于启动中状态或者停止中状态。此时，对于在后的第一蓝牙广播请求而言，由于当前蓝牙广播状态处于启动中状态或者停止中状态，因此，蓝牙监视器将会进行等待状态。正常情况下，蓝牙监视器基于在先的第二蓝牙广播请求执行的蓝牙广播操作过程中，蓝牙广播状态将会持续更新。当等待到蓝牙广播状态更新到广播中状态或者闲置状态时，蓝牙监视器再响应于在后的第一蓝牙广播请求，执行相应的蓝牙广播操作。

如图5A所示为本申请实施例提供的蓝牙监视器先后接收到两个蓝牙广播请求的处理时间顺序图。在图5A所示的示例中，蓝牙监视器在蓝牙处于闲置状态下接收到第二蓝牙广播请求时，响应于该第二蓝牙广播请求将会调用底层蓝牙硬件的启动接口，并将蓝牙广播状态由闲置状态更新为启动中状态。结合上述说明可知，响应于第二蓝牙广播请求还会依次将蓝牙广播状态更新为广播中状态、停止中状态等。而在响应于第二蓝牙广播请求将蓝牙广播状态更新为启动中状态或者停止中状态时，蓝牙监视器接收到第一蓝牙广播请求，此时由于蓝牙广播不可用，蓝牙监视器无法立即响应于第一蓝牙广播请求执行相应操作。

在本申请实施例提供的蓝牙广播请求的处理方法中，若蓝牙监视器在蓝牙广播状态为启动中状态或者停止中状态下接收到第一蓝牙广播请求，针对该第一蓝牙广播请求，将会进入等待状态。并且在等待状态下，蓝牙监视器实时监听来自蓝牙反馈的调用信息。基于蓝牙反馈的调用信息可以更新蓝牙监视器中保存的蓝牙广播状态。并且在蓝牙广播状态更新为广播中状态或者闲置状态之后，蓝牙监视器可以响应于第一蓝牙广播请求执行相应的蓝牙广播操作。这样，可以避免在蓝牙广播不可用状态下接收到的蓝牙广播请求被丢弃，减少蓝牙报文丢失的可能。

如图5B所示为本申请实施例中提供的针对在闲置状态下接收到的一个蓝牙广播请求之后的执行的蓝牙广播操作的流程示意图。

S501.蓝牙监视器接收蓝牙广播请求。

在一些实施例中，蓝牙广播请求具体可以是用户触发的；例如用户希望通过蓝牙向其他电子设备传输数据时，可以触发蓝牙广播请求。在另一些实施例中，电子设备中可能设置了部分定时任务需要通过蓝牙广播来实现，在该实施例中，蓝牙监视器每隔一定时间将会接收到定时任务触发的蓝牙广播请求。应理解，在其他实施例中，蓝牙广播请求也可以通过其他方式触发。

S502.蓝牙监视器获取当前的蓝牙广播状态。

在一些实施例中，蓝牙广播状态可以存储在蓝牙监视器的存储空间中。蓝牙监视器在接收到蓝牙广播请求之后，将会获取当前时刻的蓝牙广播状态。之后将会根据蓝牙广播状态决定对于蓝牙广播请求的响应操作。

S503.若当前的蓝牙广播状态为闲置状态，则蓝牙监视器调向蓝牙发送蓝牙广播启动接口的调用请求。

可以理解的，蓝牙广播启动接口的调用请求用于请求调用蓝牙提供的广播启动接口。蓝牙接收到该调用请求后，将会启动蓝牙广播。在一些实施例中，如果当前蓝牙广播状态实际是处于广播中状态，而蓝牙监视器请求调用蓝牙广播启动接口，蓝牙将会向蓝牙监视器反馈调用出错的反馈信息。

S504.蓝牙监视器将当前的蓝牙广播状态更新为启动中状态。

S505.蓝牙响应于蓝牙广播启动接口的调用请求，启动蓝牙广播。

其中，对于S504和S505的执行先后顺序不做限定。

S506.在蓝牙成功启动之后，蓝牙向蓝牙监视器返回第一调用成功信息。

其中，第一调用成功信息用于指示蓝牙广播启动接口调用成功。

S507.蓝牙监视器在接收到第一调用成功信息之后，将当前的蓝牙广播状态由启动中状态更新为广播中状态。

S508.蓝牙监视器响应于蓝牙广播请求更新蓝牙广播报文，使蓝牙开始广播更新后的广播报文。

S509.在蓝牙广播请求对应的蓝牙广播完成时，蓝牙监视器向蓝牙发送蓝牙广播停止接口的调用请求。

应理解，蓝牙广播停止接口的调用请求用于调用蓝牙广播停止接口。蓝牙响应于该蓝牙广播停止接口的调用请求，将会停止蓝牙广播。在一些实施例中，如果当前蓝牙广播状态实际是处于关闭状态，而蓝牙监视器请求调用蓝牙广播停止接口，蓝牙可以会向蓝牙监视器反馈调用成功的反馈信息。

S510.蓝牙监视器将当前的蓝牙广播状态由广播中状态更新为停止中状态。

其中，对于S509和S510的执行先后顺序不做限定。

S511.蓝牙响应于蓝牙广播停止接口的调用请求，停止蓝牙广播。

S512.在蓝牙成功停止之后，蓝牙向蓝牙监视器发送第二调用成功信息。

其中，第二调用成功信息用于指示蓝牙广播停止接口调用成功。

S513.蓝牙监视器在接收到第二调用成功信息之后，将当前的蓝牙广播状态由停止中状态更新为闲置状态。

应理解，在S513之后，蓝牙广播状态回到闲置状态，此时如果蓝牙监视器再接收到新的蓝牙广播请求，可以按照顺序执行上述S501-S513。

以下将结合附图和实施例对本申请提供的蓝牙广播请求的处理方法进行详细说明，在以下实施例中，以电子设备是手机为例进行说明。如图6A所示，为本申请实施例提供的蓝牙广播请求的处理方法的流程示意图。该方法包括S601-S607，其中：

S601.蓝牙监视器接收第一蓝牙广播请求。

第一蓝牙广播请求用于请求通过蓝牙广播发送消息。

在一些实施例中，蓝牙广播请求对应的广播内容，具体可以包括通过蓝牙发送的数据文件(如图片、文档)，通过蓝牙广播手机当前的手机状态信息(如WiFi开关是否打开，WiFi连接的网络名称等等)。

在另一些实施例中，蓝牙广播请求也可以用于指示蓝牙监视器重启蓝牙广播。在该实施例中，在蓝牙监视器接收到这一类型的蓝牙广播请求时，如果当前蓝牙广播状态为广播中状态，则蓝牙监视器需要响应于该蓝牙广播请求调用蓝牙广播停止接口，并在蓝牙广播停止成功之后，再调用蓝牙广播启动接口，以重新启动蓝牙广播。

S602.蓝牙监视器获取蓝牙监视器中保存的当前的蓝牙广播状态。

由上述说明可知，在本申请实施例中，蓝牙广播状态保存在蓝牙监视器中，并且由蓝牙监视器对蓝牙广播状态进行更新。

S603.蓝牙监视器判断当前的蓝牙广播状态是否为第一蓝牙广播状态。

其中，第一蓝牙广播状态包括启动中状态或者停止中状态。结合图5B所示的流程可知，当前蓝牙广播状态为启动中状态或者停止中状态，具体可以表示当前蓝牙监视器在第一蓝牙广播请求之前已经接收到其他蓝牙广播请求(如第二蓝牙广播请求)。并且响应于该第二蓝牙广播请求，蓝牙监视器正在执行相应的蓝牙广播操作。

在S603之后，如果蓝牙监视器判断当前的蓝牙广播状态是第一蓝牙广播状态，则表示当前的蓝牙广播不可用,对于第一蓝牙广播请求无法立即执行相应的蓝牙广播操作。由于正常情况下，响应于第二蓝牙广播请求执行蓝牙广播操作的过程中，蓝牙广播状态会持续更新。因此，针对第一蓝牙广播请求可以等待一段时间，等待蓝牙广播状态更新为可用状态再执行第一蓝牙广播请求对应的蓝牙广播操作。

示例性的，S603的判断结果为是的情况下，具体对应表示为在图5B所示的流程中，在S504-S507之间，或者在S507-S513之间接收到第一蓝牙广播请求。

进一步的，以S603中蓝牙监视器判断当前的蓝牙广播状态是启动中状态为例，如果蓝牙以及蓝牙监视器与蓝牙之间的通信正常，那么当前时刻具体可以是蓝牙监视器响应于第二蓝牙广播请求(在先接收到的广播请求)调用了蓝牙广播启动接口，但还未接收到蓝牙反馈的调用成功信息的时候。其中，蓝牙监视器与蓝牙之间的通信正常表示蓝牙可以正常接收来自蓝牙监视器的调用请求，蓝牙监视器也可以正常接收来自蓝牙反馈的调用反馈信息。

以S603中蓝牙监视器判断当前的蓝牙广播状态是停止中状态为例，如果蓝牙以及蓝牙监视器与蓝牙之间的通信正常，那么停止中状态对应的是第二蓝牙广播请求对应的蓝牙广播完成之后，蓝牙监视器调用了蓝牙广播停止接口，且未接收到蓝牙反馈的调用成功信息的时间段。

在另一些实施例中，若上述S603的判断结果为否，则表示当前的蓝牙广播状态为闲置状态或者广播中状态。针对当前的蓝牙广播状态是闲置状态或者广播中状态的具体实施方式将在后的实施例中详细说明，在此不予赘述。

S604.蓝牙监视器进入第一等待状态。

应理解，上述S604具体表示的是针对第一蓝牙广播请求，蓝牙监视器等待一段时间。在第一等待状态下，针对蓝牙监视器在之前接收到的蓝牙广播请求(如第二蓝牙广播请求)，蓝牙监视器将会继续执行相应的蓝牙广播操作。

S605.在第一等待状态下，蓝牙监视器监听蓝牙发送的调用信息。

结合上述实施例的说明可知，在第一等待状态下，当前蓝牙监视器中保存的蓝牙广播状态为启动中状态或者停止中状态。通常情况下，蓝牙广播状态处于启动中状态表示蓝牙监视器已经响应于在先的蓝牙广播请求调用过蓝牙广播启动接口，但还未收到蓝牙反馈的调用成功信息。同样的，蓝牙广播状态处于停止中状态表示蓝牙监视器已经基于在先的蓝牙广播请求调用过蓝牙广播停止接口，但还未收到蓝牙反馈的调用成功信息。并且，通常从蓝牙监视器调用蓝牙接口至接收到蓝牙发送的调用成功信息之间的时间较短。也就是说，针对上述第一蓝牙广播请求而言，只需要等待较短的时间即可等到蓝牙广播状态更新为可用的状态，如广播中状态或者闲置状态。

也就是说，通常情况下在上述S605中，在第一等待状态下，蓝牙监视器只需等待较短的时间，即可接收到蓝牙发送的调用信息。如果接收到用于指示蓝牙广播启动接口/蓝牙广播停止接口的调用成功信息，蓝牙监视器即可将蓝牙广播状态更新为可用状态。如果出现蓝牙监视器在第一等待状态下等待较长时间，未接收到蓝牙发送的调用信息，则有可能是蓝牙出现了故障，或者蓝牙监视器与蓝牙之间的通信出现了故障。

为了避免在这种故障情况下蓝牙监视器针对第一蓝牙广播请求持续长时间的等待，可以通过对蓝牙广播状态在第一蓝牙广播状态的停留时间进行计时。一旦检测到蓝牙广播状态在第一蓝牙广播状态的停留时间超出一定时间，则判断可能出现了故障问题，需要执行相应操作。

在一些实施例中，在蓝牙监视器进入第一等待状态之后，上述方法还包括：在第一等待状态下，蓝牙监视器获取蓝牙在第一蓝牙广播状态的第一停留时间；若第一停留时间未超出第一预设时间，则蓝牙监视器维持第一等待状态。

其中，蓝牙在第一蓝牙广播状态的停留时间具体可以表示：从蓝牙广播状态从上一状态更新为当前状态的时间点开始，直至当前时刻之间的时间。示例性的，当前的蓝牙广播状态是启动中状态，蓝牙在启动中状态的停留时间包括：从蓝牙广播状态是闲置状态更新为启动中状态开始，直至当前时刻之间的时间。当前的蓝牙广播状态是停止中状态，蓝牙在停止中状态的停留时间包括：从蓝牙广播状态是广播中状态更新为停止中状态开始，直至当前时刻之间的时间。

在一些实施例中，可以在由上一蓝牙广播状态更新为当前的蓝牙广播状态的时间点开始计时，计时时间用于指示蓝牙在当前的蓝牙广播状态的停留时间。示例性的，当前的蓝牙广播状态为启动中状态时，在蓝牙监视器将蓝牙广播状态由闲置状态更新为启动中状态时开始计时。当前的蓝牙广播状态为停止中状态时，则可以在蓝牙监视器将蓝牙广播状态由广播中状态更新为停止中状态时开始计时。

在另一些实施例中，也可以直接记录由上一蓝牙广播状态更新为当前的蓝牙广播状态的时间点，如由闲置状态更新为启动中状态的时间点可以记为启动时间，由广播中状态更新为停止中状态的时间点可以记为停止时间。之后，在启动中状态下，根据当前时间与启动时间之间的时间差值，可以确定蓝牙广播状态在启动中状态的停留时间。同理，在停止中状态下，根据当前时间与停止时间之间的时间差值，可以确定蓝牙广播状态在停止中状态的停留时间。

第一预设时间可以根据实际情况进行设置。示例性的，通常蓝牙监视器在调用蓝牙广播启动接口或者蓝牙广播停止接口之后，几毫秒内即可接收到蓝牙反馈的调用成功信息。因此，在一些实施例中，上述第一预设时间可以设置为大于上述从调用接口到接收待反馈信息所需的时间；例如上述第一预设时间可以设置为50ms、100ms等等。在第一等待状态下，如果蓝牙监视器检测到蓝牙在第一蓝牙广播状态的停留时间没有超出第一预设时间的话，可以维持第一等待状态。

可以理解的，如果在第一等待状态下蓝牙监视器检测到蓝牙处于第一蓝牙广播状态的停留时间超出第一预设时间，那么判断可能出现了故障。在一些实施例中，蓝牙监视器调用蓝牙广播启动接口或者蓝牙广播停止接口之后，如果没有接收到蓝牙反馈的调用信息(调用成功信息或者调用出错信息)，有可能是蓝牙发生故障，蓝牙的接口无法正常被调用。或者，也有可能是蓝牙反馈的调用成功信息没有被传递到蓝牙监视器。

在一些实施例中，在进入第一等待状态之后，如果检测到蓝牙在第一蓝牙广播状态的停留时间超出第一预设时间，可以由蓝牙监视器直接调用蓝牙的蓝牙广播启动接口或者蓝牙广播停止接口，以更新蓝牙广播状态。

在一些实施例中，在进入第一等待状态之后，如果当前蓝牙在启动中状态的停留时间超出第一预设时间，则蓝牙监视器直接调用蓝牙广播停止接口。

由上述说明可知，蓝牙在第一蓝牙广播状态的停留时间超出一定时间可能是蓝牙反馈的调用成功信息未被传递到蓝牙监视器，或者蓝牙发生故障、蓝牙广播启动接口无法正常被调用。针对第一种情况，如果是蓝牙监视器调用蓝牙广播启动接口，蓝牙广播启动成功，只是调用成功信息没有被传递到蓝牙监视器。那么此时蓝牙实际处于启动的状态，只是蓝牙监视器由于未收到调用反馈信息而没有及时更新蓝牙广播状态。此时，蓝牙监视器调用蓝牙广播停止接口，蓝牙可以根据该调用请求停止蓝牙广播，并在蓝牙广播停止成功之后，向蓝牙监视器返回指示调用蓝牙广播停止接口成功的反馈信息。

进一步的，如果蓝牙未发生故障，在当前蓝牙在启动中状态的停留时间超出第一预设时间，蓝牙监视器调用蓝牙广播停止接口之后，蓝牙可以响应于对蓝牙广播停止接口的调用请求停止蓝牙广播，并且向蓝牙监视器反馈用于指示蓝牙广播停止接口调用成功的信息。即，蓝牙监视器将会接收到用于指示蓝牙广播停止接口调用成功的信息。在该实施例中，蓝牙监视器在调用蓝牙广播停止接口之后，可以将当前蓝牙广播状态更新为停止中状态。之后，蓝牙监视器如果接收到用于指示蓝牙广播停止接口的调用成功信息，可以将当前的蓝牙广播状态更新为闲置状态。这样，可以避免因蓝牙监视器没有接收到蓝牙反馈的调用成功信息导致蓝牙广播状态没有及时更新，而导致新接收到的蓝牙广播请求(如第一蓝牙广播请求)长时间无法进行广播的问题。

针对上述第二种情况，如果导致蓝牙在启动中状态的停留时间超出第一预设时间的原因是蓝牙广播启动接口发生故障，那么此时蓝牙实际没有启动成功，仍处于关闭状态。此时，如果蓝牙监视器调用蓝牙广播停止接口，也无法接收到蓝牙反馈的调用成功信息。

进一步的，在该实施例中，在当前蓝牙在启动中状态的停留时间超出第一预设时间，蓝牙监视器调用蓝牙广播停止接口之后，如果在一定时间内蓝牙监视器没有接收到蓝牙广播停止接口的调用反馈信息，则可以确定当前蓝牙发生故障。在一些实施例中，在确定蓝牙发生故障之后，可以生成提醒信息，用于提醒用户蓝牙发生故障。这样，可以在蓝牙可能发生故障时提醒用户，尽快采取相应措施。

与第一蓝牙广播状态是启动中状态类似的，如果第一蓝牙广播状态是停止中状态，在进入第一等待状态之后，当前蓝牙在停止中状态的停留时间超出第一预设时间，则蓝牙监视器直接调用蓝牙广播启动接口。同样的，蓝牙在停止中状态的停留时间超出第一预设时间存在两种可能的情况，即蓝牙反馈的调用成功信息未被传递到蓝牙监视器，或者蓝牙发生故障、蓝牙广播启动接口无法正常被调用。

针对第一种情况，由于蓝牙未发生故障，实际上蓝牙已经响应于在先的蓝牙广播停止接口的调用请求将蓝牙广播停止，即蓝牙广播当前是处于关闭状态的。只是蓝牙监视器未接收到用于指示蓝牙广播停止接口调用成功的反馈信息，从而没有及时更新蓝牙广播状态。也就是说，如果此时蓝牙监视器调用蓝牙广播启动接口，蓝牙响应于该调用请求可以启动蓝牙广播，之后可以向蓝牙监视器反馈用于指示蓝牙广播启动接口调用成功的信息。在该实施例中，蓝牙监视器在调用蓝牙广播启动接口之后，可以将当前蓝牙广播状态更新为启动中状态。之后，蓝牙监视器如果接收到用于指示蓝牙广播停止接口的调用成功信息，可以将当前的蓝牙广播状态更新为广播中状态。这样，可以避免因蓝牙监视器没有接收到蓝牙反馈的调用成功信息导致蓝牙广播状态没有及时更新，而导致新接收到的蓝牙广播请求(如第一蓝牙广播请求)长时间无法进行广播的问题。

针对上述第二种情况，如果当前蓝牙在停止中状态的停留时间超出第一预设时间的原因是蓝牙发生故障，那么此时蓝牙实际仍处于广播中状态。此时，如果蓝牙监视器请求调用蓝牙广播启动接口，由于蓝牙实际是处于广播中状态的，因此如果蓝牙此时接收到对应蓝牙广播启动接口的调用请求，将会产生调用出错信息。在该实施例中，蓝牙监视器在第一等待状态下调用蓝牙广播启动接口之后，如果接收到蓝牙反馈的调用出错信息，则蓝牙监视器确定蓝牙发生故障。此时，蓝牙监视器可以生成提醒信息，用于提醒用户蓝牙可能发生故障。这样，可以在蓝牙可能发生故障时提醒用户，尽快采取相应措施。

结合图5B所示的流程可知，当前的蓝牙广播状态为启动中状态时，表示蓝牙监视器已经响应于在先的蓝牙广播请求(如第二蓝牙广播请求)向蓝牙发送了蓝牙广播启动接口的调用请求。在该实施例中，上述方法还包括：在第一等待状态下，蓝牙监视器在接收到蓝牙反馈的第一调用成功信息时，将当前的蓝牙广播状态更新为广播中状态。其中，第一调用成功信息用于指示蓝牙广播启动接口调用成功。

同理，当前的蓝牙广播状态为停止中状态时，表示蓝牙监视器已经向蓝牙发送了蓝牙广播停止接口的调用请求。在该实施例中，上述方法还包括：在第一等待状态下，蓝牙监视器在接收到蓝牙反馈的第二调用成功信息时，将当前的蓝牙广播状态更新为闲置状态。其中，第二调用成功信息用于指示蓝牙广播停止接口调用成功。

S606.蓝牙监视器在接收到蓝牙发送的调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态更新为第二蓝牙广播状态。

其中，第二蓝牙广播状态包括闲置状态或者广播中状态。

如果蓝牙监视器在第一等待状态下接收到蓝牙反馈的调用成功信息，则可以将蓝牙监视器中保存的蓝牙广播状态更新为第二蓝牙广播状态。此时，表示当前蓝牙广播更新为可用状态。之后，针对第一蓝牙广播请求，可以执行相应的蓝牙广播操作。

S607.蓝牙监视器响应于第一蓝牙广播请求，执行蓝牙广播操作。

在正常情况下，蓝牙广播状态是按照图2所示的顺序更新。也就是说，在S603中如果判断蓝牙广播状态是启动中状态，那么在S607中蓝牙监视器接收到蓝牙反馈的调用成功信息，蓝牙监视器可以将蓝牙监视器中保存的蓝牙广播状态更新为广播中状态。而S603中判断蓝牙广播状态是停止中状态，在S607中蓝牙监视器接收到反馈的调用成功信息，蓝牙监视器可以将蓝牙监视器中保存的蓝牙广播状态更新为闲置状态。

结合图5B所示的流程可知，在当前的蓝牙状态为广播中状态时，蓝牙监视器响应于蓝牙广播请求可以更新蓝牙广播报文。在一些实施例中，如图6B所示，上述S606具体可以包括:

S606a.在接收到蓝牙发送的第一调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态更新为广播中状态。

进一步的，在该实施例中，请继续参照图6B，上述S607具体可以包括S607a：

S607a.蓝牙监视器响应于第一蓝牙广播请求，更新蓝牙广播报文。

其中，更新后的蓝牙广播报文用于蓝牙广播。在S607b之后，蓝牙将会广播更新后的广播报文，即第一蓝牙广播请求对应的广播内容。

在当前的蓝牙广播状态为闲置状态的情况下，蓝牙监视器响应于蓝牙广播请求可以调用蓝牙广播启动接口。在一些实施例中，如图6C所示，上述S606具体可以包括S606b：

S606b.在接收到蓝牙发送的第二调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态更新为闲置状态。

进一步的，上述S607具体可以包括S607b：

S607b.蓝牙监视器响应于第一蓝牙广播请求，向蓝牙发送蓝牙广播启动接口的调用请求。

本申请实施例提供的技术方案中，如果在蓝牙广播不可用状态(第一蓝牙广播状态)下接收到第一蓝牙广播请求，针对该第一蓝牙广播请求将会等待一段时间。等到蓝牙广播状态更新为可用状态(第二蓝牙广播状态)之后，再执行上述第一蓝牙广播请求对应的蓝牙广播操作。这样，可以避免蓝牙广播请求因当前蓝牙广播不可用而被丢弃，减少蓝牙广播报文丢失的情况。

上述实施例中在蓝牙监视器接收到第一蓝牙广播请求时，获取到的蓝牙广播状态为第一蓝牙广播状态，即启动中状态或者停止中状态。此时蓝牙广播不可用，针对第一蓝牙广播请求，蓝牙监视器需要进入等待状态。在另一些实施例中，如果在接收到第一蓝牙广播请求时，蓝牙监视器获取到当前的蓝牙广播状态并未处于第一蓝牙广播状态，即上述S603之后，蓝牙监视器判断蓝牙广播状态不是第一蓝牙广播状态。进一步的，如果当前的蓝牙广播状态为闲置状态或者广播中状态，则表示当前蓝牙可以直接使用。

以当前的蓝牙广播状态是闲置状态为例，如图7所示，若上述S603的判断结果为否，上述方法还包括S701-S707，需要说明的是，在图7所示的流程图中S603的判断结果为是时执行的流程(S604-S607)没有示出。其中：

S701.蓝牙监视器判断蓝牙广播状态是否为闲置状态。

在一些实施例中，在确定当前的蓝牙广播状态为闲置状态时，可以执行S702。需要说明的是，在图7所示的流程中，如果当前的蓝牙广播状态不属于第一蓝牙广播状态，也不是闲置状态，那么当前的蓝牙广播状态可能是广播中状态。当S701的判断结果为否，即S602中获取的当前的蓝牙广播状态为广播中状态的实施方式将在后实施例中详细说明，在此不予赘述。

S702.蓝牙监视器响应于第一蓝牙广播请求，向蓝牙发送蓝牙广播启动接口的调用请求。

结合图5B所示的流程可知，如果蓝牙未发生故障，且蓝牙与蓝牙监视器之间的通信正常，则蓝牙可以响应于调用请求将会启动蓝牙广播，如S703。

S703.蓝牙监视器将当前的蓝牙广播状态由闲置状态更新为启动中状态。

S704.蓝牙响应于蓝牙广播启动接口的调用请求，启动蓝牙广播。

应理解，本申请实施例中对于上述S703和S704的执行先后顺序不予限定。

S705.在蓝牙成功启动之后，蓝牙向蓝牙监视器返回第一调用成功信息。

其中，第一调用成功信息用于指示蓝牙广播启动接口调用成功。

S706.蓝牙监视器在接收到第一调用成功信息时，将当前的蓝牙广播状态由启动中状态更新为广播中状态。

S707.蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文。

其中，更新后的广播报文用于蓝牙进行广播。蓝牙监视器基于第一蓝牙广播请求更新蓝牙的广播报文，具体可以包括：蓝牙监视器获取第一蓝牙广播请求对应的广播报文，将蓝牙的广播报文更新为第一蓝牙广播请求对应的广播报文。其中，蓝牙更新广播报文的具体实现方式可以参照相关技术中的描述，在本申请实施例中不予赘述。

在本申请实施例提供的技术方案中，在接收到第一蓝牙广播请求时，如果当前的蓝牙广播状态是闲置状态，则表示当前蓝牙处于可用状态。此时蓝牙监视器可以直接响应第一蓝牙广播请求，调用蓝牙广播启动接口，快速的对第一蓝牙广播请求做出响应。

上述实施例中，蓝牙广播状态处于闲置状态下，则认为当前蓝牙是可用的。然而，在实际情况中，部分蓝牙在蓝牙广播状态刚刚由停止中状态更新为闲置状态的一小段时间内，蓝牙广播可能仍处于无法使用的状态。因此，在接收到第一蓝牙广播请求时检测到蓝牙广播状态是闲置状态，蓝牙监视器可以通过获取蓝牙处于闲置状态的停留时间，当在闲置状态的停留时间未达到第二预设时间时，针对第一蓝牙广播请求也需等待一段时间。

在一些实施例中，在上述S701的判断结果为是之后，在S702之前，上述方法还包括：蓝牙监视器获取蓝牙在闲置状态的第二停留时间。在该实施例中，上述S702具体可以包括：蓝牙监视器在确定第二停留时间超出第二预设时间时，向蓝牙发送蓝牙广播启动接口的调用请求。

蓝牙广播状态为闲置状态时，可以将蓝牙广播状态由停止中状态更新为闲置状态的时间点记为停止成功时间。从停止成功时间开始计时，该从停止成功时间开始的计时时间用于指示蓝牙广播状态在闲置状态的停留时间。

第二预设时间可以根据实际情况进行设置，示例性的，第二预设时间可以设置为50ms、60ms、70ms、100ms等等。

在本申请实施例提供的技术方案中，针对蓝牙广播状态刚从停止中状态更新为闲置状态的情况下接收到第一蓝牙广播请求的情况，针对第一蓝牙广播请求可以等待一段时间，再响应于第一蓝牙广播请求调用蓝牙广播启动接口。这样，可以避免蓝牙广播状态刚从停止中状态更新为闲置状态的一小段时间内蓝牙无法使用，从而导致调用蓝牙广播启动接口失败的问题。

结合图5B所示的流程可知，在S508之后，蓝牙监视器基于蓝牙广播请求更新蓝牙广播报文，使得蓝牙对蓝牙广播请求的广播内容进行广播。S509中蓝牙广播请求对应的蓝牙广播完成时，蓝牙监视器可以调用蓝牙广播停止接口，停止蓝牙广播。在一些实施例中，具体可以通过设置计时器来判断蓝牙广播请求对应的蓝牙广播是否完成。

在一些实施例中，如图8所示，在上述S702之后，上述方法还包括S801：

S801.蓝牙监视器基于第一蓝牙广播请求对应的待广播时长设置第一计时器，第一计时器开始计时。

其中，第一蓝牙广播请求对应的待广播时长表示第一蓝牙广播请求对应需要广播的内容的广播时长。可以理解的，不同蓝牙广播请求所请求的蓝牙广播内容所需要的广播时长可能不相同。

在一些实施例中，上述第一计时器可以是倒计时器，在该实施例中，第一计时器的计时时间表示的是蓝牙的剩余广播时长。应理解，蓝牙的剩余广播时长变为0则表示当前的蓝牙广播完成。上述S801具体可以包括：蓝牙监视器根据第一蓝牙广播请求确定第一蓝牙广播请求对应的待广播时长之后，将待广播时长设置为倒计时器的倒计时时长。可以理解的，倒计时时长用于指示蓝牙广播针对第一蓝牙广播请求对应的广播内容还剩余的广播时长。当倒计时器的倒计时时长变为0时，表示针对第一蓝牙广播请求的广播时长已经达到第一蓝牙广播请求所对应的待广播时长。也就是说，第一蓝牙广播请求对应的蓝牙广播完成。此时蓝牙监视器可以调用蓝牙广播停止接口，以关闭蓝牙广播。

在另一些实施例中，上述第一计时器也可以是正向计时器，在该实施例中，第一计时器的计时时间表示的是蓝牙的已广播时长。结合第一蓝牙广播请求对应的待广播时长以及第一计时器的计时时间，可以确定第一蓝牙广播请求对应的剩余广播时长。上述S801具体可以包括:蓝牙监视器确定第一蓝牙广播请求对应的待广播时长之后，第一计时器从0开始计时。若检测到计时时间达到待广播时长，即表示第一蓝牙广播请求对应的蓝牙广播完成。此时可以触发蓝牙监视器调用蓝牙广播停止接口，以关闭蓝牙广播。应理解，在该实施例中，第一计时器的计时时间用于指示蓝牙广播针对第一蓝牙广播请求对应的广播内容的已广播时长。

在一些实施例中，上述S801中的第一计时器具体可以是在S702之后立即开始计时，也可以是在S707蓝牙监视器基于第一蓝牙广播请求更新蓝牙的广播报文之后开始计时。

进一步的，在一些实施例中，在上述S707之后，上述方法还包括S802-S806，其中：

S802.在根据第一计时器的计时时间确定当前蓝牙的剩余广播时长为0时，蓝牙监视器向蓝牙发送蓝牙广播停止接口的调用请求。

由上述实施例的说明可知，第一计时器的计时时间可以用于确定蓝牙的剩余广播时长。

当确定蓝牙的剩余广播时长变为0时，表示第一蓝牙广播请求对应的蓝牙广播已完成，此时蓝牙监视器可以调用蓝牙广播停止接口，以关闭蓝牙广播，从而减少不必要的耗电。

S803.蓝牙监视器将当前的蓝牙广播状态更新为停止中状态。

S804.蓝牙响应于蓝牙广播停止接口的调用请求，停止蓝牙广播。

S805.蓝牙在蓝牙广播停止成功时，向蓝牙监视器发送第二调用成功信息。

其中，第二调用成功信息用于指示蓝牙广播停止接口调用成功。

S806.在接收到蓝牙反馈的第二调用成功信息时，蓝牙监视器将当前的蓝牙广播状态由停止中状态更新为闲置状态。

在本申请实施例提供的技术方案中，在响应于第一蓝牙广播请求开始进行蓝牙广播之后，设置第一计时器，并根据计时时间来判断当前的蓝牙广播是否完成。这样，便于蓝牙监视器在第一蓝牙广播请求对应的蓝牙广播完成之后及时调用蓝牙广播停止接口，以关闭蓝牙广播。从而可以减少没有广播时蓝牙广播开启导致不必要的耗电。

在一些实施例中，上述用于确定蓝牙广播是否完成的第一计时器可能出现失效不工作的情况。在这种情况下，第一蓝牙广播请求对应的蓝牙广播完成之后，蓝牙监视器可能不会调用蓝牙广播停止接口，从而导致蓝牙广播长时间保持在广播中状态，但没有需要蓝牙广播的内容。为了避免这种情况，可以在向蓝牙发送蓝牙广播启动接口的调用请求时，设置一个广播时长最大值。如果蓝牙监视器在蓝牙广播完成之后，没有调用蓝牙广播停止接口。蓝牙可以在蓝牙广播启动之后的累计时间达到上述广播时长最大值时，由蓝牙主动停止蓝牙广播(即关闭蓝牙广播)。

在一些实施例中，上述S702中蓝牙监视器向蓝牙发送的蓝牙广播启动接口的调用请求中携带第三预设时间。该第三预设时间用于指示蓝牙在从当前时间开始的第三预设时间对应的时间点停止蓝牙广播。

进一步的，在该实施例中，在上述S704蓝牙在启动蓝牙广播之后，蓝牙对本次累计蓝牙广播时长开始计时。在上述S704之后，当蓝牙检测到计时时长达到第三预设时间，蓝牙仍未接收到蓝牙监视器发送的蓝牙广播停止接口的调用请求时，蓝牙可以主动停止蓝牙广播。从而避免不必要的耗电。第三预设时间可以根据实际情况进行设置，例如第三预设时间可以设置为30秒(s)、40s、45s等等。

在本申请实施例提供的技术方案中，在计时器发生故障或者其他情况，导致蓝牙监视器在蓝牙广播完成之后没有及时调用蓝牙广播停止接口关闭蓝牙广播时，可以由蓝牙控制在一段时间之后主动停止蓝牙广播。这样，可以避免不必要的耗电。

上述图7-图8所示的流程中介绍了在S603的判断结果为否且当前蓝牙广播状态是闲置状态时对应的执行步骤。在S603的判断结果为否时，当前的蓝牙广播状态还有可能是处于广播中状态，即蓝牙监视器已经响应于在先的第二蓝牙广播请求调用蓝牙广播启动接口并且蓝牙广播启动成功。在该实施例中，在当前的蓝牙广播状态为广播中状态下，蓝牙监视器可以直接响应于第一蓝牙广播请求更新蓝牙的广播报文，以使蓝牙开始广播第一蓝牙广播请求对应的广播内容。

在一些实施例中，如图9所示，若上述S603的判断结果为否，上述方法还包括S900和S902，需要说明的是，在图9所示的流程中，针对S603的判断结果为是的流程(S604-S607)未示出，其中：

S900.蓝牙监视器判断蓝牙广播状态是否处于广播中状态。

如果蓝牙广播状态不属于启动中状态、停止中状态或者闲置状态，那么蓝牙广播状态可能是处于广播中状态。当判断当前的蓝牙广播状态是广播中状态之后，可以执行S902：

S902.蓝牙监视器基于第一蓝牙广播请求，更新蓝牙的广播报文。

其中，更新后的广播报文用于蓝牙进行广播。在一些实施例中，蓝牙监视器基于第一蓝牙广播请求更新蓝牙的广播报文，具体可以包括：蓝牙监视器解析第一蓝牙广播请求获得对应的待广播报文；蓝牙监视器将蓝牙广播报文更新为上述待广播报文。其中，蓝牙监视器对蓝牙广播报文进行更新的具体实现方式可以参照相关技术中的描述，在本申请实施例中不予赘述。

需要说明的是，上述S900和S902对应的技术方案也可以与图7中S701-S707的流程并列存在。在该实施例中，S603、S701以及S900的三个判断步骤可以先后进行判断，如果S603的判断结果为是，表示接收到第一蓝牙广播请求时的蓝牙广播状态为启动中状态或者停止中状态，此时可以按照S604-S607的步骤执行。如果S603的判断结果为否，可以直接执行S701，若S701的判断结果为是，则表示接收到第一蓝牙广播请求时的蓝牙广播状态为闲置状态，此时可以执行S702-S707。如果S701的判断结果为否，可以执行S900，若S900的判断结果为是，此时可以执行S902。

或者，接收到第一蓝牙广播请求之后，蓝牙监视器也可以先执行S603，确定当前的蓝牙广播状态是否为启动中状态或者停止中状态。然后在S603的判断结果为否时，先判断蓝牙广播状态是否为广播中状态(S900)，若不是再判断是否为闲置状态(S701)。或者，在接收到第一蓝牙广播请求之后，蓝牙监视器还可以先判断当前的蓝牙广播状态是否为闲置状态(S701)，若否则再判断是否为广播中状态(S900)，最后再判断是否为启动中状态或者停止中状态(S603)。即，在本申请实施例中，对于接收到的第一蓝牙广播请求时的蓝牙广播状态的判断先后顺序不予限定。

在本申请实施例提供的技术方案中，针对接收到的第一蓝牙广播请求时的蓝牙广播状态是广播中状态的情况下，表示当前蓝牙可以直接进行广播。因此蓝牙监视器可以直接响应于第一蓝牙广播请求更新蓝牙广播报文，以使蓝牙开始广播第一蓝牙广播请求对应的广播内容。这样，蓝牙广播请求可以得到快速的响应。

由上述实施例的说明可知，第一蓝牙广播请求可能用于指示蓝牙监视器重启蓝牙广播。在该实施例中，如果是在蓝牙广播状态为广播中状态时接收到第一蓝牙广播请求，由于当前蓝牙广播可用，且蓝牙广播处于广播中状态，此时，蓝牙监视器需要重启蓝牙广播。

在一些实施例中，在S900之后，在S902之前，请参照图10A，上述方法还包括S901：

S901.蓝牙监视器判断第一蓝牙广播请求对应的广播内容是否为预设周期性广播。

在一些实施例中，上述S902具体可以是在上述S901的判断结果为否时执行。

其中，预设周期性广播用于指示蓝牙监视器重启蓝牙广播。在一些实施例中，预设周期性广播是每隔预设时间间隔触发一次蓝牙广播请求。蓝牙监视器如果在蓝牙广播状态为广播中状态下接收到预设周期性广播的蓝牙广播请求，则需要重新启动蓝牙广播。应理解，在其他实施例中，预设周期性广播也可以命名为其他名称，如心跳广播。

其中，预设时间间隔可以根据实际情况进行设置。例如预设时间间隔可以设置为20s、30s、40s等等。在一些实施例中，预设周期性广播的预设时间间隔可以根据当前手机的屏幕状态进行设置。示例性的，在手机的屏幕状态为亮屏状态下，表示当前用户可能在使用手机，此时可以将预设时间间隔设置为较小的数值，如30s。而在手机的屏幕状态为息屏状态下，表示当前用户可能没有在使用手机，此时则可以将预设时间间隔设置为较大的数值，如5分钟(min)。应理解，上述预设时间间隔均为示例，在其他实施例中，预设周期性广播的预设时间间隔也可以设置为其他数值。

结合上述实施例的说明可知，在一些实施例中，蓝牙监视器在调用蓝牙广播启动接口时，设置了广播时长最大值，用于指示蓝牙在蓝牙的已广播时长达到广播时长最大值时，由蓝牙主动关闭蓝牙广播。在一些实施例中，上述预设周期性广播的预设时间间隔可以设置为小于上述广播时长最大值。如图10B所示为本申请实施例中提供的根据预设周期性广播(心跳广播)重启蓝牙广播的示意图。在一些实施例中，图10B中所示的业务广播D的广播过程中，接收到预设周期性广播的蓝牙广播请求时，业务广播D未广播完的部分将不会再继续广播，而是直接重启蓝牙广播。

在一些实施例中，蓝牙监视器响应于蓝牙广播请求可以设置计时器，该计时器的计时时间可以用于确定蓝牙广播的剩余广播时长。并且在根据计时时间确定剩余广播时长变为0时，由蓝牙监视器调用蓝牙广播停止接口，以关闭蓝牙广播。因此，如果在广播中状态接收到第一蓝牙广播请求，需要结合当前广播中状态的剩余广播时长来确定，是否适合直接在该广播中状态下直接广播第一蓝牙广播请求对应的广播内容。

具体的，在接收到第一蓝牙广播请求时检测到当前的蓝牙广播状态处于广播中状态，则表示此前蓝牙监视器已经响应于在先收到的第二蓝牙广播请求启动了蓝牙广播。这时，蓝牙广播可能正在广播第二蓝牙广播请求对应的广播内容，并且根据计时器可以确定当前蓝牙的剩余广播时长，即第二蓝牙广播请求对应的剩余广播时长。若第二蓝牙广播请求对应的剩余时长小于一定值，则表示在该广播中状态下，可能无法完整的播放第二蓝牙广播请求对应的广播内容。这时，如果要在该广播中状态下广播第一蓝牙广播请求对应的广播内容，则有可能导致第一蓝牙广播请求的广播内容无法被其他电子设备收到，从而导致报文丢失。

为了避免这种情况，可以设置广播时长最小值，在广播中状态下接收到第一蓝牙广播请求时，蓝牙监视器先根据第二计时器的计时时间确定当前蓝牙的剩余广播时长是否大于该广播时长最小值，若是则可以在该广播中状态下进行第一蓝牙广播请求对应的广播操作。若否则不在该广播中状态下进行第一蓝牙广播请求对应的广播操作。

在一些实施例中，请继续参照图10A，在S901的判断结果为否之后，在S902之前，上述方法还包括S1001：

S1001.蓝牙监视器获取蓝牙的第二计时器的计时时间。

其中，第二计时器的计时时间用于指示蓝牙的剩余广播时长。

进一步的，在该实施例中，上述S902具体可以包括S902a：

S902a.蓝牙监视器在根据第二计时器的计时时间确定当前蓝牙的剩余广播时长超出第四预设时间时，基于第一蓝牙广播请求，更新蓝牙的广播报文。

其中，第四预设时间用于指示蓝牙广播所需的广播时长最小值，广播时长最小值表示一次广播所需要的最小的时长，小于该时长则有可能蓝牙广播无法被其他电子设备接收到。需要说明的是，该第四预设时间可以根据实际情况进行设置，例如可以设置为400ms、500ms等等。

在本申请实施例提供的技术方案中，在蓝牙广播状态为广播中状态下接收到第一蓝牙广播请求时，先根据第二计时器的计时时间确定当前蓝牙的剩余广播时长是否大于一定值，只有在确定剩余广播时长大于一定值时才会在该广播中状态执行第一蓝牙广播请求对应的广播操作。这样，可以确保在当前的广播中状态下，第一蓝牙广播请求对应的广播内容能够顺利的进行广播。可以避免在当前的广播中状态下，第一蓝牙广播请求对应的广播内容开始进行蓝牙广播之后，蓝牙监视器响应于在先的第二蓝牙广播请求关闭蓝牙广播导致第一蓝牙广播请求对应的广播内容无法被其他电子设备接收到。

在另一些实施例中，如果在广播中状态下接收到第一蓝牙广播请求，但当前蓝牙的剩余广播时长小于广播时长最小值，那么针对该第一蓝牙广播请求，可以等待当前的蓝牙广播完成之后，蓝牙广播状态回到闲置状态时，再执行第一蓝牙广播请求对应的广播操作。

在一些实施例中，在S1001之后，上述方法还包括：在根据第二计时器的计时时间确定当前蓝牙的剩余广播时长未超出第四预设时间时，蓝牙监视器进入第二等待状态。在第二等待状态下，蓝牙监视器监听蓝牙反馈的调用信息。在接收到蓝牙反馈的调用成功信息之后，蓝牙监视器将当前的蓝牙广播状态更新为闲置状态，并且蓝牙监视器响应于第一蓝牙广播请求，执行蓝牙广播操作。

其中，蓝牙监视器进入第二等待状态，具体表示蓝牙监视器针对第二蓝牙广播请求进入第二等待状态。在第二等待状态下，蓝牙监视器监听蓝牙反馈的调用信息。如果蓝牙监视器接收到蓝牙反馈的调用成功信息，则可以将蓝牙监视器中保存的蓝牙广播状态更新为闲置状态。并且，由于当前的蓝牙广播状态已更新为闲置状态，此时蓝牙监视器可以执行第一蓝牙广播请求对应的蓝牙广播操作。应理解，在第二等待状态下接收到蓝牙反馈的调用成功信息，由蓝牙监视器将蓝牙监视器中保存的蓝牙广播状态更新为闲置状态之后，蓝牙监视器响应于第一蓝牙广播请求执行蓝牙广播操作的流程，可以参照上述图5B所示的流程，在此不予赘述。

需要说明的是，第一计时器与第二计时器可以是相同的计时器，也可以是不同的计时器。

在本申请实施例提供的技术方案中，如果当前的蓝牙广播状态为广播中状态，但是当前的剩余广播时长不足以满足蓝牙广播所需的最小时长(广播时长最小值)，那么针对第一蓝牙广播请求需等待当前的蓝牙广播完成，并且蓝牙广播状态更新为闲置状态之后，再执行第一蓝牙广播请求所对应的蓝牙广播操作。这样，可以使第一蓝牙广播请求对应的广播内容更有可能被其他电子设备接收到，从而提高广播效果。

在另一些实施例中，如果在蓝牙广播状态为广播中状态下接收到第一蓝牙广播请求，为了避免当前蓝牙的剩余广播时长不足以广播第一蓝牙广播请求的广播内容的问题，也可以对计时器进行更新，以增加蓝牙的剩余广播时长，从而保证在该广播中状态下能够正常的广播第一蓝牙广播请求对应的广播内容。

在一些实施例中，如图10C所示，在S902之后，上述方法还包括S1002：

S1002.蓝牙监视器基于第一蓝牙广播请求更新第三计时器的计时时间，第三计时器重新开始计时。

第三计时器的计时时间用于指示当前蓝牙的剩余广播时长。

在接收到第一蓝牙广播请求时，如果蓝牙广播状态为广播中状态，则蓝牙监视器在基于第一蓝牙广播请求更新蓝牙广播报文之后，同时还会基于第一蓝牙广播请求更新第三计时器的计时时间。

在一些实施例中，第三计时器可以是倒计时器，倒计时器的倒计时时间用于指示当前蓝牙的剩余广播时长。在该实施例中，上述1002具体可以包括：蓝牙监视器获取第一蓝牙广播请求对应的待广播时长；蓝牙监视器比较倒计时时间与待广播时长的大小。当待广播时长大于倒计时时间时，蓝牙监视器将当前倒计时器的倒计时时间，更新为第一蓝牙广播请求对应的待广播时长。当倒计时时间大于待广播时长时，蓝牙监视器对倒计时器的计时时间维持不变。

第一蓝牙广播请求对应的待广播时长表示广播第一蓝牙广播请求对应的广播内容所需的时长，如果当前蓝牙的剩余广播时长小于该第一蓝牙广播请求对应的待广播时长，那么则将倒计时器的计时时间更新为待广播时长。相反，如果当前蓝牙的剩余广播时长大于该第一蓝牙广播请求对应的待广播时长，那么对于倒计时器的计时时间不进行更新。这样，无论当前的剩余广播时长是否大于第一蓝牙广播请求对应的待广播时长，都可以确保更新之后的倒计时器的计时时长，能够完整的广播第一蓝牙广播请求对应的广播内容。

进一步的，上述S1002之后,请继续参照图10C，上述方法还包括S1003-S1007，其中：

S1003.在根据第三计时器的计时时间确定当前蓝牙的剩余广播时长为0时，蓝牙监视器向蓝牙发送蓝牙广播停止接口的调用请求。

S1004.蓝牙监视器将当前的蓝牙广播状态更新为停止中状态。

S1005.蓝牙响应于蓝牙广播停止接口的调用请求，停止蓝牙广播。

S1006.蓝牙在蓝牙广播停止成功之后，向蓝牙监视器发送第二调用成功信息。

其中，第二调用成功信息用于指示蓝牙广播停止接口调用成功。

S1007.蓝牙监视器在接收到蓝牙反馈的第二调用成功信息时，将当前的蓝牙广播状态由停止中状态更新为闲置状态。

上述S1003-S1007的具体实现过程可以参考上述实施例中的描述，在此不予赘述。

在本申请实施例提供的技术方案中，在蓝牙广播状态为广播中状态时接收到第一蓝牙广播请求时，蓝牙监视器将会在该广播中状态下执行第一蓝牙广播请求对应的广播操作的同时，更新第三计时器的计时时间。这样，可以确保在该广播中状态下能够完整的广播第一蓝牙广播请求对应的广播内容，减少蓝牙广播报文被丢失的可能。

此外，在一些实施例中，第三计时器可能出现失效的问题。第三计时器失效的情况下，当前所执行的蓝牙广播请求的蓝牙广播完成之后，蓝牙监视器不会去调用蓝牙广播停止接口，导致蓝牙广播一直处于广播中状态。为了避免这一情况，可以在确定当前的蓝牙广播请求对应的蓝牙广播完成之后计时，如果距离蓝牙广播请求对应的蓝牙广播完成之后一段时间内，蓝牙监视器未根据第三计时器的计时时间调用蓝牙广播停止接口，则蓝牙监视器可以强制停止蓝牙广播。

在一些实施例中，在S902之后，上述方法还包括：在第三计时器失效时，蓝牙监视器调用蓝牙的蓝牙广播停止接口，并将当前的蓝牙广播状态更新为停止中状态。在接收到蓝牙反馈的第二调用成功信息时，蓝牙监视器将当前的蓝牙广播状态由停止中状态更新为闲置状态。

在一些实施例中，第三计时器失效具体可以包括倒计时器的计时时间不准确。示例性的，时器的计时时间不准确可以包括：第三计时器的计时时间停止不变，第三计时器的计时时间的计时速度不准确等等。在该实施例中，蓝牙监视器一旦监测到第三计时器失效，可以立即调用蓝牙广播停止接口，以关闭蓝牙广播。

在另一些实施例中，以第三计时器为倒计时器为例，第三计时器失效也可以是倒计时器的计时时间变为0之后没有触发蓝牙监视器调用蓝牙广播停止接口，等等。在该实施例中，蓝牙监视器可以从倒计时器的计时时间变为0开始计时。如果监测到倒计时器的计时时间变为0之后的持续时间达到第五预设时间，则确定第三计时器失效。此时，蓝牙监视器可以立即调用蓝牙广播停止接口，以关闭蓝牙广播。

需要说明的是，第三计时器与第一计时器、第二计时器可以是相同的计时器，也可以是不同的计时器。

在本申请实施例提供的技术方案中，在蓝牙监视器无法在蓝牙广播完成时关闭蓝牙广播的情况下，可以在确定第三计时器失效时，由蓝牙监视器立即调用蓝牙广播停止接口，来关闭蓝牙广播。这样，可以避免当前的蓝牙广播完成之后而蓝牙广播仍长时间处于广播中状态导致不必要的耗电的问题，节约电量。

在另一些实施例中，上述S901的判断结果为是时，蓝牙监视器需要重启蓝牙广播，如图11所示，上述方法还包括S1101-S1105。需要说明的是，在图11所示的流程中，针对S901的判断结果为否时的执行流程未示出，其中：

S1101.蓝牙监视器响应于第一蓝牙广播请求，向蓝牙发送蓝牙广播停止接口的调用请求。

S1102.蓝牙监视器将蓝牙广播状态由广播中状态更新为停止中状态。

S1103.蓝牙响应于蓝牙广播停止接口的调用请求，停止蓝牙广播。

S1104.在蓝牙广播停止成功之后，蓝牙向蓝牙监视器发送第二调用成功信息。

第二调用成功信息用于指示蓝牙广播停止接口的调用成功。

S1105.蓝牙监视器在接收到第二调用成功信息之后，将蓝牙广播状态由停止中状态更新为闲置状态。

在本申请实施例提供的技术方案中，设置预设周期性广播用于指示重启蓝牙广播，即每隔一段时间就会重启蓝牙广播，避免蓝牙广播长时间连续的广播导致蓝牙可能出现的问题，如不必要的耗电等等。

此外，预设周期性广播还可以对应有实际的广播内容。在一些实施例中，预设周期性广播还用于广播手机的当前设备状态信息。其中，设备状态信息用于指示手机当前的状态；在一些实施例中，手机的设备状态信息具体可以包括手机的WiFi开关是否打开，WiFi所连接的网络名称以及WiFi网络质量等等。

在该实施例中，在S1105之后，上述方法还包括：蓝牙监视器通过调用蓝牙的接口，执行预设周期性广播对应的广播操作，以广播电子设备的当前设备状态信息。

在一些实施例中，蓝牙监视器通过调用蓝牙的接口，执行预设周期性广播对应的广播操作，以广播电子设备的当前设备状态信息，由于当前蓝牙广播状态为闲置状态，因此，蓝牙监视器执行预设周期性广播对应的广播操作的过程，可以参照图5B所示的流程执行。即，蓝牙监视器调用蓝牙广播启动接口，然后再蓝牙广播启动成功之后，将蓝牙广播报文更新为预设周期性广播对应的广播报文。从而使蓝牙广播预设周期性广播对应的广播报文内容，即手机的当前设备状态信息。

在本申请实施例提供的技术方案中，设置预设周期性广播，以每隔预设时间间隔广播手机最新的设备状态信息，这样，可以维持手机与其他电子设备之间的连接。

在一些实施例中，如图12所示，为本申请一实施例提供的蓝牙广播请求的处理方法的完整流程示意图。在该示例中，以第一预设时间、第二预设时间均设置为100ms，第四预设时间设置为500ms，第五预设时间设置为100ms为例进行说明。

示例性的，蓝牙监视器在闲置状态下接收到第二蓝牙广播请求，且第二蓝牙广播请求是预设周期性广播的广播请求。蓝牙监视器在后接收到第一蓝牙广播请求，第一蓝牙广播请求是由用户触发的WiFi开关断开(WiFi离线)的广播请求。并且，上述预设周期性广播对应的待广播时长为5s。以下对上述蓝牙广播请求的处理方法的场景进行举例说明。

蓝牙监视器响应于第二蓝牙广播请求，正在执行预设周期性广播对应的广播操作。正常情况下，响应于第二蓝牙广播请求，蓝牙广播状态会依次由闲置状态更新为启动中状态、广播中状态以及停止中状态，然后再由停止中状态更新为闲置状态。

如果在当前的蓝牙广播状态为启动中状态的情况下，蓝牙监视器接收到第一蓝牙广播请求。此时，由于当前的蓝牙广播状态为不可用的状态，则针对第一蓝牙广播请求，需进入第一等待状态。等到蓝牙监视器基于第二蓝牙广播请求将当前的蓝牙广播状态更新为广播中状态之后，再由蓝牙监视器针对第一蓝牙广播请求更新蓝牙报文，以广播WiFi开关断开的消息。

如果在当前的蓝牙广播状态为广播中状态的情况下，蓝牙监视器接收到第一蓝牙广播请求。此时，由于当前的蓝牙广播状态为广播中状态，如果检测到预设周期性广播的剩余广播时长为3s(已广播2s)，由于3s大于500ms，判断当前的剩余广播时长足够广播第一蓝牙广播请求对应的广播内容。因此此时，蓝牙监视器可以直接基于第一蓝牙广播请求更新蓝牙的广播报文，以广播第一蓝牙广播请求对应的广播内容。

如果在当前的蓝牙广播状态为停止中状态的情况下，蓝牙监视器接收到第一蓝牙广播请求。此时，由于当前的蓝牙广播状态是不可用的状态，则针对第一蓝牙广播请求，需进入第一等待状态。等到蓝牙监视器基于第二蓝牙广播请求将当前的蓝牙广播状态更新为闲置状态之后，再由蓝牙监视器针对第一蓝牙广播请求，调用蓝牙广播启动接口以启动蓝牙，并通过蓝牙广播第一蓝牙广播请求对应的广播内容。

本申请另一些实施例提供了一种计算机设备，该计算机设备可以是上述电子设备(如手机)。该计算机设备可以包括：存储器和一个或多个处理器。该存储器与处理器耦合。该存储器还用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，计算机设备可执行上述方法实施例中手机执行的各个功能或者步骤。该计算机设备是电子设备时，其结构可以参考图3所示的电子设备100的结构。

本申请实施例还提供一种芯片系统，如图13所示，该芯片系统130包括至少一个处理器1301和至少一个接口电路1302。处理器1301和接口电路1302可通过线路互联。例如，接口电路1302可用于从其它装置(例如计算机设备的存储器)接收信号。又例如，接口电路1302可用于向其它装置(例如处理器1301)发送信号。示例性的，接口电路1302可读取存储器中存储的指令，并将该指令发送给处理器1301。当指令被处理器1301执行时，可使得计算机设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当计算机指令在上述电子设备(如手机)上运行时，使得该电子设备执行上述方法实施例中手机执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行上述方法实施例中手机执行的各个功能或者步骤。其中，该计算机可以是电子设备，如手机。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。