CN111309395B - 对象保活方法、装置、电子设备及计算机可读存储介质 - Google Patents

对象保活方法、装置、电子设备及计算机可读存储介质 Download PDF

Info

Publication number
CN111309395B
CN111309395B CN202010083816.0A CN202010083816A CN111309395B CN 111309395 B CN111309395 B CN 111309395B CN 202010083816 A CN202010083816 A CN 202010083816A CN 111309395 B CN111309395 B CN 111309395B
Authority
CN
China
Prior art keywords
alive
keep
kept
kept alive
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010083816.0A
Other languages
English (en)
Other versions
CN111309395A (zh
Inventor
吕海岭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Xingxuan Technology Co Ltd
Original Assignee
Beijing Xingxuan Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Xingxuan Technology Co Ltd filed Critical Beijing Xingxuan Technology Co Ltd
Priority to CN202010083816.0A priority Critical patent/CN111309395B/zh
Publication of CN111309395A publication Critical patent/CN111309395A/zh
Application granted granted Critical
Publication of CN111309395B publication Critical patent/CN111309395B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44505Configuring for program initiating, e.g. using registry, configuration files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44594Unloading

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本公开实施例公开了一种对象保活方法、装置、电子设备及计算机可读存储介质,所述对象保活方法包括:接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;基于所述待保活对象保活请求获取所述待保活对象信息;根据所述待保活对象信息,对所述待保活对象执行多级保活操作。该技术方案不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。

Description

对象保活方法、装置、电子设备及计算机可读存储介质
技术领域
本公开涉及网络技术领域,具体涉及一种对象保活方法、装置、电子设备及计算机可读存储介质。
背景技术
操作系统在管理移动设备的内存时,通常会清除置于后台且占用较大内存的应用进程,以释放更多的内存供其他应用程序使用。应用被清除说明用户处于一种不活跃状态,也就是用户长时间没有与应用交互,但是,在某些情况下,应用有保持存活的硬性需求从而实时响应请求,比如导航类应用在息屏时也需要实时播报语音、聊天通信类应用在后台运行时也需要实时接受交互双方发送的内容、以及APP商户接餐饮定单应用也需要确保无论多久未与用户交互都需要在接到订单时播放声音,以便及时通知商户处理订单。现有技术中,已经有一些方法在不同的操作系统版本上实现了应用保活的功能,比如提升应用优先级的保活方式,在操作系统的主屏幕上设置只有一个像素的悬浮框绑定应用的保活方式,这些方式有两个不利因素,一是保活时长随着应用置于后台时间的变长呈指数现象减弱,这对需要强力保活的应用是难以接受的;二是随着系统对设备权限、电量优化、保护隐私等因素的重视,在高版本操作系统上的保活效果较差。
发明内容
本公开实施例提供一种对象保活方法、装置、电子设备及计算机可读存储介质。
第一方面,本公开实施例中提供了一种对象保活方法。
具体的,所述对象保活方法,适用于对象保活服务器,包括:
接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;
基于所述待保活对象保活请求获取所述待保活对象信息;
根据所述待保活对象信息,对所述待保活对象执行多级保活操作。
结合第一方面,本公开在第一方面的第一种实现方式中,所述待保活对象保活信息包括以下信息中的一种或多种:待保活对象保活时长、待保活对象保活等级、待保活对象等级。
结合第一方面,本公开在第一方面的第二种实现方式中,所述根据所述待保活对象信息,对所述待保活对象执行多级保活操作,被实施为:
获取可选保活操作架构层级,根据所述待保活对象信息确定对应的目标保活操作架构层级,并从所述目标保活操作架构层级中确定至少一种保活操作执行。
结合第一方面的第二种实现方式,本公开在第一方面的第三种实现方式中,所述可选保活操作架构层级包括三层:第一保活操作层级、第二保活操作层级和第三保活操作层级。
结合第一方面的第三种实现方式,本公开在第一方面的第四种实现方式中,所述第一保活操作层级中包括以下保活操作:
绑定所述待保活对象与AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务,当所述待保活对象处于非存活状态时,利用所述AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务定时唤醒所述待保活对象;
将所述待保活对象的优先级修改为前台任务优先级;
将所述待保活对象置于电量优化白名单中;
将所述待保活对象在终端屏幕上显示时的终端屏幕显示模式设置为常亮模式;
设置空语音,将所述空语音与所述待保活对象绑定,并按照预设条件播放所述空语音;
根据预设轮询条件轮询所述待保活对象是否存活,若否,则对所述待保活对象进行拉活;
将所述待保活对象与系统组件绑定。
结合第一方面的第三种实现方式,本公开在第一方面的第五种实现方式中,所述第二保活操作层级中包括以下保活操作:
建立与所述待保活对象通讯的第一服务组件,当所述待保活对象处于非存活状态时,响应于接收到所述第一服务组件发送的预设信息,拉活所述待保活对象;
建立与所述待保活对象通讯的第二服务组件,当所述待保活对象处于非存活状态时,响应于所述第二服务组件发出的预设信息被触发,拉活所述待保活对象;
将所述待保活对象的前端显示页面设置为锁屏页面。
结合第一方面的第三种实现方式,本公开在第一方面的第六种实现方式中,所述第三保活操作层级中包括以下保活操作:
识别与所述待保活对象处于同一应用生态链上的其他对象,当所述待保活对象处于非存活状态时,响应于所述其他对象的授权,利用所述其他对象与所述待保活对象的通信实现所述待保活对象与所述其他对象间的相互唤醒。
第二方面,本公开实施例中提供了一种对象保活装置。
具体地,所述装置适用于对象保活服务器,包括:
接收模块,被配置为接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;
获取模块,被配置为基于所述待保活对象保活请求获取所述待保活对象信息;
执行模块,被配置为根据所述待保活对象信息,对所述待保活对象执行多级保活操作。
结合第二方面,本公开在第二方面的第一种实现方式中,所述待保活对象保活信息包括以下信息中的一种或多种:待保活对象保活时长、待保活对象保活等级、待保活对象等级。
结合第二方面,本公开在第二方面的第二种实现方式中,所述执行模块被配置为:
获取可选保活操作架构层级,根据所述待保活对象信息确定对应的目标保活操作架构层级,并从所述目标保活操作架构层级中确定至少一种保活操作执行。
结合第二方面的第二种实现方式,本公开在第二方面的第三种实现方式中,所述可选保活操作架构层级包括三层:第一保活操作层级、第二保活操作层级和第三保活操作层级。
结合第二方面的第三种实现方式,本公开在第二方面的第四种实现方式中,所述第一保活操作层级中包括以下保活操作:
绑定所述待保活对象与AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务,当所述待保活对象处于非存活状态时,利用所述AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务定时唤醒所述待保活对象;
将所述待保活对象的优先级修改为前台任务优先级;
将所述待保活对象置于电量优化白名单中;
将所述待保活对象在终端屏幕上显示时的终端屏幕显示模式设置为常亮模式;
设置空语音,将所述空语音与所述待保活对象绑定,并按照预设条件播放所述空语音;
根据预设轮询条件轮询所述待保活对象是否存活,若否,则对所述待保活对象进行拉活;
将所述待保活对象与系统组件绑定。
结合第二方面的第三种实现方式,本公开在第二方面的第五种实现方式中,所述第二保活操作层级中包括以下保活操作:
建立与所述待保活对象通讯的第一服务组件,当所述待保活对象处于非存活状态时,响应于接收到所述第一服务组件发送的预设信息,拉活所述待保活对象;
建立与所述待保活对象通讯的第二服务组件,当所述待保活对象处于非存活状态时,响应于所述第二服务组件发出的预设信息被触发,拉活所述待保活对象;
将所述待保活对象的前端显示页面设置为锁屏页面。
结合第二方面的第三种实现方式,本公开在第二方面的第六种实现方式中,所述第三保活操作层级中包括以下保活操作:
识别与所述待保活对象处于同一应用生态链上的其他对象,当所述待保活对象处于非存活状态时,响应于所述其他对象的授权,利用所述其他对象与所述待保活对象的通信实现所述待保活对象与所述其他对象间的相互唤醒。
第三方面,本公开实施例提供了一种电子设备,包括存储器和处理器,其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现上述第一方面中对象保活方法的方法步骤。
第四方面,本公开实施例提供了一种计算机可读存储介质,用于存储数据处理装置所用的计算机指令,其包含用于执行上述第一方面中对象保活方法为对象保活装置所涉及的计算机指令。
本公开实施例提供的技术方案可以包括以下有益效果:
上述技术方案通过接收待保活对象保活请求,从待保活对象保活请求中获取待保活对象信息,然后根据待保活对象信息,对待保活对象执行多级保活操作,以确保待保活对象不被清除。上述技术方案不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。
当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
结合附图,通过以下非限制性实施方式的详细描述,本公开的其它特征、目的和优点将变得更加明显。在附图中:
图1示出根据本公开一实施方式的对象保活方法的流程图;
图2示出根据本公开一实施方式的目标保活操作架构层级的设置示意图;
图3示出执行操作a至操作k后的待保活对象发出的响应请求随时间的分布图;
图4示出根据本公开一实施方式的对象保活装置的结构框图;
图5是适于用来实现根据本公开实施方式的对象保活方法的计算机系统的结构示意图。
具体实施方式
下文中,将参考附图详细描述本公开的示例性实施方式,以使本领域技术人员可容易地实现它们。此外,为了清楚起见,在附图中省略了与描述示例性实施方式无关的部分。
在本公开中,应理解,诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在,并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。
另外还需要说明的是,在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
本公开实施例提供的技术方案通过接收待保活对象保活请求,从待保活对象保活请求中获取待保活对象信息,然后根据待保活对象信息,对待保活对象执行多级保活操作,以确保待保活对象不被清除。上述技术方案不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。
图1示出根据本公开一实施方式的对象保活方法的流程图,适用于对象保活服务器,如图1所示,所述对象保活方法包括以下步骤S101-S103:
在步骤S101中,接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;
在步骤S102中,基于所述待保活对象保活请求获取所述待保活对象信息;
在步骤S103中,根据所述待保活对象信息,对所述待保活对象执行多级保活操作。
上文提及,操作系统在管理移动设备的内存时,通常会清除置于后台且占用较大内存的应用进程,以释放更多的内存供其他应用程序使用。应用被清除说明用户处于一种不活跃状态,也就是用户长时间没有与应用交互,但是,在某些情况下,应用有保持存活的硬性需求从而实时响应请求,比如导航类应用在息屏时也需要实时播报语音、聊天通信类应用在后台运行时也需要实时接受交互双方发送的内容、以及APP商户接餐饮定单应用也需要确保无论多久未与用户交互都需要在接到订单时播放声音,以便及时通知商户处理订单。现有技术中,已经有一些方法在不同的操作系统版本上实现了应用保活的功能,比如提升应用优先级的保活方式,在操作系统的主屏幕上设置只有一个像素的悬浮框绑定应用的保活方式,这些方式有两个不利因素,一是保活时长随着应用置于后台时间的变长呈指数现象减弱,这对需要强力保活的应用是难以接受的;二是随着系统对设备权限、电量优化、保护隐私等因素的重视,在高版本操作系统上的保活效果较差。
考虑到上述缺陷,在该实施方式中,提出一种对象保活方法,该方法通过接收待保活对象保活请求,从待保活对象保活请求中获取待保活对象信息,然后根据待保活对象信息,对待保活对象执行多级保活操作,以确保待保活对象不被清除。上述技术方案不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。
在本实施例的一个可选实现方式中,所述待保活对象指的是运行于操作系统的应用APP或其他进程文件等等,比如可以是即时通讯类应用、导航类应用或者是外卖类应用等。其中,所述操作系统可以是Android(谷歌)系统、iOS(苹果)系统、windows mobile(微软)系统或Harmony(鸿蒙)系统等等。
在本实施例的一个可选实现方式中,所述对象保活服务器指的是执行上述方法步骤的一台或多台终端设备或服务器,若是多台终端设备或服务器,则每台终端设备或服务器均可执行所述多级保活操作或者全部终端设备或服务器组合起来执行所述多级保活操作。其中,所述终端设备或服务器可以是智能设备、平板电脑或台式计算机等,在终端设备或服务器上安装有上述操作系统。
在本实施例的一个可选实现方式中,所述待保活对象信息可包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息等等,其中,所述待保活对象标识信息指的是能够对待保活对象进行区分的信息,比如待保活对象名称、ID信息等等。
所述待保活对象保活信息可包括以下信息中的一种或多种:待保活对象保活时长、待保活对象保活等级、待保活对象等级等等,其中,所述待保活对象保活时长指的是待保活对象未被系统清除的时长与被系统清除后能够重新启动从而继续存活的时长的总和;所述待保活对象保活等级指的是待保活对象保活的强弱程度等级,可以用待保活对象被清除后重新启动的时间长度来衡量,也可以用待保活对象被清除后重新启动的顺序来衡量,比如,对该保活对象进行强保活,则每次待保活对象被清除后优先进行拉活;所述待保活对象等级指的是待保活对象的保活重要性程度等级,当有若干待保活对象需要进行保活时,可以先确定每个待保活对象等级,从而便于针对性地对每个待保活对象确定适应的待保活对象保活等级。
在本实施例的一个可选实现方式中,所述多级保活操作指的是应对不同触发事件可能导致的待保活对象被清除的保活组合操作。其中,不同触发事件可以是锁屏事件、系统内存不足、电量优化等事件。
上述实现方式中,所述对象保活服务器接收待保活对象或者其他待保活对象保活请求方发送的待保活对象保活请求,从所述待保活对象活动请求中获取待保活对象信息后,根据所述待保活对象信息,对待保活对象执行多级保活操作。基于该技术方案,可对于所述待保活对象针对性地执行多级保活操作,不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。
在本实施例的一个可选实现方式中,所述步骤S103,即根据所述待保活对象信息,对所述待保活对象执行多级保活操作的步骤,可被实施为:获取可选保活操作架构层级,根据所述待保活对象信息确定对应的目标保活操作架构层级,并从所述目标保活操作架构层级中确定至少一种保活操作执行。
也就是说,通过构建目标保活操作架构层级,然后从目标保活操作架构层级中确定至少一种保活操作,将选择的保活操作组合起来形成保活操作组合,来对待保活对象进行多级保活,以应对不同触发事件可能导致的待保活对象被清除的情况发生,从而提高待保活对象的存活时长。
在本实施例的一个可选实现方式中,所述可选保活操作架构层级包括三层:第一保活操作层级、第二保活操作层级和第三保活操作层级。其中,所述第一保活操作层级指的是基于操作系统的可执行的保活操作集合。所述第二保活操作层级指的是利用第三方与待保活对象的依赖关系来保活待保活对象的操作集合。所述第三保活操作层级指的是利用应用生态链内的其他对象来保活待保活对象的操作集合。在本公开一实施方式中,在构建目标保活操作架构层级时,可根据待保活对象信息,即待保活对象标识信息、待保活对象类型、待保活对象保活时长、待保活对象保活等级以及待保活对象等级中的一种或多种,从第一保活操作层级、第二保活操作层级和第三保活操作层级中选择一个或多个作为目标保活操作架构层级,然后从所述目标保活操作架构层级中确定至少一种保活操作执行,以提高待保活对象的存活时长。
图2示出根据本公开一实施方式的目标保活操作架构层级的设置示意图,如图2所示,所述目标保活操作架构层级包括第一保活操作层级100、第二保活操作层级200和第三保活操作层级300,其中,所述目标保活操作架构层级仅是一种示意性的说明,根据上述实施例中的描述,可以自由地从可选保活操作架构层级中确定目标保活操作架构层级。为了便于说明,下面以待保活对象为应用进程为例对于所述目标保活操作架构层级进行示意性说明,其中,所述应用进程在Android操作系统中运行。
其中:所述第一保活操作层级100中可包括以下保活操作:
操作a:绑定所述待保活对象与AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务,当所述待保活对象处于非存活状态时,利用所述AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务定时唤醒所述待保活对象。其中,AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务被触发时,系统会发出响应广播,当所述待保活对象处于非存活状态时,可以通过监听系统发出的响应广播,即可在监听到广播时被拉活。
操作b:将所述待保活对象的优先级修改为前台任务优先级。Android系统会根据应用进程中正在运行的组件以及组件的状态,按照重要性划分不同的应用进程,比如,前台进程>可见进程>服务进程>后台进程>空进程,通过执行操作b将待保活的应用进程修改为前台任务优先级,即前台进程,从而系统在清除应用进程时,会最后清除待保活的应用进程。
操作c:将所述待保活对象置于电量优化白名单中。其中,所述电量优化白名单指的是不限制应用进程在特定情况下使用电量的对象名单,对于应用进程在后台运行时消耗电量的情况,置于电量优化白名单中的待应用进程不会因为电量消耗而被系统清除,从而提高待保活对象的存活时长。
操作d:将所述待保活对象在终端屏幕上显示时的终端屏幕显示模式设置为常亮模式。也就是说,当应用的任意页面显示于终端屏幕时,将屏幕设置为长时间不息屏。通过执行操作d可以避免终端屏幕的息屏造成应用进程的优先级变为后台进程,从而免于被系统清除。
操作e:设置空语音,将所述空语音与所述待保活对象绑定,并按照预设条件播放所述空语音。执行操作e可以保持应用进程的优先级为前台进程,从而不被系统清除。其中,预设条件可以是固定的时间间隔,采用该方式播放空语音,对电量的消耗也是可以接受的。经过测试一个应用一直播放空语音,电量可使用4000个小时。
操作f:根据预设轮询条件轮询所述待保活对象是否存活,若否,则对所述待保活对象进行拉活。也就是说,利用Linux中的fork机制创建Native进程,在Native进程中通过定时器轮询判断应用进程是否存活,若应用进程被清除,则在Native进程中对应用进程进行拉活。其中,由于轮询执行判断逻辑非常耗电,因此轮询条件可根据实际应用的需要进行灵活设置,以节省电量。
操作g:将所述待保活对象与系统组件绑定。其中,所述系统组件指的是Android系统的账号同步机制组件,可利用该组件的定期同步账号的功能,对应用进程进行拉活。比如,Android系统提供了SyncAdapter服务组件,通过系统的定时器更新待保活对象的应用数据,SyncAdapter服务组件工作在独立进程,使用了SyncAdapter服务的应用进程的优先级会提高,从而降低了被清除的概率。
所述第二保活操作层级200中可包括以下保活操作:
操作h:建立与所述待保活对象通讯的第一服务组件,当所述待保活对象处于非存活状态时,响应于接收到所述第一服务组件发送的预设信息,拉活所述待保活对象。其中,第一服务组件指的是与待保活对象处于同一个生态圈的其他对象,在该生态圈内,其他对象可以与应用进程进行通讯,比如,以待保活对象为聊天进程为例,其他对象可以新闻进程,当聊天进程被清除后,通过新闻进程向聊天进程发送预设消息来重启聊天进程实现拉活,确保通讯不中断。其中,所述第一服务组件发送的预设信息可以是推送消息、广播消息等等。
操作i:建立与所述待保活对象通讯的第二服务组件,当所述待保活对象处于非存活状态时,响应于所述第二服务组件发出的预设信息被触发,拉活所述待保活对象。其中,所述第二服务组件指的是第三方提供的服务组件,也就是与所述待保活对象不属于同一个生态圈的其他对象,所述其他对象虽然不会在应用进程被清除后尝试重启应用进程,但是当预设消息显示于屏幕并且被用户触发时仍然可以拉活应用进程,从而提高应用进程的存活率。其中,所述第二服务组件发出的预设信息可以是推送消息、广播消息等等。
操作j:将所述待保活对象的前端显示页面设置为锁屏页面。执行操作j可以保持应用进程的优先级为前台进程,以提高用户与应用的交互频率,从而保障所述待保活对象不被系统清除。
所述第三保活操作层级300中可包括以下保活操作:
操作k:识别与所述待保活对象处于同一应用生态链上的其他对象,当所述待保活对象处于非存活状态时,响应于所述其他对象的授权,利用所述其他对象与所述待保活对象之间的通信实现所述待保活对象与所述其他对象间的相互唤醒。其中,所述应用生态链指的是基于服务连接的待保活对象与其他对象形成的消息链路。比如,对于共享单车应用来说,地图导航应用可以为其提供路线导航服务以及定位服务,则共享单车应用与地图导航应用的相应进程处于同一应用生态链。执行操作k需要满足以下条件:一、得到用户的授权,得到用户授权后应用进程方可与其他对象进行互动;二是存在应用生态链,在所述应用生态链内应用进程之间会互相暴露服务,从而能够正确识别对方,这样当应用进程处于非存活状态时,利用其他对象与应用进程的通信即可实现精准拉活应用进程的效果,从而提高应用进程的存活率。
上述实现方式中,在执行操作a至操作k后,应用进程2小时存活率基本可以接近100%,6小时存活率99%以上,存活率边缘效应得到明显改善。图3示出执行操作a至操作k后的待保活对象发出的响应请求随时间的分布图,如图3所示,该待保活对象发出响应请求的时间为23时00分(待保活对象使用低谷时间点)到次日的23时00分。图中23时至次日8时的时段内,用户使用待保活对象的频率较少,响应请求是依靠处于存活状态的待保活对象发出的,说明了上述操作a至操作k有效地实现了待保活对象的保活,从而能够持续地响应业务请求。
下述为本公开装置实施例,可以用于执行本公开方法实施例。
图4示出根据本公开一实施方式的对象保活装置的结构框图,该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图4所示,所述对象保活装置包括:
接收模块401,被配置为接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;
获取模块402,被配置为基于所述待保活对象保活请求获取所述待保活对象信息;
执行模块403,被配置为根据所述待保活对象信息,对所述待保活对象执行多级保活操作。
上文提及,操作系统在管理移动设备的内存时,通常会清除置于后台且占用较大内存的应用进程,以释放更多的内存供其他应用程序使用。应用被清除说明用户处于一种不活跃状态,也就是用户长时间没有与应用交互,但是,在某些情况下,应用有保持存活的硬性需求从而实时响应请求,比如导航类应用在息屏时也需要实时播报语音、聊天通信类应用在后台运行时也需要实时接受交互双方发送的内容、以及APP商户接餐饮定单应用也需要确保无论多久未与用户交互都需要在接到订单时播放声音,以便及时通知商户处理订单。现有技术中,已经有一些方法在不同的操作系统版本上实现了应用保活的功能,比如提升应用优先级的保活方式,在操作系统的主屏幕上设置只有一个像素的悬浮框绑定应用的保活方式,这些方式有两个不利因素,一是保活时长随着应用置于后台时间的变长呈指数现象减弱,这对需要强力保活的应用是难以接受的;二是随着系统对设备权限、电量优化、保护隐私等因素的重视,在高版本操作系统上的保活效果较差。
考虑到上述缺陷,在该实施方式中,提出一种对象保活方法,该方法通过接收待保活对象保活请求,从待保活对象保活请求中获取待保活对象信息,然后根据待保活对象信息,对待保活对象执行多级保活操作,以确保待保活对象不被清除。上述技术方案不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。
在本实施例的一个可选实现方式中,所述待保活对象指的是运行于操作系统的应用APP或其他进程文件等等,比如可以是即时通讯类应用、导航类应用或者是外卖类应用等。其中,所述操作系统可以是Android(谷歌)系统、iOS(苹果)系统、windows mobile(微软)系统或Harmony(鸿蒙)系统等等。
在本实施例的一个可选实现方式中,所述对象保活服务器指的是执行上述方法步骤的一台或多台终端设备或服务器,若是多台终端设备或服务器,则每台终端设备或服务器均可执行所述多级保活操作或者全部终端设备或服务器组合起来执行所述多级保活操作。其中,所述终端设备或服务器可以是智能设备、平板电脑或台式计算机等,在终端设备或服务器上安装有上述操作系统。
在本实施例的一个可选实现方式中,所述待保活对象信息可包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息等等,其中,所述待保活对象标识信息指的是能够对待保活对象进行区分的信息,比如待保活对象名称、ID信息等等。
所述待保活对象保活信息可包括以下信息中的一种或多种:待保活对象保活时长、待保活对象保活等级、待保活对象等级等等,其中,所述待保活对象保活时长指的是待保活对象未被系统清除的时长与被系统清除后能够重新启动从而继续存活的时长的总和;所述待保活对象保活等级指的是待保活对象保活的强弱程度等级,可以用待保活对象被清除后重新启动的时间长度来衡量,也可以用待保活对象被清除后重新启动的顺序来衡量,比如,对该保活对象进行强保活,则每次待保活对象被清除后优先进行拉活;所述待保活对象等级指的是待保活对象的保活重要性程度等级,当有若干待保活对象需要进行保活时,可以先确定每个待保活对象等级,从而便于针对性地对每个待保活对象确定适应的待保活对象保活等级。
在本实施例的一个可选实现方式中,所述多级保活操作指的是应对不同触发事件可能导致的待保活对象被清除的保活组合操作。其中,不同触发事件可以是锁屏事件、系统内存不足、电量优化等事件。
上述实现方式中,所述对象保活服务器接收待保活对象或者其他待保活对象保活请求方发送的待保活对象保活请求,从所述待保活对象活动请求中获取待保活对象信息后,根据所述待保活对象信息,对待保活对象执行多级保活操作。基于该技术方案,可对于所述待保活对象针对性地执行多级保活操作,不仅能够避免操作系统的版本更新对待保活对象的保活时长的影响,而且能够对待保活对象实现强力保活,从而提高待保活对象的存活时间,保障对于业务请求的持续响应。
在本实施例的一个可选实现方式中,所述第一保活操作层级中包括以下保活操作:
绑定所述待保活对象与AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务,当所述待保活对象处于非存活状态时,利用所述AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务定时唤醒所述待保活对象;
将所述待保活对象的优先级修改为前台任务优先级;
将所述待保活对象置于电量优化白名单中;
将所述待保活对象在终端屏幕上显示时的终端屏幕显示模式设置为常亮模式;
设置空语音,将所述空语音与所述待保活对象绑定,并按照预设条件播放所述空语音;
根据预设轮询条件轮询所述待保活对象是否存活,若否,则对所述待保活对象进行拉活;
将所述待保活对象与系统组件绑定。
在本实施例的一个可选实现方式中,所述第二保活操作层级中包括以下保活操作:
建立与所述待保活对象通讯的第一服务组件,当所述待保活对象处于非存活状态时,响应于接收到所述第一服务组件发送的预设信息,拉活所述待保活对象;
建立与所述待保活对象通讯的第二服务组件,当所述待保活对象处于非存活状态时,响应于所述第二服务组件发出的预设信息被触发,拉活所述待保活对象;
将所述待保活对象的前端显示页面设置为锁屏页面。
在本实施例的一个可选实现方式中,所述第三保活操作层级中包括以下保活操作:
识别与所述待保活对象处于同一应用生态链上的其他对象,当所述待保活对象处于非存活状态时,响应于所述其他对象的授权,利用所述其他对象与所述待保活对象的通信实现所述待保活对象与所述其他对象间的相互唤醒。
本公开还公开了一种电子设备,所述电子设备包括存储器和处理器;其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现上述方法步骤。
图5是适于用来实现根据本公开实施方式的对象保活方法的计算机系统的结构示意图。
如图5所示,计算机系统500包括中央处理单元(CPU)501,其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行上述实施方式中的各种处理。在RAM503中,还存储有系统500操作所需的各种程序和数据。CPU501、ROM502以及RAM503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。
以下部件连接至I/O接口505:包括键盘、鼠标等的输入部分506;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507;包括硬盘等的存储部分508;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器510上,以便于从其上读出的计算机程序根据需要被安装入存储部分508。
特别地,根据本公开的实施方式,上文描述的方法可以被实现为计算机软件程序。例如,本公开的实施方式包括一种计算机程序产品,其包括有形地包含在及其可读介质上的计算机程序,所述计算机程序包含用于执行上述对象保活方法的程序代码。在这样的实施方式中,该计算机程序可以通过通信部分509从网络上被下载和安装,和/或从可拆卸介质511被安装。
附图中的流程图和框图,图示了按照本公开各种实施方式的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,路程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。
作为另一方面,本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质;也可以是单独存在,未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序,所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离所述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (14)

1.一种对象保活方法,适用于对象保活服务器,其特征在于,包括:
接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;
基于所述待保活对象保活请求获取所述待保活对象信息;
根据所述待保活对象信息,对所述待保活对象执行多级保活操作;
所述根据所述待保活对象信息,对所述待保活对象执行多级保活操作,被实施为:
获取可选保活操作架构层级,根据所述待保活对象信息确定对应的目标保活操作架构层级,并从所述目标保活操作架构层级中确定至少一种保活操作执行,所述可选保活操作架构层级包括利用第三方与待保活对象的依赖关系来保活待保活对象的操作集合对应的架构层级,或者,利用应用生态链内的其他对象来保活待保活对象的操作集合对应的架构层级。
2.根据权利要求1所述的方法,其特征在于,所述待保活对象保活信息包括以下信息中的一种或多种:待保活对象保活时长、待保活对象保活等级、待保活对象等级。
3.根据权利要求1所述的方法,其特征在于,所述可选保活操作架构层级包括三层:第一保活操作层级、第二保活操作层级和第三保活操作层级。
4.根据权利要求3所述的方法,其特征在于,所述第一保活操作层级中包括以下保活操作:
绑定所述待保活对象与AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务,当所述待保活对象处于非存活状态时,利用所述AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务定时唤醒所述待保活对象;
将所述待保活对象的优先级修改为前台任务优先级;
将所述待保活对象置于电量优化白名单中;
将所述待保活对象在终端屏幕上显示时的终端屏幕显示模式设置为常亮模式;
设置空语音,将所述空语音与所述待保活对象绑定,并按照预设条件播放所述空语音;
根据预设轮询条件轮询所述待保活对象是否存活,若否,则对所述待保活对象进行拉活;
将所述待保活对象与系统组件绑定。
5.根据权利要求3所述的方法,其特征在于,所述第二保活操作层级中包括以下保活操作:
建立与所述待保活对象通讯的第一服务组件,当所述待保活对象处于非存活状态时,响应于接收到所述第一服务组件发送的预设信息,拉活所述待保活对象;
建立与所述待保活对象通讯的第二服务组件,当所述待保活对象处于非存活状态时,响应于所述第二服务组件发出的预设信息被触发,拉活所述待保活对象;
将所述待保活对象的前端显示页面设置为锁屏页面。
6.根据权利要求3所述的方法,其特征在于,所述第三保活操作层级中包括以下保活操作:
识别与所述待保活对象处于同一应用生态链上的其他对象,当所述待保活对象处于非存活状态时,响应于所述其他对象的授权,利用所述其他对象与所述待保活对象的通信实现所述待保活对象与所述其他对象间的相互唤醒。
7.一种对象保活装置,适用于对象保活服务器,其特征在于,包括:
接收模块,被配置为接收待保活对象保活请求,其中,所述待保活对象保活请求携带有待保活对象信息,其中,所述待保活对象信息至少包括以下信息中的一种或多种:待保活对象标识信息、待保活对象类型和待保活对象保活信息;
获取模块,被配置为基于所述待保活对象保活请求获取所述待保活对象信息;
执行模块,被配置为根据所述待保活对象信息,对所述待保活对象执行多级保活操作;
所述执行模块被配置为:
获取可选保活操作架构层级,根据所述待保活对象信息确定对应的目标保活操作架构层级,并从所述目标保活操作架构层级中确定至少一种保活操作执行,所述可选保活操作架构层级包括利用第三方与待保活对象的依赖关系来保活待保活对象的操作集合对应的架构层级,或者,利用应用生态链内的其他对象来保活待保活对象的操作集合对应的架构层级。
8.根据权利要求7所述的装置,其特征在于,所述待保活对象保活信息包括以下信息中的一种或多种:待保活对象保活时长、待保活对象保活等级、待保活对象等级。
9.根据权利要求7所述的装置,其特征在于,所述可选保活操作架构层级包括三层:第一保活操作层级、第二保活操作层级和第三保活操作层级。
10.根据权利要求9所述的装置,其特征在于,所述第一保活操作层级中包括以下保活操作:
绑定所述待保活对象与AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务,当所述待保活对象处于非存活状态时,利用所述AlarmManager定时任务、JobScheduler定时任务以及Handler定时任务定时唤醒所述待保活对象;
将所述待保活对象的优先级修改为前台任务优先级;
将所述待保活对象置于电量优化白名单中;
将所述待保活对象在终端屏幕上显示时的终端屏幕显示模式设置为常亮模式;
设置空语音,将所述空语音与所述待保活对象绑定,并按照预设条件播放所述空语音;
根据预设轮询条件轮询所述待保活对象是否存活,若否,则对所述待保活对象进行拉活;
将所述待保活对象与系统组件绑定。
11.根据权利要求9所述的装置,其特征在于,所述第二保活操作层级中包括以下保活操作:
建立与所述待保活对象通讯的第一服务组件,当所述待保活对象处于非存活状态时,响应于接收到所述第一服务组件发送的预设信息,拉活所述待保活对象;
建立与所述待保活对象通讯的第二服务组件,当所述待保活对象处于非存活状态时,响应于所述第二服务组件发出的预设信息被触发,拉活所述待保活对象;
将所述待保活对象的前端显示页面设置为锁屏页面。
12.根据权利要求9所述的装置,其特征在于,所述第三保活操作层级中包括以下保活操作:
识别与所述待保活对象处于同一应用生态链上的其他对象,当所述待保活对象处于非存活状态时,响应于所述其他对象的授权,利用所述其他对象与所述待保活对象的通信实现所述待保活对象与所述其他对象间的相互唤醒。
13.一种电子设备,其特征在于,包括存储器和处理器;其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现权利要求1-6任一项所述的方法步骤。
14.一种计算机可读存储介质,其上存储有计算机指令,其特征在于,该计算机指令被处理器执行时实现权利要求1-6任一项所述的方法步骤。
CN202010083816.0A 2020-02-10 2020-02-10 对象保活方法、装置、电子设备及计算机可读存储介质 Active CN111309395B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010083816.0A CN111309395B (zh) 2020-02-10 2020-02-10 对象保活方法、装置、电子设备及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010083816.0A CN111309395B (zh) 2020-02-10 2020-02-10 对象保活方法、装置、电子设备及计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN111309395A CN111309395A (zh) 2020-06-19
CN111309395B true CN111309395B (zh) 2021-07-20

Family

ID=71152725

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010083816.0A Active CN111309395B (zh) 2020-02-10 2020-02-10 对象保活方法、装置、电子设备及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN111309395B (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114168212A (zh) * 2020-09-09 2022-03-11 成都鼎桥通信技术有限公司 应用处理方法、装置、设备及计算机可读存储介质
CN114860392A (zh) * 2021-02-04 2022-08-05 腾讯科技(深圳)有限公司 客户端的保活方法、装置及存储介质
CN114816546A (zh) * 2022-04-28 2022-07-29 合肥高维数据技术有限公司 客户端应用程序多重保活方法及系统
CN117407068B (zh) * 2023-12-08 2024-03-29 厦门她趣信息技术有限公司 一种多策略拉活Android进程的方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102340480A (zh) * 2010-07-14 2012-02-01 杭州华三通信技术有限公司 终端与中心服务器之间的保活方法及中心服务器、终端
CN103297470A (zh) * 2012-02-29 2013-09-11 中国移动通信集团公司 永远在线业务的处理方法、应用服务器、用户终端和系统
CN105228238A (zh) * 2014-06-13 2016-01-06 中国移动通信集团公司 一种周期性保活传输方法、设备及系统
CN106909446A (zh) * 2015-12-23 2017-06-30 阿里巴巴集团控股有限公司 一种应用程序的保活方法和装置
CN108632306A (zh) * 2017-03-17 2018-10-09 华为技术有限公司 安全保活的方法、设备以及系统
CN108696509A (zh) * 2018-04-11 2018-10-23 海信集团有限公司 一种终端的接入处理方法和装置
CN109379337A (zh) * 2018-09-18 2019-02-22 四川长虹电器股份有限公司 一种安卓平台下应用进程的保活方法
CN109711152A (zh) * 2018-12-25 2019-05-03 北京潘达互娱科技有限公司 一种应用保活方法、计算设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8650305B2 (en) * 2005-05-24 2014-02-11 International Business Machines Corporation Centralized session management in an aggregated application environment
US20070233855A1 (en) * 2006-04-03 2007-10-04 International Business Machines Corporation Adaptible keepalive for enterprise extenders
CN105554151B (zh) * 2015-12-29 2019-01-15 联想(北京)有限公司 一种保活时间确定方法和电子设备
CN106656653B (zh) * 2016-10-28 2019-08-27 浙江宇视科技有限公司 注册与保活处理方法及装置
CN109992310B (zh) * 2019-03-12 2024-04-05 中国平安财产保险股份有限公司 应用程序保活方法、装置、计算机设备和存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102340480A (zh) * 2010-07-14 2012-02-01 杭州华三通信技术有限公司 终端与中心服务器之间的保活方法及中心服务器、终端
CN103297470A (zh) * 2012-02-29 2013-09-11 中国移动通信集团公司 永远在线业务的处理方法、应用服务器、用户终端和系统
CN105228238A (zh) * 2014-06-13 2016-01-06 中国移动通信集团公司 一种周期性保活传输方法、设备及系统
CN106909446A (zh) * 2015-12-23 2017-06-30 阿里巴巴集团控股有限公司 一种应用程序的保活方法和装置
CN108632306A (zh) * 2017-03-17 2018-10-09 华为技术有限公司 安全保活的方法、设备以及系统
CN108696509A (zh) * 2018-04-11 2018-10-23 海信集团有限公司 一种终端的接入处理方法和装置
CN109379337A (zh) * 2018-09-18 2019-02-22 四川长虹电器股份有限公司 一种安卓平台下应用进程的保活方法
CN109711152A (zh) * 2018-12-25 2019-05-03 北京潘达互娱科技有限公司 一种应用保活方法、计算设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"应用保活终极总结(一):Android6.0以下的双进程守护保活实践";即时通讯网;《52im.net/thread-1135-1-1.html》;20180302;第1-12页 *

Also Published As

Publication number Publication date
CN111309395A (zh) 2020-06-19

Similar Documents

Publication Publication Date Title
CN111309395B (zh) 对象保活方法、装置、电子设备及计算机可读存储介质
CN105677469B (zh) 定时任务执行方法及装置
CN108388479A (zh) 延迟消息推送方法、装置、计算机设备及存储介质
CN111858125B (zh) 任务处理方法、装置、电子设备和可读存储介质
CN110098998B (zh) 用于处理信息的方法和设备
CN111427706A (zh) 数据处理方法、多服务器系统、数据库、电子设备及存储介质
CN111880948A (zh) 数据刷新方法、装置、电子设备及计算机可读存储介质
CN113296976A (zh) 消息处理方法、装置、电子设备、存储介质及程序产品
CN110008187B (zh) 文件传输调度方法、装置、设备及计算机可读存储介质
CN113590017B (zh) 用于处理数据的方法、电子设备和计算机程序产品
CN113791876A (zh) 用于处理任务的系统、方法和装置
CN115390897B (zh) 微前端管理的方法、装置、电子设备及存储介质
CN115129429B (zh) 容器应用管理方法、装置、电子设备及存储介质
CN109067864B (zh) 通知消息推送方法、装置及电子设备
CN111368184A (zh) 智能语音设备的屏保投放方法、设备及存储介质
CN112445597B (zh) 定时任务调度方法和装置
CN115442420A (zh) 区块链跨链服务管理方法及装置
CN115361382A (zh) 基于数据群组的数据处理方法、装置、设备和存储介质
CN111290873B (zh) 故障处理方法和装置
CN110083283B (zh) 用于管理信息的方法、装置和系统
CN113190624A (zh) 基于分布式跨容器的异步转同步调用方法及装置
CN113791944A (zh) 页面定时器的监控方法、装置、介质及电子设备
CN112561620A (zh) 目标订单提醒方法、装置、电子设备及计算机存储介质
CN111352709A (zh) 分布式系统中的任务调度方法和装置
CN115604261B (zh) 云网服务资源处理方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant