一种应用程序的保活方法和装置与流程

本申请涉及终端技术领域，尤其涉及一种应用程序的保活方法和装置。

背景技术：

由于系统运行时资源的限制，因此应用程序无法保持较长时间存活、无法实现一些时效性要求很高的功能。

应用程序保活对于一些需要强实时消息推送、发警告通知、运营信息更新等场景乃至提升人机交互的连续性、流畅性等都有重大价值。

现有的技术大多数的方案通过应用程序之间主动交互来实现保活，若交互达不到预期效果或抛出了异常，便认为对端程序已经消亡。这种主动交互既浪费计算资源(继而消耗电量)又需要用心控制交互的频率来实现保活。并且，采用这种主动交互的方法，并不能对对端程序的消亡做任何挽救，对于应用程序之间的相互支撑仍然存在一定的不足。

技术实现要素：

本申请实施例提出了一种应用程序的保活方法和装置，用以实现对被保活程序的挽救。

在一个方面，本申请实施例提供了一种应用程序的保活方法，包括：

第一应用程序发起绑定第二应用程序的第二服务的请求；

在服务管理器判断出存在第二服务时，所述第二应用程序向所述第一应用程序返回所述第二服务的代理对象；

所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系；

在所述第二服务被杀死时，所述服务管理器根据所述依赖关系通知所述第一服务；

第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求；

所述服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。

在另一个方面，本申请实施例提供了一种应用程序的保活装置，包括：第一应用程序、第二应用程序以及服务管理器，所述第一应用程序包括第一服务，所述第二应用程序包括第二服务，其中：

所述第一应用程序发起绑定所述第二服务的请求；

所述第二应用程序向所述第一应用程序返回所述第二服务的代理对象；

所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系；

在所述第二服务被杀死时，所述服务管理器根据所述依赖关系通知所述第一服务；

第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求；

服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。

有益效果如下：

在本发明实施例中，通过第一服务注册与第二服务的依赖关系，在第二服务被杀死时，第一服务对应的第一应用程序发起绑定所述第二服务的请求，服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序，从而实现了对第二程序的保活。本发明实施例采用的 方案，不需要主动交互来实现保活，而仅仅是在该第二程序被杀死时才进行操作，降低了计算资源和电量的浪费。并且，在第二程序被杀死时，可以重新创建第二程序，实现对被保活的第二程序的挽救。

附图说明

下面将参照附图描述本申请的具体实施例，其中：

图1示出了安卓系统的Binder机制组件结构示意图；

图2示出了本申请实施例中应用程序的保活方法的流程示意图；

图3示出了本申请实施例一中应用程序的保活方法的流程示意图；

图4示出了本申请实施例中应用程序的保活装置的结构示意图。

具体实施方式

为了使本申请的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。并且在不冲突的情况下，本说明书中的实施例及实施例中的特征可以互相结合。

发明人在发明过程中注意到：为了跟踪Server(服务方)对象是存活着还是已经消亡，Android(安卓)SDK(Software Development Kit，软件开发工具包)提供了androidos出inder.DeathRecipient类来监听Server对象消亡的事件。基于此，发明人想到一种利用Binder(绑定者)机制来进行安卓应用程序保活的方法和装置，下面进行详细说明。

为了实现系统自带的服务和上层应用能够跨越进程边界与其他应用交互而设计了Binder这一IPC(Inter-Process Communication，进程间通信)机制。安卓系统的Binder机制由一系列组件组成，分别是客户方(Client)、服务方、服务管理器(Service Manager)和Binder驱动程序，其中客户方、服务方和服务管理器运行在用户空间，Binder驱动程序运行在内核空间。Binder就是一种把这 四个组件粘合在一起的粘结剂了，其中，核心是Binder驱动程序，其在内核空间实现让不同用户空间进程之间通信的功能，服务管理器提供了服务管理的功能，客户方和服务方正是在Binder驱动程序和服务管理器提供的基础设施上进行双向通信的实体。构成Binder通信的四个组件之间的关系如图1所示。

