CN110928586B - App后台保活方法及装置 - Google Patents

Abstract

本发明实施例涉及物联网技术领域，公开了一种APP后台保活方法及装置。该方法应用于iOS设备，iOS设备与终端设备通信连接，该方法包括：接收终端设备周期性发送的唤醒通知以唤醒目标APP，并监测目标APP的存活状况信息；根据存活状况信息确定当前唤醒通知的发送周期是否需要调整；在需要调整时，根据存活状况信息确定调整方向，并通知终端设备按照调整方向调整发送周期。本发明实施方式可在节约功耗的前提下使得应用在后台持续存活而不被挂起，提高用户使用的便利性。

Description

APP后台保活方法及装置

技术领域

本发明涉及物联网技术领域，特别涉及一种APP后台保活方法及装置。

背景技术

近年来，蓝牙无钥匙系统越来越受市场欢迎。数字钥匙应用一般在智能操作系统后台运行。但iOS操作系统中，APP退到后台后很快就会被系统挂起，使得应用无法正常工作，导致用户需要频繁手动唤醒APP，操作繁琐。

发明内容

本发明实施方式的目的在于提供一种APP后台保活方法及装置，可在节约功耗的前提下使得应用在后台持续存活而不被挂起，提高用户使用的便利性。

为解决上述技术问题，本发明的实施方式提供了一种APP后台保活方法，应用于iOS设备，所述iOS设备与终端设备通信连接，所述方法包括：

接收所述终端设备周期性发送的唤醒通知以唤醒目标APP，并监测所述目标APP的存活状况信息；

根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整；

在需要调整时，根据所述存活状况信息确定调整方向，并通知所述终端设备按照所述调整方向调整所述发送周期。

本发明的实施方式还提供了一种APP后台保活方法，应用于与iOS设备通信连接的终端设备，所述方法包括：

周期性地向所述iOS设备发送用于唤醒目标APP的唤醒通知；

响应于所述iOS设备发送的发送周期调整请求，基于所述调整请求指示的调整方向调整所述发送周期，并根据调整后的发送周期发送唤醒通知。

本发明的实施方式还提供了一种APP后台保活装置，包括：

唤醒模块，用于接收所述终端设备周期性发送的唤醒通知以唤醒目标APP；

监测模块，用于监测所述目标APP的存活状况信息；

调整模块，用于根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整；

在需要调整时，根据所述存活状况信息确定调整方向，并通知所述终端设备按照所述调整方向调整所述发送周期。

本发明实施方式相对于现有技术而言，iOS设备接收终端设备周期性发送的唤醒通知以唤醒目标APP，并监测目标APP的存活状况信息，然后根据存活状况信息确定当前的发送周期需要调整时，根据存活状况信息确定调整方向，并通知终端设备按照调整方向调整发送周期。因此，本发明实施方式不仅能够通过终端设备周期性地向iOS设备发送唤醒通知，而使得目标APP在后台保持存活，而且能够通过监测目标APP的存活状况信息调整唤醒通知的发送周期，使得发送周期与目标APP的实际存活状况相匹配，从而可尽量减少不必要的唤醒操作，降低终端的功耗。

作为一个实施例，所述存活状况信息包括所述目标APP在监测时间段内的存活状况信息；所述监测时间段包括N个当前所述发送周期；N为大于或者等于1的自然数；

所述根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整，以及根据所述存活状况信息确定调整方向，具体包括：

根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内是否被挂起，或者根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内的挂起情况是否满足预设条件；

若所述目标APP在所述监测时间段内被挂起或者所述挂起情况满足预设条件，则确定调小所述发送周期。从而可及时调小发送周期，实现APP保活。

作为一个实施例，所述监测时间段内的存活状况信息包括：所述监测时间段内各发送周期内所述目标APP的存活时长；其中，所述监测时间段内各发送周期内所述目标APP的存活时长通过以下方式监测得到：

在接收到当前的所述唤醒通知时控制计时器开始计时，当接收到下一唤醒通知时获取所述计时器的计时时长，将所述计时时长作为各所述发送周期内所述目标APP的存活时长；其中，所述计时器在所述目标APP被挂起时停止计时；

