一种数据收发方法、电子设备与计算机可读存储介质与流程

本申请涉及计算机领域，尤其涉及一种数据收发方法、电子设备与计算机可读存储介质。

背景技术：

电子设备，例如手机、智能手表、智能电视等，能够通过无线网络实现数据的接收和发送。目前，电子设备可以支持休眠状态与唤醒状态。在电子设备的数据收发过程中，电子设备可以在唤醒状态下收发数据。若经过一段固定的时长，例如200ms，电子设备无其他数据收发，则电子设备可以关闭自身的天线等无线传输模块，使得自身处于休眠状态。这种数据收发方式为电子设备提供了休眠机会，能够节省电子设备的电量和功耗，延长待机时长。其中，电子设备进入休眠状态的时机，也直接影响了电子设备节省电量和功耗的程度。

技术实现要素：

本申请提供了一种数据收发方法、电子设备与计算机可读存储介质，用以节省电子设备的电量和功耗，延长电子设备的待机时长。

第一方面，本申请提供了一种数据收发方法，在该方法中，第一设备在唤醒状态下，接收第二设备发送的第一数据，之后，响应于接收完所述第一数据，经过第一时长，所述第一设备进入休眠状态，经过第二时长，所述第一设备进入唤醒状态，之后，所述第一设备接收所述第二设备发送的第二数据，从而，响应于接收完所述第二数据，经过第三时长，所述第一设备进入休眠状态，其中，所述第一时长与所述第三时长不同。如此，第一设备在不同的数据收发情况下，可以采取不同的时长进入休眠状态，这能够为sta提供更多的休眠机会，以节省功耗。

本申请实施例中，第一时长、第二时长与第一设备的数据收发情况相关。具体而言，第一时长与所述第一设备的业务量、信号强度、共用天线占用情况、干扰情况、所述第一设备中的当前应用类型、第二设备类型中的至少一种相关联；所述第二时长与所述第一设备的业务量、信号强度、共用天线占用情况、干扰情况、所述第一设备中的当前应用类型、第二设备类型中的至少一种相关联。

示例性的，图6b所示的实施例中，当手机的前台应用发生切换，手机可以采取不同的等待时长进入休眠状态。例如，当手机当前应用为王者荣耀，则手机可以在收发数据d1(作为第一数据)后，经过时长t2，再进入休眠状态。当手机的前台应用为微信，则手机可以在收发数据d2(此时作为第二数据)后，经过时长t4，再进入休眠状态。时长t2大于时长t4，这能够保证时延敏感应用的数据收发，应用使用体验，而对于时延不太敏感的应用，则采用较短时长快速休眠，以节省手机电量和功耗，延长待机时长。

示例性的，图8所示实施例中，第一设备，如sta，可以根据当前业务量情况确定进入休眠状态前的等待时长。例如，若sta在收发完第一数据时，当前业务量较大，则第一时长可以取值较大，例如200ms；若sta在收发完第一数据时，当前业务量较小，则第一时长可以取值较小，例如100ms或60ms。第二时长也有类似设计。其中，业务量可以由sta中的wifi吞吐率与单位时间内收发报文数中的至少一种来确定。

示例性的，图9所示实施例中，第一设备，如sta，可以根据当前信号强度确定进入休眠状态前的等待时长。例如，若信号强度较高，则第一时长(或第二时长)可以取值较小；若信号强度较弱，则第一时长(或第二时长)可以取值较大。

示例性的，图10所示实施例中，第一设备，如sta，可以根据共用天线的占用情况确定进入休眠状态前的等待时长。例如，若共用天线被占用，则第一时长(或第二时长)可以取值较大；若共用天线未被占用，则第一时长(或第二时长)可以取值较小。

示例性的，图11所示实施例中，第一设备，如sta，可以根据干扰情况确定进入休眠状态前的等待时长。例如，若存在频段干扰，则第一时长(或第二时长)可以取值较大；若无频段干扰，则第一时长(或第二时长)可以取值较小。

综上，第一设备可以根据实际数据收发情况，来确定进入休眠状态的等待时长。例如，第一时长可以为时长t2，其时长可以为200ms，第二时长可以为时长t4，其时长可以为60ms或100ms。又例如，第一时长可以为时长t4，第二时长可以为时长t2。

本申请实施例中，所述第一设备进入休眠状态之前，所述第一设备发送休眠指示信息，例如p1，所述休眠指示信息用于指示所述第一设备即将进入休眠状态。例如，图8所示场景中的第一个beacon周期中，sta在经过时长t2后，sta发送p1至ap，并进入休眠状态；在第二个beacon周期中，sta经过时长t4后，也发送p1至ap，随后进入休眠状态。

当所述第一设备处于休眠状态时，所述第一设备的无线传输能力被限制。因此，当第二设备，如ap，在接收到休眠指示信息p1后，即可确定第一设备休眠。此时，所述第一设备的下行数据由所述第二设备进行缓存。

本申请实施例中，第二时长的计时起点可以为休眠指示信息p1的发送完成时刻。而第二时长的计时终点可以与信标帧(beacon帧)相关，所述信标帧由所述第二设备周期广播。

一种可能的设计中，在所述第二时长的计时终点，所述第一设备收听所述信标帧。例如，图8～图11所示场景中，sta可以在beacon帧的发送时刻醒来。

另一种可能的设计中，从所述第二时长的计时终点开始，经过第四时长，所述第一设备收听所述信标帧。例如，图13所示场景中，sta可以在收听beacon帧之前醒来。如此，在sta唤醒后，经过时长t5(作为第四时长)，sta才会收听beacon帧。

另一种可能的设计中，所述第二时长还包含至少一个所述信标帧的周期时长。例如，在图14所示的实施例中，第二时长的计时起点为第一个beacon周期中，sta发送完p1的时刻，第二时长的计时终点为第三个beacon帧的发送时刻，sta在第二个beacon周期中保持sleep状态。

在具体实现前述方案时，第一设备可以通过beacon帧的发送周期来确定beacon帧的发送时刻，而beacon帧的发送周期，可以在所述第一设备与所述第二设备连接时获取得到，如图12所示。

本申请实施例中，当所述第一设备处于唤醒状态时，所述第一设备收听所述第二设备周期发送的信标帧；所述信标帧可用于指示所述第二设备是否有为所述第一设备缓存下行数据。例如，图3所示，beacon帧可能指示有sta的缓存数据，也可能指示没有sta的缓存数据，这由实际通信场景决定。

一方面，当所述信标帧指示所述第二设备有为所述第一设备缓存的下行数据时，所述第一设备发送唤醒指示信息，如图3所示的p0，所述唤醒指示信息用于指示所述第一设备当前处于唤醒状态。如此，第二设备，例如ap，在接收到p0时即可确定sta处于唤醒状态，就可以发送缓存数据给sta。

另一方面，当所述信标帧指示所述第二设备中没有为所述第一设备缓存的下行数据时，经过第五时长，例如图3所示的时长t3，所述第一设备进入休眠状态。当无缓存数据时，第一设备可以快速休眠，以节省功耗和电量。

本申请实施例中，第一时长的计时起点为第一数据的接收完毕时刻，此时，若第一设备在唤醒状态下接收了多个数据，那么，第一数据课可以有如下设计：

一种可能的设计中，第一数据为所述第一设备最近一次接收的数据。例如，图17a所示场景的第二个beacon周期中，sta依次接收数据d7与数据d8，数据d8为最近一次接收的数据，则将数据d8作为第一数据，以接收完数据d8的时刻为计时起点，经过时长t4，sta进入休眠状态。这种实现方式中，在时长t4这段等待过程中，若有新的接收数据，还需要重新确定等待时长的起点。

另一种可能的设计中，第一数据为所述第一设备在唤醒状态下接收到的第一个数据。例如，图17b所示场景中的第二个beacon周期，sta以唤醒状态下接收到的第一个数据，也就是数据d7，作为第一数据，从而，sta是以接收完数据d8的时刻为计时起点，经过时长t4，sta进入休眠状态。这种实现方式中，在时长t4这段等待过程中，无论是否有其他收发数据，不再重新确定计时起点，而是在计时达到t4时，sta进入休眠状态。

除此之外，在本申请实施例中，当sta处于休眠状态时，sta还可以在发送上行数据时醒来。

一种实施例中，所述响应于接收完所述第二数据，经过第三时长，所述第一设备进入休眠状态之后，所述方法还包括：经过第六时长，所述第一设备进入唤醒状态；所述第一设备向所述第二设备发送第三数据；响应于发送完所述第三数据，经过第七时长，所述第一设备进入休眠状态。

示例性的，图16b示出了一种可能的情况。sta在唤醒状态下，接收数据d3(作为第一数据)，之后，等待时长t2(第一时长)后，sta发送p1并随后进入休眠状态；经过第二时长，sta在第二个beacon帧的发送时刻醒来，并接收数据d7(作为第二数据)，之后，经过时长t4(作为第三时长)，sta再度进入休眠状态。之后，本申请实施例还可以包括如下步骤：经过第六时长，sta在第三个beacon帧的发送时刻醒来，并在唤醒状态下发送数据d5(作为第三数据)，数据d5发送完成后，sta经过时长t6(作为第七时长)，sta再次进入休眠状态。

另一种实施例中，在所述经过第二时长，所述第一设备进入唤醒状态之后，且在所述第一设备接收所述第二设备发送的第二数据之前，所述方法还包括：所述第一设备向所述第二设备发送第四数据；响应于发送完所述第四数据，经过第八时长，所述第一设备进入休眠状态；经过第九时长，所述第一设备进入唤醒状态。

示例性的，图16a示出了一种可能的情况。sta在唤醒状态下，接收数据d3(作为第一数据)，之后，等待时长t2(第一时长)后，sta发送p1并随后进入休眠状态；经过第二时长，sta在第二个beacon帧的发送时刻醒来。sta在唤醒状态下，可以发送数据d5(作为第四数据)，数据d5发送完成时起，经过时长t6(作为第八时长)，sta又进入休眠状态。之后，经过第九时长，sta在接收第三个beacon帧时醒来，sta再次被唤醒。唤醒后，sta可以接收数据d7(作为第二数据)，之后，经过时长t4(作为第三时长)，sta再度进入休眠状态。之后，本申请实施例还可以包括如下步骤：经过第六时长，sta在第三个beacon帧的发送时刻醒来，并在唤醒状态下发送数据d5(作为第三数据)，数据d5发送完成后，sta经过时长t6(作为第七时长)，sta再次进入休眠状态。

此外，sta在同一个beacon周期中，可以休眠两次或以上。例如，图16c所示场景中，在第一个sta周期中，sta在接收完数据d3后，经过时长t2后，第一次进入休眠状态；之后，仍在该beacon周期中，sta在发送完数据d5后，经过时长t6后，第二次进入休眠状态。

