一种应用程序的保活方法和装置制造方法及图纸

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

Method and device for keeping alive of application program

Keep alive method and device of the invention provides a application program, through the dependence of the first service registration and service second, were killed in the second service, the first service corresponding to the first application by binding the second service request, service manager out there are second services in judgment, to create second service, and re created to accommodate second service second applications, so as to achieve the second program alive. The scheme adopted in this application does not require active interaction to achieve live protection, but only when the second program is killed, it reduces the waste of computing resources and power consumption. And, when the second program is killed, you can recreate the second program to save the second program that is alive.

【技术实现步骤摘要】
一种应用程序的保活方法和装置
本申请涉及终端
，尤其涉及一种应用程序的保活方法和装置。
技术介绍
由于系统运行时资源的限制，因此应用程序无法保持较长时间存活、无法实现一些时效性要求很高的功能。应用程序保活对于一些需要强实时消息推送、发警告通知、运营信息更新等场景乃至提升人机交互的连续性、流畅性等都有重大价值。现有的技术大多数的方案通过应用程序之间主动交互来实现保活，若交互达不到预期效果或抛出了异常，便认为对端程序已经消亡。这种主动交互既浪费计算资源(继而消耗电量)又需要用心控制交互的频率来实现保活。并且，采用这种主动交互的方法，并不能对对端程序的消亡做任何挽救，对于应用程序之间的相互支撑仍然存在一定的不足。
技术实现思路
本申请实施例提出了一种应用程序的保活方法和装置，用以实现对被保活程序的挽救。在一个方面，本申请实施例提供了一种应用程序的保活方法，包括：第一应用程序发起绑定第二应用程序的第二服务的请求；在服务管理器判断出存在第二服务时，所述第二应用程序向所述第一应用程序返回所述第二服务的代理对象；所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系；在所述第二服务被杀死时，所述服务管理器根据所述依赖关系通知所述第一服务；第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求；所述服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。在另一个方面，本申请实施例提供了一种应用程序的保活装置，包括：第一应用程序、第二应用程序以及服务管理器，所述第一应用程序包括第一服务，所述第二应用程序包括第二服务，其中：所述第一应用程序发起绑定所述第二服务的请求；所述第二应用程序向所述第一应用程序返回所述第二服务的代理对象；所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系；在所述第二服务被杀死时，所述服务管理器根据所述依赖关系通知所述第一服务；第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求；服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。有益效果如下：在本专利技术实施例中，通过第一服务注册与第二服务的依赖关系，在第二服务被杀死时，第一服务对应的第一应用程序发起绑定所述第二服务的请求，服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序，从而实现了对第二程序的保活。本专利技术实施例采用的方案，不需要主动交互来实现保活，而仅仅是在该第二程序被杀死时才进行操作，降低了计算资源和电量的浪费。并且，在第二程序被杀死时，可以重新创建第二程序，实现对被保活的第二程序的挽救。附图说明下面将参照附图描述本申请的具体实施例，其中：图1示出了安卓系统的Binder机制组件结构示意图；图2示出了本申请实施例中应用程序的保活方法的流程示意图；图3示出了本申请实施例一中应用程序的保活方法的流程示意图；图4示出了本申请实施例中应用程序的保活装置的结构示意图。具体实施方式为了使本申请的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。并且在不冲突的情况下，本说明书中的实施例及实施例中的特征可以互相结合。专利技术人在专利技术过程中注意到：为了跟踪Server(服务方)对象是存活着还是已经消亡，Android(安卓)SDK(SoftwareDevelopmentKit，软件开发工具包)提供了androidos出inder.DeathRecipient类来监听Server对象消亡的事件。基于此，专利技术人想到一种利用Binder(绑定者)机制来进行安卓应用程序保活的方法和装置，下面进行详细说明。为了实现系统自带的服务和上层应用能够跨越进程边界与其他应用交互而设计了Binder这一IPC(Inter-ProcessCommunication，进程间通信)机制。安卓系统的Binder机制由一系列组件组成，分别是客户方(Client)、服务方、服务管理器(ServiceManager)和Binder驱动程序，其中客户方、服务方和服务管理器运行在用户空间，Binder驱动程序运行在内核空间。Binder就是一种把这四个组件粘合在一起的粘结剂了，其中，核心是Binder驱动程序，其在内核空间实现让不同用户空间进程之间通信的功能，服务管理器提供了服务管理的功能，客户方和服务方正是在Binder驱动程序和服务管理器提供的基础设施上进行双向通信的实体。构成Binder通信的四个组件之间的关系如图1所示。客户方、服务方和服务管理器实现在用户空间中，Binder驱动程序实现在内核空间中。Binder驱动程序和服务管理器在Android平台中已经提供，开发者只需要在用户空间实现自己的客户方和服务方。Binder驱动程序提供设备文件/dev/binder与用户空间交互，客户方、服务方和服务管理器通过open和ioctl文件操作函数与Binder驱动程序进行通信。客户方和服务方之间的进程间通信通过Binder驱动程序间接实现。服务管理器是一个守护进程，用来管理服务方，并向客户方提供查询服务方接口的能力。在应用开发层(Java层)，安卓SDK提供了aidl这种接口定义语言来定义客户方和服务方之间的接口，之后客户方和服务方便可以遵照aidl接口的约定进行跨进程通信(对进程透明)。为了跟踪服务方对象是存活着还是已经消亡，AndroidSDK提供了android.os.Binder.DeathRecipient类来监听服务方对象消亡的事件。图2示出了本申请实施例中的安卓应用程序的保活方法，如图所示，包括：步骤201，APP1(第一应用程序)发起绑定APP2(第二应用程序)的Service2(第二服务)的请求；具体操作为App1通过bindService2绑定到Service2。Service2为App2中的一个应用组件，Service2可以独立于UI(UserInterface，用户界面)在后台运行。步骤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被杀本文档来自技高网...