所述根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内是否被挂起，具体包括：

若所述监测时间段内一个或者多个所述发送周期内所述APP的存活时长小于当前所述发送周期，则判定所述目标APP在所述监测时间段内被挂起；

所述根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内的挂起情况是否满足预设条件，具体包括：

若所述监测时间段内一个或者多个所述发送周期内当前所述发送周期与所述APP的存活时长之差大于第一阈值，则确定所述挂起情况满足预设条件。通过检测APP的存活时长，从而便于准确地调整发送周期。

作为一个实施例，还包括：

若确定调小所述发送周期，则根据所述监测时间段内各发送周期内所述目标APP的存活时长确定当前所述发送周期的调小幅度，并将所述调小幅度发送至所述终端设备。

作为一个实施例，所述存活状况信息还包括：与所述APP的实际存活时长相关的系统资源使用信息；

所述根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整，以及根据所述存活状况信息确定调整方向，具体包括：

若所述目标APP在所述监测时间段内未被挂起或者所述挂起情况不满足预设条件，根据所述系统资源使用信息以及预设的估计存活时长与系统资源使用信息对应关系得到对应的估计存活时长；

若所述估计存活时长与当前所述发送周期之差大于第二阈值，则确定调大所述发送周期。

作为一个实施例，还包括：

若根据所述系统资源使用信息确定系统资源使用变化率在预设变化范围内，则暂停通知所述终端设备调整所述发送周期，直到所述系统资源使用变化率偏离所述预设变化范围。从而可在APP的存活时长波动较快时避免频繁调整发送周期，有利于节约功耗。

作为一个实施例，所述响应于所述iOS设备发送的发送周期调整请求，基于所述调整请求指示的调整方向调整所述发送周期，具体包括：

若接收到所述目标APP的实际存活时长或者估计存活时长，则根据所述实际存活时长或者估计存活时长调整所述发送周期。

作为一个实施例，所述响应于所述iOS设备发送的发送周期调整请求，基于所述调整请求指示的调整方向调整所述发送周期，还包括：

若未接收到所述目标APP的实际存活时长或者估计存活时长，则按照固定步长或者步长从大到小的方式逐步调整所述发送周期。

附图说明

图1是根据本发明第一实施方式APP后台保活方法的流程图；

图2是根据本发明第二实施方式APP后台保活方法的流程图；

图3是根据本发明第三实施方式APP后台保活装置的结构示意图；

图4是根据本发明第四实施方式APP后台保活装置的结构示意图；

图5是根据本发明第五实施方式电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本发明而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本发明所要求保护的技术方案。

如图1所示，本发明的第一实施方式涉及一种APP后台保活方法，应用于iOS设备，iOS设备包括但不限于智能手机、掌上电脑。iOS设备与终端设备通信连接，终端设备比如是车载蓝牙设备。该方法包括步骤101至步骤105。

步骤101：接收终端设备周期性发送的唤醒通知以唤醒目标APP。

本实施方式中，目标APP比如是蓝牙数字钥匙。iOS设备中，退出到后台的APP一般在10秒左右就会被挂起，不同的机型以及运行状态均可能影响APP的挂起时间。就同一机型而言，不同的运行状态下APP的挂起时间可能在5S(秒)到10S(秒)之间变化。

iOS设备与终端设备在未建立蓝牙连接前，可以打开目标APP，iOS设备持续扫描终端设备，扫描成功后，与终端设备建立蓝牙连接。或者iOS设备发送广播包，由终端设备扫描，从而建立连接。蓝牙连接建立成功后，终端设备周期性地向iOS设备发送唤醒通知，iOS设备在每次接收到唤醒通知后会执行唤醒应用操作以唤醒目标APP。具体地，若接收到唤醒通知时目标APP已被挂起，则自动唤醒目标APP，目标APP被唤醒后在后台的存活时长会重新计算，若接收到唤醒通知时目标APP存活，则执行完唤醒操作后目标APP的存活时长亦重新计算。因此，iOS设备端通过周期性地执行唤醒操作可以使目标APP在后台保持存活。