一种可能的实施例中，所述第一设备为无线工作站sta，所述第二设备为无线访问节点ap。

另一种可能的实施例中，第一设备可以为一个sta，第二设备可以为另一个sta。

第二方面，本申请提供了一种数据收发方法，在该数据收发方法中，第一设备在唤醒状态下，向第二设备发送第五数据，并响应于发送完所述第五数据，经过第十时长，所述第一设备进入休眠状态，之后，经过第十一时长，所述第一设备进入唤醒状态，在唤醒状态下，所述第一设备向所述第二设备发送第六数据，并响应于发送完所述第六数据，经过第十二时长，所述第一设备进入休眠状态。其中，所述第十时长与所述第十二时长不同。

本申请实施例的细节部分可以参见第一方面，不作赘述。

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

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

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

第六方面，本申请还提供了一种芯片，该芯片位于第一设备中，用于与第二设备进行数据收发。例如，该芯片可以为wifi芯片。当第一设备处于休眠状态时，该芯片下电；当第一设备处于唤醒状态时，该芯片上电。在芯片上电后，即可接收和/或发送数据。

综上，本申请所提供的一种数据收发方法、电子设备与计算机可读存储介质，能够根据第一设备的实际通信情况，来选择适合当前业务情况的等待时长，如此，能够尽可能的在不影响业务使用的情况下，为第一设备进入休眠状态提供尽可能多的机会和时长，有利于节省第一设备的电量和功耗，延长待机时长。

附图说明

图1为本申请实施例所提供的一种网络系统的架构示意图；

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

图3为本申请实施例所提供的一种电子设备的数据收发过程示意图；

图4a为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图4b为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

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

图6a为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图6b为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图7为本申请实施例所提供的一种电子设备的模式切换方式的流程示意图；

图8为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图9为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图10为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图11为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图12为本申请实施例中电子设备接入无线网络的过程示意图；

图13为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图14为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图15为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图16a为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图16b为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图16c为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图17a为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图17b为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图17c为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图17d为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图18a为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图18b为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图19a为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图19b为本申请实施例所提供的另一种电子设备的数据收发过程示意图；

图20为本申请所提供的一种数据收发方法的流程示意图；

图21为本申请所提供的另一种数据收发方法的流程示意图。

具体实施方式

以下，结合附图对本实施例的实施方式进行详细描述。

首先，介绍本申请实施例涉及的系统架构。请参看图1，图1为本申请实施例所提供的一种网络系统的架构示意图。

如图1所示，该网络系统中包括访问节点(accesspoint，ap)和无线工作站(station，sta)。其中，ap，又称为无线ap(wirelessaccesspoint)、回话点或者存取桥接器，是一种无线接入设备，可供多个sta接入无线网络。ap可以几十米至上百米，可用于宽带家庭、大楼内部以及园区内部等场景内的无线接入。

示例性的，图1示出了一个家庭无线场景，在该场景中，ap可以为无线路由器，手机sta1、智能电视sta2、智能眼镜sta3等设备。ap与各sta均可以支持无线保真(wirelessfidelity，wifi)技术，sta可以与ap进行单独通信，以接入无线网络。在一些可能的实现场景中，多个sta还可以通过ap进行通信，如图1所示，手机sta1可以通过ap与智能电视sta2进行通信，从而，用户可以通过手机sta1来控制智能电视sta2实现开关机、切换频道、调节音量等功能。

实际场景中，一个网络系统中可以存在一个或多个ap，也可以存在一个或多个sta。例如，在园区的无线接入场景中，就经常在多个位置分别设置ap，如此，用户在园区内使用手机时，能够通过附近的ap接入无线网络。可以理解，当网络系统中存在多个ap时，随着用户(或手持的sta)所在的位置不同，还可能会涉及到ap的切换，不作赘述。

ap的类型可以有多种，ap可以包括但不限于：无线路由器、无线网关、无线网桥中的至少一种电子设备。

sta的类型也可以有多种，可以包括但不限于：终端设备、智能家居设备、可穿戴设备等电子设备。其中，终端设备可以包括但不限于：智能手机、笔记本电脑、平板电脑、多媒体播放器等。智能家居设备可以包括但不限于：智能电视、智能电饭煲、智能开关、智能电灯、电子投影仪、智能温控设备、智能冰箱等。可穿戴设备可以包括但不限于：智能眼镜、智能手表、智能手环、虚拟现实设备等，其中，虚拟现实设备可以包括但不限于：虚拟现实(virtualreality，vr)设备、增强现实(augmentedreality，ar)设备等。

本申请实施例中，第一设备可以为sta，第二设备可以为ap。可以理解，这不应作为本申请的技术限制，例如，另一实施例中，第一设备可以为一个sta，第二设备可以为另一个sta。

示例性的，图2示出了本申请所提供的一种电子设备的结构示意图。

电子设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universalserialbus，usb)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，传感器180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriberidentificationmodule，sim)卡接口195等。可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。图示的部件可以以硬件，软件，或软件和硬件的组合实现。

在本申请另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。例如，当sta为智能电视时，在该智能电视中，可以不设置sim卡接口195、摄像头193、按键190、受话器170b、麦克风170c、耳机接口170d、传感器模块180、充电管理模块140，电池142中的一个或多个。又例如，当sta为智能手表时，在该智能手表中，可以不设置sim卡接口195、受话器170b、麦克风170c、耳机接口170d、电池142中的一个或多个。又例如，当ap为无线路由器时，可以不在该无线路由器中设置sim卡接口195、摄像头193、按键190、受话器170b、麦克风170c、耳机接口170d、传感器模块180、充电管理模块140，电池142中的一个或多个。

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

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integratedcircuit，i2c)接口，集成电路内置音频(inter-integratedcircuitsound，i2s)接口，脉冲编码调制(pulsecodemodulation，pcm)接口，通用异步收发传输器(universalasynchronousreceiver/transmitter，uart)接口，移动产业处理器接口(mobileindustryprocessorinterface，mipi)，通用输入输出(general-purposeinput/output，gpio)接口，用户标识模块(subscriberidentitymodule，sim)接口，和/或通用串行总线(universalserialbus，usb)接口等。其中，usb接口130是符合usb标准规范的接口，具体可以是miniusb接口，microusb接口，usbtypec接口等。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可以提供应用在电子设备上的包括无线局域网(wirelesslocalareanetworks，wlan)，蓝牙，全球导航卫星系统(globalnavigationsatellitesystem，gnss)，调频(frequencymodulation，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可以包括全球卫星定位系统(globalpositioningsystem，gps)，全球导航卫星系统(globalnavigationsatellitesystem，glonass)，北斗卫星导航系统(beidounavigationsatellitesystem，bds)，准天顶卫星系统(quasi-zenithsatellitesystem，qzss)和/或星基增强系统(satellitebasedaugmentationsystems，sbas)。

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

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquidcrystaldisplay，lcd)，有机发光二极管(organiclight-emittingdiode，oled)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganiclightemittingdiode的，amoled)，柔性发光二极管(flexlight-emittingdiode，fled)，miniled，microled，micro-oled，量子点发光二极管(quantumdotlightemittingdiodes，qled)等。在一些实施例中，电子设备可以包括1个或多个显示屏194。

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

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

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(chargecoupleddevice，ccd)或互补金属氧化物半导体(complementarymetal-oxide-semiconductor，cmos)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给isp转换成数字图像信号。isp将数字图像信号输出到dsp加工处理。dsp将数字图像信号转换成标准的rgb，yuv等格式的图像信号。在一些实施例中，电子设备100可以包括1个或多个摄像头193。

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

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(movingpictureexpertsgroup，mpeg)1，mpeg2，mpeg3，mpeg4等。

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

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