【技术保护点】
一种应用程序的保活方法，其特征在于，包括：第一应用程序发起绑定第二应用程序的第二服务的请求；在服务管理器判断出存在第二服务时，所述第二应用程序向所述第一应用程序返回所述第二服务的代理对象；所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系；在所述第二服务被杀死时，所述服务管理器根据所述依赖关系通知所述第一服务；第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求；所述服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。

【技术特征摘要】
1.一种应用程序的保活方法，其特征在于，包括：第一应用程序发起绑定第二应用程序的第二服务的请求；在服务管理器判断出存在第二服务时，所述第二应用程序向所述第一应用程序返回所述第二服务的代理对象；所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系；在所述第二服务被杀死时，所述服务管理器根据所述依赖关系通知所述第一服务；第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求；所述服务管理器在判断出不存在第二服务时，重新创建第二服务，并重新创建容纳第二服务的第二应用程序。2.如权利要求1所述的方法，其特征在于，所述第一应用程序的第一服务通过所述代理对象注册与所述第二服务的依赖关系具体包括：所述第一应用程序的第一服务通过所述代理对象以所述第一服务为入参调用所述第二服务的方法linkToDeath()。3.如权利要求1所述的方法，其特征在于，根据所述依赖关系通知所述第一服务具体包括：调用Service1.binderDied()方法。4.如权利要求1所述的方法，其特征在于，第一应用程序在获知第二服务被杀死具体为：通过binderDied()回调收到了Service2被杀死的消息。5.如权利要求1所述的方法，其特征在于，所述第一应用程序在获知所述第二服务被杀死后，发起绑定所述第二服务的请求时，指明自动创建模式；根据该自动创建模式，服务管理器在判断出不存在第二服务时，自动重新创建第二服务，并重新创建容纳第二服务的第二应用程序。6.如权利要求1所述的方法，其特征在于，还包括：第二应用程序发起绑定所述第一服务的请求；所述第一应用程序向所述第二应用程序返回所述第一服务的代理对象；在所述服务管理器判断出存在第一服务时，所述第二服务通过所述代理对象注册与所述第一服务的依赖关系；在所述第一服务被杀死时，所述服务管理器根据所述依赖关系通知所述第二服务；第二应用程序在获知所述第一服务被杀死后，发起绑定所述第一服务的请求；所述服务管理器在判断出不存在第一服务时，重新创建第一服务，并重新创建容纳第一服务的第一应用程序。7.如权利要求6所述的方法，其特征在于，所述第二应用程...

【专利技术属性】
技术研发人员：王飞，
申请(专利权)人：阿里巴巴集团控股有限公司，
类型：发明
国别省市：开曼群岛,KY