步骤102：监测目标APP的存活状况信息。

APP的存活状况信息包括：目标APP在监测时间段内的存活状况信息；监测时间段包括N个当前发送周期；N为大于或者等于1的自然数。

本实施方式中，监测时间段比如为1个当前发送周期。在一些例子中，监测时间段可以是多个发送周期，比如监测时间段可以包含2个或者3个发送周期。

步骤103：根据存活状况信息确定当前唤醒通知的发送周期是否需要调整，在需要调整时，执行步骤104，若不需要调整，则返回步骤101。

步骤104：根据存活状况信息确定调整方向。

步骤105：通知终端设备按照调整方向调整发送周期。

本实施方式中，步骤103、104具体包括：根据监测时间段内的存活状况信息确定目标APP在监测时间段内是否被挂起,若目标APP在监测时间段内被挂起，则确定需要调整发送周期，并且需要调小发送周期。

本实施方式中，监测时间段内的存活状况信息包括：监测时间段内各发送周期内目标APP的存活时长；其中，监测时间段内各发送周期内目标APP的存活时长通过以下方式监测得到：

在接收到当前的唤醒通知时控制计时器开始计时，当接收到下一唤醒通知时获取计时器的计时时长，将获取的计时时长作为各发送周期内目标APP的存活时长；其中，计时器在目标APP被挂起时停止计时。

在此，可以在目标APP中设置一个计数器，通过计数实现计时功能。当接收到当前的唤醒通知时，将计数器置0，然后每单位时间计数器数值加1，单位时间可以是1秒、500毫秒、200毫秒等。当接收到下一个唤醒通知时，读取该计数器的计数值，并根据计数值以及单位时间计算得到当前的发送周期内的计时时长，该计时时长即为目标APP在当前的发送周期内的存活时长。

根据监测时间段内的存活状况信息确定目标APP在监测时间段内是否被挂起，具体包括：若监测时间段内一个或者多个发送周期内APP的存活时长小于当前发送周期，则判定目标APP在监测时间段内被挂起。具体地，若监测时间段为一个当前发送周期，则若当前发送周期内APP的存活时长小于当前发送周期，则确定目标APP在监测时间段内被挂起；如果监测时间段包含多个当前发送周期，则在监测时间段内任一发送周期内APP的存活时长小于当前发送周期时，确定目标APP在监测时间段内被挂起。

值得一提的是，本实施方式中，若根据监测时间段内APP在各发送周期内的存活时长确定需要调小发送周期，则可以根据监测时间段内各发送周期内目标APP的存活时长确定当前发送周期的调小幅度，并将调小幅度发送至终端设备。

具体地，调小幅度可以等于当前的发送周期与对应的APP的存活时长之差，比如，当前的发送周期为8S，对应的APP的存活时长为7.5S，则调小幅度可以等于0.5S，此时调整后的发送周期即为APP的存活时长。或者，也可以适当增大调小幅度，即使得调整后的发送周期略小于APP的存活时长。

在一些例子中，监测时间段内的存活状况信息还可以包括：监测时间段内各发送周期内目标APP与后台服务器的网络长连接是否断开的记录。类似地，若监测时间段内任一发送周期内目标APP与后台服务器的网络长连接存在断开的记录，则确定目标APP在监测时间段内被挂起。

在一些例子中，还可以根据监测时间段内的存活状况信息确定目标APP在监测时间段内的挂起情况是否满足预设条件，若挂起情况满足预设条件，则确定需要调整发送周期，并且需要调小发送周期。具体地，若监测时间段内一个或者多个发送周期内当前发送周期与APP的存活时长之差大于第一阈值，则确定挂起情况满足预设条件。举例而言，第一阈值比如为0.5S,若监测时间段为一个当前发送周期，当前发送周期比如为9S,而监测时间段内的存活时长为8.8S，此时，当前发送周期与对应的存活时长之差为0.2S，由于0.2S小于0.5S，因此判定挂起情况不满足预设条件，从而确定不需要调整发送周期。换言之，在当前发送周期与对应的存活时长之差很小时，可以不对发送周期进行调整，在当前发送周期与对应的存活时长之差较大时再通知终端设备执行发送周期调整动作，从而可在不影响用户使用体验的情况下，避免频繁调整发送周期。

