Application monitoring method, electronic device and computer readable storage medium
By introducing a system event manager and a process event manager at the application layer to manage listeners, the problem of increased application listening complexity is solved, system performance is improved and functional modules are decoupled, enhancing system fluency and scalability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HONOR DEVICE CO LTD
- Filing Date
- 2024-10-22
- Publication Date
- 2026-05-22
AI Technical Summary
As applications provide more and more functional services, the complexity of application monitoring increases, leading to increased system performance overhead and reduced system smoothness, flexibility, and scalability.
A new system event manager and process event manager are added to the application layer. The application process status is monitored through the target listener, and internal and external listeners are managed through the system event manager and process event manager, which reduces system performance overhead and reduces the coupling between functional modules and the activity manager.
It improves system fluency, flexibility, and scalability, reduces system performance overhead, and lowers the coupling between functional modules and the activity manager.
Smart Images
Figure CN120429189B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of smart terminal technology, specifically to an application monitoring method, an electronic device, and a computer-readable storage medium. Background Technology
[0002] To meet diverse and personalized user needs, the variety and number of applications (APPs) in the market are increasing, and the functional services offered by these applications are becoming increasingly rich. Electronic devices primarily manage applications by monitoring their process status throughout their lifecycle. However, as the functional services offered by applications gradually increase, the complexity of application monitoring also gradually increases. Summary of the Invention
[0003] Therefore, embodiments of this application provide an application monitoring method, an electronic device, and a computer-readable storage medium, aiming to solve the problem of how to implement application monitoring.
[0004] The first aspect of this application provides an application monitoring method applied to an electronic device. The electronic device has a target application installed, and the target application includes at least one functional module. The method includes: implementing a target listener in response to the functional module starting; registering the target listener with an activity manager, which manages the activities of the application process; monitoring the application process status related to the functional module through the target listener; and sending status change information through the activity manager when a change in the application process status related to the functional module is detected.
[0005] In this embodiment, when a functional module of a target application in the application layer registers a target listener with the activity manager in the framework layer, the activity manager uses the registered target listener to monitor the application process status related to the functional module. When the activity manager detects a change in the application process status related to the functional module, it sends status change information to the functional module, thereby assisting the functional module of the target application in monitoring its related applications.
[0006] In one embodiment, implementing the target listener includes: implementing a target internal listener through a target listener interface; registering the target internal listener with a system event manager, which provides registration and unregistration methods for functional modules; and registering the target internal listener with a process event manager, which manages internal listeners of all functional modules, registers and unregisters external listeners, and handles information distribution.
[0007] In this embodiment, a system event manager and a process event manager are added to the application layer. The system event manager provides registration and unregistration methods for each functional module and manages the execution priority of callback methods of internal listeners within functional modules. The process event manager interacts with the activity manager in the framework layer, manages the internal listeners of all functional modules, registers and unregisters external listeners, and handles information distribution. The activity manager enables multiple functional modules to listen to their related applications through target listeners, thereby reducing system performance overhead and lowering the coupling between functional modules and the activity manager, thus improving system fluency, flexibility, and scalability.
[0008] In another embodiment, registering a target listener with the Activity Manager includes: registering an external listener with the Activity Manager when it is determined that the process event manager has not registered an external listener.
[0009] In another embodiment, sending state change information via the Activity Manager includes: sending state change information to the Process Event Manager via the Activity Manager; and iterating through the listener list to send state change information to the functional modules. The listener list is used to store registered internal listeners.
[0010] In another embodiment, the method further includes: unregistering the target listener with the Activity Manager when the process of the target application is destroyed.
[0011] In this embodiment, by unregistering the target listener with the activity manager, the target listener stops monitoring the application process status related to the functional module, thereby releasing system resources.
[0012] In another embodiment, unregistering the target listener with the Activity Manager includes: unregistering the target internal listener with the System Event Manager, which provides registration and unregistration methods for functional modules; and unregistering the target internal listener with the Process Event Manager, which manages all internal listeners of functional modules, registers and unregisters external listeners, and handles information distribution. When it is determined that all listener lists are empty, unregistering the external listener with the Activity Manager. The listener lists include a foreground / background switching listener list and a process death listener list. The internal listeners stored in the foreground / background switching listener list are those that call the foreground / background switching listener method, and the internal listeners stored in the process death listener list are those that call the process death listener method.
[0013] In another embodiment, implementing the target listener includes implementing the target listener through the IProcessObserverEx class.
[0014] In another embodiment, registering a target listener with the activity manager includes registering the target listener via the register method, which passes the mProcessObserver variable as a parameter.
[0015] In another embodiment, implementing the target internal listener through the target listener interface includes: implementing the target internal listener through the full-process listener interface IAllProcessEventHandler, which is used to implement foreground / background switching listener and process death listener. Alternatively, implementing the target internal listener through the foreground / background switching listener interface IONForegroundActivitiesChangedEventHandler, which is used to implement foreground / background switching listener. Alternatively, implementing the target internal listener through the process death listener interface IONProcessDiedEventHandler, which is used to implement process death listener.
[0016] In another embodiment, registering a target internal listener with the process event manager includes adding the target internal listener to a listener list, which stores registered internal listeners.
[0017] A second aspect of this application provides an electronic device including a memory and a processor, which implements the application monitoring method provided in the first aspect when the processor executes computer instructions stored in the memory.
[0018] A third aspect of this application provides a computer-readable storage medium storing computer instructions thereon, which implements the application monitoring method provided in the first aspect when a processor executes the computer instructions.
[0019] A fourth aspect of this application provides a computer program product that includes computer instructions, which implement the application monitoring method provided in the first aspect when the processor executes the computer instructions.
[0020] It is understood that the beneficial effects of the electronic device provided in the second aspect of the embodiments of this application, the computer-readable storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are substantially the same as the beneficial effects of the application monitoring method provided in the first aspect, and will not be repeated here. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the software structure of an electronic device provided as an example.
[0022] Figure 2 This is a sample screenshot of the interface of a butler application.
[0023] Figure 3 This is a sequence diagram of the listening implementation process provided in an example.
[0024] Figure 4 This is a schematic diagram of the logical structure of an implementation of a listener provided as an example.
[0025] Figure 5 This is a schematic diagram of the logical structure of a registered listener provided as an example.
[0026] Figure 6 This is a sequence diagram of the listening implementation process provided in another example.
[0027] Figure 7 This is a schematic diagram of the logical structure of an implementation of a listener interface provided as an example.
[0028] Figure 8 This is a schematic diagram of the logical structure of a registered listener provided as another example.
[0029] Figure 9 This is a schematic diagram of the hardware structure of an electronic device provided as an example. Detailed Implementation
[0030] It should be noted that in the embodiments of this application, "at least one" refers to one or more, and "multiple" refers to two or more. The terms "first," "second," "third," "fourth," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects, not to describe a specific order or sequence. The methods disclosed in the embodiments of this application, or the methods shown in the flowcharts, include one or more steps for implementing the method. Without departing from the scope of the claims, the execution order of multiple steps can be interchanged, and some steps can be deleted.
[0031] In this application embodiment, the electronic device includes, but is not limited to, smartphones, tablets, handheld computers, laptops, intelligent robots, drones, mobile internet devices (MIDs), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal devices in 5G networks, or Public Land Mobile (PLT) networks. Terminal devices in a network (PLMN).
[0032] The software system of the electronic device is described in detail below.
[0033] The software system of electronic devices can adopt a layered architecture, which divides the software into several layers, each with a clear role and division of labor, and the layers communicate with each other through software interfaces. For example... Figure 1 As shown, the software system of an electronic device is divided into four layers, from top to bottom: Application (APP) layer, Framework (FWK) layer, Hardware Abstraction Layer (HAL) and Hardware layer.
[0034] The application layer includes a series of application packages. Each application package may include at least one functional module, which provides specific functional services to implement specific functional applications. For example, the application layer includes a manager application, whose functional modules include, but are not limited to, application lock, virus scanning, traffic management, cleaning and acceleration, and battery management.
[0035] Taking smartphones as an example, such as Figure 2 As shown, on the smartphone's Home screen, when the user taps the Phone Manager icon, the Phone Manager is launched and its interface is displayed. The Phone Manager interface displays function module icons, including an app lock icon (11), a virus scan icon (12), a data usage management icon (13), a cleanup and speed-up icon (14), and a battery management icon (15). When the user taps a function module icon, that function is launched, enabling that specific application.
[0036] The framework layer provides application programming interfaces (APIs) and programming frameworks for various apps in the application layer. The framework layer includes an activity manager, which provides an activity management service (AMS) to manage the activities of the application process throughout its lifecycle.
[0037] The Hardware Abstraction Layer (HAL) is used to execute various application functions and data processing in mobile applications. The HAL includes the processor driver. The processor driver is a processor-oriented control node used to control the processor to implement various processing algorithms.
[0038] The hardware layer provides hardware support for the various applications and data processing functionalities of the hardware abstraction layer. The hardware layer includes processors, which consist of a Central Processing Unit (CPU) and a Graphics Processing Unit (GPU). The CPU handles control logic and serial computation tasks. The GPU handles image processing logic and parallel computation tasks.
[0039] In the aforementioned software system, taking the application layer's manager application as an example, when the manager application's functional modules register listeners with the framework layer's activity manager, the activity manager can monitor the process status of the APP related to the functional modules through the registered listeners. The APP's process status includes the foreground state, the background state, and the process die state.
[0040] In this context, the foreground state refers to the state where the application process interacts with the user. The background state refers to the state where the application process does not interact with the user but performs auxiliary tasks in the background. Auxiliary tasks include, but are not limited to, data synchronization, file download, and scheduled tasks. The process death state refers to the state where the application process terminates for some reason. Reasons include, but are not limited to, normal exit, abnormal termination, external signals, resource exhaustion, and timeout.
[0041] When the Activity Manager detects a change in the process state of an app related to a functional module, it sends state change information to the functional module via a callback. This information includes foreground / background switching and process termination. When the manager app process is destroyed, the functional module unregisters the listener with the Activity Manager, causing the listener to stop monitoring the process state of apps related to the functional module.
[0042] In this embodiment, registering a listener refers to the process of associating a listener with a listening event. A callback refers to invoking a registered listener when a listening event occurs. A listening event refers to a change in the process state of the APP related to a functional module. Unregistering a listener is the reverse process of registering a listener, that is, removing the association between the listener and the listening event. Destroying the manager application process refers to the operating system terminating the manager application's process, causing it to stop running.
[0043] The following section uses the application lock of the Butler application as an example to describe a sample monitoring implementation process.
[0044] like Figure 3 As shown, the listening implementation process includes the following steps:
[0045] S101, APP Lock Service implements a listener.
[0046] In this embodiment, the application lock is used to provide an application lock service, which in turn implements the application lock functionality. Listeners can be implemented using the `IProcessObserverEx` class. The `IProcessObserverEx` class is used to observe and manage application processes. A callback function associated with a listening event can be defined using the `IProcessObserverEx` class, and the listener is implemented through this callback function, as shown in the following pseudocode.
[0047] private val mProcessObserver:IProcessObserverEx=object:IProcessObserverEx()
[0048] {Execute the listener's callback method}
[0049] Here, mProcessObserver is a variable of the IProcessObserverEx class, which implements the callback function defined in the IProcessObserverEx class.
[0050] like Figure 4As shown, the application lock service implements listeners (mProcessObserver) through the IProcessObserverEx class. The IProcessObserverEx class includes the foreground / background switching listener method onForegroundActivitiesChanged and the process death listener method onProcessDied. The foreground / background switching listener method onForegroundActivitiesChanged is used to listen for when the application process switches from foreground to background or vice versa. The process death listener method onProcessDied is used to listen for when the application process switches to a dead state.
[0051] S102. The Application Lock Service registers a listener with the Activity Management Service (AMS).
[0052] In this embodiment, the activity manager in the framework layer provides activity management services, which manage the activities of the application process throughout its lifecycle. The application lock service registers listeners using the `register` method. The `register` method passes the `mProcessObserver` variable as a parameter, i.e., `register(mProcessObserver)`.
[0053] S103. The activity management service uses registered listeners to monitor the process status values of apps related to application locks.
[0054] In this embodiment, the process state of the APP includes foreground state, background state, and process dead state. The process state of the APP can be represented by a process state value. For example, a process state value of "0" is used to represent the foreground state, a process state value of "1" is used to represent the background state, and a process state value of "2" is used to represent the process dead state.
[0055] When an application process runs, it declares metadata information, which includes process state values. The activity management service can obtain the application's process state values from the metadata information.
[0056] S104. When the activity management service detects a change in the process state value of an APP related to the application lock, it sends the state change information to the application lock service.
[0057] In this embodiment, a change in the process state value reflects a change in the process state, such as foreground / background switching or process death. State change information includes foreground / background switching information and process death information. State change information includes the process state value.
[0058] For example, when the activity management service detects that the process status value of an app related to the app lock changes from "0" to "1", reflecting a switch from foreground to background, the activity management service sends foreground / background switch information to the app lock service, which includes the process status value "1". When the activity management service detects that the process status value of an app related to the app lock changes from "1" to "0", reflecting a switch from background to foreground, the activity management service sends foreground / background switch information to the app lock service, which includes the process status value "0". When the activity management service detects that the process status value of an app related to the app lock changes from "0" to "2", reflecting a switch from foreground to process dead state, the activity management service sends process dead information to the app lock service, which includes the process status value "2". When the activity management service detects that the process status value of an app related to the app lock changes from "1" to "2", reflecting a switch from background to process dead state, the activity management service sends process dead information to the app lock service, which includes the process status value "2".
[0059] S105. When the manager application process is destroyed, unregister the listener with the activity management service.
[0060] In this embodiment, the application lock service unregisters the listener using the `unregister` method. The `unregister` method passes the `mProcessObserver` variable as a parameter, i.e., `unregister(mProcessObserver)`. By unregistering the listener with the activity management service, the listener stops monitoring the process status of the app associated with the application lock, thereby releasing system resources.
[0061] The above provides a detailed explanation of the application lock monitoring process. In this embodiment, when the application lock of the manager application in the application layer registers a listener with the activity manager in the framework layer, the activity manager can monitor the process status of the apps related to the application lock through the registered listener. When the activity manager detects a change in the process status of an app related to the application lock, it sends status change information to the application lock, thereby assisting the application lock in the manager application to monitor its related apps.
[0062] However, when multiple functional modules of the management application register listeners with the Activity Manager in the framework layer, it increases system performance overhead and reduces system smoothness. Furthermore, the high coupling between the various functional modules and the Activity Manager means that maintaining each functional module requires maintaining the Activity Manager as well, leading to high maintenance costs and reducing system flexibility and scalability.
[0063] For example, such as Figure 5 As shown, in the application layer's management application, application locking, virus scanning, traffic management, cleanup and acceleration, and battery management are all implemented through the IProcessObserverEx class as listeners, and then the listeners are registered with the activity manager in the framework layer, which increases the system performance overhead.
[0064] To reduce system performance overhead and decrease the coupling between functional modules and the activity manager, the following description uses the application lock of the manager application as an example to illustrate another example of the listening implementation process.
[0065] like Figure 6 As shown, the listening implementation process includes the following steps:
[0066] S201. The application lock service implements internal listeners through a predefined listener interface.
[0067] In this embodiment, the listener interface includes a foreground / background switching listener interface, a process death listener interface, and a full-process listener interface. The foreground / background switching listener interface is used to listen for when an application process switches from a foreground state to a background state or vice versa. The process death listener interface is used to listen for when an application process switches to a dead state. The full-process listener interface is used to listen for when an application process switches from a foreground state to a background state, vice versa, or to a dead state. In other words, the full-process listener interface can simultaneously implement foreground / background switching listening and process death listening.
[0068] For example, the implementation of the internal listener can be seen in the following pseudocode.
[0069] Implement an internal listener by switching between foreground and background listening interfaces:
[0070] private val mProcessObserver=object:IOnForegroundActivitiesChangedEventHandler(){
[0071] override fun onForegroundActivitiesChanged() { execute the callback method of the internal listener}}
[0072] Implement an internal listener using a process death listener interface:
[0073] private val mProcessObserver=object:IOnProcessDiedEventHandler(){
[0074] override fun onProcessDied(){executes the callback method of the internal listener}}
[0075] Implement an internal listener using a full-process listening interface:
[0076] private val mProcessObserver=object:IAllProcessEventHandler(){
[0077] override fun onForegroundActivitiesChanged() { execute the callback method of the internal listener}
[0078] override fun onProcessDied(){executes the callback method of the internal listener}}
[0079] In the examples above, IONForegroundActivitiesChangedEventHandler, IONProcessDiedEventHandler, and IAllProcessEventHandler are all predefined listener interfaces. Specifically, IONForegroundActivitiesChangedEventHandler is the foreground / background switching listener interface, IONProcessDiedEventHandler is the process death listener interface, and IAllProcessEventHandler is the full-process listener interface. Figure 7 As shown, the application lock service implements its internal listener (mProcessObserver) through the full-process listening interface IAllProcessEventHandler. The full-process listening interface IAllProcessEventHandler includes the foreground / background switching listener method onForegroundActivitiesChanged and the process death listener method onProcessDied. The foreground / background switching listener method onForegroundActivitiesChanged is used to listen for when the application process switches from foreground to background or vice versa. The process death listener method onProcessDied is used to listen for when the application process switches to a dead state.
[0080] It is understandable that the listener interfaces of functional modules are implemented according to business requirements. For example, the virus scanning service needs to implement a full-process listening interface, the traffic management service needs to implement a foreground / background switching listening interface, the cleanup and acceleration service needs to implement a full-process listening interface, and the battery management service needs to implement a process death listening interface.
[0081] S202. The application lock service registers an internal listener with the System Event Manager (SEM).
[0082] In this embodiment, the application layer includes a system event manager. The system event manager provides registration and unregistration methods for functional modules and manages the execution priority of callback methods of internal listeners within functional modules. The execution priority of callback methods of internal listeners within functional modules is set according to business requirements. The parameters of the registration method include the identifier of the functional module, the internal listener, and the execution priority of the callback methods of the internal listener of the functional module. The identifier of the functional module is used to distinguish each functional module; for example, the identifier of a functional module is its name.
[0083] S203. The System Event Manager registers an internal listener with the Process Event Manager (PEM).
[0084] In this embodiment, the application layer includes a process event manager. The process event manager interacts with the activity manager of the framework layer, manages the internal listeners of all functional modules, registers and unregisters external listeners, and handles information distribution. The system event manager registers internal listeners by adding them to a listener list. The listener list stores the registered internal listeners. The listener list includes a foreground / background switching listener list and a process death listener list. The internal listeners stored in the foreground / background switching listener list are those that call the foreground / background switching listener method. The internal listeners stored in the process death listener list are those that call the process death listener method.
[0085] S204. The process event manager determines whether an external listener has been registered.
[0086] If yes, proceed to step S206; otherwise, proceed to steps S205-S206.
[0087] S205. When the process event manager determines that no external listener is registered, it registers the external listener with the Activity Management Service (AMS).
[0088] In this embodiment, the process event manager implements an external listener. For example, the following pseudocode illustrates how to implement an external listener.
[0089] private val mProcessObserver:IProcessObserverEx=object:IProcessObserverEx(){
[0090] override fun onForegroundActivitiesChanged() { Iterate through the list of listeners and execute the callback methods of each internal listener}
[0091] override fun onProcessDied(){Iterate through the listener list and execute the callback methods of each internal listener}}
[0092] Here, mProcessObserver is a variable of the IProcessObserverEx class, which implements the callback function defined in the IProcessObserverEx class.
[0093] The process event manager implements external listeners (mProcessObserver) through the IProcessObserverEx class. The IProcessObserverEx class includes the foreground / background switching listener method `onForegroundActivitiesChanged` and the process death listener method `onProcessDied`. The foreground / background switching listener method `onForegroundActivitiesChanged` iterates through the list of foreground / background switching listeners and executes the callback methods of each listener within the list. The process death listener method `onProcessDied` iterates through the list of process death listeners and executes the callback methods of each listener within the list.
[0094] In this embodiment, the process event manager registers listeners using the register method. The register method passes the mProcessObserver variable as a parameter, i.e., register(mProcessObserver).
[0095] S206. When the process event manager determines that an external listener has been registered, the activity management service listens to the process status values of the APP related to the application lock through the registered external listener.
[0096] In this embodiment, the process state of the app includes foreground state, background state, and process dead state. The process state of the app can be represented using process state values. The application process declares metadata information during runtime, which includes process state values. The activity management service can obtain the process state values from the metadata information.
[0097] The activity management service can use an external listener to enable multiple functional modules to monitor the process status of their associated apps.
[0098] S207. When the activity management service detects a change in the process state value of an APP related to the application lock, it sends the state change information to the process event manager.
[0099] In this embodiment, a change in the process state value reflects a change in the process state, such as foreground / background switching or process death. State change information includes foreground / background switching information and process death information. State change information includes the process state value.
[0100] S208. The process event manager traverses the listener list and sends state change information to the application lock service.
[0101] In this embodiment, the process event manager executes the callback methods of each listener within the listener list by traversing the listener list.
[0102] S209. When the manager application process is destroyed, the application lock service unregisters the internal listener with the system event manager.
[0103] In this embodiment, the parameters of the deregistration method include the identifier of the functional module.
[0104] S210, The System Event Manager unregisters the internal listener with the Process Event Manager.
[0105] In this embodiment, the system event manager unregisters internal listeners by removing them from the listener list.
[0106] S211. The process event manager determines whether all listener lists are empty.
[0107] If yes, proceed to step S212; otherwise, end. End means not continuing with subsequent steps.
[0108] In this embodiment, when the process event manager finds all listener lists to be empty, it indicates that there are no listener tasks to be executed. When the process event manager finds at least one listener list to be non-empty, it indicates that there are listener tasks to be executed.
[0109] S212. When the process event manager determines that all listener lists are empty, it unregisters the external listeners with the activity management service.
[0110] In this embodiment, the process event manager unregisters external listeners using the `unregister` method. The `unregister` method passes the `mProcessObserver` variable as a parameter, i.e., `unregister(mProcessObserver)`. By unregistering the external listener with the activity management service, the activity manager terminates any functional module's monitoring of the related app's process status, thereby releasing system resources.
[0111] The above provides a detailed explanation of the application lock's listening implementation process. In this embodiment, a system event manager and a process event manager are added to the application layer. When the application lock registers an internal listener with the system event manager, the system event manager registers the internal listener with the process event manager. When the process event manager determines that no external listener is registered, it implements the external listener and registers it with the activity manager in the framework layer. The activity manager can monitor the process status of apps related to the application lock through the registered external listeners. When the activity manager detects a change in the process status of an app related to the application lock, it sends status change information to the process event manager, which in turn sends status change information to the application lock, thereby assisting the application lock in the manager application to monitor its related apps. The system event manager provides registration and unregistration methods for each functional module and manages the execution priority of callback methods for internal listeners within the functional modules. The process event manager interacts with the activity manager in the framework layer, manages the internal listeners of all functional modules, registers and unregisters external listeners, and handles information distribution. The Activity Manager uses an external listener to enable multiple functional modules to monitor the process status of their associated apps, thereby reducing system performance overhead and decreasing the coupling between functional modules and the Activity Manager, thus improving system smoothness, flexibility, and scalability.
[0112] For example, such as Figure 8As shown, in the application layer's management application, the application lock, virus scanning, traffic management, cleanup and acceleration, and battery management all implement internal listeners through the full-process listening interface IAllProcessEventHandler. The application lock, virus scanning, traffic management, cleanup and acceleration, and battery management all implement internal listeners through the process death listening interface IONProcessDiedEventHandler. The application lock, virus scanning, traffic management, cleanup and acceleration, and battery management all register their internal listeners with the system event manager, which in turn registers them with the process event manager. The process event manager implements external listeners through the IProcessObserverEx class and then registers these external listeners with the activity manager in the framework layer. The activity manager uses a single external listener to allow multiple functional modules to monitor the process status of their associated apps, thereby reducing system performance overhead.
[0113] The above provides a detailed explanation of the monitoring process in conjunction with the software system of the electronic device. The hardware structure of the electronic device will be described in detail below.
[0114] like Figure 9 As shown, the electronic device includes a processor 110, an external memory interface 120, an internal memory 121, a sensor module 130, and a display screen 140. The sensor module 130 includes a touch sensor 131.
[0115] The processor 110 is used to execute the various functions or steps performed by the electronic device in the above embodiments. The processor 110 includes a CPU and a GPU. The processor 110 may also include an application processor (AP), an image signal processor (ISP), a digital signal processor (DSP), a modem processor, and a video codec, etc.
[0116] The external memory interface 120 is used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 110 through the external memory interface 120 to perform data storage functions.
[0117] Internal memory 121 stores executable program code, including instructions. Processor 110 executes the various functions or steps performed by the electronic device in the above embodiments by running the instructions stored in internal memory 121. Internal memory 121 includes a program storage area and a data storage area. The program storage area may store the operating system, at least one application required for a function, etc. The data storage area may store data created during the use of the electronic device. Internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, and Universal Flash Storage (UFS), etc.
[0118] The display screen 140 is used to display an interface. The display screen 140 includes a display panel. The display panel may be a liquid crystal display (LCD), a light-emitting diode (LED), or an organic light-emitting diode (OLED), etc.
[0119] If the display screen 140 integrates the touch sensor 131, then the display screen 140 can be referred to as a touch screen. The touch sensor 131 can also be referred to as a "touch panel". That is, the display screen 140 may include a display panel and a touch panel. The touch sensor 131 is used to detect touch operations applied to or near it. After the touch sensor 131 detects a touch operation, it can trigger the driver of the hardware abstraction layer of the electronic device to periodically scan the touch parameters generated by the touch operation. Then, the driver of the hardware abstraction layer sends the touch parameters to the relevant modules in the upper layer so that the relevant modules can determine the touch event corresponding to the touch parameters.
[0120] Electronic devices can achieve display functions through GPUs, displays 140, and APs.
[0121] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements.
[0122] The functions or steps performed by the electronic device in the above embodiments can also be applied to chips, computer-readable storage media, or computer program products.
[0123] The chip includes a processor and an interface circuit, with the processor and interface circuit electrically connected. The interface circuit can read computer instructions stored in the memory and send the computer instructions to the processor. When the processor executes the computer instructions, it implements the various functions or steps performed by the electronic device in the above embodiments.
[0124] The computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the various functions or steps performed by the electronic device in the above embodiments.
[0125] Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer-readable storage media include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.
[0126] The computer program product includes computer instructions, which, when executed by a processor, implement the various functions or steps performed by the electronic device in the above embodiments.
[0127] The embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of this application.
Claims
1. An application monitoring method, applied to electronic devices, characterized in that, The electronic device has a target application installed on it, the target application including at least one functional module, and the method includes: In response to the startup of a functional module, the functional module implements an internal listener; The functional module registers the internal listener with the system event manager of the application layer. The system event manager is used to provide the functional module with registration and unregistration methods. The system event manager registers the internal listener with the process event manager of the application layer. The process event manager is used to manage the internal listeners of all functional modules, register and unregister external listeners, and handle information distribution. The process event manager implements an external listener; The process event manager registers the external listener with the activity manager of the framework layer, which is used to manage the activities of the application process. The activity manager monitors the application process status related to the functional module through the external listener; When the Activity Manager detects a change in the state of an application process related to the functional module, the Activity Manager sends state change information to the Process Event Manager, and the Process Event Manager sends the state change information to the functional module.
2. The application monitoring method as described in claim 1, characterized in that, The functional module implements an internal listener, including: The functional module implements the internal listener through a listener interface.
3. The application monitoring method as described in claim 2, characterized in that, The process event manager registers the external listener with the activity manager of the framework layer, including: When the process event manager determines that the external listener is not registered, it registers the external listener with the activity manager of the framework layer.
4. The application monitoring method as described in claim 2 or 3, characterized in that, The process event manager sends the status change information to the functional module, including: The process event manager traverses the listener list and sends the status change information to the functional module. The listener list is used to store registered internal listeners.
5. The application monitoring method as described in any one of claims 1-3, characterized in that, The method further includes: When the process of the target application is destroyed, the process event manager unregisters the external listener with the activity manager.
6. The application monitoring method as described in claim 5, characterized in that, When the process of the target application is destroyed, the process event manager unregisters the external listener with the activity manager, including: When the process of the target application is destroyed, the functional module unregisters the internal listener with the system event manager; The system event manager unregisters the internal listener with the process event manager; When the process event manager determines that all listener lists are empty, it unregisters the external listener with the activity manager. The listener lists include a foreground / background switching listener list and a process death listener list. The internal listeners stored in the foreground / background switching listener list are listeners that call the foreground / background switching listener method, and the internal listeners stored in the process death listener list are listeners that call the process death listener method.
7. The application monitoring method as described in any one of claims 1-3 and 6, characterized in that, The process event manager implements an external listener, including: The process event manager implements the external listener through the IProcessObserverEx class.
8. The application monitoring method as described in any one of claims 1-3 and 6, characterized in that, The process event manager registers the external listener with the activity manager of the framework layer, including: The process event manager registers the external listener using the register method, which passes the mProcessObserver variable as a parameter.
9. The application monitoring method as described in claim 2 or 3, characterized in that, The functional module implements the internal listener through a listener interface, including: The functional module implements the internal listener through the full-process listening interface IAllProcessEventHandler, which is used to implement foreground / background switching monitoring and process death monitoring; or The functional module implements the internal listener through the foreground / background switching listener interface IONForegroundActivitiesChangedEventHandler, which is used to implement foreground / background switching listener; or The functional module implements the internal listener through the process death listener interface IONProcessDiedEventHandler, which is used to implement process death listening.
10. The application monitoring method as described in any one of claims 1-3, characterized in that, The system event manager registers the internal listener with the application layer's process event manager, including: The system event manager adds the internal listener to the listener list, which is used to store registered internal listeners.
11. An electronic device, characterized in that, It includes a memory and a processor, which implements the application monitoring method as described in any one of claims 1-10 when the processor executes computer instructions stored in the memory.
12. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by the processor, implement the application monitoring method as described in any one of claims 1-10.