CN112445530B - Method and device for keeping third-party application program alive - Google Patents
Method and device for keeping third-party application program alive Download PDFInfo
- Publication number
- CN112445530B CN112445530B CN201910810253.8A CN201910810253A CN112445530B CN 112445530 B CN112445530 B CN 112445530B CN 201910810253 A CN201910810253 A CN 201910810253A CN 112445530 B CN112445530 B CN 112445530B
- Authority
- CN
- China
- Prior art keywords
- party application
- sub
- daemon
- application program
- daemon process
- 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
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/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4418—Suspend and resume; Hibernate and awake
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
Abstract
The embodiment of the invention provides a method and equipment for keeping third-party application program alive, wherein the method comprises the steps of establishing a daemon process in the third-party application program; the daemon process serves as a foreground; monitoring a screen locking broadcast, and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after the system is locked; binding the daemon process with each sub-process of the third-party application program, and monitoring each sub-process according to the established binding relationship; after the fact that the sub-process is stopped is monitored, the daemon process starts the stopped sub-process. The keep-alive method provided by the embodiment can ensure that the daemon process can still survive under the condition of screen locking, and the daemon process is started in time when the subprocess of the third-party application program is killed, so that the effective keep-alive of the third-party application program is achieved.
Description
Technical Field
The embodiment of the invention relates to the technical field of communication, in particular to a keep-alive method and keep-alive equipment for a third-party application program.
Background
Along with the popularization of the internet, users have higher and higher requirements on the stability and convenience of network communication services, various third-party application programs are generated, and the users can conveniently obtain various services by loading the third-party application programs on communication terminals. Wherein, part of the services provided by the third-party application need to be kept alive to reside in the background so as to provide stable services, such as a positioning application program, an instant messaging application program and the like.
In the existing keep-alive scheme of the application program, the program to be kept alive needs to be added into a white list, or the memory excess judgment value (Out of memory adjustment, oom _ adj) of the program to be kept alive is reduced to improve the priority.
However, the above keep-alive method lacks universality and requires special processing by manufacturers.
Disclosure of Invention
The embodiment of the invention provides a keep-alive method and device for a third-party application program, which are used for improving the universality and the effectiveness of the keep-alive of the application program.
In a first aspect, an embodiment of the present invention provides a method for keeping alive a third-party application program, including:
in a third-party application program, creating a daemon process; the daemon process serves as a foreground;
monitoring a screen locking broadcast, and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after the system is locked;
binding the daemon process with each subprocess of the third-party application program, and monitoring each subprocess according to the established binding relationship;
after the fact that the sub-process is stopped is monitored, the daemon process starts the stopped sub-process.
In one possible design, the binding the daemon process with each sub-process corresponding to the third-party application program, and monitoring each sub-process according to the established binding relationship includes:
implementing an IBinder interface in the daemon process;
calling a Death function of the Binder object of each sub-process through the IBinder interface;
and calling back a Death function realized by the IBinder interface according to an operating system, and monitoring each subprocess of the third-party application program.
In a possible design, before the daemon starts the stopped sub-process, the method further comprises:
saving the class name of each sub-process of the third-party application program in the daemon process;
the daemon process starts the stopped sub-process, and the method comprises the following steps:
and the daemon process starts the stopped subprocesses according to the stored class names of the subprocesses.
In a possible design, the monitoring a lock screen broadcast, and after monitoring the lock screen broadcast, starting foreground activity of a preset number of pixels for the daemon, further includes:
and monitoring the screen unlocking broadcast, and stopping the foreground activity after monitoring the screen unlocking broadcast.
In one possible design, the preset number of pixels is 1 or 2 pixels.
In a second aspect, an embodiment of the present invention provides a third-party application keep-alive device, including:
the creating module is used for creating a daemon process for the third-party application program; the daemon process serves as a foreground;
the first monitoring module is used for monitoring screen locking broadcast and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored;
the binding module is used for binding the daemon process and each subprocess of the third-party application program and monitoring each subprocess according to the established binding relationship;
and the starting module is used for starting the stopped subprocess by the daemon process after the fact that the subprocess is stopped is monitored.
In one possible design, the binding module is specifically configured to implement an IBinder interface in the daemon process;
calling a Death function of the Binder object of each sub-process through the IBinder interface;
and calling back a Death function realized by the IBinder interface according to an operating system, and monitoring each subprocess of the third-party application program.
In one possible design, the apparatus further includes:
the saving module is used for saving the class name of each subprocess of the third-party application program in the daemon process;
the starting module is specifically configured to start the stopped sub-process by the daemon process according to the stored class name of each sub-process.
In a third aspect, an embodiment of the present invention provides a third-party application keep-alive device, including: at least one processor and memory;
the memory stores computer-executable instructions;
the at least one processor executes computer-executable instructions stored by the memory to cause the at least one processor to perform the method as set forth in the first aspect above and in various possible designs of the first aspect.
In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, in which computer-executable instructions are stored, and when a processor executes the computer-executable instructions, the method according to the first aspect and various possible designs of the first aspect are implemented.
In the method, a daemon process is created in a third-party application program, the daemon process is set as a foreground service, screen locking broadcast is monitored, foreground activities of a preset number of pixels are started for the daemon process after the screen locking broadcast is monitored, so that the daemon process can continuously maintain a foreground state after a system is locked, the daemon process can still survive under the condition that a screen is locked, and each subprocess of the third-party application program is bound and monitored according to the established binding relationship; after the fact that the subprocess is stopped is monitored, the daemon process starts the stopped subprocess, and the daemon process can start the stopped subprocess in time when the subprocess of the third-party application program is killed, so that the effect of keeping the third-party application program alive is achieved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.
Fig. 1 is a schematic diagram illustrating a low memory reclamation mechanism according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating a third-party application keep-alive method according to another embodiment of the present invention;
FIG. 3 is a flowchart illustrating a third-party application keep-alive method according to another embodiment of the present invention;
FIG. 4 is a schematic structural diagram of a keep-alive device of a third-party application according to yet another embodiment of the present invention;
FIG. 5 is a schematic structural diagram of a keep-alive device of a third-party application according to yet another embodiment of the present invention;
fig. 6 is a schematic hardware structure diagram of a third-party application keep-alive device according to yet another embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Fig. 1 is a schematic diagram illustrating a low memory reclamation mechanism according to an embodiment of the present invention. In the android system, after the application program exits, the process of the application program can continue to run in the background of the system, so that the response time is shortened when the system is restarted. Thus, a Low Memory reclamation mechanism (LMK) is designed to determine when to kill some processes occupying Memory to free Memory. As shown in fig. 1, the android system includes a user space and a kernel space. The user space includes an Activity Manager Service (AMS), the kernel space includes an LMK, and all applications (e.g., application a and application B) in the user space are uniformly managed by the AMS (management activities may include startup, wakeup, background operation, etc.). The AMS updates the oom _ adj value corresponding to the process according to the state of the process, and writes the value into an adj file. The LMK of the kernel receives the file, and when the residual capacity of the memory in the machine configuration reaches a limit value, the processes with high oom _ adj values are cleaned according to oom _ adj values of each process, so that the memory space is released.
It can be seen that the size of oom _ adj of a process in this process is critical to whether the process is killed. However, setting the value of oom _ adj requires special handling by the vendor, and not all third party applications can get special treatment from the vendor. Based on this, the embodiment of the present invention provides a keep-alive method for a third-party application program, so as to improve the universality and effectiveness of the keep-alive of the third-party application program.
The technical solution of the present invention will be described in detail below with specific examples. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.
A specific embodiment is adopted to describe the third-party application keep-alive method provided by the embodiment of the present invention.
Fig. 2 is a flowchart illustrating a keep-alive method for a third-party application according to another embodiment of the present invention. As shown in fig. 2, the method may include:
201. in a third-party application program, creating a daemon process; the daemon is served as a foreground.
In practical applications, the execution subject of this embodiment is an electronic device installed with a third-party application program, for example: cell-phone, panel computer, computer and so on.
In this embodiment, the daemon process is a background process that can run without user input, often providing some kind of service. When Linux is used as a server, main processes also provide background service functions for a system or a user. Common daemons are Web servers, mail servers, and database servers, among others. The daemon process cannot control the terminal, so any input or output needs to be specially processed.
There are many ways to create daemons. This embodiment is not limited to this. Optionally, as an implementation manner, the creating process of the daemon process may include the following steps:
and after the fork function is executed in the parent process, executing exit quitting.
Setsid is called in the sub-process.
Let the root directory "/" be the working directory for the child process.
The umask of the child process is changed to 0.
Any unneeded file descriptors are closed.
Specifically, when a daemon process is created for a third-party application program, the daemon process is set as a foreground service to ensure that the daemon process has higher priority and cannot be killed.
Optionally, the preset number of pixels is any positive integer number of pixels within the range of the number of pixels on the screen, for example, may be 1 or 2 pixels, so that the effect of saving power may be achieved.
202. And monitoring a screen locking broadcast, and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after the system is locked.
In practical application, after the screen is locked, some processes are considered as power-consuming processes and are killed. That is to say, the risk that the daemon process is killed after the screen is locked is increased, so the embodiment starts the foreground activity of the preset number of pixels for the daemon process, and the foreground activity cannot be killed after the screen is locked, so that the survival of the daemon process can be ensured. And further, a foundation can be provided for keeping the sub-process of the third-party application program alive in the subsequent steps.
Specifically, the daemon process can only perform the daemon work on each subprocess of the third-party application program, so that the memory occupied by the daemon process is reduced. In addition, the daemon process exists in a foreground Service mode, and the foreground Service has the priority of the foreground process, namely oom _ adj is 0. Meanwhile, a broadcast receiver is realized to monitor the lock screen broadcast, and after the lock screen is sensed, foreground Activity of 1 pixel or 2 pixels can be started, so that the daemon process is always kept in a foreground state, the oom _ adj is always 0 and is not killed by a system, and optionally, after the screen is unlocked, the Activity can be destroyed.
203. And binding the daemon process with each sub-process of the third-party application program, and monitoring each sub-process according to the established binding relationship.
Optionally, the binding the daemon process with each sub-process corresponding to the third-party application program, and monitoring each sub-process according to the established binding relationship, includes:
implementing an IBinder interface in the daemon process;
calling a Death function of the Binder object of each sub-process through the IBinder interface;
and calling back a Death function realized by the IBinder interface according to an operating system, and monitoring each subprocess of the third-party application program.
In practical application, the IBinder.DeathRecipient interface is realized in the daemon process, and the realization of the IBinder.DeathRecipient interface is bound to the instances of all the sub-processes of the third-party application program. The specific implementation manner may be that a daemon calls a linkToDeath (innovative reception, int flags) function of the Binder object of each sub-process, and a first parameter of the function is the implementation of an ibander. By means of the binding, when the third-party application program subprocess dies, the binding Died () function realized by the IBinder.DeathRecipient interface of the Android system callback daemon can be realized, and the daemon can sense that the subprocess is killed through the realization of the IBinder.DeathRecipient interface. And the daemon process executes the operation of restarting the subprocess after sensing that the subprocess of the third-party application program is killed. Thus, the keep-alive of sub-processes of the third-party application program is realized.
204. After the fact that the sub-process is stopped is monitored, the daemon process starts the stopped sub-process.
Optionally, before the daemon starts the stopped sub-process, the method further includes:
saving the class name of each sub-process of the third-party application program in the daemon process;
the daemon process starts the stopped sub-process, and the method comprises the following steps:
and the daemon starts the stopped sub-process according to the stored class name of each sub-process.
In summary, in this embodiment, a scheme of using a daemon process to daemon multiple sub-processes is adopted. First, a daemon process needs to be started in a third-party application program, and the daemon process is bound with all sub-processes of the third-party application program. Secondly, the class name of each subprocess is stored in the daemon process, so that the daemon process can start the corresponding subprocess according to the stored class name of each subprocess. Specifically, the scheme mainly comprises the keep-alive of the subprocess of the third-party program and the keep-alive of the daemon process, and the keep-alive of each subprocess of the third-party application program is realized by the following steps: by implementing the IBinder.DeathRecipient interface in the daemon and binding the implementation of the interface to the instances of each subprocess, the system calls back the daemon when the subprocess dies. And the daemon process senses that the sub-process is killed and immediately executes the operation of restarting the sub-process. Keep-alive for daemon: the daemon process only executes the daemon operation, so that a small memory is occupied. In addition, the daemon process exists in a foreground Service mode, monitors the screen locking broadcast, starts a foreground Activity of 1 pixel or 2 pixels after sensing the screen locking, so that the daemon process is in a foreground state, keeps oom _ adj as 0 and is not killed by the system.
In practical application, a user can install an application program (for example, video playing software) provided with the third-party application program keep-alive method in a mobile phone terminal, and when the user opens the video playing software, the video playing software can create a daemon process and is bound with each sub-process of the video playing software, so that the process is pulled up in time after a certain sub-process is killed. For example, after a user watches a video program for a certain period of time, there is an incoming call or a new message needs to be checked by a certain chat software, at this time, the user closes the video playing software, and the video playing software runs in the background. If the system memory is too low at this time, the video playing software needs to be closed based on an LMK low memory recovery mechanism. Because the video playing software has the keep-alive function, the video playing software can be pulled up in time when the daemon process senses that the subprocess is killed, so that the subprocess is kept alive. When the user finishes the conversation or chats and wants to continue watching the video program, the video playing software does not need to be restarted, and the user experience is improved.
In the third-party application program keep-alive method provided by this embodiment, a daemon process is created in a third-party application program, the daemon process is set as a foreground service, a screen locking broadcast is monitored, foreground activities of a preset number of pixels are started for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after a system is locked, the daemon process is guaranteed to be still alive under the condition that a screen is locked, the daemon process is bound with each sub-process of the third-party application program, and each sub-process is monitored according to the established binding relationship; after the fact that the subprocess is stopped is monitored, the daemon process starts the stopped subprocess, and the daemon process can start the stopped subprocess in time when the subprocess of the third-party application program is killed, so that the effect of keeping the third-party application program alive is achieved.
Fig. 3 is a schematic flowchart of a keep-alive method for a third-party application according to another embodiment of the present invention. As shown in fig. 3, on the basis of the foregoing embodiment, this embodiment describes in detail the state switching of foreground activity, and the method may include:
301. in a third-party application program, creating a daemon process; the daemon is served as a foreground.
302. And monitoring a screen locking broadcast, and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after the system is locked.
303. And monitoring the screen unlocking broadcast, and stopping the foreground activity after monitoring the screen unlocking broadcast.
In practical application, in order not to affect normal display of the screen, after the screen unlocking broadcast is monitored, foreground activity of a preset number of pixels started when the screen is locked can be stopped.
304. And binding the daemon process with each sub-process of the third-party application program, and monitoring each sub-process according to the established binding relationship.
305. After the fact that the sub-process is stopped is monitored, the daemon process starts the stopped sub-process.
In the third-party application program keep-alive method provided by this embodiment, a daemon process is created in a third-party application program, the daemon process is set as a foreground service, a screen locking broadcast is monitored, foreground activities of a preset number of pixels are started for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after a system is locked, the daemon process is guaranteed to be still alive under the condition that a screen is locked, the daemon process is bound with each sub-process of the third-party application program, and each sub-process is monitored according to the established binding relationship; after the fact that the subprocess is stopped is monitored, the daemon process starts the stopped subprocess, and the daemon process can start the stopped subprocess in time when the subprocess of the third-party application program is killed, so that the effect of keeping the third-party application program alive is achieved.
Fig. 4 is a schematic structural diagram of a keep-alive device of a third-party application according to yet another embodiment of the present invention. As shown in FIG. 4, the third party application keep-alive device 40 includes: a creation module 401, a first listening module 402, a binding module 403, and an initiation module 404.
A creating module 401, configured to create a daemon process for the third-party application; the daemon serves as a foreground.
In this embodiment, the daemon process is a background process that can run without user input, often providing some kind of service. When Linux is used as a server, main processes also provide background service functions for a system or a user. Common daemons are Web servers, mail servers, and database servers, among others. The daemon process cannot control the terminal, so any input or output needs to be specially processed.
There are many ways to create daemons. This embodiment is not limited to this. Optionally, as an implementation manner, the creating process of the daemon process may include the following steps:
and after executing the fork function in the parent process, executing exit.
Setsid is called in the sub-process.
Let the root directory "/" be the working directory for the child process.
The umask of the child process is changed to 0.
Any unneeded file descriptors are closed.
Specifically, when a daemon process is created for a third-party application program, the daemon process is set as a foreground service to ensure that the daemon process has higher priority and cannot be killed.
Optionally, the preset number of pixels is any positive integer number of pixels within the range of the number of pixels on the screen, for example, may be 1 or 2 pixels, so that the effect of saving power may be achieved.
The first monitoring module 402 is configured to monitor a screen locking broadcast, and start foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored.
In practical application, after the screen is locked, some processes are considered as power-consuming processes and are killed. That is to say, the risk that the daemon process is killed after the screen is locked is increased, so the embodiment starts the foreground activity of the preset number of pixels for the daemon process, and the foreground activity cannot be killed after the screen is locked, so that the survival of the daemon process can be ensured. And further, a foundation can be provided for keeping the sub-process of the third-party application program alive in the subsequent steps.
Specifically, the daemon process can only perform the daemon work on each subprocess of the third-party application program, so that the memory occupied by the daemon process is reduced. In addition, the daemon process exists in a foreground Service mode, and the foreground Service has the priority of the foreground process, namely oom _ adj is 0. Meanwhile, a broadcast receiver is realized to monitor the lock screen broadcast, and after the lock screen is sensed, foreground Activity of 1 pixel or 2 pixels can be started, so that the daemon process is always kept in a foreground state, the oom _ adj is always 0 and is not killed by a system, and optionally, after the screen is unlocked, the Activity can be destroyed.
A binding module 403, configured to bind the daemon process with each sub-process of the third-party application program, and monitor each sub-process according to the established binding relationship;
a starting module 404, configured to, after it is monitored that the sub-process is stopped, start the stopped sub-process by the daemon process.
In the third-party application program keep-alive device provided by the embodiment of the invention, the creation module 401 creates a daemon process in the third-party application program and sets the daemon process as a foreground service, the first monitoring module 402 monitors the screen locking broadcast and starts foreground activities of a preset number of pixels for the daemon process after monitoring the screen locking broadcast, so that the daemon process continues to maintain a foreground state after the system is locked, the daemon process can still survive under the condition that the screen is locked, the daemon process is bound with each subprocess of the third-party application program through the binding module 403, and each subprocess is monitored according to the established binding relationship; after the starting module 404 monitors that the subprocess is stopped, the daemon process starts the stopped subprocess, and can start the subprocess of the third-party application program in time when the subprocess of the third-party application program is killed, so that the third-party application program is effectively kept alive.
Fig. 5 is a schematic structural diagram of a keep-alive device of a third-party application according to yet another embodiment of the present invention. As shown in fig. 5, the third party application keep-alive device 40 further includes: a second monitoring module 405 and a saving module 406.
Optionally, the binding module 403 is specifically configured to implement an ibider interface in the daemon;
calling a Death function of the Binder object of each sub-process through the IBinder interface;
and calling back a Death function realized by the IBinder interface according to an operating system, and monitoring each subprocess of the third-party application program.
In practical application, the IBinder.DeathRecipient interface is realized in the daemon process, and the realization of the IBinder.DeathRecipient interface is bound to the instances of all the sub-processes of the third-party application program. The specific implementation manner may be that a daemon calls a linkToDeath (innovative reception, int flags) function of the Binder object of each sub-process, and a first parameter of the function is the implementation of an ibander. By means of the binding, when the third-party application program subprocess is killed, the bindedDied () function realized by the IBinder.DeathRecipient interface of the Android system callback daemon can sense that the subprocess is killed through the realization of the IBinder.DeathRecipient interface. And the daemon process executes the operation of restarting the subprocess after sensing that the subprocess of the third-party application program is killed. Thus, the keep-alive of sub-processes of the third-party application program is realized.
Optionally, the apparatus further comprises:
a saving module 406, configured to save the class name of each sub-process of the third-party application program in the daemon process;
the starting module 404 is specifically configured to start the stopped sub-process by the daemon process according to the stored class name of each sub-process.
Optionally, the apparatus further comprises:
and a second monitoring module 405, configured to monitor the screen unlock broadcast, and stop the foreground activity after monitoring the screen unlock broadcast.
Optionally, the preset number of pixels is 1 or 2 pixels.
The third-party application keep-alive device provided by the embodiment of the invention can be used for executing the method embodiment, the implementation principle and the technical effect are similar, and the implementation principle and the technical effect are not described again in this embodiment.
Fig. 6 is a schematic hardware structure diagram of a keep-alive device of a third-party application program according to yet another embodiment of the present invention. As shown in fig. 6, the third-party application keep-alive device 60 provided by the present embodiment includes: at least one processor 601 and memory 602. The processor 601 and the memory 602 are connected by a bus 603.
In a particular implementation, execution of computer-executable instructions stored by the memory 602 by the at least one processor 601 causes the at least one processor 601 to perform a third party application keep-alive method as performed by the third party application keep-alive device 60 described above.
For a specific implementation process of the processor 601, reference may be made to the above method embodiments, which implement the principle and the technical effect similarly, and details of this embodiment are not described herein again.
In the embodiment shown in fig. 6, it should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose processors, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present invention may be embodied directly in a hardware processor, or in a combination of the hardware and software modules within the processor.
The memory may comprise high speed RAM memory and may also include non-volatile storage NVM, such as at least one disk memory.
The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the figures of the present application are not limited to only one bus or one type of bus.
The present application further provides a computer-readable storage medium, in which computer-executable instructions are stored, and when a processor executes the computer-executable instructions, the third-party application keep-alive method executed by the third-party application keep-alive device is implemented.
The application also provides a computer-readable storage medium, in which computer-executable instructions are stored, and when a processor executes the computer-executable instructions, the third-party application keep-alive method executed by the third-party application keep-alive device is implemented.
The computer-readable storage medium may be implemented by any type of volatile or non-volatile storage device or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. Readable storage media can be any available media that can be accessed by a general purpose or special purpose computer.
An exemplary readable storage medium is coupled to the processor such the processor can read information from, and write information to, the readable storage medium. Of course, the readable storage medium may also be an integral part of the processor. The processor and the readable storage medium may reside in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the readable storage medium may also reside as discrete components in the apparatus.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.
Claims (6)
1. A third party application keep-alive method is characterized by comprising the following steps:
in a third-party application program, creating a daemon process; the daemon process serves as a foreground;
monitoring a screen locking broadcast, and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored, so that the daemon process continues to maintain a foreground state after the system is locked;
binding the daemon process with each sub-process of the third-party application program, and monitoring each sub-process according to the established binding relationship;
after the fact that the sub-process is stopped is monitored, the daemon process starts the stopped sub-process;
the binding the daemon process and each sub-process corresponding to the third-party application program, and monitoring each sub-process according to the established binding relationship comprises the following steps:
implementing an IBinder interface in the daemon process;
calling a Death function of the Binder object of each sub-process through the IBinder interface;
monitoring each sub-process of the third-party application program according to a Death function realized by an IBinder interface called back by an operating system;
before the daemon process starts the stopped sub-process, the method further comprises the following steps:
saving the class name of each sub-process of the third-party application program in the daemon process;
the daemon process starts the stopped sub-process, and the method comprises the following steps:
and the daemon starts the stopped sub-process according to the stored class name of each sub-process.
2. The method of claim 1, wherein the listening for a lock screen broadcast and initiating foreground activity for the daemon for a preset number of pixels after listening for a lock screen broadcast, further comprises:
and monitoring the screen unlocking broadcast, and stopping the foreground activity after monitoring the screen unlocking broadcast.
3. The method of claim 1, wherein the predetermined number of pixels is 1 or 2 pixels.
4. A third party application keep-alive device, comprising:
the creating module is used for creating a daemon process for the third-party application program; the daemon is served as a foreground;
the first monitoring module is used for monitoring screen locking broadcast and starting foreground activities of a preset number of pixels for the daemon process after the screen locking broadcast is monitored;
the binding module is used for binding the daemon process and each subprocess of the third-party application program and monitoring each subprocess according to the established binding relationship;
the starting module is used for starting the stopped subprocess by the daemon process after the fact that the subprocess is stopped is monitored;
the binding module is specifically used for realizing an IBinder interface in the daemon process;
calling a Death function of the Binder object of each sub-process through the IBinder interface;
monitoring each sub-process of the third-party application program according to a Death function realized by an IBinder interface called back by an operating system;
the saving module is used for saving the class name of each subprocess of the third-party application program in the daemon process;
the starting module is specifically configured to start the stopped sub-process by the daemon process according to the stored class name of each sub-process.
5. A third party application keep-alive device, comprising: at least one processor and memory;
the memory stores computer-executable instructions;
execution of computer-executable instructions stored by the memory by the at least one processor causes the at least one processor to perform the third party application keep-alive method of any one of claims 1 to 3.
6. A computer-readable storage medium having computer-executable instructions stored thereon which, when executed by a processor, implement the third-party application keep-alive method of any one of claims 1 to 3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910810253.8A CN112445530B (en) | 2019-08-29 | 2019-08-29 | Method and device for keeping third-party application program alive |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910810253.8A CN112445530B (en) | 2019-08-29 | 2019-08-29 | Method and device for keeping third-party application program alive |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112445530A CN112445530A (en) | 2021-03-05 |
| CN112445530B true CN112445530B (en) | 2023-03-14 |
Family
ID=74740793
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910810253.8A Active CN112445530B (en) | 2019-08-29 | 2019-08-29 | Method and device for keeping third-party application program alive |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112445530B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778514A (en) * | 2021-09-17 | 2021-12-10 | 平安科技（深圳）有限公司 | Program maintenance method, device, equipment and storage medium |
| CN113918933A (en) * | 2021-09-26 | 2022-01-11 | 北京鲸鲮信息系统技术有限公司 | Front-end process searching and killing method, device, equipment and storage medium |
| CN117311840A (en) * | 2023-05-10 | 2023-12-29 | 荣耀终端有限公司 | Application starting method, electronic device and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106484461A (en) * | 2016-09-13 | 2017-03-08 | 北京智能管家科技有限公司 | Service keepalive method and device in intelligent terminal |
| CN106648855A (en) * | 2016-11-21 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | Method and device for controlling application program of terminal |
| CN109766178A (en) * | 2019-01-16 | 2019-05-17 | 四川科瑞软件有限责任公司 | A kind of application process keep-alive system and method under Android system |
| CN109992310A (en) * | 2019-03-12 | 2019-07-09 | 中国平安财产保险股份有限公司 | Application program keepalive method, device, computer equipment and storage medium |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8650290B2 (en) * | 2008-12-19 | 2014-02-11 | Openpeak Inc. | Portable computing device and method of operation of same |
| CN105335171B (en) * | 2014-06-24 | 2019-05-10 | 北京奇虎科技有限公司 | The method and device on application program resident operating system backstage |
| US10289446B1 (en) * | 2015-09-15 | 2019-05-14 | Amazon Technologies, Inc. | Preserving web browser child processes by substituting a parent process with a stub process |
| CN106371911A (en) * | 2016-09-06 | 2017-02-01 | 北京海誉动想科技股份有限公司 | Method for rebooting guarded process by daemon processes |
| CN106648861B (en) * | 2016-12-05 | 2020-07-14 | 阿里巴巴（中国）有限公司 | Keep-alive method and device for background service process |
| CN109144677B (en) * | 2017-06-16 | 2022-08-26 | 百度在线网络技术（北京）有限公司 | Keep-alive process method and device for android system |
| CN108845875B (en) * | 2018-07-09 | 2021-02-02 | 北京顺丰同城科技有限公司 | Resident process keep-alive system and method |
| CN109379337B (en) * | 2018-09-18 | 2021-01-26 | 四川长虹电器股份有限公司 | Keep-alive method for application process under android platform |
-
2019
- 2019-08-29 CN CN201910810253.8A patent/CN112445530B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106484461A (en) * | 2016-09-13 | 2017-03-08 | 北京智能管家科技有限公司 | Service keepalive method and device in intelligent terminal |
| CN106648855A (en) * | 2016-11-21 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | Method and device for controlling application program of terminal |
| CN109766178A (en) * | 2019-01-16 | 2019-05-17 | 四川科瑞软件有限责任公司 | A kind of application process keep-alive system and method under Android system |
| CN109992310A (en) * | 2019-03-12 | 2019-07-09 | 中国平安财产保险股份有限公司 | Application program keepalive method, device, computer equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112445530A (en) | 2021-03-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112445530B (en) | Method and device for keeping third-party application program alive | |
| CN109379337B (en) | Keep-alive method for application process under android platform | |
| WO2017211226A1 (en) | Method for displaying media file, terminal, and storage medium | |
| EP1628185A2 (en) | Mobile communication terminal and data access control method | |
| CN104252389A (en) | Application operation method, system and application | |
| CN109246057B (en) | Message forwarding method, device, forwarding system, storage medium and electronic equipment | |
| CN109005107B (en) | Communication method, intelligent terminal and device with storage function | |
| CN108563472B (en) | Service plug-in loading method and device based on multi-open application | |
| CN112286652A (en) | Android APP background keep-alive method | |
| CN113542256B (en) | Method, device, equipment and storage medium for updating login credentials in client | |
| CN113010214B (en) | BIOS option setting method, system and storage medium | |
| CN111625322A (en) | Data processing method, system and equipment | |
| CN107682389B (en) | Method, terminal and computer readable storage medium for executing network request | |
| CN111274047A (en) | Information processing method, terminal, system, computer device and storage medium | |
| CN109076008B (en) | Suppressing indication of incoming communications in a user interface | |
| CN115061796A (en) | Execution method and system for calling between subtasks and electronic equipment | |
| CN111782347A (en) | Mobile phone application keep-alive method, device and system and storage medium | |
| CN105468438A (en) | Method and device for carrying out recycling treatment to course in application program | |
| CN113805954A (en) | Screen saver display method, electronic device, and computer storage medium | |
| CN111736928A (en) | Picture-in-picture mode starting method and device and computer readable storage medium | |
| CN111030839A (en) | Method, device and equipment for automatically switching operation and maintenance modes and storage medium | |
| CN111240805A (en) | Cloud operating system user switching processing method and device | |
| CN107992363B (en) | Data processing method and device | |
| CN106469155A (en) | A kind of basic data processing method, apparatus and system | |
| WO2017181537A1 (en) | Method and device for processing notification message |
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 |