或者，若存活状况信息包括监测时间段内各发送周期内目标APP与后台服务器的网络长连接是否断开的记录，且监测时间段包含多个当前发送周期时，也可以得到当前监测时间段内的挂起次数，若挂起次数大于设定阈值时，确定挂起情况满足预设条件，需要调小发送周期。

本实施方式中，APP的存活状况信息还包括：与APP的实际存活时长相关的系统资源使用信息。系统资源使用信息比如为系统资源使用率。具体地，系统资源使用率可以是与应用的存活时长相关的系统资源的综合使用率，比如处理器以及内存资源的综合使用率，或者单个系统资源的使用率。

APP的实际存活时长会随着系统资源使用率的变化而变化。步骤103、步骤104中，若目标APP在监测时间段内未被挂起，或者目标APP在监测时间段内的挂起情况不满足预设条件，表示当前的发送周期已满足APP保活需求，但是随着APP存活时长的变化，可能需要调大发送周期，此时，根据系统资源使用信息以及预设的估计存活时长与系统资源使用信息对应关系得到对应的估计存活时长；若估计存活时长与当前发送周期之差大于第二阈值，则确定调大发送周期。

估计存活时长与系统资源使用信息对应关系比如是估计的存活时长区间与系统资源使用率区间的对应关系。比如，存活时长在5S到6S之间时对应的系统资源使用率在80％～90％之间。第二阈值比如为1S，若当前的发送周期为5S，而根据系统资源使用信息以及预设的估计存活时长与系统资源使用信息对应关系得到的估计存活时长比如是6.5S，则可确定估计存活时长与当前发送周期之差大于第二阈值，此时确定需要调大发送周期。

需要说明的是，在一些例子中，本实施方式还可以包括：若根据系统资源使用信息确定系统资源使用变化率在预设变化范围内，则暂停通知终端设备调整发送周期，直到系统资源使用变化率偏离预设变化范围。系统资源使用变化率反映系统资源使用率波动的快慢，也关系APP存活时长波动的快慢。预设变化范围用于反映系统资源使用率波动较快的情况。比如，用户使用一些资源消耗较大的应用时，会产生系统资源使用率波动较快的情况。本实施方式中，当系统资源使用变化率在预设变化范围内时，由于APP的存活时长波动较快，暂停通知终端设备调整发送周期，直到系统资源使用变化率偏离预设变化范围时，恢复发送周期调整功能。需要说明的是，在暂停通知终端设备调整发送周期期间，可以通知终端设备将发送周期调整为较小值以实现APP保活。因此，本实施方式可避免在APP的存活时长波动较快时调整发送周期，从而可以减少发送周期调整次数，有利于降低功耗。

本实施方式与现有技术相比，iOS设备根据终端设备周期性发送的唤醒通知唤醒目标APP，并且实时监测APP的存活状况，根据APP的存活状况确定是否需要调大或者调小唤醒通知的发送周期，并通知终端设备调大或者调小发送周期，从而使得发送周期与APP的存活情况相匹配，进而可在APP保活的同时，减少不必要的唤醒通知的发送，有利于节约设备功耗。

本发明的第二实施方式涉及一种APP后台保活方法，应用于与iOS设备通信连接的终端设备，终端设备包括但不限于车载蓝牙设备。iOS设备包括但不限于智能手机、掌上电脑等。目标APP比如是蓝牙数字钥匙。如图2所示，该方法包括步骤201至步骤203。

步骤201：周期性地向iOS设备发送用于唤醒目标APP的唤醒通知。

步骤202：响应于iOS设备发送的发送周期调整请求，基于调整请求指示的调整方向调整发送周期。