客户方、服务方和服务管理器实现在用户空间中，Binder驱动程序实现在内核空间中。

Binder驱动程序和服务管理器在Android平台中已经提供，开发者只需要在用户空间实现自己的客户方和服务方。

Binder驱动程序提供设备文件/dev/binder与用户空间交互，客户方、服务方和服务管理器通过open和ioctl文件操作函数与Binder驱动程序进行通信。

客户方和服务方之间的进程间通信通过Binder驱动程序间接实现。

服务管理器是一个守护进程，用来管理服务方，并向客户方提供查询服务方接口的能力。

在应用开发层(Java层)，安卓SDK提供了aidl这种接口定义语言来定义客户方和服务方之间的接口，之后客户方和服务方便可以遵照aidl接口的约定进行跨进程通信(对进程透明)。

为了跟踪服务方对象是存活着还是已经消亡，Android SDK提供了android.os.Binder.DeathRecipient类来监听服务方对象消亡的事件。

图2示出了本申请实施例中的安卓应用程序的保活方法，如图所示，包括：

步骤201，APP1(第一应用程序)发起绑定APP2(第二应用程序)的Service2(第二服务)的请求；

具体操作为App1通过bindService2绑定到Service2。Service2为App2中的一个应用组件，Service2可以独立于UI(User Interface，用户界面)在后台运行。

步骤202，服务管理器判断是否存在Service2，若是，进行步骤203，否则，进行步骤207；

步骤203，APP2向APP1返回Service2的代理对象；

该代理对象与Service2的接口保持一致，被App1持有引用。

步骤204，APP1的Service1通过该代理对象注册与Servicer2的依赖关系；

Service1为App1中的一个应用组件，Service1可以独立于UI在后台运行。本步骤即Service1以自己(实现了IBinder.DeathRecipient接口)为入参调用Service2的方法linkToDeath()(继承至IBinder接口)，从而，在Service2对象消亡的时候，Service1实现的IBinder.DeathRecipient.binderDied()会被调用(由Binder机制支持)。

步骤205，服务管理器在Service2被杀死时，根据该依赖关系通知Service1；

由于运行时资源限制，此时内存资源不够用，安卓系统需要杀死App2，在App2被杀死，则Service2也被杀死。

安卓系统的binder机制中的服务管理器接收到Service2被杀死的消息，由于Service是可以用于向其他应用导出自身服务的，可能存在其他服务依赖于Service2，所以此时需要通知bind(绑定)到Service2的位于App1中Service1，因此Service1.binderDied()方法被调用。

步骤206，APP1在获知Service2被杀死后，发起绑定Service2的请求，返回步骤202；

App1通过binderDied()回调收到了Service2被杀死的消息。

步骤207，服务管理器重新创建Service2，并重新创建容纳Service2的APP2。

在具体实现时，APP1在发起绑定Service2的请求时，可指明自动创建模式，则依据服务管理器的现有功能，即可根据该自动创建模式自动重新创建Service2。若不指明自动创建模式，则本发明实施例中服务管理器需新增在发现有APP请求绑定不存在的Service时，重新创建该Service的功能。

有益效果：本发明实施例采用的方案，不需要主动交互来实现保活，而仅 仅是在该第二程序被杀死时才进行操作，降低了计算资源和电量的浪费。并且，在第二程序被杀死时，可以重新创建第二程序，实现对被保活的第二程序的挽救。

发明人在进行本发明时是从安卓系统的binder机制切入进行思考，实际上，采用本发明实施例的方案并不局限与安卓系统，只要该系统支持本发明实施例相应的处理流程即可。

为了便于本申请的实施，下面以实施例进行说明。

实施例一：

实施例一以APP1和APP2互相保活为例进行说明，在实际场景中，APP1可以为淘宝安卓客户端，APP2可以为支付宝安卓客户端，Service1可以为淘宝Android客户端中用于推送消息的push服务，Service2可以为支付宝Android客户端中用于推送消息的push服务。

