CN111782347A - 手机应用保活方法、装置、系统及存储介质 - Google Patents

手机应用保活方法、装置、系统及存储介质 Download PDF

Info

Publication number
CN111782347A
CN111782347A CN201910267118.3A CN201910267118A CN111782347A CN 111782347 A CN111782347 A CN 111782347A CN 201910267118 A CN201910267118 A CN 201910267118A CN 111782347 A CN111782347 A CN 111782347A
Authority
CN
China
Prior art keywords
mobile phone
keep
alive
phone application
application
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.)
Pending
Application number
CN201910267118.3A
Other languages
English (en)
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.)
Anker Innovations Co Ltd
Original Assignee
Anker Innovations 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 Anker Innovations Co Ltd filed Critical Anker Innovations Co Ltd
Priority to CN201910267118.3A priority Critical patent/CN111782347A/zh
Publication of CN111782347A publication Critical patent/CN111782347A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/482—Application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/484—Precedence
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephone Function (AREA)

Abstract

本发明提供一种手机应用保活方法、装置、系统及存储介质，所述方法包括：启动手机应用，其包括启动所述手机应用的保活进程和业务进程；当手机系统将所述手机应用关闭时，基于至少一个预定策略使所述手机应用保活；其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。根据本发明的方法、装置、系统及计算机存储介质，实现当用户需要使用手机应用时无需手动打开，能够及时响应与设备或服务器的交互，提高用户体验。

Description