本实施方式中，若接收到目标APP的实际存活时长或者估计存活时长，则根据实际存活时长或者估计存活时长调整发送周期。

在此，当调整请求指示的调整方向为调小发送周期时，i OS设备可以根据前述实施方式中的方法得到APP在当前的发送周期内的存活时长(即实际存活时长)，并发送至终端设备。步骤202中，若接收到iOS发送的APP的实际存活时长，可以将实际存活时长作为调整后的发送周期，或者将减小了一定数值的实际存活时长作为调整后的发送周期，从而可以一步到位地对发送周期进行调整。当调整请求指示的调整方向为调大发送周期时，iOS设备可以根据前述实施方式中的方法得到APP在当前的发送周期内的估计存活时长，并发送至终端设备。终端设备可以将估计存活时长作为调整后的发送周期。

在一些例子中，若未接收到目标APP的实际存活时长或者估计存活时长，则按照固定步长或者步长从大到小的方式逐步调整发送周期。

比如，当iOS设备指示终端设备调小或者调大发送周期时，终端设备可以按照固定步长调整发送周期，固定步长比如是0.5S、0.2S等。在一些例子中，终端设备可以按照步长从大到小的方式逐步调整发送周期。比如，在调小发送周期时，开始时的步长可以为1S，即将发送周期减小1S后得到调整后的发送周期，随着调整次数的增加，步长可以减小为0.5S，或者0.2S等，从而不仅可快速调整发送周期，而且可使调整后的发送周期更接近APP的实际存活时长，进而达到应用保活以及节约能耗的平衡。

步骤203：根据调整后的发送周期发送唤醒通知。

发送周期调整完成后，终端设备可以通知iOS设备，并按照调整后的发送周期发送唤醒通知。

本实施方式与现有技术相比，通过周期性地向iOS设备发送唤醒通知，并且根据iOS设备的指示对发送周期进行调整，从而可在APP保活的同时，尽量减少唤醒通知的发送，节约设备能耗。

本发明的第三实施方式涉及一种APP后台保活装置。请参阅图3，本实施方式的APP后台保活装置300包括：

唤醒模块301，用于接收终端设备周期性发送的唤醒通知以唤醒目标APP；

监测模块302，用于监测目标APP的存活状况信息；

调整模块303，用于根据存活状况信息确定当前唤醒通知的发送周期是否需要调整；在需要调整时，根据存活状况信息确定调整方向，并通知终端设备按照调整方向调整发送周期。

可选地，存活状况信息包括目标APP在监测时间段内的存活状况信息；监测时间段包括N个当前发送周期；N为大于或者等于1的自然数；

调整模块303还用于根据监测时间段内的存活状况信息确定目标APP在监测时间段内是否被挂起，或者根据监测时间段内的存活状况信息确定目标APP在监测时间段内的挂起情况是否满足预设条件；

若目标APP在监测时间段内被挂起或者挂起情况满足预设条件，则确定调小发送周期。

进一步地，监测时间段内的存活状况信息包括：监测时间段内各发送周期内目标APP的存活时长；监测模块302还用于通过以下方式监测得到监测时间段内各发送周期内目标APP的存活时长：在接收到当前的唤醒通知时控制计时器开始计时，当接收到下一唤醒通知时获取计时器的计时时长，将计时时长作为各发送周期内目标APP的存活时长；其中，计时器在目标APP被挂起时停止计时；

调整模块303还用于若监测时间段内一个或者多个发送周期内APP的存活时长小于当前发送周期，则判定目标APP在监测时间段内被挂起；或者，

若监测时间段内一个或者多个发送周期内当前发送周期与APP的存活时长之差大于第一阈值，则确定挂起情况满足预设条件。

调整模块303还用于若确定调小发送周期，则根据监测时间段内各发送周期内目标APP的存活时长确定当前发送周期的调小幅度，并将调小幅度发送至终端设备。

可选地，存活状况信息还包括：与APP的实际存活时长相关的系统资源使用信息；调整模块303还用于若目标APP在监测时间段内未被挂起或者挂起情况不满足预设条件，根据系统资源使用信息以及预设的估计存活时长与系统资源使用信息对应关系得到对应的估计存活时长；若估计存活时长与当前发送周期之差大于第二阈值，则确定调大发送周期。