如图3所示，实施例一是本发明的一个具体实施例，其实现流程如下：

步骤301，APP1声明并创建Service1，Service1可以独立于UI在后台运行；

步骤302，APP2声明并创建Service2，Service2可以独立于UI在后台运行；

步骤303，APP1通过bindService2绑定到Service2；

即APP1发起绑定Service2的请求。

步骤304，APP2向APP1返回Service2的代理对象；

步骤305，APP1的Service1以自己为入参调用Service2的方法linkToDeath()；

即APP1的Service1通过Service2的代理对象注册与Service2的依赖关系。

步骤306，APP2通过bindService1绑定到Service1；

即APP2发起绑定Service1的请求。

步骤307，APP1向APP2返回Service1的代理对象；

步骤308，APP2的Service2以自己为入参调用Service1的方法linkToDeath()；

即APP1的Service2通过Service1的代理对象注册与Service1的依赖关系。

步骤309，服务管理器杀死Service2；

步骤310，Service1.binderDied()方法被调用，Appi通过binderDied()回调收到了Service2被杀死的消息；

步骤311，APP1发起绑定Service2的请求，指明自动创建模式；

步骤312，服务管理器自动重新创建Service2，并重新创建容纳Service2的APP2。

在图3所示的流程中，若被杀死的是Service1，则服务管理器根据所述依赖关系通知Service2；APP2发起绑定Service1的请求；服务管理器重新创建Service1，并重新创建容纳Service1的APP2。具体来说，服务管理器根据所述依赖关系通知Service2可以是：Service2.binderDied()方法被调用，App2通过binderDied()回调收到了Service1被杀死的消息。APP2发起绑定Service1的请求时，可指明自动创建模式，则依据服务管理器的现有功能，即可根据该自动创建模式自动重新创建Service1。若不指明自动创建模式，则本发明实施例中服务管理器需新增在发现有APP请求绑定不存在的Service时，重新创建该Service的功能。

基于同一发明构思，本申请实施例中还提供了一种应用程序的保活装置，由于这些设备解决问题的原理与一种应用程序的保活方法相似，因此这些设备的实施可以参见方法的实施，重复之处不再赘述。

如图4所示，本申请实施例的装置包括第一应用程序、第二应用程序以及服务管理器，所述第一应用程序包括第一服务，所述第二应用程序包括第二服务，其中：

第一应用程序发起绑定第二服务的请求；

第二应用程序向第一应用程序返回第二服务的代理对象；

第一应用程序的第一服务通过代理对象注册与第二服务的依赖关系；

在第二服务被杀死时，服务管理器根据依赖关系通知第一服务；

第一应用程序在获知第二服务被杀死后，发起绑定第二服务的请求；

服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。

进一步地，第一应用程序在获知第二服务被杀死后，发起绑定第二服务的请求时，还用于指明自动创建模式；

根据该自动创建模式，服务管理器在判断出不存在第二服务时，自动重新创建第二服务，并重新创建容纳第二服务的第二应用程序。

进一步地，本实施例的保活装置中：

第二应用程序还用于发起绑定第一服务的请求；

第一应用程序还用于向第二应用程序返回第一服务的代理对象；

在服务管理器判断出存在第一服务时，第二服务还用于通过代理对象注册与第一服务的依赖关系；

在第一服务被杀死时，服务管理器还用于根据依赖关系通知第二服务；

第二应用程序还用于在获知第一服务被杀死后，发起绑定第一服务的请求；

服务管理器还用于在判断出不存在第一服务时，重新创建第一服务，并重新创建容纳第一服务的第一应用程序。

进一步地，第二应用程序在获知第一服务被杀死后，发起绑定第一服务的请求时，还用于指明自动创建模式；

根据该自动创建模式，服务管理器在判断出不存在第一服务时，自动重新创建第一服务，并重新创建容纳第一服务的第一应用程序。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包 含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。