内部存储器121可以用于存储一个或多个计算机程序，该一个或多个计算机程序包括指令。处理器110可以通过运行存储在内部存储器121的上述指令，从而使得电子设备执行本申请一些实施例中所提供的语音切换方法，以及各种功能应用以及数据处理等。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统；该存储程序区还可以存储一个或多个应用程序(比如图库、联系人等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如照片，联系人等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflashstorage，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的开放移动电子设备平台(openmobileterminalplatform，omtp)标准接口，还可以是美国蜂窝电信工业协会(cellulartelecommunicationsindustryassociationoftheusa，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个或多个sim卡接口。sim卡接口195可以支持nanosim卡，microsim卡，sim卡等。同一个sim卡接口195可以同时插入多张卡。所述多张卡的类型可以相同，也可以不同。sim卡接口195也可以兼容不同类型的sim卡。sim卡接口195也可以兼容外部存储卡。电子设备通过sim卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备采用esim，即：嵌入式sim卡。esim卡可以嵌在电子设备中，不能和电子设备分离。

在无线通信场景中，ap与sta均符合ieee802.11协议的规定。其中，ieee802.11协议是一种无线局域网通用的标准，它是由国际电机电子工程学会(ieee)所定义的无线网络通信的标准，其定义了媒体访问控制层(mac层)和物理层。在ieee802.11协议的支持下两个设备可以自行构建临时网络，也可以在基站(basestation，bs)或ap的协调下通信。

实际场景中，使用wifi的sta多数为便携式移动设备，便携式移动设备的电池电量有限，因此，为了节约电池电量，ieee802.11协议支持省电模式。在省电模式中，在sta通过ap接入无线网络后，当ap与sta之间没有数据传输时，sta无需收发数据，可以处于休眠状态；当ap与sta之间需要传输数据时，sta也可以主动激活或被动激活以收发数据，此时，sta处于激活状态。

激活状态，也可以称之为：唤醒状态、活动状态、wake状态或active状态。sta处于激活状态，是指sta处于ieee802.11协议所规定的激活模式(activemode)的状态。在ieee802.11协议中，也给出了具体的说明：astaoperatinginthismodeshallhaveitsreceiveractivatedcontinuously；suchstasdonotneedtointerpretthetimelementsinbeaconframes。也就是说，当sta处于激活状态时，可以使它的接收端始终处于激活状态，如此，sta不需要解析beacon帧中的tim(传输指示映射，trafficindicationmap)元素。

休眠状态，也可以称之为：睡眠状态、sleep状态。sta处于休眠状态时，sta的无线传输能力被限制。例如，sta中的无线通信器件下电或被关闭。其中，无线通信器件可以包括但不限于：wifi芯片，此外，无线通信器件还可以包括但不限于天线。当sta处于sleep状态时，wifi芯片下电，wifi芯片的数据传输功能处于关闭状态，也就是，wifi芯片的发射器(transmitter)与接收器(receiver)处于关闭状态。而当sta处于wake状态时，wifi芯片上电，可以接收和/或发送数据。

由此，电子设备进入休眠状态，可以为电子设备中的无线通信器件下电，使得电子设备处于休眠状态。类似的，电子设备进入唤醒状态，可以为电子设备的无线通信器件上电，使得电子设备处于唤醒状态。

需要说明的是，本申请实施例中，电子设备处于休眠状态时，电子设备中的无线通信器件下电，此时，电子设备中其他模块可以处于开启状态，也可以处于关闭状态。例如，电子设处于休眠状态时，蓝牙可以处于断开状态或连接状态。又例如，电子设处于休眠状态时，蜂窝移动网络可以断开或连接。又例如，电子设处于休眠状态时，手机的显示模式(或配色模式)可以为暗模式(darkmode，或称为夜间模式)。不作穷举。

由此，本申请实施例中的休眠状态可能与电子设备处于省电模式(或低耗电模式等)时的状态不同。例如，手机中设置有省电模式，当手机以省电模式运行时，手机的蜂窝移动网络、蓝牙被关闭，还可能存在其他功能被限制，例如不能接打电话，但是，手机的wifi芯片并未被限制，还能继续收发数据。那么，在本申请实施例中，手机以省电模式运行时，手机处于唤醒状态。

图3示出了一种ap向sta发送数据的场景。现结合图3所示的场景，对sta的工作状态进行说明。

为便于理解，首先对图3以及后续附图中的附图标号进行说明。本申请实施例中，w表示wake状态，s表示sleep状态，b表示beaconframe(信标帧，beacon帧)，d1以及后续涉及到的d2～d6，表示data(数据)，标号用于区分不同数据。t用于表示时长，标号用于区分。p0为唤醒指示信息，p0可以在sta醒来时发送，用于指示sta当前处于wake状态，p1为休眠指示信息，p1可以在sta进入sleep状态之前发送，用于指示sta即将进入sleep状态。

一种实施例中，p0与p1可以为powermanagement字段不同的休眠帧(nulldata)。具体的，sta处于wake状态时，sta可以向ap发送p0。例如，p0可以为powermanagement字段的指示符为0的休眠帧。当sta即将进入sleep状态时，sta可以向ap发送p1。例如，p1可以为powermanagement字段的指示符为1的休眠帧。

另一实施例中，sta处于wake状态时，sta可以向ap发送p0。例如，p0可以为ps-poll报文，该ps-poll报文用于表征sta处于wake状态。而当sta即将进入sleep状态时，sta可以向ap发送p1，p1可以为powermanagement字段的指示符为1的休眠帧。

如图3所示，ap可以周期性的对外广播beacon帧，发送周期为时长t1。在ap覆盖范围内的sta都可以收听(listen)ap发送的beacon帧。

其中，beacon帧是一种信标帧，可携带ap的多种信息，可以包括但不限于：传输指示映射(trafficindicationmap，tim)元素、beacon帧发送间隔(beaconinterval)、ap能力信息(capabilityinfo)、网络名称(ssid)、国家码及可用信道资源信息(country)、11n高速率能力集信息(例如：htcap和addhtinfo)、无线qos能力信息(例如wmm)等。其中，tim元素可以指示ap中已缓存的数据对应的sta标识。sta标识可以为sta的id号或者设备名称。

当sta处于wake状态时，可以收听(listen)ap周期发送的beacon帧。如前所述，beacon帧可用于指示ap是否有为该sta缓存下行数据，由此，sta在收听beacon帧后，即可根据beacon帧中的tim元素，确定ap中是否有为自己缓存的下行数据。为便于说明，将ap为sta缓存的下行数据简称为缓存数据。

一种可能的实施例中，对任意一个sta而言，若该sta标识为tim元素指示的sta标识中的一个，则可以确定ap存储有该sta的缓存数据；反之，若该sta标识与tim属性所指示的sta标识不匹配，则可以确定ap中没有该sta的缓存数据。例如，若ap广播的beacon帧的tim中包含sta1的id，则说明ap有sta1的缓存数据。

另一种可能的实施例中，ap广播的beacon帧中，可以包含sta标识以及每个sta是否有缓存数据的指示信息。例如，ap广播的beacon帧中，tim元素中携带的信息可以包括：sta1，有；sta2，无；sta3，有；sta4，有。其中，有表示有缓存数据，无表示没有该sta的缓存数据。此外，有缓存数据与无缓存数据还可以表示为0与1(或，1与0)，或者其他自定义标识符号，本申请对此无特别限定。

此时，如图3所示的第一个beacon周期，sta可以向ap发送p0，以通知ap自身当前处于wake状态。如此，ap在接收到该p0后，确定sta处于wake状态，可以收发数据，那么，ap就可以将为sta缓存的数据d1发送给sta，ap可以采用单播报文的方式发送数据d1至sta。此时，sta仍处于wake状态，具备收发数据的能力，接收数据d1即可。

如图3所示，sta在接收到数据d1后，wifi芯片处于载荷监听态(carriersense)。此时，sta与ap之间可以直接进行数据传输。但是，若在sta接收到数据d1后的时长t2内，sta一直没有数据的收发，则可以向ap发送p1，sta随后即进入sleep状态。其中，时长t2的计时起点，可以为sta完全接收到数据d1的时刻，也即从接收完数据d1的时刻开始计时。

ap基于接收到sta发送的p1，可以确定sta处于sleep状态。此时，sta的wifi芯片下电，数据收发能力被关闭(或被限制)，因此，这种情况下，若ap有需要传输给sta的数据，则可以由ap为该sta缓存数据。从而，若ap为sta缓存了数据，则在下一个beacon周期中，ap对外广播的beacon帧时，beacon帧中的tim元素可以指示该sta标识。

而在如图3所示的第二个beacon周期中，sta在第二beacon周期醒来，并收听ap广播的beacon帧。此时，sta根据beacon中的tim元素，确定ap中没有自己的缓存数据，sta无需接收数据，在该场景中，若sta也没有向ap发送数据的需求，则sta可以在短暂唤醒一段时长t3后，就进入sleep状态，以节省功耗。

在ap与sta的数据交互场景中，各帧的接收和发送都有一定的耗时时长，本申请对各帧的耗时时长无特别限定，图3也并未具体示出各帧的耗时时长。实际场景中，各帧收发所需要的耗时时长，由各帧的数据量、通信质量等因素决定。

具体而言，图3示出了3个时长，分别为：时长t1、时长t2、时长t3。本申请对于t1、t2和t3的具体数值无特别限定，在实际场景中，三者可以满足t1大于t2，且t1大于t3的关系。

本申请实施例中，sta唤醒并完成收发数据后，至进入sleep状态前等待的时长(简称等待时长)，例如图3所示的时长t2，是根据当前的实际通信情况确定的。

换言之，在ap与sta通信的过程中，根据当前的实际通信情况，来确定各beacon周期的等待时长。那么，对任意一个sta而言，该sta在任意一个beacon周期中都可以有一个等待时长，而任意两个becon周期的等待时长可能不同。例如，在sta与ap通信过程中，sta中的某一个beacon周期的等待时长为60ms，另一个beacon周期的等待时长为200ms。如此，每个beacon周期中的等待时长都与sta当时的通信情况相关，相对于每个beacon周期都按照固定值进行休眠的方式，本申请实施例相当于实现了等待时长的动态调整。例如，相对于每个beacon周期都按照200ms的等待时长进行休眠的方式，本申请实施例中，sta可以在部分beacon周期或全部beacon周期中，采用60ms的等待时长进行休眠，这有利于在保证sta的业务能够正常进行的前提下，增加sta休眠的机会和时长，从而，增加了无线通信器件下电以节省功耗的机会和时长，有利于节省sta的功耗，延长sta的待机时长。

本申请对预设的休眠状态的数目、等待时长的数目、等待时长的数值无特别限定，可根据场景需要自定义预设。示例性的一种实现场景中，时长t2可以为200ms。示例性的，时长t4还可以为60ms。另一示例性的，时长t4的范围可以为60～100ms。示例性的另一种场景中，时长t2可以为300ms，时长t4可以为200ms。示例性的另一种场景中，时长t2可以为300ms，时长t4可以为60ms。实际场景中，根据sta的实际通信情况来自定义设计等待时长即可。

具体的，可以从ap与sta传输的数据类型(sta中的当前应用类型)、ap类型、wifi业务量情况、sta信号强弱情况、共用天线的占用情况、干扰情况中的至少一个方面，来动态调整每个beacon周期的等待时长。如此，能够在保证sta的业务正常进行的前提下，尽可能的增加wifi芯片等无线通信器件休眠的机会和时长，以节省sta的功耗。

可以根据ap与sta传输的数据类型(或数据所对应的应用程序的类型)，来调整各beacon周期的等待时长。一般情况下，ap发送给sta的数据，可以为sta的当前应用的数据。因此，可以根据sta当前应用的类型，来确定等待时长。

示例性的，图4a与图4b示出了一种ap向sta发送数据的场景。如图4a与图4b所示，ap仍按照前述方式为sta缓存数据。随着时间的发展，用户将sta的前台应用进行了切换，由第一应用切换为第二应用。如此，ap在第一个beacon周期为sta缓存的数据d1为第一应用的数据，ap在第二个beacon周期为sta缓存的数据d2为第二应用的数据。

第一应用可以为时延敏感应用(应用程序，application，app)。例如游戏应用，如王者荣耀；又例如，投屏应用(用于将手机中的视频实时传输投放在显示屏上的app)。这些app的数据对时延比较敏感。例如，若用户在用手机玩王者荣耀，则若手机无法及时接收数据，就可能会导致游戏卡顿或操作失误等问题，影响用户操控体验。因此，针对这一类应用，可以采用较长的等待时长来进入sleep状态，以便于sta可以较长时间处于wake状态，能够及时收发消息，尽量避免对当前应用的使用造成不利影响。

相应地，第二应用可以为非时延敏感应用。例如聊天app，如微信、qq、微博等；又例如，资讯类app，如知乎、头条等；又例如，购物app，如淘宝、大众点评、京东等。这些应用的数据对时延的要求较低，因此，可以采取较短的等待时长来进入sleep状态，以便于节省sta的功耗。

图4a示出了这种场景下的一种可能的实施例。

在第一个beacon周期中，ap收听beacon帧，并向ap发送p0。如此，ap接收到p0，确定sta处于wake状态，则将为其缓存的数据d1发送给sta。sta接收数据d1，若数据d1对应的app对时延比较敏感，那么，sta在接收完数据d1后，可以等待时长t2，以及，在该时长t2内，若sta一直无其他收发数据，则sta向ap发送p1，并由wake状态转入sleep状态，wifi芯片下电。

在第二个beacon周期中，ap收听beacon帧，并向ap发送p0。如此，ap接收到p0，确定sta处于wake状态，则将为其缓存的数据d2发送给sta。sta接收数据d2，若数据d2对应的app对时延不太敏感，那么，sta在接收完数据d2后，等待较短的时长t4，以及，在该时长t4内，若sta一直无其他收发数据，则sta向ap发送p1，并由wake状态转入sleep状态，wifi芯片下电。

举例说明。若sta为手机，手机通过路由器(作为ap)接入wifi。

在图4a所示的第一个beacon周期中，手机的当前应用可能为王者荣耀。如前所述，王者荣耀这种即时游戏类app对时延较为敏感，因此，可作为第一应用，按照如图4a所示的第一个beacon周期的方式进行休眠。也就是，手机在接收路由器转发的数据d1后，由于数据d1为王者荣耀的数据，对时延要求较高，那么，手机在接收完数据d1后，可以等待较长的时长t2，例如200ms。在该过程中，手机处于wake状态，可以及时接收或发送数据，能够在一定程度上降低游戏卡顿与操作失误的发生几率。若手机在200ms内无其他收发数据，wifi芯片下电，手机处于sleep状态。在该过程中，采用较长的等待时长进行休眠，保证了王者荣耀数据能够及时收发，尽量降低休眠对游戏体验的不良影响。

之后，用户切换了手机的当前应用，关闭或暂停了王者荣耀，并打开了微信与朋友聊天。

此时，在第二个beacon周期中，手机的当前应用为微信，而微信数据的时延的要求较低，可以采用较长的时长t4进行休眠，例如，t4可以为60ms。如此，手机在接收路由器转发的数据2，数据d2为微信数据，对时延的要求较低，则手机在接收完数据d2后，可以等待60ms。若在60ms内，手机无其他收发数据，则wifi芯片下电，手机处于sleep状态。在该过程中，采用较短的等待时长进行休眠，在保证用户能够使用微信正常聊天通信的前提下，尽可能的延长了手机处于sleep状态的时长，有利于降低手机功耗，延长手机的待机时长。

此外，另一种实施例中，当手机的前台应用为王者荣耀时，为了尽可能的保证这种即时游戏数据的及时收发，还可以进一步将其等待时长设置的较长。例如，手机在接收完数据d1后，可以等待300ms，而当手机的当前应用为普通应用时，例如微信，则可以等待200ms。也就是，延长对时延敏感应用的等待时长。

此外，另一种实施例中，还可以将app划分为至少两个类别，每个类别对应一个固定的等待时长。例如，可以根据app对时延的敏感程度，将手机中的app划分为三个类别：时延敏感应用，例如王者荣耀；普通应用，例如微信；时延不敏感应用，例如掌阅阅读。从而，时延敏感应用可以采用400ms进行休眠；而普通应用可以采用200ms进行休眠；时延不敏感应用可以采用60ms进行休眠。实际场景中，还可以为各类别添加相应的标识，以便于根据标识来确定手机所要采用的等待时长。该举例仅为示意性的，不应构成具体的数值或方式限定。

图4b示出了这种场景下的另一种可能的实施例。

在第一个beacon周期中，ap收听beacon帧，并向ap发送p0。如此，ap接收到p0，确定sta处于wake状态，则将为其缓存的数据d1发送给sta。sta接收数据d1，由于数据d1对应的app对时延比较敏感，因此，sta在接收完数据d1后，在该beacon周期中可以不休眠。如图4b所示，sta在第一个beacon周期中持续处于wake状态。

在第二个beacon周期中，ap收听beacon帧，并向ap发送p0。如此，ap接收到p0，确定sta处于wake状态，则将为其缓存的数据d2发送给sta。sta接收数据d2，由于数据d2对应的app对时延不太敏感，因此，sta在接收完数据d2后，可以等待一段时长，若在等待时长内，sta一直无其他收发数据，则sta向ap发送p1，并由wake状态转入sleep状态，wifi芯片下电。这种场景下，等待时长可以有不同设计，例如，可以如图4b所示的等待时长t4，又例如，还可以等待时长t2(图4b未示出)。后续详述。

这种情况可能是由于等待时长较长造成的，也有可能是由于sta的当前应用对时延敏感而特别设计的。仍以前述手机与路由器之间的数据交互为例。在第一个beacon周期，用户用手机玩王者荣耀，由于王者荣耀对时延比较敏感，则可以一直保持wifi芯片上电，使得手机由良好的收发数据能力；而在第二个beacon周期，用户用微信与他人聊天或浏览公众号推送消息，对时延的要求较低，因此，在wake状态下等待了一段时长，例如200ms，又例如60ms，若在该等待时长内一直无数据交互，则sta可向ap发送p，并进行休眠。

在前述方案的设计中，sta可以基于接收到的数据对应的app是否对时延敏感，来采取如图4a或图4b所示的不同的休眠策略。

一种实施例中，app是否对时延敏感，可以由app的类型来确定。例如，前述实施例中，若手机的当前应用为即时游戏类app，或为投屏类app，则可以认为该app对时延敏感，按照图4a或4b中的第一应用所示方式进行处理；反之，若手机的当前应用为聊天类或阅读类app，则可认为手机当前应用对时延要求较低，按照如图4a或图4b所示的第二应用所示方式进行处理。

除此之外，另一种实施例中，还可以在sta中预设app列表，该app列表中的app即为对时延敏感的app，不在该列表中的app则可视作对时延不太敏感的app。例如，该app列表可以为图5所示的极速模式下的应用列表。

具体实现时，app列表可以为电子设备出厂时的默认设置。

或者，app列表还可以在电子设备出厂时作默认设置，并在电子设备后续使用过程中，通过网络或其他通信手段，如蓝牙等，对该app列表进行更新。例如，手机出厂时预设的app列表只有王者荣耀；随着时间推移，还可以将该app列表更新为：王者荣耀与腾讯视频；或者，将该app列表更新为：忍者必须死。也即，在更新预设app列表时，更新后的app列表可以包含本次更新之前的app，或者，也可以删掉之前的app。

或者，app列表还可以在电子设备出厂时作默认设置，并可以由用户进一步对该默认设置作个性化配置。例如，手机出厂时预设的app列表只有王者荣耀，用户可以在该app列表中增加其他app，也可以将王者荣耀从该预设app列表中删除，可根据用户需求自定义更改app列表的配置。又例如，手机出厂时预设的app列表只有王者荣耀，用户可以在该app列表中增加其他app，但不可以将王者荣耀从该预设app列表中删除，换言之，手机出厂时预设的app列表中的预设应用还可以被配置为不可被用户删除。

或者，预设app列表也可以完全由用户手动配置。此时，预设的app列表在出厂时默认为空，后续也不会由系统或开发者对其更新，而是完全由用户手动添加或删除应用。

以手机为例，图5示出了一种用户手动设置该app列表的设置方式。

图5所示的a界面为一种手机桌面的示意图，该手机桌面上可以显示各种app的图标，用户可以点击任意app图标以进入相应应用，由相应应用为用户提供服务。若用户点击a界面上的设置图标501，则手机呈现如图5所示的b界面。图5所示b界面为手机的设置主界面，用户可以在b界面上进行点击，以实现对手机的设置。如图5所示，用户可以点击虚拟按键502，即可在对无线局域网作进一步设置，此时，手机呈现如图5所示的c界面。在图5所示的c界面上，用户可以通过点击虚拟按键503，来开启或关闭无线局域网(wlan)。在c界面上，无线局域网被开启，此时，在c界面上显示网络列表504，网络列表504显示各无线网络的名称和信号强度(右侧符号)，用户可以点击网络列表504中的任意一个以进行无线连接。除此之外，用户还可以通过点击虚拟按键504还设置可使用无线局域网的app。此外，在c界面上还显示了“极速模式”对应的虚拟按键506，用户可以点击虚拟按键506以进入极速模式下应用的设置界面(d界面)。并且，d界面上还可以进一步对极速模式进行说明，“以下应用，将优先保证wifi通信质量，这可能会引起您的手机耗电增加。”在d界面上，设置有虚拟按键507，用户可以通过点击虚拟按键507来对手机中安装的app进行选择，并将选中的app显示在极速模式下的app列表里。如图5所示，在该d界面上已经显示了极速模式下的app列表，此时，该app列表中包含4个用户选中的应用，每个应用的右侧还对应显示有删除按钮508，用户可以点击删除按钮508，来将对应app移除极速模式应用列表。基于此，用户可以根据个人喜好或需要来添加极速模式对应的应用。

需要说明的是，如图5所示的极速模式对应的app列表，在用户自定义添加该app列表时，添加的应用可以为对时延敏感的第一应用，也可以为对时延要求较低的应用。换言之，用户手动建立的极速模式app列表具备更高的灵活性，满足用户对自己手机的自定义设置需求。

在这种场景中，可以将极速模式app列表中的应用作为第一应用，例如，华为投屏位于图5所示的d界面上应用列表中的应用，则将华为投屏作为第一应用，采取如图4a的第一个beacon周期所示的方式，以较长的等待时长进行休眠；或者，采取如图4b的第一个beacon周期所示的方式，在该beacon周期内不休眠，手机持续处于wake状态。而不处于该app列表中的其他应用，例如，网易云音乐并不是如图5所示的d界面上的应用，则可以将网易云音乐作为第二应用，采取如图4a或图4b所示的第二个beacon周期所示的方式，进行休眠，以节省功耗。

本申请实施例中，可以根据ap的类型，来动态调整进入sleep状态前的等待时长。

示例性的，图6a示出了另一种ap向sta发送数据的场景。如图6所示，第一ap与第二ap都可以与sta进行数据交互，第一ap与第二ap不同。当sta接入的ap不同时，sta的接入网状态也可能发生变化。

例如，在一个家庭通信场景中，手机作为sta。第一ap可以为电视，手机可以接入电视，并控制电视播放节目或其他功能，此时，手机与电视处于一个局部无线网络环境中，与外部网络无数据交互，sta甚至可以断开与外部网络的连接。第二ap可以为路由器，手机可以接入路由器，从而连接外部网络，则用户可以通过手机与远在千里之外的朋友进行聊天，手机通过路由器与外部网络设备存在数据交互。

如此，sta在接收到第一ap发送的数据d1后，sta等待时长t2，若sta在时长t2范围内无数据收发，则sta由wake状态转变为sleep状态。若sta接收到第二ap发送的数据d2，则sta可以等待时长t4，若sta在时长t4范围内无数据收发，则sta进入sleep状态。

除此之外的另一种实现场景中，若sta接收到第一ap发送的数据，还可以采取与图4b类似的方式，在第一ap对应的beacon周期中不进行休眠，持续保持wake状态，直至下一个beacon周期，再根据ap类型、sta当前应用类型等，来确定是否休眠和如何休眠。不作赘述。

在图6a的一种可能的设计中，接入第一ap的sta不休眠，或者，可以采用较长的等待时长休眠。例如，接入电视的手机，可以不休眠，手机的wifi芯片持续处于上电状态，以保证可以随时与电视进行数据交互；或者，接入电视的手机，可以采用较长的200ms的等待时长，进行休眠。接入第二ap的sta则可以采用较短的等待时长进行休眠，或者，也可以采用较长的等待时长休眠，或者，也可以不休眠。例如，接入路由器的手机，若当前应用为王者荣耀时，可以不休眠，也可以采用200ms的等待时长进行休眠；若当前应用为微信时，可以采用60ms的等待时长进行休眠。

举例说明。一种可能的实施例中，若sta接入了第一ap，例如电视，且当前sta的当前应用为第一应用，例如王者荣耀，则sta可以不休眠，直至sta的当前应用发生切换；后来，sta的当前应用由第一应用切换为第二应用，例如，切换为微博，则sta可以采用较长的时长，例如200ms，进行休眠。或者，若sta接入了第二ap，例如路由器，且当前sta的当前应用为第一应用，例如王者荣耀，则sta可以采用200ms进行休眠；后来，sta的当前应用由第一应用切换为第二应用，例如，切换为微博，则sta可以采用60ms进行休眠。

一种可能的网络场景中，可以预先在sta中设置“ap列表”，其中，当sta接入该ap列表中的ap时，sta不休眠，或者，以较长的等待时长进行休眠。换言之，ap列表可以由一个或多个第一ap构成。如此，在ap与sta进行数据交互时，sta可以获取到当前数据交互的关联ap的标识，从而，将关联ap的标识与ap列表进行比对。若关联ap(也即，sta当前接入的ap)的标识在ap列表中，则该sta接入第一ap，那么，该sta可以利用时长t2进行休眠或者不休眠；若关联ap的标识不在ap列表中，则该sta接入第二ap，可以利用时长t4或时长t2进行休眠。这种实现方式中，需要在sta中预设ap列表，在sta中设置ap列表的工作量较大，但确定等待时长的方式便捷高效。

另一种可能的网络场景中，sta自身可以根据与ap的通信情况，以确定ap属于第一ap还是第二ap。示例性的，sta可以对曾经接入过的ap的历史传输数据，对于任意一个曾关联过的ap，可以获取sta与该ap之间的收包成功率、发包成功率、传输效率、wifi信号强度、接入频率、数据传输量中的至少一种，将这些数据进行数字化处理，得到ap的分值。ap的分值可用于表征ap与sta之间的数据传输能力。从而，ap的分值越高，ap的数据传输能力越好，数据传输的效率越高，则可以采用较短的等待时长进行休眠；反之，ap的分值越低，则ap的数据传输能力可能较差，那么，若数据传输失败，由于较长的等待时长，sta还处于wake状态，能够尽快请求ap重新传输数据，避免sta很快进入sleep状态后，要等待很长时间才能够重新获取传输失败数据的情况。因此，可以采用较长的等待时长以进行休眠，或者不休眠。基于此，可以将ap的分值与预设分数阈值进行比较，若ap的分值大于预设分数阈值，可以在sta中将该ap标识为第二ap；反之，则将该ap标识为第一ap。由此，sta也可以基于该方式，将第一ap记录在一个固定存储位置，形成“ap列表”，不赘述。这种场景中，sta可以根据历史传输数据，自动区分ap类型，不需要提前预设sta中的ap列表，降低了人工维护ap列表的工作量。

另一种可能的网络场景中，在ap与sta初次连接时，ap可以把自己的ap类型发送给sta，以便于sta可以在接入该ap时，能够根据ap类型来采取不同的休眠方式。

采用快速休眠模式快速进入sleep状态，以节省sta的功耗，延长其待机时长。

如图4a、图4b所示的实现方式与图6a所示实现方式，可以独立实施；或者，也可以结合实施。

示例性的，可以参考图6b，图6b示出了另一种ap向sta发送数据的场景。在该实现场景中，手机通过路由器接入无线网络，此时路由器不是预设的ap列表中的ap，手机可以采用t2或t4进行休眠。如图6b所示的第一个beacon周期中，路由器为手机缓存了王者荣耀的游戏数据d1，数据d1对时延要求较高，可以采用较长的等待时长t2进行休眠。而在图6b所示的第二beacon周期中，路由器为手机缓存了微信数据d2，微信数据d2对时延的要求较低，可以采用较短的等待时长t4快速进入睡眠，以节省手机功耗，延长手机待机时长。

综上所述，ap类型、ap与sta传输的数据类型，与sta进行休眠的方式相关联。因此，在具体实现本方案时，可以根据ap类型、ap与sta传输的数据类型，来确定是否可以快速休眠。

本申请实施例中，根据等待时长的不同，也可以设置不同的休眠模式，进而，来动态调整sta的休眠模式。

一种可能的实现场景中，可以设置两个等待时长：时长t2(例如200ms)和时长t4(例如60ms)，由此，采用200ms进行休眠的模式可称为第一休眠模式，也可以称为普通休眠模式，采用60ms进行休眠的模式可称为第二休眠模式，也可以称为快速休眠模式。

另一种可能的实现场景中，第一休眠模式为普通休眠模式，采用时长t1(beacon周期时长)进行休眠，则在任意一个beacon周期，sta都处于wake状态，sta不休眠。第二休眠模式可以为快速休眠模式，采用60ms的等待时长进行休眠。

另一种可能的实现场景中，第一休眠模式为普通休眠模式，可以包含两种休眠策略：采用200ms的等待时长进行休眠或者不休眠；第二休眠模式为快速休眠模式，可以包含至少一个等待时长，例如，可以采用60ms的等待时长进行休眠，或者，还可以采用100ms的等待时长进行休眠。

如前所述，本申请实施例对休眠模式的划分规则无特别限制。

sta采取何种休眠模式，可以由ap类型与sta当前应用的类型，来实时判断并确定。

示例性的，图7示出了一种快速休眠模式的开启和关闭策略。图7是以sta具备快速休眠模式(60ms)与普通休眠模式(200ms)为例示出的。

如图7所示，当发生s702、s704、s706中任意的一种情况时，就可以执行s708～s716的判断，进而来确定是否开启或关闭快速休眠模式。

s702，sta成功接入网络，或者，sta断开网络连接。

也就是，sta的接入网状态发生变化。若sta的接入网状态发生了s702示出的任意一种变化，都可以直接执行后续s708～s716的判断处理。

s704，关联ap接入网络状态发生变化。

也就是，sta通过关联ap接入无线网络，sta的关联ap的接入网状态发生变化，包括：关联ap断开网络连接，或者，关联ap成功接入网络。可以理解，若关联ap断开网络连接，sta也无法通过该关联ap接入无线网络，则可能会发生sta断开网络连接的情况，也可能会发生切换网络的情况。

例如，若手机当前通过路由器1接入无线网络1，但路由器1发生故障或其他情况，断开了网络连接，则手机可以断开该无线网络1，并通过路由器2接入无线网络2。此时，sta的关联ap发生变化。如图5所示，sta也可以基于关联ap的类型来确定采取何种休眠模式。

除此之外，sta接入的ap不同，sta的接入网状态也可以存在区别。例如，手机接入路由器，可以与外部网络进行通信连接；若手机接入电视，则可以实现手机与电视之间局部网络传输。

s706，sta前台切换应用。

此时，sta当前应用发生切换，ap与sta之间交互的数据发生变化。例如，图7所示的网络场景中，手机的当前应用由王者荣耀切换为微信时，就可以执行s08～s716的判断，以确定是否满足开启快速休眠模式的条件。

换言之，sta可以保持对s702～s706中所涉及事件的监听，从而，当监听到前述事件发生时，就执行s08～s716的判断。

如图7所示，当s708～s716中的任意一项的判断结果为“否”时，就执行s720，关闭快速休眠模式；当s708～s716的判断结果均为“是”时，就执行s718，开启快速休眠模式。可以理解，图7为示例性的一种实现流程，本申请实施例对于s708～s716的执行次序无特别限定，可以任意次序颠倒执行，或者，还可以全部或部分判断步骤并行执行。

s708，sta的关联ap是否可以接入网络。

如前所述，sta的关联ap可以接入网络，sta才可以接入无线网络。因此，可以将关联ap成功接入网络，作为开启快速休眠模式的前提条件之一。

s710，时长t1是否小于预设的周期阈值。

周期阈值可以根据需要预设。示例性的，周期阈值可以为100ms。

也就是，判断sta的关联ap发送beacon帧的周期时长是否较小。若时长t1较小(例如，小于100ms)，则在一个beacon周期中，sta接收数据之后到下一个beacon帧的发送时刻，可能还小于预设的等待时长，那么，sta可能就会持续处于wake状态，或者，处于sleep状态的时长较短、次数较少，对sta的功耗较大。因此，当ap发送beacon帧的周期时长较短时，就可以开启快速休眠模式，以便于sta可以以更短的等待时长进入sleep状态，从而，增加sta处于sleep状态的时长和次数，以节省功耗。

基于此，可以将时长小于预设的周期阈值，作为开启快速休眠模式的前提条件之一。

s712，sta的当前应用是否为非时延敏感应用。

若sta的当前应用对时延敏感，则需要较长的等待时长，采取普通休眠模式更有利于数据的及时收发。

反之，若sta的当前应用对时延不太敏感，则可以适当缩短等待时长，因此，可以开启快速休眠模式，使sta快速进入sleep状态，节省功耗。

s714，sta的当前应用是否不在预设的app列表。

若sta的当前应用在预设app列表上，sta不休眠或等待较长时间再休眠，则无需开启快速休眠模式，直接以普通休眠模式进行休眠即可。

反之，若sta的当前应用不是该预设的app列表中的应用，则可以开启快速休眠模式。

s716，ap是否不在预设的ap列表。

若ap在预设ap列表中，则接入该ap的sta不休眠，或者，等待较长时间再休眠，也无需开启快速休眠模式；反之，则可以开启快速休眠模式。

s718，开启快速休眠模式。

一种实施例中，开启快速休眠模式，是指sta可以利用较短的等待时长，如60ms进行休眠，此时，sta也可以利用200ms进行休眠，对于sta而言，相当于多了一个可能性。

在这种情况下，sta具体采用的等待时长是多少，还可以根据wifi业务量情况、sta信号强弱情况、共用天线的占用情况、频段干扰情况中的至少一个方面，来作进一步确定。

另一种实施例中，开启快速休眠模式，是指sta无需再作进一步判断，可以直接利用60ms进行休眠，不再有200ms的可能性。相应的，在快速休眠模式关闭时，采用200ms进行休眠。

s720，关闭快速休眠模式。

在该实施例中，快速休眠模式被关闭，则sta采用200ms进行休眠。

在具体实现场景中，前述s708～s716中任意一个的判断结果为“否”，就可以不再进行后续判断，而直接关闭快速休眠模式。若s708～s716中任意一个的判断结果为“否”，并且，此时sta的快速休眠模式刚好处于关闭状态，则无需重复关闭。

除前述提及的ap类型、与sta当前应用的类型之外，本申请实施例还可以根据wifi业务量情况、sta信号强弱情况、共用天线的占用情况、频段干扰情况中的至少一个方面，来确定sta如何休眠。

一方面，可以根据sta的wifi业务量，来确定sta的等待时长。

示例性的，可以参考图8，图8示出了另一种ap向sta发送数据的场景。

在图8的第一个beacon周期中，sta在收听beacon帧时处于wake状态，并收听beacon确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，如此，sta接收ap发送的数据d3。此时，wifi的业务量较大，就会有很多业务的数据需要收发，可能还会包含很多对实时性要求较高的数据，这种情况下，sta可以采用较长的等待时长进行休眠，以保证业务的实时传递。也就是，sta在接收完数据d3后，sta等待时长t2，例如200ms，若在该时长t2内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态，wifi芯片下电。

在图8的第二个beacon周期中，sta由sleep状态转为wake状态，wifi芯片上电，sta具备收发能力。此时，sta可以收听ap广播的beacon帧，并由此确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，之后，sta接收ap发送的数据d4。此时，sta的wifi业务量较小，sta的收发效率较高，可以采用较短的时长t4，例如60ms，进行休眠，从而，sta可以快速休眠，且不会对实际业务造成过大干扰。

一种可能的实施例中，wifi的业务量是否较大，可以由sta中wifi的吞吐率来确定。可以获取sta中wifi业务的吞吐率，若该吞吐率小于预设的吞吐阈值，则确定wifi的业务量较小；反之，若wifi业务的吞吐率大于或等于该吞吐阈值，则确定wifi的业务量较大。sta中wifi业务的吞吐率可以由wifi芯片统计得到。示例性的，吞吐阈值可以预设为10mbps。

另一种可能的实施例中，wifi的业务量是否较大，还可以通过单位时间内收发报文数来确定。也就是，若sta在单位时间内收发报文数小于预设的数目阈值，则确定wifi的业务量较小；反之，若sta在单位时间内收发报文数大于或等于预设的数目阈值，则确定wifi的业务量较大。

另一方面，还可以根据sta信号强度，来确定采取sta的等待时长。

示例性的，可以参考图9，图9示出了另一种ap向sta发送数据的场景。

在图9的第一个beacon周期中，sta在收听beacon帧时处于wake状态，并收听beacon确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，如此，sta接收ap发送的数据d3。此时，sta的信号强度小于预设的强度阈值，那么，sta收发报文的成功率可能较低，这种情况下，可以采用较长的等待时长进行休眠。也就是，sta在接收完数据d3后，sta等待时长t2，例如200ms，若在该时长t2内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态。

在图9的第二个beacon周期中，sta醒来，并在wake状态下收听beacon帧。由此，当由beacon帧确定ap有为自己缓存数据时，sta发送p0，告知ap自己当前处于wake状态。之后，ap发送数据d4，sta接收ap发送的数据d4。数据d4传输完成时，sta的信号强度大于或等于预设的强度阈值，那么，sta收发报文的成功率可能较高，这种情况下，可以采用较短的等待时长进行休眠。也就是，sta在接收完数据d4时，sta等待时长t4，例如60ms，若在该时长t4内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态。

本申请实施例中，sta信号可以具体为：接收信号的强度指示(receivedsignalstrengthindication，rssi)。该数据也可以由wifi芯片统计得到。

在一种可能的实现场景中，若wifi业务与其他业务使用共同的天线进行通信，那么，在考虑采用何种休眠模式时，还需要进一步考虑共用天线的占用情况。其他业务可以包括但不限于：蓝牙业务、zigbee业务中的至少一种。现以蓝牙为例进行说明。

可以参考图10，图10示出了另一种ap向sta发送数据的场景。在该场景中，sta已经开启了快速休眠模式，那么，根据共用天线的占用情况，存在如下两种休眠方式：

在图10的第一个beacon周期中，sta在wake状态下收听beacon帧，并由此确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，之后，sta接收ap发送的数据d3。此时，蓝牙在使用该共用天线收发数据，那么，sta收发数据的成功率可能较低，这种情况下，可以采用较长的等待时长进行休眠，因此采用普通休眠模式休眠。也就是，sta在接收完数据d3后，sta等待时长t2，例如200ms，若在该时长t2内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态。

在图10的第二个beacon周期中，sta在wake状态下收听beacon帧，并由此确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，之后，sta接收ap发送的数据d4。此时，蓝牙并未使用该共用天线，那么，sta收发报文的成功率可能较高，这种情况下，可以采用较短的等待时长进行快速休眠。也就是，sta在接收完数据d4后，sta等待时长t4，例如60ms，若在该时长t4内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态。

再一方面，还可以根据sta信号是否收到信号干扰，来确定采取何种休眠模式。

示例性的，可以参考图11，图11示出了另一种ap向sta发送数据的场景。在该场景中，sta已经开启了快速休眠模式，那么，当前sta信号是否受到干扰，会影响sta信号的收发成功率，存在如下两种休眠方式：

在图11的第一个beacon周期中，sta在wake状态下收听beacon帧，并由此确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，如此，sta接收ap发送的数据d3。此时，sta的信号受到频段干扰，那么，sta收发报文的成功率可能较低，这种情况下，可以采用较长的等待时长进行休眠。也就是，sta在接收完数据d3后，sta等待时长t2，例如200ms，若在该时长t2内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态。

在图11的第二个beacon周期中，sta在wake状态下收听beacon帧，并由此确定ap有为自己缓存数据，则发送p0，告知ap自己当前处于wake状态，如此，sta接收ap发送的数据d4。此时，sta的信号没有受到频段干扰，那么，sta收发报文的成功率可能较高，这种情况下，则可以采用较短的等待时长快速休眠。也就是，sta在接收完数据d4后，sta等待时长t4，例如60ms，若在该时长t4内，sta一直无其他收发数据，则sta发送p1，并由wake状态转入sleep状态。

本申请实施例中，sta所受到的信号干扰可以包括但不限于：ism(industrialscientificmedicalband)频段干扰。其中，ism频段为一段各国主要开放给工业(industrial)、科学(scientific)和医学(medical)机构使用的频段。ism在各国的规定中并不统一，而2.4ghz为各国共同的ism频段。而无线局域网(ieee802.11b/ieee802.11g)、蓝牙、zigbee等无线网络，均可工作在2.4ghz频段上，因此，ism频段可能会对sta与ap之间的数据传输过程产生干扰。

本申请实施例中，前述各实现方式，可以独立执行，无需考虑其他实施例。例如，无论ap类型、sta的当前应用类型，只要sta的业务量较大，就采用较长的等待时长200ms进行休眠；反之，若sta的业务量较小，则采用60ms进行休眠。

本申请的另一实施例中，前述各实现方式中，还可以结合以确定等待时长。例如，无论ap类型、sta的当前应用类型，若出现sta业务量较大、sta信号强度较弱、共用天线被占用、存在频段干扰中的至少一种情况，则sta采用200ms进行休眠；若前述情况均未出现，则采用60ms进行休眠。又例如，若出现ap为第一ap、sta的当前应用为第一应用、sta业务量较大、sta信号强度较弱、共用天线被占用、存在频段干扰中的至少一种情况，则sta采用200ms进行休眠；若前述情况均未出现，则采用60ms进行休眠。

本申请的再一实施例中，还可以预先根据ap类型与sta的当前应用确定是否开启快速休眠模式，并在开启快速休眠模式之后，再执行后续图8～图11所示的至少一种条件的判断，进而，根据判断结果，来确定sta进入sleep状态的等待时长。

在一实施例中，若经过图7所示判断，确定开启快速休眠模式(s718)，sta可以采用60ms或200ms的休眠模式进行休眠，则进一步根据图8～图11中的至少一种进行判断。例如，若sta的业务量较大，则采用200ms进行休眠；若sta的业务量较小，则采用60ms进行休眠。又例如，若出现sta业务量较大、sta信号强度较弱、共用天线被占用、存在频段干扰中的至少一种情况，则sta采用200ms进行休眠；若前述情况均未出现，则采用60ms进行休眠。

另一实施例中，若经过若经过图7所示判断，确定开启快速休眠模式(s718)，sta可以采用60ms的休眠模式进行休眠，则进一步根据图8～图11中的至少一种进行判断，以确定是否要用60ms的等待时长休眠。例如，若sta的业务量较大，则可以关闭快速休眠模式，采用普通休眠模式对应的200ms进行休眠；若sta的业务量较小，则采用60ms进行休眠。又例如，若出现sta业务量较大、sta信号强度较弱、共用天线被占用、存在频段干扰中的至少一种情况，则关闭快速休眠模式，sta采用200ms进行休眠；若前述情况均未出现，则采用快速休眠模式对应的60ms进行休眠。

另一实施例中，若经过若经过图7所示判断，确定关闭快速休眠模式(s720)，sta可以采用200ms的休眠模式进行休眠，或者，也可以不休眠，则进一步根据图8～图11中的至少一种进行判断，以确定sta是否休眠。例如，若sta的业务量较大，则sta可以不休眠；若sta的业务量较小，则sta可以采用200ms进行休眠。又例如，若出现sta业务量较大、sta信号强度较弱、共用天线被占用、存在频段干扰中的至少一种情况，则sta可以不休眠；若前述情况均未出现，则sta可以采用较长的等待时长200ms进行休眠。

此外，针对ap中没有该sta的缓存数据的情况，可以等待时长t3后即进入sleep状态。另一种可能的实施例中，无论ap是否有sta的缓存数据，ap都可以在醒来后通知ap自己处于wake状态(发送p0)，之后，等待一段时长后，若无数据收发，则发送p1并休眠。

这种情况下，若sta中开启了快速休眠模式，那么，也可以根据sta的业务量、信号强度、共用天线占用情况、干扰情况中的至少一种，来确定是否快速休眠。不作赘述。

如图3～图11所示的通信场景中，sta可以在接收ap发送的beacon帧时醒来，如此，sta可以在于ap进行关联以接入无线网络时，可以获取到ap发送beacon帧的间隔。

图12示出了sta接入无线网络的过程示意图。如图12所示，在sta的无线通信功能开启后，就可以自动对附近的ap进行扫描。sta可以向扫描到的ap发送扫描请求(proberequest)，ap在收到扫描请求后向sta发送扫描应答(proberesponse)，该扫描应答里就携带有一些ap的信息，如图12所示出的ap发送beacon帧的周期时长t1。之后，sta向ap进行认证。如图12所示，sta向ap发送认证请求(authenticationrequest)，而ap可以根据认证请求向认证服务器(authenticationserver)对sta进行认证，并在认证成功后，向sta发送的认证应答(authenticationresponse)。sta接收认证应答后，sta与ap进行关联。如图12所示，sta向ap发送关联请求(associationrequest)，并接收ap反馈的关联应答(associationresponse)。如此，完成ap与sta的关联，sta可以经ap接入无线网络。

由图12可知，在sta与ap进行关联时，具体为sta在接收到ap发送的proberesponse时，即可获取到beacon的发送周期，从而，sta能够在ap发送beacon帧时醒来。也就是说，可以在sta中进行设置，使得sta在ap发送beacon帧时醒来。

图13示出了另一种ap向sta发送数据的场景。如图13所示，在ap发送beacon帧之前，sta就提前时长t5醒来。

在图13所示的第一个beacon周期中，sta在收听beacon帧前醒来，处于wake状态。由于beacon帧指示ap中有该sta的缓存数据，则sta向ap发送p0，以通知ap自己当前处于wake状态。从而，ap向sta发送数据d3，sta接收数据d3。在接收完数据d3的时候，若蓝牙当前在使用与wifi共用的天线，sta的发包成功率可能较低，可以等待时长t2，若确定无数据收发，则向ap发送p1，p1用于通知ap自己即将进入sleep状态，并随后进行sleep装。也即，在第一个beacon周期中，sta采用普通休眠模式休眠。

在图13所示的第二个beacon周期中，sta仍然在收听beacon帧前醒来，处于wake状态。sta收听beacon帧后，向ap发送p0，并接收ap发送的数据d4。sta在完全接收数据d4时，若此时蓝牙并没有使用共用天线，则可以采用快速休眠模式休眠，也即利用时长t4进行休眠，不再赘述过程。

在图13所示的第三个beacon周期中，sta仍然在收听beacon帧前，提前醒来，并在收听beacon帧后，确定ap中并没有自己的缓存数据，且sta没有发送数据的需求，则sta可在收听完beacon帧后快速进入sleep状态。

换言之，本申请实施例中，sta可以在收听beacon帧前醒来，也可以在ap发送beacon帧的时刻醒来，以便于收听beacon帧的内容，从而在ap由缓存数据时可以及时接收，保证业务的通畅进行。

除此之外的另一种可能的实施例中，sta可以基于时长t1确定ap发送beacon帧的时刻，由此，除图3～图13所示的实现方式之外，sta还可以被配置为在部分beacon周期中不醒来。示例性的，图14示出了另一种ap向sta发送数据的场景，这种场景就示出了sta在第二beacon周期中持续sleep的情况。

在图14所示的第一个beacon周期中，sta在接收beacon帧时醒来，beacon帧指示ap中有该sta的缓存数据，则sta向ap发送p0后，接收ap发送的数据d3。由于接收完数据d3时，sta信号强度较弱，则sta按照时长t2进行休眠，也即按照普通休眠模式进行休眠。

自sta在第一beacon周期进入sleep状态开始，直至ap发送第三个beacon帧，sta才由sleep状态转入wake状态。换言之，sta跳过了ap发送的第二个beacon帧并未醒来，持续保持sleep状态。此时，第二个beacon帧可能指示ap有sta的缓存数据，或者，第二个beacon帧也可能指示ap没有该sta的缓存数据。在sta处于sleep状态的这段过程中，若ap有需要转发给sta的数据，则由ap为其缓存，直至sta醒来，向ap发送p0，ap再将缓存数据发送给sta。

在图14所示的第三个beacon周期中，sta醒来后，收听beacon帧，发送p0至ap，并接收ap发送的数据d4。此时，数据d4即可以包括sta在上一段sleep状态期间缓存的数据，还可以包括sta在第三个beacon周期中醒来后至当前时刻，需要发送给sta的数据。sta在接收完数据d4后，由于sta信号强度较强，则sta按照时长t4进行快速休眠。

实际场景中，sta可以连续在n个beacon周期中醒来并入睡，再连续在m个beacon周期中持续sleep，直至第n+m+1个beacon周期再醒来，并重复前述过程。其中，n和m的值可以根据需要预设。

例如，sta可以如图14所示，在一个beacon周期中醒来并入睡，然后间隔一个beacon周期持续sleep，再在下一个beacon周期醒来。又例如，sta可以在第1～3个beacon周期醒来并入睡，然后，在第4个beacon周期内维持sleep状态，直至第5个beacon周期再醒来；如此，在第5～7个beacon周期中醒来并入睡，在第8个beacon周期内持续sleep……不作赘述。

本申请实施例中，而无论sta采取何种方式wake，当sta处于wake状态且完成数据传输之后，都可以按照前述方式，根据实际通信场景来选择不同的休眠模式进行休眠。

除ap向sta发送数据的场景之外，本申请实施例还涉及到sta主动向ap发送数据的场景。示例性的，可以参考图15，图15为一种sta向ap发送数据的场景。

当sta处于wake状态时，sta可以直接向ap发送数据d5。数据d5传输结束后，sta检测到当前存在频段干扰，则sta可以时长较长的t6进行休眠。也就是，sta可以等待时长t6，若在时长t6内，sta一直无数据收发，则sta向ap发送p1，并随后进入sleep状态。而ap接收到p1后，即可知道sta进入sleep状态。

sta进入sleep状态一段时间后，若sta有需要向ap发送数据，则sta醒来，由sleep状态转入wake状态。sta醒来后，即可发送p0和数据d6。数据d6传输结束后，sta检测到当前无频段干扰，则sta可以采用较短的时长t7以快速休眠。也就是，sta可以等待时长t7，若在时长t7内，sta一直无数据收发，则sta向ap发送p1，并随后进入sleep状态。

sta在需要发送上行数据时，由sleep状态进入wake状态。例如，一种实现场景中，当sta需要发送上行数据时，则sta的处理器可以发送数据发送指令给无线通信模块，以使得无线通信模块在接收到该数据发送指令时上电工作。又例如，当sta需要发送上行数据时，sta的处理器可以直接将待发送的上行数据发送给无线通信模块，以使得无线通信模块接收到上行数据后上电，并将这些上行数据发送出去。

如图15所示，时长t6大于时长t7。一种可能的实现场景中，若预设了普通休眠模式与快速休眠模式。那么，若普通休眠模式中，sta接收数据后的等待时长可以为t2，而sta发送数据后的等待时长可以为t6，那么，在具体实现场景中，时长t6与时长t2可以相同，也可以不同。类似的，若快速休眠模式中，sta接收数据后的等待时长可以为t4，而sta发送数据后的等待时长可以为t7，那么，时长t7与时长t4可以相同，也可以不同。换言之，sta发送数据场景下的快速休眠模式，与sta接收数据场景下的快速休眠模式，可以相同，也可以不同。sta发送数据场景下的普通休眠模式，与sta接收数据场景下的普通休眠模式，可以相同，也可以不同。

本申请实施例中，sta在醒来后，可以分别单独的发送p0和数据d6。或者，sta在醒来后，也可以发送数据d6，数据d6中可以携带p0，或在数据d6中携带p0中sta处于wake状态的指示信息。或者，sta在醒来后，也可以仅发送数据d6，此时，可以不再向ap发送自身处于wake状态的指示信息，ap收到数据d6即可确定sta处于wake状态。

在sta主动向ap发送数据的场景中，sta也可以按照如图3～图14所示的方式，根据实际通信场景，采取不同的休眠模式。例如，可以根据图7所示的方式，来确定是否开启快速休眠模式。又例如，在开启快速休眠模式之后，可以根据图8～图11中任一实施例所示的方式，来确定各beacon周期采取的等待时长。又例如，还可以按照图13、图14所示的方式，来控制sta醒来的时机。

在sta与ap之间的数据交互场景中，一般既会涉及sta发送数据给ap的情况，也会涉及sta接收ap发送的数据的情况。此时，sta除可以在收听beacon帧时唤醒之外，还可以在发送数据时被唤醒。

示例性的，可以参考图16a。在图16a的第一个beacon周期中，sta也根据时长t1醒来，收听ap发送的第一个beacon帧，beacon帧指示ap中有ap的缓存数据，则sta发送p0，以表明sta处于wake状态；ap收到p0后，发送数据d3至sta。sta接收完数据d3时，由于sta的业务量较大，则sta可以等待时长t2，若再无数据收发，就发送p1至ap，sta随即进入sleep状态。在图16a的第二个beacon周期中，sta醒来，进入wake状态，开始收听ap发送的第二个beacon帧。sta发送p0给ap，并接收ap发送的数据d4。除此之外，sta在wake状态下，也可以主动向ap发送数据。如图16a所示，sta完成接收数据d4后(示例性的，可以同时或之前)，sta还可以主动向ap发送数据d5。sta将数据d5传输完成后，由于sta收发数据的业务量较大，此时，sta可以等待时长t6，再无数据收发后，sta发送p1至ap，并进入sleep状态。在图16a的第三个beacon周期中，sta在收听beacon帧时醒来，并发送p0给ap，之后，接收ap为sta缓存的数据d7。接收完数据d7后，由于当前sta的业务量较小，则可以经过时长t4，sta发送p1，随后再度进入sleep状态。

示例性的，还可以参考图16b。在图16b所示的第一个beacon周期中，sta接收数据d3，由于当前业务量较大，经过时长t2，一直无数据收发，sta进入sleep状态。在第二个beacon周期中，sta醒来收听beacon帧，以及，发送p0并接收数据d7，由于当前业务量较小，则sta经过时长t4均无数据收发，sta进入sleep状态。而在第三个beacon周期中，sta醒来收听beacon，并在接收数据d4后，向ap发送了数据d5，而由于数据量较大，因此，sta等待了时长t6，若无数据收发，则sta再次进入sleep状态。

示例性的，还可以参考图16c。在图16c的第一个beacon周期中，sta接收数据d3后，由于当前业务量较大，经过时长t2，一直无数据收发，sta进入sleep状态。在该beacon周期中，经过一段时长后，sta需要主动向ap发送数据，例如无线通信模块接收到处理器发送的数据发送指令时，sta被唤醒，并向ap发送数据d5。此时，由于业务量较大，则sta等待时长t6后，即发送p1，并再次进入sleep状态。直至sta在收听第二个beacon帧时醒来，并接收数据d4，之后，经过时长t4后，再度进入sleep状态。

换言之，sta可以在收听beacon帧时(发送时刻或发送时刻之前)唤醒，也可以基于主动发送上行数据而被唤醒，而本申请实施例对于这两次唤醒是否位于同一个beacon周期不予限定，这取决于实际通信过程。

除此之外，当sta处于wake状态时，可以接收和/或发送数据，本申请实施例对于一个beacon周期中，sta接收下行数据和发送上行数据的数目不予限定。基于此，sta可以采取不同的策略，来确定等待时长的起点。

示例性的，可以参考图17a与图17b所示场景。在该示实施例中，sta在第一个beacon周期中，接收数据d3后，由于当前业务量较大，等待时长t2后，进入sleep状态。而在第二个beacon周期中，sta依次接收了ap发送的数据d7与数据d8，此时，sta可以采取不同的策略进入sleep状态。

一种设计中，如图17a所示，sta以最近一次接收到的数据的接收完毕时刻为等待时长的计时起点。如图17a所示，sta在接收完数据d8时，开始计时，等待时长t4后，sta进入sleep状态。这种情况下，若在时长t4中有新的接收数据，则sta将新的接收数据的接收完毕时刻，作为新的计时起点，重新开始计时。

另一种设计中，如图17b所示，sta以wake状态中接收到的第一个数据的接收完毕时刻，作为等待时长的计时起点。如图17b所示，sta在唤醒后，第一个接收到的数据为数据d7，则以数据d7的接收完毕时刻，为等待时长的计时起点开始计时，并在达到计时终点时，进入sleep状态。在该实现场景中，即便在等待时长过程中，sta有其他收发数据，也不再重新确定计时起点。

当涉及到接收数据时，也可以有类似设计。可以参考图17c与图17d所示场景。

另一种设计中，可以参考图17c。在图17c所示实施例的第二个beacon周期中，sta接收了数据d7，并在之后向ap发送了数据d5。此时，sta可以以最近一次收发的数据的收发完毕时刻为计时起点。则sta在发送完数据d5后，等待时长t7后进入sleep状态。

另一种设计中，请参考图17d。在图17c所示实施例的第二个beacon周期中，sta在唤醒后第一个接收的数据为数据d7，此时，sta可以将数据d7的接收完毕时刻，作为等待时长的计时起点开始计时，并在达到时长t4时，进入sleep状态。在该实现场景中，即便在等待时长过程中，sta有其他收发数据，也不再重新确定计时起点。

除此之外，还可以限制为，sta仅根据接收数据，来确定等待时长。或者，仅根据发送数据，来确定等待时长。例如，图17d所示场景中，sta可以将最近一次接收的数据作为等待时长的计时起点，如此，即便sta在接收完数据d7后，又发送了数据d5，sta也按照数据d7的接收完毕时刻，来计时等待时长。

当涉及到数据接收和发送的情况时，前述延时休眠策略、提前wake的方式也依然可以适用。此时，可以参考图18a～图18b。

示例性的一种实施例中，如图18a所示，sta在第一个beacon周期中，根据时长t1醒来。sta唤醒后，收听ap发送的第一个beacon帧，由于beacon帧指示ap中有ap的缓存数据，则sta发送p0，以表明sta处于wake状态；ap收到p0后，发送数据d3至sta。sta接收完数据d3时，由于sta的业务量较小，则sta可以等待时长t4，若再无数据收发，就发送p1至ap，sta随即进入sleep状态。

sta在第二个beacon帧进入sleep状态后，在ap发送第三个beacon帧时，并未醒来。此时，在第三个beacon周期中，ap并未接收到sta发送的p0，因此，ap确定sta仍处于sleep状态，那么，若有需要转发给sta的数据，则由ap为sta进行缓存，直至ap收到sta发送的p0或其他数据后，再将缓存数据发送给sta。

在图16的第三个beacon周期中，sta需要向ap主动发送数据d6，此时，sta由sleep状态切换为wake状态，wifi芯片及其他无线通信器件上电工作，sta将数据d6发送给ap。而ap在接收到数据d6后，即可确定sta处于wake状态，则ap可以将为该sta缓存的数据d7发送给sta。sta接收该数据d7，接收完成时，由于sta的业务量较小，此时，sta可以采取较短的等待时长t4进入sleep状态，也就是，等待时长t4后，若无数据收发，sta再向ap发送p1，并进入sleep状态。

示例性的，图18b示出了另一种实施例。在该实施例中前两个beacon周期的情况与图17a相同，不作赘述。

在图18b所示，sta在ap发送第三个beacon帧时醒来，收听beacon后，确定ap中没有自己的缓存数据，则可以在醒来时长t3后，再次由wake状态进入sleep状态。当其处于sleep状态一段时长后，wake需要向ap发送数据d6，此时，sta由sleep状态切换为wake状态，wifi芯片及其他无线通信器件上电工作，sta将数据d6发送给ap。其中，sta发送的数据d6中携带p0，ap可基于数据d6中携带的p0确定sta处于wake状态。那么，若在第三个beacon周期中，sta处于休眠状态过程中，ap有为该sta缓存数据，则sta可在收到数据d6后发送给sta，可以参考图18a所示实现方式。如图18b所示，若sta在数据d6传输完成时，sta中的业务量较小，则可以等待时长t7，若确定再无其他收发数据，则sta发送p1，并随后进入sleep状态。

示例性的，图19a示出了另一种ap与sta的数据交互场景。在该场景中，ap按照100ms的周期对外广播beacon帧。

在图19a所示的第一个beacon周期中，sta醒来与ap进行数据交互，接收ap发送的数据d3。在接收完数据d3时，由于sta的业务量较大，因此，sta采用较长的200ms的等待时长进行休眠。此时，从接收完数据d3的时刻，可以启动计时器开始计时。如图19a所示，在200ms的计时过程中，持续处于wake状态。在该过程中，ap又向sta发送了两个beacon帧，由于sta处于wake状态，sta可以不听这两个beacon帧，也可以听了beacon帧后丢弃。在计时器达到200ms时，sta向ap发送p1，并进入sleep状态。可以理解，sta进入sleep状态之后，若sta有向ap发送上行数据的需求，则sta可以在该beacon周期中醒来；若ap有需要发送给sta的下行数据，则由ap为sta缓存，直至sta下一次醒来。例如，sta在接收到下一个beacon帧时醒来，或者，在需要向ap发送数据时醒来。

除此之外，图19b示出了这种场景下的另一种处理方式。sta在接收完数据d3后连续200ms处于wake状态，在该过程中，sta具备数据收发能力，也就是，sta可以主动向ap发送上行数据，也可以接收ap下发的数据。如图19b所示，sta在接收到数据d3后，由于业务量较大，启动计时器开始计时，计时时长为200ms。在该过程中，sta接收了ap发送的数据d4，以及，sta还向ap发送了数据d5。在计时器计时过程中，sta以唤醒状态下接收完第一个数据的时刻为起点开始计时，即便有数据收发，也不重新确定计时器的起点和终点，而是当计时达到200ms时进入sleep状态。例如，在sta接收ap发送的数据d4时，或者，当sta向ap发送数据d5时，都不需要确定当前通信情况对应的等待时长，计时器仍然以接收完数据d3的时刻为起点，当计时达到200ms，sta进入sleep状态。

综上所述，本申请实施例所提供技术方案，根据sta的实际通信场景，包括sta联网状态、关联sp的类型、sta的当前应用类型、业务量情况、共用天线的占用情况、sta的信号强度、业务干扰情况，来动态调节wifi芯片下电的等待时长，如此，能够在保证sta的业务正常进行的前提下，尽可能的增加wifi芯片下电的机会和时长，有利于降低sta的功耗，延长sta的待机时长。

示例性的，本申请所提供的一种数据收发方法的流程，可以参考图20，该方法可以包括如下步骤：

s2002，第一设备在唤醒状态下，接收第二设备发送的第一数据。

s2004，响应于接收完所述第一数据，经过第一时长，所述第一设备进入休眠状态。

s2006，经过第二时长，所述第一设备进入唤醒状态。

s2008，所述第一设备接收所述第二设备发送的第二数据。

s2010，响应于接收完所述第二数据，经过第三时长，所述第一设备进入休眠状态；其中，所述第一时长与所述第三时长不同。

如前所述，第一设备可以为sta，第二设备可以ap。而第一时长与第三时长为第一设备，进入sleep状态之前的等待时长，因此，第一时长与所述第一设备的业务量、信号强度、共用天线占用情况、干扰情况、所述第一设备中的当前应用类型、第二设备类型中的至少一种相关联。所述第二时长与所述第一设备的业务量、信号强度、共用天线占用情况、干扰情况、所述第一设备中的当前应用类型、第二设备类型中的至少一种相关联。

而第二时长可以与beacon帧相关。在不同的实施例中，第二时长可以有不同的计时起点和计时终点。

例如，在图4a所示的实施例中，第一时长为t2，第三时长为t4，二者由于sta的应用不同而不同。而第二时长的计时起点为sta发送完p1的时刻，第二时长的计时终点为beacon帧的发送时刻。换言之，在第二时长的计时终点，sta即可收听beacon帧。

又例如，在图13所示的实施例中，第二时长的计时起点为sta发送完p1的时刻，第二时长的计时终点为beacon帧的发送时刻之前的一个时刻，第二时长的计时终点与beacon帧的发送时刻之间相差时长t5。换言之，从第二时长的计时终点开始，经过时长t5(作为第四时长)，sta收听beacon帧。

除此之外，在图14所示的实施例中，第二时长的计时起点为第一个beacon周期中，sta发送完p1的时刻，第二时长的计时终点为第三个beacon帧的发送时刻。此时，第二时长也可以包含至少一个beacon帧的周期时长。

除此之外，本申请还提供了另一种数据收发方法，可以参考图21，该方法可以包括如下步骤：

s2102，第一设备在唤醒状态下，向第二设备发送第五数据。

s2104，响应于发送完所述第五数据，经过第十时长，所述第一设备进入休眠状态。

s2106，经过第十一时长，所述第一设备进入唤醒状态。

s2108，所述第一设备向所述第二设备发送第六数据。

s2110，响应于发送完所述第六数据，经过第十二时长，所述第一设备进入休眠状态；其中，所述第十时长与所述第十二时长不同。

示例性的，可以参考图15，不作赘述。在这种数据收发方法中，sta可以根据业务量、信号强度、共用天线占用情况、干扰情况、sta的当前应用类型、ap类型中的至少一种，来实时确定等待时长，可以理解，第十时长与所述第十二时长均可以与前述条件相关联。不作额外赘述。未详述的部分，可以参考前述实施例。

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

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

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

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

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

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