优选地，调整模块303还用于若根据系统资源使用信息确定系统资源使用变化率在预设变化范围内，则暂停通知终端设备调整发送周期，直到系统资源使用变化率偏离预设变化范围。

本实施方式与现有技术相比，APP后台保活装置根据终端设备周期性发送的唤醒通知唤醒目标APP，并且实时监测APP的存活状况，根据APP的存活状况确定是否需要调大或者调小唤醒通知的发送周期，并通知终端设备调大或者调小发送周期，从而使得发送周期与APP的存活情况相匹配，进而可在APP保活的同时，减少不必要的唤醒通知的发送，有利于节约设备功耗。

本发明的第四实施方式涉及一种APP后台保活装置。请参阅图4，本实施方式的APP后台保活装置400包括：

发送模块401，用于周期性地向iOS设备发送用于唤醒目标APP的唤醒通知；

调整模块402，用于响应于iOS设备发送的发送周期调整请求，基于调整请求指示的调整方向调整发送周期；

所述发送模块还用于根据调整后的发送周期发送唤醒通知。

可选地，调整模块402还用于若接收到目标APP的实际存活时长或者估计存活时长，则根据实际存活时长或者估计存活时长调整发送周期；若未接收到目标APP的实际存活时长或者估计存活时长，则按照固定步长或者步长从大到小的方式逐步调整发送周期。

本实施方式与现有技术相比，APP后台保活装置通过周期性地向iOS设备发送唤醒通知，并且根据iOS设备的指示对发送周期进行调整，从而可在APP保活的同时，尽量减少唤醒通知的发送，节约设备能耗。

本发明的第五实施方式涉及一种电子设备。本实施方式的电子设备可以是智能手机、智能穿戴设备等智能终端。如图5所示，该电子设备包括：存储器502和处理器501；

其中，所述存储器502存储有可被所述至少一个处理器501执行的指令，所述指令被所述至少一个处理器501执行以实现如第一或者第二实施方式所述的APP后台保活方法。

该电子设备包括一个或多个处理器501以及存储器502，图5中以一个处理器501为例。处理器501、存储器502可以通过总线或者其他方式连接，图5中以通过总线连接为例。存储器502作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。处理器501通过运行存储在存储器502中的非易失性软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述APP后台保活方法。

存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序。此外，存储器502可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施方式中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至外接设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

一个或者多个模块存储在存储器502中，当被一个或者多个处理器501执行时，执行上述任意方法实施方式中的APP后台保活方法。

上述设备可执行本发明实施方式所提供的方法，具备执行方法相应的功能模块和有益效果，未在本实施方式中详尽描述的技术细节，可参见本发明实施方式所提供的方法。

本实施方式与现有技术相比，操作端通过接收到的应用的存活信息对唤醒周期进行调整得到满足预设条件的唤醒周期，从而不仅可以通过周期性地发送唤醒通知以唤醒APP后台使其保持存活状态，而且可使唤醒周期与应用的存活时间基接近，从而可以尽量减少唤醒次数，节约终端能耗。

本发明的第六实施方式涉及一种非易失性存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行上述部分或全部的方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (8)

1.一种APP后台保活方法，其特征在于，应用于iOS设备，所述iOS设备与终端设备通信连接，所述方法包括：

接收所述终端设备周期性发送的唤醒通知以唤醒目标APP，并监测所述目标APP的存活状况信息；

根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整；

在需要调整时，根据所述存活状况信息确定调整方向，并通知所述终端设备按照所述调整方向调整所述发送周期；

所述存活状况信息包括所述目标APP在监测时间段内的存活状况信息；所述监测时间段包括N个当前所述发送周期；N为大于或者等于1的自然数；

所述根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整，以及根据所述存活状况信息确定调整方向，具体包括：

根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内是否被挂起，或者根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内的挂起情况是否满足预设条件；

