CN114490549A - 一种安卓应用进程守护方法和系统 - Google Patents
一种安卓应用进程守护方法和系统 Download PDFInfo
- Publication number
- CN114490549A CN114490549A CN202111611442.6A CN202111611442A CN114490549A CN 114490549 A CN114490549 A CN 114490549A CN 202111611442 A CN202111611442 A CN 202111611442A CN 114490549 A CN114490549 A CN 114490549A
- Authority
- CN
- China
- Prior art keywords
- processes
- file
- module
- daemon
- binder
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
- G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
- G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明涉及一种安卓应用进程守护方法和系统,所述方法包括:为目标应用创建两个以上的第一进程,其中所述每个第一进程具有对应的第一文件,并且所述第一进程持有所述对应的第一文件的排他锁;所述两个以上第一进程两两组成一个相互监听第一进程对,第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态;以及响应于第一进程对中的任一第一进程监听到对方第一进程对应的第一文件的排他锁被释放,所述第一进程拉起所述对方第一进程,并由拉起的所述对方第一进程拉起所述目标应用进程。本发明提供的多进程守护方案成功率高、耗电小,既满足了用户需求,也能够为产品的变现创造更多利益。
Description
技术领域
本发明涉及计算机技术领域,特别地涉及一种安卓应用进程守护方法和系统。
背景技术
由于Android系统对应用的强杀机制,使得Android应用在被系统强杀后无法立即重启,进而影响到用户的使用。一个常见的情形是某个常用的应用需要定时或在某种条件满足时触发向用户发送提醒消息。为了使用户能够接收到该消息,即使该应用处于后台而用户没有使用,但也应处于存活状态以被触发而发送提醒消息。其他常见情形包括杀毒应用需要常驻后台以随时应对病毒的入侵;即时通讯类的应用需要常驻后台以便在接收消息后提醒用户;以及,用户将正在运行的游戏设置成静默模式,虽然用户并没有操作游戏,但是仍然需要游戏继续运行。
现有技术中出现了一些对应用进行保活的技术。例如,使要保活的应用一直运行某些活动,如播放无声音乐。然而,这种方法占用系统资源,耗电严重。或者,利用系统漏洞使用startForeground()方法将当前进程伪装成前台进程。但是,一些版本的Android系统能够识别出这种伪装,因而达不到保活的目的。现有技术中还有其他一些如采用守护进程的方式,在应用被系统杀死后,由守护进程将其拉起。然而,由于某些版本的Android系统对于进程的重启有时间限制,受限于时间限制条件,在拉起应用进程之前,守护进程也已经被杀死。因而,目前还未有适用范围广、系统资源消耗小、成功率高的保活方案。
发明内容
针对现有技术中存在的技术问题,本发明提出了一种安卓应用进程守护方法和系统,用以根据需要守护目标应用进程。
为了解决上述技术问题,本发明提供了一种安卓应用进程守护方法,其包括以下步骤:为目标应用创建两个以上的第一进程,其中所述每个第一进程具有对应的第一文件,并且所述第一进程持有所述对应的第一文件的排他锁;所述两个以上第一进程两两组成一个相互监听第一进程对,第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态;以及响应于第一进程对中的任一第一进程监听到对方第一进程对应的第一文件的排他锁被释放,所述第一进程拉起所述对方第一进程,并由拉起的所述对方第一进程拉起所述目标应用进程。
另一方面,本发明还提供了一种安卓应用进程守护系统,其中包括第一进程模块、第一文件锁模块、第一监听模块以及进程启动模块,其中,所述第一进程模块为目标应用创建两个以上的第一进程;所述第一文件锁模块与所述第一进程模块相连接,为每个第一进程设置第一文件,并使每个第一进程持有其对应第一文件的排他锁;所述第一监听模块与所述第一文件锁模块相连接,将所述两个以上第一进程两两组成一个相互监听第一进程对,所述第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态,响应于第一进程对中的任一个第一进程监听到对方第一进程对应第一文件的排他锁释放,发送进程拉起请求;所述进程启动模块与所述第一监听模块相连接,在接收到进程拉起请求时,所述第一进程拉起对方第一进程,由所述拉起的对方第一进程拉起所述目标应用进程。
本发明通过多进程守护方案,不但增加了进程数据的扩展空间,弥补了传统进程守护方案中无法准确监测到目标进程被杀死的信息,而且在进程拉起时突破了系统对进程重起的时间限制,从而提高了拉起被杀进程的成功率。本发明提供的应用进程守护方法和系统能够更好地满足用户需求,例如,能够为用户在后台提供挂机和托管操作,使用户不用担心使用目标应用的过程中被接听电话,微信聊天等操作打断,并且,用户在使用其他应用的时候(如:微信、QQ、接打电话、看视频、锁屏)也可以接受目标应用的各种消息,如好友信息、游戏社区互动信息、游戏体力恢复信息等。从产品运营角度,本发明提供的方法和系统可以保证目标应用的使用时长生命周期,从而能够增加产品拉活策略,为产品的变现创造更多利益。
附图说明
下面,将结合附图对本发明的优选实施方式进行进一步详细的说明,其中:
图1是根据本发明一个实施例安卓应用进程守护方法流程图;
图2是根据本发明一个实施例实现自定义启动接口的流程图;
图3是根据本发明一个实施例一个未被杀死的进程通过自定义启动接口拉起另一个刚被杀死进程的流程图;
图4是根据本发明另一个实施例的安卓应用进程守护方法中的进程关系示意图;
图5是根据本发明另一个实施例的安卓应用进程守护方法流程图;
图6是根据本发明另一个实施例的安卓应用进程守护方法中的进程关系示意图;
图7是根据本发明又一个实施例的安卓应用进程守护方法中的进程关系示意图;
图8是根据本发明一个实施例的安卓应用进程守护流程图;
图9是根据本发明一个实施例的安卓应用进程守护系统原理框图;
图10是根据本发明另一个实施例的安卓应用进程守护系统原理框图;
图11是根据本发明又一个实施例的安卓应用进程守护系统原理框图;
图12是根据本发明再一个实施例的安卓应用进程守护系统原理框图;以及
图13是根据本发明一个实施例的进程启块模块原理框图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
在以下的详细描述中,可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中,相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述,使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解,还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。
本发明提供了一种安卓应用进程守护方法和系统,能够根据用户对应用的不同需求对应用进程进行守护。图1是根据本发明一个实施例的安卓应用进程守护方法流程图。所述守护方法包括以下步骤:
步骤S1a,在目标应用启动的同时创建两个系统最高级别的第一进程。为了方便叙述,将所述两个第一进程分别命名为Deamon进程和MSF进程。需要说明的是,本发明对创建的进程的命名只是为了方便说明,其名字可以是随机或任意名字。在本实施例中,根据用户对目标应用能够在终端系统运行期间一直处于存活状态的需求,在目标应用启动的同时创建两个第一进程。具体地,当用户点击桌面的目标应用图标时,点击图标事件发生在系统Launcher进程,Launcher进程调用startActivity()函数,由Instrumentation通过Android系统的Binder跨进程通信机制发送消息给System_server进程。System_server进程中的ActivityManagerService通过Socket通信机制告知Zygote进程,由Zygote进程forkapp进程。在本实施例中,当Zygote进程fork app进程的同时,也分别fork Deamon进程和MSF进程。
步骤S2a,为每个第一进程设置第一文件,并使每个第一进程持有其对应第一文件的排他锁。例如分别为Deamon进程和MSF进程各自新建一个任意名字的文件,如Doc_D和Doc_M。调用flock()函数或fcntl()函数,在函数的参数中指定锁的类型为排他锁,指定锁定的文件名和对应的进程ID,进程ID即是指前述由Zygote进程fork出的Deamon进程ID和MSF进程ID,则为每一个文件设置排他锁,并由相应的进程持有。经过上述设置,Deamon进程持有第一文件Doc_D的排他锁,MSF进程持有第一文件Doc_M的排他锁。
步骤S3a,将所述两个第一进程组成一个相互监听第一进程对。
步骤S4a,第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态。即Deamon进程监听MSF进程所持有的文件锁,MSF进程监听Deamon进程所持有的文件锁。由于本实施设置的是文件排他锁,文件排他锁、进程和文件紧密相连,当一个进程持有一个文件的排他锁时,会阻塞其他进程对该文件的访问。在进程被杀死时,系统回收杀死进程的所有资源,则其所持有的文件排他锁会被释放,则其他进程能够访问该文件,例如能够对文件进行读或写。
步骤S5a,判断Deamon进程和MSF进程中的一个是否被杀死,当Deamon进程能够访问所述第一文件Doc_M时,则确定第一文件Doc_M的排他锁释放,MSF进程被杀死。同理,当MSF进程能够访问所述第一文件Doc_D时,则可以确定第一文件Doc_D的排他锁释放,Deamon进程被杀死。如果没有任何进程被杀死,则返回步骤S4a,继续监听。如果Deamon进程和MSF进程中的一个被杀死,以Deamon进程先被杀死为例,在步骤S6a未被杀死的MSF进程基于自定义启动接口拉起被杀死的Deamon进程,然后在步骤S7a,由被拉起的Deamon进程拉起目标应用进程和随后被杀死的MSF进程,此时完成一次守护。Deamon进程和MSF进程再次回到步骤4a进入相互监听状态。
当目标应用进入后台,或者例如系统为了获得更多的内存等其他原因,目标应用进程被系统杀死,由于安卓系统机制,此时系统回收该应用进程的所有资源,包括杀死当前创建的两个第一进程:Deamon进程和MSF进程,而系统执行进程的杀死操作也是有一个时间的消耗,这个时间消耗在有些系统中可以精确到毫秒级。本发明创建的两个第一进程为系统最高级别进程,如在创建时设置其级别为前台进程,因而系统执行进程杀死操作的三个进程的命名、优先级、权限、操作的文件等等都不相同,可使得系统资源回收时,不能同时将这三个进程杀死,通常是创建的两个第一进程相对于目标应用进程而后被杀死。当Deamon进程和MSF进程之一被先杀死后,例如Deamon进程先于MSF进程被杀死,MSF进程监听到Deamon进程死亡,未被杀死的MSF进程将先被杀死的Deamon进程拉起,而后MSF进程被杀死。被拉起的Deamon进程将后被杀死的MSF进程和目标应用进程拉起,从而继续对目标应用进程守护。
随着安卓系统的升级,有些系统为了避免对应用的滥用,在其源码上对进程的重启设置了诸多限制条件,表现是在进程被杀死后不能立即被拉起。因而,本发明自定义了启动接口,在一个进程被杀死后可以不受源码的限帽而被立即拉起。
图2是根据本发明一个实施例的实现自定义启动接口的流程图。在本实施例中,通过以下步骤实现自定义启动接口:
步骤S100,新建客户管理器和Binder,并在所述客户管理器中注册所述Binder。其中,所述的客户管理器为一个与ActivityManager相同的类,其功能与ActivityManager相同,在SystemSever进程中,在与应用进程通信的过程中作为服务端。本实施例中将其命名为客户管理器(CustomerManager),但应当明白的是,也可以将其命名为其他的名字,而非限制为客户管理器(CustomerManager)。由于客户管理器位于SystemSever进程中,为了与本发明创建的两个第一进程进行通信,客户管理器需要通过一个Android类—Binder与系统内核的Binder驱动相通信,因而创建一个Binder并将其注册到客户管理器中,从而使得所述客户管理器可以通过过Binder与Binder驱动相通信。
步骤S101,所述客户管理器调用函数binder_open()打开设备文件/dev/binder,并将它映射到本进程的地址内存空间,映射后的地址内存作为Binder数据传输的缓存区。其中,所述客户管理器通过系统调用open、mmap和ioctl来访问设备文件/dev/binder,实现与Binder驱动的交互来间接地实现跨进程通信。
步骤S102,所述客户管理器调用函数binder_become_context_manager()将自己注册为Binder的管家。
步骤S103,调用函数binder_loop()等待和处理进程的通信请求。
所述客户管理器通过所述Binder与系统中的Binder驱动建立通信连接,告知Binder驱动所述客户管理器的功能,从而所述客户管理器可以监听Binderr驱动的驱动数据。当图1中的Deamon进程或MSF进程发送进程拉起请求时,所述客户管理器在循环监听Binder驱动的驱动数据时可以得到所述进程拉起请求。
图3是根据本发明一个实施例的一个未被杀死的进程通过自定义启动接口拉起另一个刚被杀死进程的流程图。在图1的步骤S6a中,未被杀死的MSF进程基于自定义启动接口拉起被杀死的Deamon进程如图3所示:
步骤61a,MSF进程基于Binder通信机制向客户管理器发送进程拉起请求。其中,所述进程创建请求作为Binder驱动的驱动数据可以被所述客户管理器监听到。
步骤S62a,所述客户管理器收到所述进程拉起请求后,调用do_add_service()函数,为其注册服务,例如命名为ActivityManagerService_1。
步骤S63a,所述ActivityManagerService_1通过Socket进程间通信机制向系统Zygote进程发送拉起Deamon进程的请求。
步骤S64a,所述Zygote进程监听到拉起Deamon进程的请求时,根据所述进程的标识,依据原进程组件fork出所述Deamon进程。
同理,在由Deamon进程拉起目标应用进程和刚刚死去的MSF进程的过程与此相同,则不再赘述。
图4是根据本发明另一个实施例的安卓应用进程守护方法中的进程关系示意图。在本实施例中,创建三个进程,分别为进程A、进程B和进程C,这三个进程两两组成一个相互监听进程对,如图中所示共有3对相互监听进程对,当任意一个进程(如进程A)被杀死时,可以被另外两个进程(如进程B和进程C)监听到,并由另外两个进程(进程B和进程C)将其拉起,在另外两个进程(进程B和进程C)被杀死后,由刚被拉起的进程(进程A)再将他们拉起,并拉起目标应用进程。本实施例中创建了三个进程,从而组成了三对相互监听进程对,从而进一步保证了将第一个杀死的进程拉起的成功率。
图5是根据本发明另一个实施例的安卓应用进程守护方法流程图。所述守护方法包括以下步骤:
步骤S1b,在目标应用启动的同时创建两个系统最高级别的第一进程。为了方便叙述,将所述两个第一进程分别命名为Deamon进程和MSF进程。
步骤S2b,为每个第一进程设置第一文件,并使每个第一进程持有其对应第一文件的排他锁。
步骤S3b,将所述两个第一进程组成一个相互监听第一进程对。
步骤S4b,所述两个第一进程分别创建两个第二进程。如Daemon进程分别fork两个进程,为方便说明,在此命名为app_do1进程和app_do2进程。同理,MSF进程fork两个进程,分别为app_msf1进程和app_msf2进程。在一个更好的实施例中,第一进程在创建两个第二进程时,使第二进程托孤。例如,Daemon进程首先fork一个第三进程,所述第三进程fork得到app_do1进程,而后关闭第三进程,使app_do1进程成为孤儿,从而减弱了Daemon进程和app_do1进程的关联。
步骤S5b,为每个第二进程设置第二文件,并使每个第二进程持有其对应第二文件的排他锁。
步骤S6b,每个第一进程的第二进程与对方第一进程的第二进程两两组成一个相互监听第二进程对。在一个实施例中,将app_do1进程和app_msf1进程组成一个相互监听第二进程对,将app_do2进程和app_msf2进程组成一个相互监听第二进程对,从而得到图6所示的进程关系示意图。
步骤S7b,三个进程对中的两个进程相互监听。
需要说明的是,前述步骤S1b-S6b之间的关系仅是为了说明进程对的创建过程,其并不一定是按时间顺序进行,例如,可以在步骤S1b完成之后执行步骤S4b,在执行步骤S2b的同时执行步骤S5b,在执行步骤S3b的同时执行步骤S6b。
步骤S8b,判断是否有进程对中的一个进程监听到另一个进程被杀死。如果有,则在步骤S9b由该进程拉起对方进程。
步骤S10b,由拉起的进程拉起其他进程和目标应用进程。
由于app_do1进程和app_do2进程是由Daemon进程两次fork得到,当Daemon进程被杀死,根据系统机制,app_do1进程和app_do2进程也会被杀死。当MSF进程监听到Daemon进程被杀死,其拉起Daemon进程,随后也会被杀死,进而其两次fork得到的app_msf1进程和app_msf2进程被杀死。被拉起的Daemon进程拉起MSF进程和4个第二进程。同时,当app_do1进程和app_do2进程被杀死会分别由app_msf1进程和app_msf2进程监听到,则app_msf1进程分别拉起对应的app_do1进程和Daemon进程,而app_msf2进程会分别拉起对应的app_do2进程和Daemon进程。从而可见,当Daemon进程被杀死后,可以分别由MSF进程和其fork得到的app_msf1进程和app_msf2进程拉起,为Daemon进程的拉起设置了三重保险,因而进一步增加了拉起Daemon进程的成功率。
当然,第一进程也可以只二度fork一个第二进程,如图7所示的进程关系示意图。当Daemon进程被杀死,根据系统机制,app_do进程也会被杀死。当MSF进程监听到Daemon进程被杀死,其拉起Daemon进程,随后也会被杀死,进而其两次fork得到的app_msf进程。被拉起的Daemon进程拉起MSF进程和app_do进程和app_msf进程。同时,当app_msf进程监听到app_do进程被杀死时,会拉起app_do进程和Daemon进程,即为Daemon进程的拉起设置了双重保险,同样可以提高拉起Daemon进程的成功率。
在前述实施例中,对目标应用的守护进程是在目标应用进程创建的同时创建,当然也可以在目标应用运行过程中,根据一些设置的条件而创建,具体可以根据目标应用的用途、需要来设置。例如,当检测到目标应用进入后台时,创建前述的守护进程,或者在用户实施了某些操作,如挂机操作、设置了接收好友消息、游戏社区互动信息、体力恢复通知等操作时对目标应用进行守护。也可以设置结束守护的条件,在守护过程中,在满足结束守护条件时,关闭前述创建的守护进程。具体流程如图8所示:
步骤S1c,检测守护触发条件,例如,可将触发条件设置为目标应用启动或用户的一些储如打开守护按钮、挂机、设置接收消息等操作。
步骤S2c,判断是否满足触发条件,如果满足,则在步骤S3c创建守护进程,对目标应用进行守护,具体如前述实施例,在此不再赘述。如果不满足,则返回步骤S1c。
步骤S4c,在守护过程中检测守护结束条件。例如,当用户无需守护时,用户可以点击退出守护的按钮,用户在设置页面点击停止应用按钮等。
步骤S5c,判断是否满足守护结束条件,如果满足,则在步骤S6c关闭守护进程,即主动杀死守护进程,结束守护。如果不满足,则返回步骤S4c。
图9是根据本发明一个实施例的安卓应用进程守护系统原理框图。在本实施例中,所述安卓应用进程守护系统包括第一进程模块1、第一文件锁模块2、第一监听模块3和进程启动模块4,其中,所述第一进程模块1为目标应用创建两个以上的第一进程,如图1实施例中的两个进程,或如图4所示的三个进程,当然也可以是更多的进程。在一个实施例中,所述第一进程模块1通过AMS向系统Zygote进程发送进程创建请求,由Zygote进程创建对应数量的第一进程。
所述第一文件锁模块2与所述第一进程模块1相连接,为每个第一进程设置第一文件,并使每个第一进程持有其对应第一文件的排他锁。例如,第一文件锁模块2为每个第一进程新建一个任意名字的文件,而后调用flock()函数或fcntl()函数,在函数的参数中指定锁的类型为排他锁,指定锁定的文件名和对应的进程ID,从而使第一进程持有其对应第一文件的排他锁。
所述第一监听模块3与所述第一文件锁模块2和第一进程模块1相连接,将所述两个以上第一进程两两组成一个相互监听第一进程对,所述第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态。在任一第一进程对中的任一个第一进程监听到对方第一进程对应第一文件的排他锁释放,发送进程拉起请求给所述进程启动模块4。
所述进程启动模块4与所述第一监听模块3相连接,在接收到进程拉起请求时,基于自定义启动接口启动对方第一进程,由所述对方第一进程启动所述目标应用进程。
图10是据本发明另一个实施例的安卓应用进程守护系统原理框图。在本实施例中,所述安卓应用进程守护系统除了包括图9中的第一进程模块1、第一文件锁模块2、第一监听模块3和进程启动模块4外,还包括第二进程模块5、第二文件锁模块6和第二监听模块7,其中,所述第二进程模块5与所述第一进程模块1相连接,所述第一进程模块1在创建出所述第一进程后发送通知给所述第二进程模块5,所述第二进程模块5为所述每个第一进程分别创建一个以上第二进程,如图6中的两个进程,或如图7中所示的一个进程。所述第二文件锁模块6与所述第二进程模块5相连接,为每个第二进程设置一个第二文件,并使每个第二进程持有其对应第二文件的排他锁。所述第二监听模块7分别与第二进程模块5和所述第二文件锁模块6相连接,将每个第一进程的第二进程与对方第一进程的第二进程两两组成一个相互监听第二进程对,第二进程对中的两个第二进程相互监听对方第二文件的排他锁状态,当任一个第二进程对中的任一个第二进程监听到对方第二进程对应第二文件的排他锁释放,发送进程拉起请求给所述进程启动模块4。所述进程启动模块4还与所述第二监听模块7相连接,在接收到第二监听模块7发送来的进程拉起请求时,基于自定义启动接口启动对方第二进程及对应的第一进程,由所述对方第二进程或对应的第一进程启动所述目标应用进程。
其中,第二进程模块5进一步包括第二进程创建单元51和进程托孤单元52,所述第二进程创建单元51在接收到来自于第一进程模块1发送的已创建第一进程的通知后,使所述第一进程创建第三进程,并由所述第三进程创建预置数量的第二进程,在进程创建完后发送通知给所述进程托孤单元52,进程托孤单元52接收到第二进程创建完的通知后,使第三进程退出从而使所述第二进程成为第一进程的孤儿进程,进而减少第一进程与第二进程的关联。
图11是据本发明另一个实施例的安卓应用进程守护系统原理框图。在本实施例中,在本实施例中,所述安卓应用进程守护系统除了包括图9中的第一进程模块1、第一文件锁模块2、第一监听模块3和进程启动模块4外,还包括守护触发模块8,其与所述第一进程模块1相连接,用于检测是否满足守护条件,在满足守护条件时发送触发消息给所述第一进程模块1,进而由第一进程模块1创建两个以上的第一进程。通过本实施例,通过设置触发条件,在满足触发条件时再对目标应用进行守护,从而能够更好地满足用户对目标应用的需求,且能减小对系统资源的占用和消耗。
图12是据本发明另一个实施例的安卓应用进程守护系统原理框图。在本实施例中,在本实施例中,所述安卓应用进程守护系统除了包括图9中的第一进程模块1、第一文件锁模块2、第一监听模块3和进程启动模块4外,还包括启动接口自定义模块9,经配置,所述启动接口自定义模块9包括类新建单元91、通信连接单元92和监听单元93,其中,所述类新建单元91新建客户管理器和Binder,并在所述客户管理器中注册所述Binder。其中,所述的客户管理器为一个与ActivityManager相同的类,其功能与ActivityManager相同,在与应用进程通信的过程中作为服务端。
所述通信连接单元92与所述类新建单元91相连接,使所述客户管理器通过所述Binder与所述系统中的Binder驱动建立通信连接,具体地,所述客户管理器调用函数binder_open打开设备文件/dev/binder,并将它映射到本进程的地址内存空间,映射后的地址内存作为Binder数据传输的缓存区,从而实现客户管理器与Binder驱动交互,以此来间接地实现跨进程通信。
所述监听单元93使所述客户管理器监听Binder驱动的驱动数据以获得所述第一进程或第二进程基于Binder通信机制发送的进程拉起请求。例如,所述客户管理器调用函数binder_loop()循环监听来自其他进程的通信请求。
在一个实施例中,如图13所示,图13是根据本发明一个实施例的进程启块模块原理框图。所述进程启动模块4进一步包括启动请求单元41、进程启动单元42和目标应用启动单元43,其中,所述启动请求单元41在获得来自第一监听模块3或第二监听模块7的进程拉起请求时,生成进程创建请求,由所述第一进程或第二进程基于Binder通信机制发送给自定义的客户管理器。所述进程启动单元42与所述启动请求单元41相连接,使所述客户管理器响应进程启动请求启动所述对方第一进程和/或第二进程。例如,所述客户管理器收到所述进程创建请求后,调用do_add_service()函数,为其注册服务,例如命名为ActivityManagerService_1。所述ActivityManagerService_1通过Socket进程间通信机制向系统Zygote进程发送拉起进程的请求。由Zygote根据进程请求中的进程标识,依据原进程组件fork出所述进程,如第一进程或第二进程。所述目标应用启动单元43与所述进程启动单元42相连接,经配置使拉起的第一进程或第二进程fork所述目标应用进程。
本发明通过多进程守护方案,既弥补了传统进程守护方案中无法准确监测到目标进程被杀死的信息,又因为在进程拉起时采用自定义启动接口,突破了系统对进程重起的时间限制,从而提高了拉起被杀进程的成功率。在应用守护过程中不需要过多消耗资源,耗电小。本发明适应用户对目标应用保活的需求而进行应用进程的守护,既满足了用户需求,也可以保证目标应用的使用时长生命周期,为产品的变现创造更多利益。
上述实施例仅供说明本发明之用,而并非是对本发明的限制,有关技术领域的普通技术人员,在不脱离本发明范围的情况下,还可以做出各种变化和变型,因此,所有等同的技术方案也应属于本发明公开的范畴。
Claims (14)
1.一种安卓应用进程守护方法,包括:
为目标应用创建两个以上的第一进程,其中所述每个第一进程具有对应的第一文件,并且所述第一进程持有所述对应的第一文件的排他锁;
所述两个以上第一进程两两组成一个相互监听第一进程对,第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态;以及
响应于第一进程对中的任一第一进程监听到对方第一进程对应的第一文件的排他锁被释放,所述第一进程拉起所述对方第一进程,并由拉起的所述对方第一进程拉起所述目标应用进程。
2.根据权利要求1所述的方法,其中进一步包括:所述两个以上第一进程分别创建一个以上第二进程,其中每个第二进程具有对应的第二文件,并且所述第二进程持有所述对应的第二文件的排他锁。
3.根据权利要求2所述的方法,其中进一步包括:
所述第一进程对中的第一进程的第二进程与对方第一进程的第二进程两两组成一个相互监听第二进程对,所述第二进程对中的两个第二进程相互监听对方第二文件的排他锁状态;以及
响应于第二进程对中的任一第二进程监听到对方第二进程对应第二文件的排他锁被释放,所述第二进程拉起对方第二进程及对应的第一进程,并由所述拉起的对方第二进程或对应的第一进程拉起所述目标应用进程。
4.根据权利要求2所述的方法,其中,进一步包括:
所述第一进程创建一个第三进程;
所述第三进程创建一个以上第二进程;以及
所述第三进程退出,以使所述第二进程托孤。
5.根据权利要求1-4任一所述的方法,其中在为目标应用创建两个以上的第一进程步骤之前还包括:判断是否满足守护条件;以及响应于满足守护条件,为目标应用创建两个以上的第一进程。
6.根据权利要求2所述的方法,其中所述第一进程和第二进程为系统最高级别进程。
7.根据权利要求3所述的方法,其中进一步包括:
所述第一进程或第二进程基于Binder通信机制发送进程拉起请求给客户管理器;以及
所述客户管理器响应进程拉起请求拉起所述对方第一进程和/或第二进程。
8.根据权利要求7所述的方法,其中进一步包括:
新建客户管理器和Binder,并在所述客户管理器中注册所述Binder;
所述客户管理器通过所述Binder与所述系统中的Binder驱动建立通信连接;以及
所述客户管理器监听Binder驱动的驱动数据以获得所述第一进程和/或第二进程基于Binder通信机制发送的进程拉起请求。
9.一种安卓应用进程守护系统,包括:
第一进程模块,经配置以为目标应用创建两个以上的第一进程;
第一文件锁模块,其与所述第一进程模块相连接,经配置以为每个第一进程设置第一文件,并使每个第一进程持有所述对应的第一文件的排他锁;
第一监听模块,其与所述第一文件锁模块相连接,经配置以将所述两个以上第一进程两两组成一个相互监听第一进程对,所述第一进程对中的两个第一进程相互监听对方第一文件的排他锁状态,响应于第一进程对中的任一第一进程监听到对方第一进程对应第一文件的排他锁被释放,发送进程拉起请求;以及
进程启动模块,其与所述第一监听模块相连接,经配置以在接收到进程拉起请求时,所述第一进程拉起对方第一进程,并由所述对方第一进程拉起所述目标应用进程。
10.根据权利要求9所述的系统,其中进一步包括:
第二进程模块,其与所述第一进程模块相连接,经配置以在创建出所述第一进程后,所述两个以上第一进程分别创建一个以上第二进程;
第二文件锁模块,其与所述第二进程模块相连接,经配置以为每个第二进程设置第二文件,并使每个第二进程持有对应的第二文件的排他锁;以及
第二监听模块,与所述第二文件锁模块相连接,经配置以将所述第一进程对中的第一进程的第二进程与对方第一进程的第二进程两两组成一个相互监听第二进程对,第二进程对中的两个第二进程相互监听对方第二文件的排他锁状态,并且响应于第二进程对中的任一第二进程监听到对方第二进程对应第二文件的排他锁被释放,发送进程拉起请求;
对应地,所述进程启动模块与所述第二监听模块相连接,在接收到进程拉起请求时,所述第二进程拉起对方第二进程及对应的第一进程,由所述拉起的对方第二进程或对应的第一进程拉起所述目标应用进程。
11.根据权利要求10所述的系统,其中所述第二进程模块包括:
第二进程创建单元,经配置在所述第一进程创建后,所述第一进程创建第三进程,并由所述第三进程创建一个以上第二进程;以及
进程托孤单元,其与所述第二进程创建单元相连接,经配置以在第二进程创建后,使第三进程退出从而使所述第二进程托孤。
12.根据权利要求9-11任一所述的系统,其中进一步包括守护触发模块,其与所述第一进程模块相连接,经配置以在满足守护条件时,发送触发消息给所述第一进程模块。
13.根据权利要求9所述的系统,其中进一步包括启动接口自定义模块,经配置包括:
类新建单元,经配置以新建客户管理器和Binder,并在所述客户管理器中注册所述Binder;
通信连接单元,其与所述类新建单元相连接,经配置以使所述客户管理器通过所述Binder与所述系统中的Binder驱动建立通信连接;以及
监听单元,经配置以使所述客户管理器监听Binder驱动的驱动数据以获得所述第一进程或第二进程基于Binder通信机制发送的进程拉起请求。
14.根据权利要求13所述的系统,其中所述进程启动模块进一步包括:
启动请求单元,经配置在获得所述进程拉起请求时,所述第一进程或第二进程基于Binder通信机制发送进程启动请求给所述客户管理器;
进程启动单元,其与所述启动请求单元相连接,经配置,所述客户管理器响应进程启动请求拉起所述对方第一进程和/或第二进程;以及
目标应用启动单元,其与所述进程启动单元相连接,经配置由拉起的第一进程或第二进程拉起所述目标应用进程。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111611442.6A CN114490549A (zh) | 2021-12-27 | 2021-12-27 | 一种安卓应用进程守护方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111611442.6A CN114490549A (zh) | 2021-12-27 | 2021-12-27 | 一种安卓应用进程守护方法和系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114490549A true CN114490549A (zh) | 2022-05-13 |
Family
ID=81496325
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111611442.6A Pending CN114490549A (zh) | 2021-12-27 | 2021-12-27 | 一种安卓应用进程守护方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114490549A (zh) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140201163A1 (en) * | 2013-01-16 | 2014-07-17 | Microsoft Corporation | Handling file system corruption |
CN106951335A (zh) * | 2017-02-28 | 2017-07-14 | 维沃移动通信有限公司 | 一种进程守护方法和移动终端 |
CN113760492A (zh) * | 2020-11-04 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种程序进程保活方法、系统、装置、设备以及存储介质 |
-
2021
- 2021-12-27 CN CN202111611442.6A patent/CN114490549A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140201163A1 (en) * | 2013-01-16 | 2014-07-17 | Microsoft Corporation | Handling file system corruption |
CN106951335A (zh) * | 2017-02-28 | 2017-07-14 | 维沃移动通信有限公司 | 一种进程守护方法和移动终端 |
CN113760492A (zh) * | 2020-11-04 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种程序进程保活方法、系统、装置、设备以及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109379337B (zh) | 一种安卓平台下应用进程的保活方法 | |
CN108430116B (zh) | 断网重连方法、介质、装置和计算设备 | |
EP3952423B1 (en) | Method and device for determining terminal behavior analysis | |
CN112534776B (zh) | 用于在网络环境中检测网络功能失败和重启的方法及装置 | |
US8219990B2 (en) | Techniques for managing virtual machine (VM) states | |
US7130899B1 (en) | Robust indication processing | |
TW201944236A (zh) | 任務處理方法、裝置及系統 | |
CN109246220B (zh) | 一种消息推送系统及方法 | |
WO2017211226A1 (zh) | 展示媒体文件的方法、终端和存储介质 | |
CN111414208B (zh) | 应用程序的启动方法、装置及设备 | |
EP0920662A1 (en) | Interprocess communication in a distributed computer environment | |
CN106657299B (zh) | 关注主播上线提醒方法及系统 | |
CN113660350A (zh) | 分布式锁协调方法、装置、设备及存储介质 | |
WO2019006808A1 (zh) | 一种处理长连接建立请求的方法和装置 | |
KR20130108613A (ko) | 프로세스 간 통신을 위한 방법, 장치 및 컴퓨터 기록 매체 | |
CN106484461A (zh) | 智能终端中的服务保活方法及装置 | |
CN106550030B (zh) | 一种数据共享方法、装置及系统 | |
WO2011023020A1 (zh) | 客户端/服务端架构中服务端和客户端的业务执行方法及系统 | |
CN108781358A (zh) | 一种管理eUICC中的签约信息集的方法及相关设备 | |
WO2008025198A1 (fr) | Procédé, système et appareil pour la communication entre un terminal et un serveur | |
CN113778280B (zh) | 一种Linux兼容Android的显示消息通知方法及装置 | |
JP7373679B2 (ja) | Wi-Fi制御方法、装置及び電子機器 | |
CN109947576B (zh) | 一种虚拟机内部代理程序管理的方法 | |
CN114490549A (zh) | 一种安卓应用进程守护方法和系统 | |
EP2949083B1 (en) | Receiving a communication event |
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 |