手机应用保活方法、装置、系统及存储介质
技术领域
本申请涉及计算机技术领域，特别涉及手机应用保活方法、装置、系统及存储介质。
背景技术
随着智能电子设备的快速发展，如手机等电子设备需要与应用程序APP进行的交互越来越多，甚至有些电子设备必须要依赖于APP才能使用。但是手机中大部分情况下APP不能一直处于激活状态，导致用户需要使用时，APP没有处于激活状态，无法和手机做交互，需要用户拿出手机并且打开APP才能使用。所以，使手机应用保持处于激活状态变得极其重要。
因此，现有技术中存在手机应用不能一直处于激活状态，使得用户使用手机应用时需要手动打开，不能及时响应与设备或服务器的交互的问题，导致用户体验不好。
发明内容
考虑到上述问题而提出了本发明。根据本发明实施例的提供了一种手机应用保活方法、装置、系统及计算机存储介质，以解决手机应用不能一直处于激活状态，使得用户使用手机应用时需要手动打开，不能及时响应与设备或服务器的交互的问题。
根据本发明实施例的第一方面，提供了一种手机应用保活方法，所述方法包括：
启动手机应用，其包括启动所述手机应用的保活进程和业务进程；
当所述手机应用关闭时，基于至少一个预定策略使所述手机应用保活；
其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。
示例性地，所述基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程包括：
所述保活进程中的第一类型服务向手机系统添加定时任务；
手机系统根据所述定时任务定时拉起所述第一类型服务。
示例性地，所述增加所述手机应用的优先级包括：所述业务进程中的第二类型服务向手机系统添加无感通知。
示例性地，所述基于所述保活进程和所述业务进程的互相监测进行互拉包括：
所述保活进程和所述业务进程相互监测对方的生命周期；
当所述保活进程被手机系统关闭，则所述业务进程将所述保活进程拉起；
当所述业务进程被手机系统关闭，则所述保活进程将所述保活进程拉起。
示例性地，所述保活进程和所述业务进程相互监测对方的生命周期包括：
所述保活进程和所述业务进程之间通过跨进程通信监测对方的生命周期。
示例性地，所述预定策略还包括：提示用户将所述手机应用加入手机的后台运行白名单。
示例性地，所述手机应用关闭包括：
手机系统自动关闭所述手机应用或用户关闭所述手机应用或第三方应用关闭所述手机应用。
根据本发明实施例的第二方面，提供了一种手机应用保活装置，所述装置包括：
启动模块，用于启动手机应用，其包括启动所述手机应用的保活进程和业务进程；
保活模块，当所述手机应用关闭时，基于预定策略使所述手机应用保活；
其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。
示例性地，所述基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程包括：
所述保活进程中的第一类型服务向手机系统添加定时任务；
手机系统根据所述定时任务定时拉起所述第一类型服务。
示例性地，所述增加所述手机应用的优先级包括：所述业务进程中的第二类型服务向手机系统添加无感通知。
示例性地，所述基于所述保活进程和所述业务进程的互相监测进行互拉包括：
所述保活进程和所述业务进程相互监测对方的生命周期；
当所述保活进程被手机系统关闭，则所述业务进程将所述保活进程拉起；
当所述业务进程被手机系统关闭，则所述保活进程将所述保活进程拉起。
示例性地，所述保活进程和所述业务进程相互监测对方的生命周期包括：
所述保活进程和所述业务进程之间通过跨进程通信监测对方的生命周期。
示例性地，所述预定策略还包括：提示用户将所述手机应用加入手机的后台运行白名单。
示例性地，所述手机应用关闭包括：
手机系统自动关闭所述手机应用或用户关闭所述手机应用或第三方应用关闭所述手机应用。
根据本发明实施例的第三方面，提供了一种手机应用保活系统，包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本发明实施例的第一方面所述方法的步骤。
根据本发明实施例的第四方面，提供了一种计算机存储介质，其上存储有计算机程序，所述计算机程序被计算机执行时实现本发明实施例的第一方面所述方法的步骤。
根据本发明提供的手机应用保活方法、装置、系统及计算机存储介质，通过多种拉起进程的策略的结合以使所述手机应用的保持存活，实现了用户需要使用手机应用时无需手动打开的功能，能够及时响应与设备或服务器的交互，提高用户体验。
附图说明
通过结合附图对本发明实施例进行更详细的描述，本发明的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与本发明实施例一起用于解释本发明，并不构成对本发明的限制。在附图中，相同的参考标号通常代表相同部件或步骤。
图1是用于实现根据本发明实施例的一种手机应用保活方法的流程示意图；
图2是用于实现根据本发明实施例的一种手机应用保活方法的示例；
图3是用于实现根据本发明实施例的一种手机应用保活装置的示意性框图。
具体实施方式
为了使得本发明的目的、技术方案和优点更为明显，下面将参照附图详细描述根据本发明的示例实施例。显然，所描述的实施例仅仅是本发明的一部分实施例，而不是本发明的全部实施例，应理解，本发明不受这里描述的示例实施例的限制。基于本发明中描述的本发明实施例，本领域技术人员在没有付出创造性劳动的情况下所得到的所有其它实施例都应落入本发明的保护范围之内。
随着现在智能手机的普及，越来越多的手机应用充斥着各种市场，然后并不是每一个应用都会在手机里使用，不是每一个应用都会被经常使用，所以，Android手机有自己的一套内存管理方法，当手机在一定时间内没有使用该应用，那么可能会被关闭。但是如果手机应用一直处于激活状态下去的话，手机再次打开的时候，这个应用的使用会比较快速，这种方式也能得到了用户的青睐。
在Android中，进程依据重要性被分为5级，越高级的进程越重要，在内存不够回收进程时也会越晚被回收：
前台进程(Foreground process)：指用户当前操作必须的进程。一般来说，系统中仅存在极少的前台进程，而且它们会到最后才被回收掉。
可见进程(Visible process)：正在执行某些用户可见操作的进程。当关闭这些进程时，用户会有一定的影响。
服务进程(Service process)：拥有一个正在运行的Service的进程。通常这种进程都是不可见的，会在运行较长的时候后考虑降级回收掉。
后台进程(Background process)：这是一种对用户体验没有直接影响的进程，系统会在需要内存的时候随时回收这种进程，这种进程通常会持有一个已调用onStop方法的Activity。
空进程(Empty process)：不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间。为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。
一般来说，Android进程被关闭有以下几种情况：触发系统进程管理机制回收(Lowmemory killer)：这种方法会按照阈值从大到小进行清理；被没有进行Root的第三方应用关闭(使用kill Backg round Process方法)：这种方法只能关闭OOM_ADJ为4以上的进程；被进行Root的第三方应用关闭(使用force-stop或者kill)：理论上来说可以关闭所有进程，但一般只会清理非系统关键进程和非前台可见进程；厂商的杀进程功能(force-stop或者kill)：理论上来说可以关闭所有进程，包括Linux原生进程；用户主动“强行停止”进程(force-stop)：只能停用第三方和非system/phone进程应用(停用system进程应用会造成Android系统重启)。
其中，触发系统进程管理机制回收(Low memory killer)具体包括：Android系统是基于Linux系统，他继承了Linux的内存管理策略，即使当用户退出应用程序之后，应用程序的进程也还是存在于系统中，这样是为了方便程序的再次启动，但是这样的话，随着打开的程序数量的增加，系统的内存会变得不足，就需要杀掉一部分进程以释放内存空间。至于是否需要关闭一些进程和哪些进程需要被关闭，是通过Low Memory Killer机制来进行判定的，它是基于Linux内核的OOM Killer(Out-Of-Memory killer)机制诞生。采取的判定标准就是该进程的OOM_ADJ值的大小。OOM_ADJ是Linux内核分配给每个系统进程的一个值，代表进程的优先级，进程回收机制就是根据这个优先级来决定是否进行回收。进程OOM_ADJ值越大，越容易被终止；普通应用程序进程的OOM_ADJ>＝0,系统应用进程的OOM_ADJ才可能<0；进程OOM_ADJ值不是固定不变的，随着用户的操作，每个应用进程的优先级都会发生变化，进程对应的OOM_ADJ值也会因此改变。比较容易被关闭的Android进程OOM_ADJ>＝4,不容易被关闭的Android进程OOM_ADJ在0-3之间，非Android进程(即纯Linux进程)OOM_ADJ＜0。在Low Memory Killer回收内存时会根据进程的级别优先关闭OOM_ADJ比较大的进程，对于优先级相同的进程则进一步受到进程所占内存和进程存活时间的影响。
基于上述考虑，本发明实施例提供了一种手机应用保活方法。参见图1，图1示出了用于实现本发明实施例的一种手机应用保活方法的流程示意图。如图1所示，所述方法100包括：
首先，在步骤S110中，启动手机应用，其包括启动所述手机应用的保活进程和业务进程；
在步骤S120中，当所述手机应用关闭时，基于至少一个预定策略使所述手机应用保活；
其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。
手机应用保活是指当手机应用的进程在被关闭后马上启动，而不是保证手机应用的进程不被关闭。所述手机应用保活的基本策略中，通过采用定时任务使手机系统定时拉起所述手机应用的保活进程，增加所述手机应用的优先级，基于所述保活进程和所述业务进程的互相监测进行互拉均是合理利用手机系统本身的机制，绕过手机本身的限制，实现Android手机应用的保活。可以理解，可以通过所述预定策略中的一个进行手机应用的保活，也可以通过多个所述预定策略的几个进行手机应用的保活，在此不做限制。
根据本发明实施例的手机应用保活方法可以部署在个人终端处，例如智能电话、平板电脑、个人计算机等；还可以分布地部署在服务器端(或云端)。
根据本发明实施例提供的手机应用保活方法，通过多种拉起进程的策略的结合以使所述手机应用的保持处于激活状态，实现了用户需要使用手机应用时无需手动打开的功能，能够及时响应与设备或服务器的交互，提高用户体验。
根据本发明实施例，在步骤S110中，所述保活进程可以是手机应用中用于保持手机应用在后台运行的进程。
示例性地，所述手机系统将所述手机应用关闭包括：
手机系统自动关闭所述手机应用或用户关闭所述手机应用或第三方应用关闭所述手机应用。
根据本发明实施例，在步骤S120中，所述基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程包括：
所述保活进程中的第一类型服务向手机系统添加定时任务；
手机系统根据所述定时任务定时拉起所述第一类型服务。
在一个实施例中，所述第一类型服务可以是KeepAliveService。
在一个实施例中，所述添加定时任务包括：采用JobScheduler添加所述定时任务。
在一个实施例中，所述定时任务包括：在预定时间或预定时间间隔拉起所述保活进程。
其中，JobScheduler是在Android 5.0中引入的一个能够执行某项任务的API(Application Programming Interface,应用程序编程接口)，它允许APP(Application，应用)在将来达到一定条件时执行指定的任务。通常情况下，即使APP被强制停止，预定的任务仍然会被执行。
Android 5.0系统以后，为了优化Android系统，提高使用流畅度以及延长电池续航，加入了在应用后台/锁屏时，系统会回收应用，同时自动销毁应用拉起的Service的机制。同时为了满足在特定条件下需要执行某些任务的需求，在全新一代操作系统上，采取了Job(jobservice&JobInfo)的方式，即每个需要后台的业务处理为一个job，通过系统管理job，来提高资源的利用率，从而提高性能，节省电源。这样又能满足APP开发商的要求，又能满足系统性能的要求。所以，可以采用JobScheduler来添加定时任务，然后手机系统根据所述定时任务定时拉起相应的进程以保活所述手机应用。可以理解，采用JobScheduler向手机系统添加定时任务的基本策略适用于Android 5.0以上系统。
在一个实施例中，采用JobScheduler向手机系统添加定时任务包括：首先在一个实现了JobService的子类的onStartJob方法中执行定时任务，使用JobInfo的Builder方法来设定条件并和实现了JobService的子类的组件名绑定，然后调用系统服务JobScheduler的schedule方法。这样，即便在执行定时任务之前应用程序进程被杀，也不会导致定时任务不会执行，因为系统服务JobScheduler会使用bindServiceAsUser的方法把实现了JobService的子类服务启动起来，并执行它的onStartJob方法。
由上述可知，Jobscheduler是通过Jobservice服务和JobInfo搭配来完成特定情况下需要完成的各种工作的一个新组件，不仅对系统环境的友好，同时在特定的预置条件下执行任务也节省了手机的电量，节约了系统资源。
根据本发明实施例，在步骤S120中，所述增加所述手机应用的优先级包括：所述业务进程中的第二类型服务向手机系统添加无感通知。
在一个实施例中，所述第二类型服务可以是CoreService。
其中，手机系统会对处于不同状态的进程设置不同的优先级。但实际上，进程的状态是一直在变化中的。例如：用户可以随时会启动一个新的Activity，或者将一个前台的Activity切换到后台。在这个时候，发生状态变化的Activity的所在进程的优先级就需要进行更新。并且，Activity可能会使用其他的Service或者ContentProvider。当Activity的进程优先级发生变化的时候，它所使用的Service或者ContentProvider的优先级也应当发生变化。
在Android中，例如优先级Service的优先级为第一优先级，通过setForeground接口可以将后台Service设置为前台Service，使进程的优先级由第一优先级提升为第二优先级，从而使进程的优先级仅仅低于用户当前正在交互的进程，与可见进程优先级一致，使进程被关闭的概率大大降低。从Android2.3开始调用setForeground将后台Service设置为前台Service时，必须在系统的通知栏发送一条通知，也就是前台Service与一条可见的通知时绑定在一起的。基于上述考虑，可以采用想手机系统添加无感通知以解决上述可见通知的问题。
在一个实施例中，所述业务进程中的第二类型服务向手机系统添加无感通知可以包括：通过实现一个内部Service，在CoreService和其内部Service中同时发送具有相同ID的Notification，然后将内部Service结束掉。随着内部Service的结束，Notification将会消失，但系统优先级依然保持为第二优先级。这样，业务进程中的CoreService向手机系统中添加无感Notification，增加APP的优先级，减少APP被手机系统关闭的概率。
由于Android系统进行了改进，采用增加所述手机应用的优先级的基本策略适用于Android 7.0以下(不包括Android 7.0)系统，对于Android 7.0及以上的系统也会在通知栏显示通知，从而无法实现无感通知。
根据本发明实施例，在步骤S120中，所述基于所述保活进程和所述业务进程的互相监测进行互拉包括：
所述保活进程和所述业务进程相互监测对方的生命周期；
当所述保活进程被手机系统关闭，则所述业务进程将所述保活进程拉起；
当所述业务进程被手机系统关闭，则所述保活进程将所述保活进程拉起。
示例性地，所述保活进程和所述业务进程相互监测对方的生命周期包括：
所述保活进程和所述业务进程之间通过跨进程通信监测对方的生命周期。
其中，通过两个进程互相监测进行双进程互拉以实现手机应用的保活，即利用两个进程如业务线程和保活进程，它们彼此双向绑定来对手机应用进行守护，类似于采用“环”的形式来进行互拉，无论那个进程被关闭，最后活着的进程都能够将其他被杀进程拉起来。进一步地，为了防止两个进程同时被系统关闭，可以采取高低优先级与双进程互相监测结合的方式来解决。
在一个实施例中，所述基于所述保活进程和所述业务进程的互相监测进行互拉可以包括：保活进程的KeepAliveService与业务进程的CoreService互相监控对方的生命周期，当保活进程被关闭了，业务进程就将保活进程拉起，当业务进程被关闭了，保活进程就将业务进程拉起，最终实现双进程互拉。可以理解，采用两个进程互相监测进行双进程互拉的基本策略适用于Android任何版本的系统。
根据本发明实施例，所述方法100中所述预定策略还可以包括：提示用户将所述手机应用加入手机的后台运行白名单。
其中，后台运行白名单表示可以信任的重要进程，是手机制造厂商根据实际需要以及多方面考虑设置的默认可以一直保活的手机应用。后台运行白名单上的手机应用不用采取其他方法可以一直处于保活状态。
在采用上述预定策略拉起后，手机应用应该只做一些必要的操作，否则会比较耗电，也容易再次被系统关闭。由于手机可能修改Android系统机制以应对上述的预定策略，所以还可以采用提示用户将手机应用添加在后台运行白名单中，以进一步提高手机应用的保活成功率。
在一个实施例中，参见图2，图2示出了根据本发明实施例的一种手机应用保活方法的示例。如图2所示，一种手机应用保活方法200包括：
首先，启动手机应用，此时所述手机应用的保活进程和业务进程也启动；
然后，当手机系统自动关闭所述手机应用或用户关闭所述手机应用或第三方应用关闭所述手机应用时，基于如下预定策略使所述手机应用保活：
基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；具体包括：在一个实现了JobService的子类的onStartJob方法中执行定时任务，使用JobInfo的Builder方法来设定条件并和实现了JobService的子类的组件名绑定，然后调用系统服务JobScheduler的schedule方法。这样，即便在执行定时任务之前应用程序进程被杀，也不会导致定时任务不会执行，因为系统服务JobScheduler会使用bindServiceAsUser的方法把实现了JobService的子类服务启动起来，并执行它的onStartJob方法；手机系统根据所述定时任务，在预定时间或预定时间间隔拉起所述保活进程。
增加所述手机应用的优先级；具体包括：通过实现一个内部Service，在CoreService和其内部Service中同时发送具有相同ID的Notification，然后将内部Service结束掉。随着内部Service的结束，Notification将会消失，但系统优先级依然保持为较高优先级。
基于所述保活进程和所述业务进程的互相监测进行互拉；具体包括：保活进程的KeepAliveService与业务进程的CoreService互相监控对方的生命周期，当保活进程被关闭了，业务进程就将保活进程拉起，当业务进程被关闭了，保活进程就将业务进程拉起，最终实现保活进程与业务进程的互拉。
提示用户将所述手机应用加入手机的后台运行白名单。
由此可知，通过上述多种保活手机应用的策略的结合以使所述手机应用的保持处于激活状态，实现了用户需要使用手机应用时无需手动打开的功能，能够及时响应与设备或服务器的交互，提高用户体验。
参见图3，图3示出了根据用于实现本发明的实施例的手机应用保活装置的示意性框图。如图3所示，所述装置300包括：
启动模块310，用于启动手机应用，其包括启动所述手机应用的保活进程和业务进程；
保活模块320，当系统将所述手机应用关闭时，基于预定策略使所述手机应用保活；
其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。
示例性地，所述保活进程可以是手机应用中用于保持手机应用在后台运行的进程。
示例性地，所述手机系统将所述手机应用关闭包括：手机系统自动关闭所述手机应用或用户关闭所述手机应用或第三方应用关闭所述手机应用。
根据本发明实施例，所述保活模块320可以包括：
定时拉起模块321，用于基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；
优先级模块322，用于或增加所述手机应用的优先级；
互拉模块323，用于基于所述保活进程和所述业务进程的互相监测进行互拉。
示例性地，所述定时拉起模块321可以进一步用于：
所述保活进程中的第一类型服务向手机系统添加定时任务；
手机系统根据所述定时任务定时拉起所述第一类型服务。
在一个实施例中，所述第一类型服务可以是KeepAliveService。
在一个实施例中，所述添加定时任务包括：采用JobScheduler添加所述定时任务。
在一个实施例中，所述定时任务包括：在预定时间或预定时间间隔拉起所述保活进程。
Android 5.0系统以后，为了优化Android系统，提高使用流畅度以及延长电池续航，加入了在应用后台/锁屏时，系统会回收应用，同时自动销毁应用拉起的Service的机制。同时为了满足在特定条件下需要执行某些任务的需求，在全新一代操作系统上，采取了Job(jobservice&JobInfo)的方式，即每个需要后台的业务处理为一个job，通过系统管理job，来提高资源的利用率，从而提高性能，节省电源。这样又能满足APP开发商的要求，又能满足系统性能的要求。所以，可以采用JobScheduler来添加定时任务，然后手机系统根据所述定时任务定时拉起相应的进程以保活所述手机应用。可以理解，采用JobScheduler向手机系统添加定时任务的基本策略适用于Android 5.0以上系统。
在一个实施例中，定时拉起模块321采用JobScheduler向手机系统添加定时任务包括：首先在一个实现了JobService的子类的onStartJob方法中执行定时任务，使用JobInfo的Builder方法来设定条件并和实现了JobService的子类的组件名绑定，然后调用系统服务JobScheduler的schedule方法。这样，即便在执行定时任务之前应用程序进程被杀，也不会导致定时任务不会执行，因为系统服务JobScheduler会使用bindServiceAsUser的方法把实现了JobService的子类服务启动起来，并执行它的onStartJob方法。
由上述可知，Jobscheduler是通过Jobservice服务和JobInfo搭配来完成特定情况下需要完成的各种工作的一个新组件，不仅对系统环境的友好，同时在特定的预置条件下执行任务也节省了手机的电量，节约了系统资源。
示例性地，所述优先级模块322可以进一步用于：
所述业务进程中的第二类型服务向手机系统添加无感通知。
在一个实施例中，所述第二类型服务可以是CoreService。
其中，手机系统会对处于不同状态的进程设置不同的优先级。但实际上，进程的状态是一直在变化中的。例如：用户可以随时会启动一个新的Activity，或者将一个前台的Activity切换到后台。在这个时候，发生状态变化的Activity的所在进程的优先级就需要进行更新。并且，Activity可能会使用其他的Service或者ContentProvider。当Activity的进程优先级发生变化的时候，它所使用的Service或者ContentProvider的优先级也应当发生变化。
在Android中，例如优先级Service的优先级为第一优先级，通过setForeground接口可以将后台Service设置为前台Service，使进程的优先级由第一优先级提升为第二优先级，从而使进程的优先级仅仅低于用户当前正在交互的进程，与可见进程优先级一致，使进程被关闭的概率大大降低。从Android2.3开始调用setForeground将后台Service设置为前台Service时，必须在系统的通知栏发送一条通知，也就是前台Service与一条可见的通知时绑定在一起的。基于上述考虑，可以采用想手机系统添加无感通知以解决上述可见通知的问题。
在一个实施例中，所述优先级模块322通过实现一个内部Service，在CoreService和其内部Service中同时发送具有相同ID的Notification，然后将内部Service结束掉。随着内部Service的结束，Notification将会消失，但系统优先级依然保持为第二优先级。这样，业务进程中的CoreService向手机系统中添加无感Notification，增加APP的优先级，减少APP被手机系统关闭的概率。
由于Android系统进行了改进，采用增加所述手机应用的优先级的基本策略适用于Android 7.0以下(不包括Android 7.0)系统，对于Android 7.0及以上的系统也会在通知栏显示通知，从而无法实现无感通知。
示例性地，所述互拉模块323可以进一步用于：在所述保活进程和所述业务进程相互监测对方的生命周期时，当所述保活进程被手机系统关闭，则所述业务进程将所述保活进程拉起；当所述业务进程被手机系统关闭，则所述保活进程将所述保活进程拉起。
示例性地，所述保活进程和所述业务进程相互监测对方的生命周期包括：所述保活进程和所述业务进程之间通过跨进程通信监测对方的生命周期。
其中，通过两个进程互相监测进行双进程互拉以实现手机应用的保活，即利用两个进程如业务线程和保活进程，它们彼此双向绑定来对手机应用进行守护，类似于采用“环”的形式来进行互拉，无论那个进程被关闭，最后活着的进程都能够将其他被杀进程拉起来。进一步地，为了防止两个进程同时被系统关闭，可以采取高低优先级与双进程互相监测结合的方式来解决。
在一个实施例中，所述基于所述保活进程和所述业务进程的互相监测进行互拉可以包括：保活进程的KeepAliveService与业务进程的CoreService互相监控对方的生命周期，当保活进程被关闭了，业务进程就将保活进程拉起，当业务进程被关闭了，保活进程就将业务进程拉起，最终实现双进程互拉。可以理解，采用两个进程互相监测进行双进程互拉的基本策略适用于Android任何版本的系统。
示例性地，所述保活模块320可以包括：
提示模块324，用于提示用户将所述手机应用加入手机的后台运行白名单。
其中，后台运行白名单表示可以信任的重要进程，是手机制造厂商根据实际需要以及多方面考虑设置的默认可以一直保活的手机应用。后台运行白名单上的手机应用不用采取其他方法可以一直处于保活状态。
在采用上述预定策略拉起后，手机应用应该只做一些必要的操作，否则会比较耗电，也容易再次被系统关闭。由于手机可能修改Android系统机制以应对上述的预定策略，所以提示模块324可以采用提示用户将手机应用添加在后台运行白名单中，以进一步提高手机应用的保活成功率。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
根据本发明的另一方面，提供一种手机应用保活系统，包括存储器、以及处理器；
所述存储器存储用于实现根据本发明实施例的手机应用保活方法中的相应步骤的程序代码；
所述处理器用于运行所述存储器中存储的程序代码，以执行以上根据本发明实施例的手机应用保活方法的相应步骤。
在一个实施例中，在所述程序代码被所述处理器运行时执行以上根据本发明实施例的前述手机应用保活方法的相应步骤。
此外，根据本发明的另一方面，还提供了一种计算机可读存储介质，在所述存储介质上存储了程序指令，在所述程序指令被计算机或处理器运行时用于执行本发明实施例的手机应用保活方法的相应步骤，并且用于实现根据本发明实施例的手机应用保活系统。
示例性地，所述计算机可读存储介质可以是一个或多个计算机可读存储介质的任意组合。
在一个实施例中，所述计算机程序指令在被计算机运行时可以实现根据本发明实施例的前述手机应用保活方法。
根据本发明实施例提供的手机应用保活方法、装置、系统和存储介质，通过多种拉起进程的策略的结合以使所述手机应用的保持存活，实现了用户需要使用手机应用时无需手动打开的功能，能够及时响应与设备或服务器的交互，提高用户体验。
尽管这里已经参考附图描述了示例实施例，应理解上述示例实施例仅仅是示例性的，并且不意图将本发明的范围限制于此。本领域普通技术人员可以在其中进行各种改变和修改，而不偏离本发明的范围和精神。所有这些改变和修改意在被包括在所附权利要求所要求的本发明的范围之内。
以上所述，仅为本发明的具体实施方式或对具体实施方式的说明，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种手机应用保活方法，其特征在于，所述方法包括：
启动手机应用，其包括启动所述手机应用的保活进程和业务进程；
当所述手机应用关闭时，基于至少一个预定策略使所述手机应用保活；
其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。
2.如权利要求1所述的方法，其特征在于，所述基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程包括：
所述保活进程中的第一类型服务向手机系统添加定时任务；
手机系统根据所述定时任务定时拉起所述第一类型服务。
3.如权利要求1所述的方法，其特征在于，所述增加所述手机应用的优先级包括：
所述业务进程中的第二类型服务向手机系统添加无感通知。
4.如权利要求1所述的方法，其特征在于，所述基于所述保活进程和所述业务进程的互相监测进行互拉包括：
所述保活进程和所述业务进程相互监测对方的生命周期；
当所述保活进程被手机系统关闭，则所述业务进程将所述保活进程拉起；
当所述业务进程被手机系统关闭，则所述保活进程将所述保活进程拉起。
5.如权利要求4所述的方法，其特征在于，所述保活进程和所述业务进程相互监测对方的生命周期包括：
所述保活进程和所述业务进程之间通过跨进程通信监测对方的生命周期。
6.如权利要求1所述的方法，其特征在于，所述预定策略还包括：提示用户将所述手机应用加入手机的后台运行白名单。
7.如权利要求1所述的方法，其特征在于，所述手机应用关闭包括：
手机系统自动关闭所述手机应用或用户关闭所述手机应用或第三方应用关闭所述手机应用。
8.一种手机应用保活装置，其特征在于，所述装置包括：
启动模块，用于启动手机应用，其包括启动所述手机应用的保活进程和业务进程；
保活模块，当系统将所述手机应用关闭时，基于预定策略使所述手机应用保活；
其中，所述预定策略包括：基于所述保活进程中的定时任务，手机系统定时拉起所述保活进程；或增加所述手机应用的优先级；或基于所述保活进程和所述业务进程的互相监测进行互拉。
9.一种手机应用保活系统，包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。
10.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被计算机执行时实现权利要求1至7中任一项所述方法的步骤。
CN201910267118.3A 2019-04-03 2019-04-03 手机应用保活方法、装置、系统及存储介质 Pending CN111782347A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910267118.3A CN111782347A (zh) 2019-04-03 2019-04-03 手机应用保活方法、装置、系统及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910267118.3A CN111782347A (zh) 2019-04-03 2019-04-03 手机应用保活方法、装置、系统及存储介质