若所述目标APP在所述监测时间段内被挂起或者所述挂起情况满足预设条件，则确定调小所述发送周期。

2.根据权利要求1所述的APP后台保活方法，其特征在于，所述监测时间段内的存活状况信息包括：所述监测时间段内各发送周期内所述目标APP的存活时长；其中，所述监测时间段内各发送周期内所述目标APP的存活时长通过以下方式监测得到：

在接收到当前的所述唤醒通知时控制计时器开始计时，当接收到下一唤醒通知时获取所述计时器的计时时长，将所述计时时长作为各所述发送周期内所述目标APP的存活时长；其中，所述计时器在所述目标APP被挂起时停止计时；

所述根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内是否被挂起，具体包括：

若所述监测时间段内一个或者多个所述发送周期内所述APP的存活时长小于当前所述发送周期，则判定所述目标APP在所述监测时间段内被挂起；

所述根据所述监测时间段内的存活状况信息确定所述目标APP在所述监测时间段内的挂起情况是否满足预设条件，具体包括：

若所述监测时间段内一个或者多个所述发送周期内当前所述发送周期与所述APP的存活时长之差大于第一阈值，则确定所述挂起情况满足预设条件。

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

若确定调小所述发送周期，则根据所述监测时间段内各发送周期内所述目标APP的存活时长确定当前所述发送周期的调小幅度，并将所述调小幅度发送至所述终端设备。

4.根据权利要求1所述的APP后台保活方法，其特征在于，所述存活状况信息还包括：与所述APP的实际存活时长相关的系统资源使用信息；

所述根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整，以及根据所述存活状况信息确定调整方向，具体包括：

若所述目标APP在所述监测时间段内未被挂起或者所述挂起情况不满足预设条件，根据所述系统资源使用信息以及预设的估计存活时长与系统资源使用信息对应关系得到对应的估计存活时长；

若所述估计存活时长与当前所述发送周期之差大于第二阈值，则确定调大所述发送周期。

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

若根据所述系统资源使用信息确定系统资源使用变化率在预设变化范围内，则暂停通知所述终端设备调整所述发送周期，直到所述系统资源使用变化率偏离所述预设变化范围。

6.一种APP后台保活方法，其特征在于，应用于与iOS设备通信连接的终端设备，所述方法包括：

周期性地向所述iOS设备发送用于唤醒目标APP的唤醒通知；

响应于所述iOS设备发送的发送周期调整请求，基于所述调整请求指示的调整方向调整所述发送周期，并根据调整后的发送周期发送唤醒通知；

所述响应于所述iOS设备发送的发送周期调整请求，基于所述调整请求指示的调整方向调整所述发送周期，具体包括：

若接收到所述目标APP的实际存活时长或者估计存活时长，则根据所述实际存活时长或者估计存活时长调整所述发送周期。

7.根据权利要求6所述的APP后台保活方法，其特征在于，所述响应于所述iOS设备发送的发送周期调整请求，基于所述调整请求指示的调整方向调整所述发送周期，还包括：

若未接收到所述目标APP的实际存活时长或者估计存活时长，则按照固定步长或者步长从大到小的方式逐步调整所述发送周期。

8.一种APP后台保活装置，其特征在于，包括：

唤醒模块，用于接收终端设备周期性发送的唤醒通知以唤醒目标APP；

监测模块，用于监测所述目标APP的存活状况信息；

调整模块，用于根据所述存活状况信息确定当前所述唤醒通知的发送周期是否需要调整；

在需要调整时，根据所述存活状况信息确定调整方向，并通知所述终端设备按照所述调整方向调整所述发送周期；

所述存活状况信息包括目标APP在监测时间段内的存活状况信息；所述监测时间段包括N个当前发送周期；N为大于或者等于1的自然数；

调整模块还用于根据监测时间段内的存活状况信息确定目标APP在监测时间段内是否被挂起，或者根据监测时间段内的存活状况信息确定目标APP在监测时间段内的挂起情况是否满足预设条件；若目标APP在监测时间段内被挂起或者挂起情况满足预设条件，则确定调小发送周期。

Images