Publications (1)

Publication Number Publication Date
CN111782347A true CN111782347A (zh) 2020-10-16

Family

ID=72755537

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910267118.3A Pending CN111782347A (zh) 2019-04-03 2019-04-03 手机应用保活方法、装置、系统及存储介质

Country Status (1)

Country Link
CN (1) CN111782347A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114222164A (zh) * 2021-12-17 2022-03-22 深圳Tcl新技术有限公司 一种视频推流方法、装置、智能设备和存储介质
JP7352308B1 (ja) 2022-03-10 2023-09-28 株式会社フロンティア・フィールド パケット監視装置、パケット監視システム、パケット監視方法、パケット監視プログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002111674A (ja) * 2000-09-26 2002-04-12 Hitachi Ltd コネクション管理方法およびシステムおよび前記方法を実現するプログラムを記録したコンピュータ読み取り可能な記録媒体
CN105335171A (zh) * 2014-06-24 2016-02-17 北京奇虎科技有限公司 应用程序常驻操作系统后台的方法及装置
CN105653934A (zh) * 2015-12-25 2016-06-08 惠州Tcl移动通信有限公司 移动终端及其应用保护方法
CN107844342A (zh) * 2017-11-21 2018-03-27 广东欧珀移动通信有限公司 应用程序保活的管控方法、装置及存储介质和移动终端
CN109379337A (zh) * 2018-09-18 2019-02-22 四川长虹电器股份有限公司 一种安卓平台下应用进程的保活方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002111674A (ja) * 2000-09-26 2002-04-12 Hitachi Ltd コネクション管理方法およびシステムおよび前記方法を実現するプログラムを記録したコンピュータ読み取り可能な記録媒体
CN105335171A (zh) * 2014-06-24 2016-02-17 北京奇虎科技有限公司 应用程序常驻操作系统后台的方法及装置
CN105653934A (zh) * 2015-12-25 2016-06-08 惠州Tcl移动通信有限公司 移动终端及其应用保护方法
CN107844342A (zh) * 2017-11-21 2018-03-27 广东欧珀移动通信有限公司 应用程序保活的管控方法、装置及存储介质和移动终端
CN109379337A (zh) * 2018-09-18 2019-02-22 四川长虹电器股份有限公司 一种安卓平台下应用进程的保活方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
干掉CRASH: "【腾讯Bugly干货分享】Android进程保活招式大全 - 知乎", pages 1 - 4, Retrieved from the Internet <URL:https://zhuanlan.zhihu.com/p/21987083?utm_id=0> *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114222164A (zh) * 2021-12-17 2022-03-22 深圳Tcl新技术有限公司 一种视频推流方法、装置、智能设备和存储介质
JP7352308B1 (ja) 2022-03-10 2023-09-28 株式会社フロンティア・フィールド パケット監視装置、パケット監視システム、パケット監視方法、パケット監視プログラム
JP2023144164A (ja) * 2022-03-10 2023-10-11 株式会社フロンティア・フィールド パケット監視装置、パケット監視システム、パケット監視方法、パケット監視プログラム

Similar Documents

Publication Publication Date Title
CN104252389B (zh) 应用程序运行方法、系统
US20060136882A1 (en) System and method for background JAVA application resource control
CN101873616B (zh) 一种移动终端自检的方法、系统及移动终端
US11429461B2 (en) Broadcast control method and apparatus, and terminal
WO2017211226A1 (zh) 展示媒体文件的方法、终端和存储介质
CN103425506A (zh) 关机方法及开机方法及通信终端
CN111782347A (zh) 手机应用保活方法、装置、系统及存储介质
CN108008950B (zh) 一种用户界面更新的实现方法及装置
CN104503828A (zh) 一种进程管理方法及终端
US20160044157A1 (en) Method for managing data traffic of software and portable electronic apparatus using the same
CN106155777A (zh) 一种后台应用管理装置、终端及后台应用管理方法
CN111913851A (zh) 进程监控方法、系统、终端及存储介质
CN105653974A (zh) 一种文档防护方法及装置
CN111143170A (zh) 云手机监控系统和方法
CN112732674A (zh) 云平台服务管理方法、装置、设备及可读存储介质
CN112445530B (zh) 第三方应用程序保活方法及设备
CN117234698B (zh) 一种程序异常处理方法、电子设备及存储介质
US20120137155A1 (en) Electronic apparatus and power saving control method for electronic apparatus
CN105824660A (zh) 一种应用程序的更新方法及终端
CN105242964A (zh) 应用运行监控方法及系统
CN103297600A (zh) 移动终端和移动终端系统自动重启方法
CN113542256A (zh) 客户端中登录凭证的更新方法、装置、设备及存储介质
CN104102498A (zh) 一种移动终端及其开机方法
CN112636978A (zh) 安全事件处理方法、装置、设备及计算机可读存储介质
CN111783081A (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