A method for managing system services and related devices

Abstract

The present application provides a method and related device for managing system services. The method includes: obtaining the invocation situation of a first system service, where the first system service is a system service other than a preset basic system service; obtaining the occurrence situation of one or more events related to the first system service, where the one or more events are configured in a configuration file corresponding to the first system service; obtaining the silent running state of the first system service; and determining the state of the first system service based on the invocation situation, the occurrence situation of the one or more events, and the silent running state, where the state includes a working state or an idle state. In this way, it can be determined whether each system service is in a working state or an idle state.

Description

Technical Field

[0001] This application relates to the field of terminal technologies, and in particular, to a method for managing system services and related devices. Background Art

[0002] System services refer to programs, routines, or processes that perform specified system functions to support other programs, especially underlying (close to hardware) programs. In other words, system services encapsulate basic system capabilities oriented to applications, such as application process management, component management, window management, installation package management, telephone management, network management, distributed communication, etc., and provide application programming interfaces (APIs) to applications.

[0003] In the current operating system, as long as the terminal device is powered on, regardless of whether the system services in the operating system of the terminal device are in a working state, each service system will occupy a certain amount of system resources, which causes a certain amount of resource waste. However, at present, it is impossible to accurately judge the status of each system service, and thus it is also impossible to manage the system resources corresponding to each system service based on the status of each system service. Therefore, how to accurately judge the status of each system service has become a technical problem to be solved urgently. Summary of the Invention

[0004] This application provides a method for managing system services and related devices, in order to accurately judge the status of each system service.

[0005] In a first aspect, this application provides a method for managing system services. This method can be executed by a terminal device, or can also be executed by components (such as chips, chip systems, etc.) configured in the terminal device, or can also be implemented by a logic module or software capable of implementing all or part of the functions of the terminal device. This application does not make any limitations in this regard.

[0006] Exemplarily, the method includes: obtaining the invocation situation of a first system service, where the first system service is a system service other than a preset basic system service; obtaining the occurrence situation of one or more events related to the first system service, where the one or more events are configured in a configuration file corresponding to the first system service; obtaining the silent running state of the first system service; and determining the state of the first system service based on the invocation situation, the occurrence situation of the one or more events, and the silent running state, where the state includes a working state or an idle state.

[0007] Based on the above solution, by obtaining the invocation situation of non-basic system services, the occurrence situation of events related to non-basic system services, and the silent running state of non-basic system services, the state of non-basic system services is judged according to the above three items. For example, whether it is in a working state or an idle state, so that the state of each system service can be accurately judged.

[0008] Combined with the first aspect, in some possible implementation manners, the silent running state includes being in silent running or not being in silent running.

[0009] Combined with the first aspect, in some possible implementation manners, in the case where the first system service declares to start silent running but does not declare to end silent running, the silent running state is being in silent running; or, in the case where the first system service declares to end silent running, or has never declared to start silent running, the silent running state is not being in silent running.

[0010] Combined with the first aspect, in some possible implementation manners, whether the occurrence of any one of the one or more events triggers the first system service to run or triggers the first system service to end running is also configured in the configuration file corresponding to the first system service.

[0011] Combined with the first aspect, in some possible implementation manners, determining the state of the first system service based on the invocation situation, the occurrence situation of the one or more events, and the silent running state includes: in the case where the first system service is invoked, or, in the case where the occurrence of any one of the one or more events triggers the first system service to run, or, in the case where the silent running state is being in silent running, determining the state of the first system service as the working state.

[0012] That is to say, the terminal device can determine whether the state of the first system service is the working state based on any one of the invocation situation, the occurrence situation of the one or more events, or the silent running state of the first system service.

[0013] Combined with the first aspect, in some possible implementation manners, determining the state of the first system service based on one or more of the invocation situation of the first system service, the occurrence situation of the one or more events, and the silent running state includes: in the case where the first system service is not invoked, and, the occurrence of any one of the one or more events triggers the first system service to end running or no event occurs among the one or more events, and, the silent running state is not being in silent running, determining the state of the first system service as the idle state.

[0014] That is to say, the terminal device can determine whether the status of the first system service is the idle status by combining the three items: the invoked situation of the first system service, the occurrence situation of the one or more events, and the silent running status of the first system service.

[0015] Combined with the first aspect, in some possible implementation manners, obtaining the invoked situation of the first system service includes: obtaining the invocation count of the first system service; in the case that the invocation count is zero, determining that the invoked situation is not invoked; or, in the case that the invocation count is greater than zero, determining that the invoked situation is invoked.

[0016] Combined with the first aspect, in some possible implementation manners, obtaining the occurrence situation of one or more events related to the first system service includes: detecting the one or more events related to the first system service.

[0017] Combined with the first aspect, in some possible implementation manners, the method further includes: updating a status identifier according to the status of the first system service determined most recently, where the status identifier is used to record the status of the first system service.

[0018] The terminal device can not only use the status identifier to record the status of each system service, but also modify the status of each system service.

[0019] Combined with the first aspect, in some possible implementation manners, updating the status identifier according to the status of the first system service determined most recently includes: in the case that the status identifier is empty or the status of the first system service recorded is the working status, when it is determined most recently that the invoked situation is not invoked, and no event occurs in the one or more events or the occurrence of any event in the one or more events triggers the first system service to end running, and the silent running status is not in silent running, updating the status identifier to the idle status.

[0020] Combined with the first aspect, in some possible implementation manners, updating the status identifier according to the status of the first system service determined most recently includes: in the case that the status identifier is empty or the status of the first system service recorded is the idle status, when it is determined most recently that the invoked situation is invoked, or when the occurrence of any event in the one or more events triggers the first system service to run, or when the silent running status is in silent running, updating the status identifier to the working status.

[0021] Combined with the first aspect, in some possible implementation manners, the method further includes: in the case that the status of the first system service is the idle status, releasing the system resources occupied by the first system service.

[0022] On the premise of mastering the status of each system service, the terminal device can manage the system resources corresponding to each system service based on the status of each system service. For example, when the first system service is in an idle state, the terminal device can release the system resources corresponding to the first system service to avoid waste of system resources, so that other system services or application processes can utilize this part of the system resources.

[0023] In a second aspect, the present application provides a terminal device, which can be used to implement the methods in the above first aspect and any possible implementation manner of the first aspect. The terminal device includes corresponding modules for executing the above methods. The modules included in the terminal device can be implemented in software and / or hardware manners.

[0024] In a third aspect, the present application provides a terminal device, which at least includes one processor and at least one communication interface. The processor is coupled to the communication interface and can be used to execute a program to implement the method for managing system services in the first aspect and any possible implementation manner in the first aspect.

[0025] Optionally, the terminal device further includes a memory, and the processor is coupled to the memory.

[0026] In a fourth aspect, the present application provides a chip system, which includes at least one processor for supporting the implementation of the functions involved in the above first aspect and any possible implementation manner of the first aspect. For example, processing the data involved in the above methods, etc.

[0027] In a possible design, the chip system further includes a memory, and the memory is used to store program instructions and data. The memory is located inside or outside the processor.

[0028] The chip system can be composed of chips or can include chips and other discrete devices.

[0029] In a fifth aspect, a readable storage medium is provided. A program (which can also be referred to as code or instruction) is stored on the storage medium. When the program is run, the methods in the above first aspect and any possible implementation manner in the first aspect are executed.

[0030] In a sixth aspect, a program product is provided. The program product includes: a program (which can also be referred to as code or instruction). When the program is run, the methods in the above first aspect and any possible implementation manner in the first aspect are executed.

[0031] It should be understood that the technical solutions of the second to sixth aspects of the present application correspond to those of the first aspect of the present application, and the beneficial effects obtained by each aspect and the corresponding feasible implementation manners are similar, and will not be elaborated herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 is a schematic structural diagram of a terminal device applicable to the method for managing system services provided in an embodiment of the present application;

[0033] Figure 2 is a schematic block diagram of the software of a terminal device applicable to the method for managing system services provided in an embodiment of the present application;

[0034] Figure 3 is another schematic block diagram of the software of a terminal device applicable to the method for managing system services provided in an embodiment of the present application;

[0035] Figure 4 is a schematic flowchart of the method for managing system services provided in an embodiment of the present application;

[0036] Figure 5 is a schematic diagram of various triggering methods for changing the state of system services provided in an embodiment of the present application;

[0037] Figure 6 is a schematic diagram of an application process calling a system service provided in an embodiment of the present application;

[0038] Figure 7 is a schematic diagram of obtaining the call count of a first system service provided in an embodiment of the present application;

[0039] Figure 8 is a schematic diagram of detecting system events provided in an embodiment of the present application;

[0040] Figure 9 is a schematic diagram of a system service declaring to start silent operation and declaring to end silent operation provided in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0041] Next, the technical solutions in the present application will be described with reference to the accompanying drawings.

[0042] First, in the embodiments of the present application, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a device, system, product or equipment comprising a series of modules, units or components need not be limited to those modules, units or components clearly listed, but may include other modules, units or components not clearly listed or inherent to these devices, systems, products or equipment.

[0043] Second, in the embodiments of the present application, "and / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship, but it does not exclude the case where the associated objects before and after are in an "and" relationship. The specific meaning represented can be understood in combination with the context.

[0044] Third, in the present application, "when...", "in the case of...", "if", and "when" all mean that the device will perform corresponding processing under certain objective circumstances, not limited to time, and it is not required that the device must have a judgment action when implemented, nor does it mean that there are other limitations.

[0045] System service refers to a program, routine, or process that executes specified system functions to support other programs, especially underlying (close to hardware) programs. In other words, system service encapsulates the basic system capabilities oriented to applications, such as application process management, component management, window management, installation package management, telephone management, network management, distributed communication, etc., and provides APIs to applications. The operating system of the terminal device includes many system services. Among them, some system services are system services that must always be in a running state when the terminal device is operating normally. For example, but not limited to, some system services related to power management, some system services related to screen display, or some system services related to application processes, etc. These system services can be called basic system services; while there are also some system services that do not need to always be in a running state when the terminal device is operating normally. For example, but not limited to, Bluetooth service, telephone service, or upgrade service, etc. These system services can be called non-basic system services.

[0046] In the current operating system, as long as the terminal device is powered on, regardless of whether the system services in the operating system of the terminal device are in a working state, each service system will occupy a certain amount of system resources, which causes a certain amount of resource waste. However, at present, it is still impossible to accurately judge the status of each system service, and thus it is also impossible to manage the system resources corresponding to each system service based on the status of each system service. Therefore, how to accurately judge the status of each system service has become an urgent technical problem to be solved.

[0047] To solve the above problems, the present application provides a method and related device for managing system services. By obtaining the invocation situation of non-basic system services, the occurrence situation of events related to non-basic system services, and the silent running state of non-basic system services, the state of non-basic system services can be judged. For example, whether it is in a working state or an idle state, so that the state of each system service can be accurately judged.

[0048] Before elaborating on the method for managing system services provided in the embodiments of the present application in detail, first in combination with Figure 1 、 Figure 2 and Figure 3 ,an exemplary description of the terminal device applicable to the embodiments of the present application will be given.

[0049] The method for managing system services provided in the embodiments of the present application can be applied to devices such as mobile phones, tablet computers, smart TVs, smart screens, smart watches, wearable devices, in-vehicle devices, laptop computers, personal computers (PCs), ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), distributed devices, etc. The specific types of devices are not limited in the embodiments of the present application. Among them, the device can also be called a user equipment (UE), a mobile device, a user terminal, a wireless communication device, or a user device, etc., and the embodiments of the present application also do not limit this.

[0050] In addition, the methods described in the embodiments of the present application can support operating systems such as the Android operating system (Android OS), the Harmony OS, the OpenHarmony OS, iOS, the Windows operating system (Windows OS), and lightweight operating systems (such as LiteOS). The embodiments of the present application do not make any limitations in this regard.

[0051] Figure 1 is a schematic structural diagram of a terminal device applicable to the method for managing system services provided in the embodiments of the present application.

[0052] Exemplarily, Figure 1 shows a schematic structural diagram of the terminal device 100. As Figure 1As shown in the figure, the terminal device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, and a bone conduction sensor 180M, etc.

[0053] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and a neural-network processing unit (NPU), etc. One or more of them. Among them, different processing units may be independent devices or integrated in one or more processors.

[0054] Among them, the application processor outputs a sound signal through the audio module 170 (such as the speaker 170A, etc.), or displays an image or video through the display screen 194.

[0055] The controller may be the nerve center and command center of the terminal device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0056] A memory can also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can hold the instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses and reduces the waiting time of the processor 110, thus improving the efficiency of the system.

[0057] The processor 110 can perform different operations by executing instructions to achieve different functions. Such instructions can be, for example, instructions pre-stored in the memory before the device leaves the factory, or instructions read from an APP by the user after installing a new APP during use. The embodiments of the present application do not make any limitations on this.

[0058] In some embodiments, the processor 110 may include one or more interfaces. The interfaces can include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM interface, and / or a USB interface, etc.

[0059] The USB interface 130 is an interface that conforms to the USB standard specification. Specifically, it can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the terminal device 100, and can also be used for data transmission between the terminal device 100 and peripheral devices. It can also be used to connect headphones to play audio through the headphones. This interface can also be used to connect other devices, such as augmented reality (AR) devices, etc. It can be understood that the interface connection relationships between the modules illustrated in the present application are only illustrative and do not constitute a structural limitation on the terminal device 100. In other embodiments, the terminal device 100 can also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0060] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some embodiments of wired charging, the charging management module 140 can receive the charging input of the wired charger through the USB interface 130. In some embodiments of wireless charging, the charging management module 140 can receive the wireless charging input through the wireless charging coil of the terminal device 100. While charging the battery 142, the charging management module 140 can also supply power to the terminal device 100 through the power management module 141.

[0061] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives the input from the battery 142 and / or the charging management module 140 and supplies power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, the wireless communication module 160, etc. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be provided in the processor 110. In some other embodiments, the power management module 141 and the charging management module 140 can also be provided in the same device.

[0062] The wireless communication function of the terminal device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modulation and demodulation processor, the baseband processor, etc.

[0063] The antenna 1 and the antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas.

[0064] The mobile communication module 150 can provide solutions for wireless communication including 2G / 3G / 4G / 5G, etc. applied to the terminal device 100.

[0065] The wireless communication module 160 may provide solutions for wireless communications applied to the terminal device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC) technology, infrared (IR) technology, etc.

[0066] In some embodiments, the antenna 1 of the terminal device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, enabling the terminal device 100 to communicate with the network and other devices through wireless communication technologies.

[0067] The terminal device 100 may implement a display function through a GPU, the display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or change display information.

[0068] The display screen 194, which may also be referred to as a screen, can be used to display images, videos, etc. It should be understood that the display screen 194 may further include more components. For example, a backlight panel, a driving circuit, etc. Among them, the backlight panel can be used to provide light sources, and the display panel emits light based on the light sources provided by the backlight panel. The driving circuit can be used to control the liquid crystal in the liquid crystal layer to be transparent or opaque.

[0069] The terminal device 100 may implement a shooting function through an ISP, the camera 193, a video codec, a GPU, the display screen 194, and an application processor, etc.

[0070] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are saved in the external memory card.

[0071] The internal memory 121 can be used to store device-executable program code, and the executable program code includes instructions. The processor 110 executes various functional applications and data processing of the terminal device 100 by running the instructions stored in the internal memory 121. The internal memory 121 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the terminal device 100 (such as audio data, phone book, etc.), etc. In addition, the internal memory 121 can include high-speed random access memory and can also include non-volatile memory, such as at least one disk storage device, a flash memory device, etc.

[0072] The terminal device 100 can implement audio functions through an audio module 170, such as a speaker 170A, a receiver 170B, a microphone 170C, and a headphone interface 170D, as well as an application processor, etc. For example, music playback, recording, etc.

[0073] It can be understood that the structure illustrated in this application does not constitute a specific limitation on the terminal device 100. In other embodiments, the terminal device 100 may include more or fewer components than those illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components can be implemented in hardware, software, or a combination of software and hardware.

[0074] The software system of the terminal device 100 can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture. Among them, the layered architecture divides the software system of the terminal device 100 into several layers, each layer having a clear role and division of labor, and communicating through software interfaces between layers. In this application, taking operating systems such as the layered OpenHarmony OS and Android as examples, the software structure of the terminal device 100 is illustrated exemplarily, but it should not limit the type of the operating system of the terminal device used in the method for managing system services provided by the embodiments of this application.

[0075] Figure 2 It is a structural block diagram of the software of the terminal device applicable to the method for managing system services provided by the embodiments of this application.

[0076] As Figure 2 shown, in some embodiments, the operating system is divided into four layers, from top to bottom are the application layer, the framework layer, the system service layer, and the kernel layer. In some embodiments, the terminal device 100 also includes hardware, such as a GPU, a central processing unit (CPU), a display screen, etc.

[0077] The application layer can include a series of application programs. Figure 2 As shown, the application layer can include system applications and third-party applications. System applications can be understood as some applications that come with the system, such as camera, gallery, calendar, call, map, Bluetooth, video and music applications. Third-party applications can be understood as non-system applications that can be downloaded and installed from application stores or application markets.

[0078] Figure 2 Not shown in the figure, the framework layer may include a user interface (UI) framework, a user program framework, and a component framework. The framework layer provides the operating system's application with a user program framework and component framework in multiple languages, such as C, C++, and JavaScript (JS), as well as APIs for multiple language frameworks open to the outside world for various software and hardware services; it also provides devices with a UI framework in multiple languages, such as C, C++, and JS. The APIs supported by different devices are related to the degree of componentization and tailoring of the system.

[0079] The system service layer is a collection of core capabilities of the operating system, which provides various system services to applications through the framework layer. In an embodiment of the present application, the system service layer may also include a system service management module, which may be used to determine the status of non-basic system services based on one or more of the above three items by obtaining the calling status of non-basic system services, the occurrence of events related to non-basic system services, and the silent running status of non-basic system services. For a detailed description of the system service management module, please refer to the relevant description below, which will not be repeated here for the sake of brevity.

[0080] Figure 2 Not shown in the figure, the system service layer may include a system basic capability subsystem set, a basic software service subsystem set, an enhanced software service subsystem set and a hardware service subsystem set.

[0081] Among them, the system basic capability subsystem set can be composed of subsystems such as distributed soft bus and distributed data management. The system basic capability subsystem set can provide basic capabilities for the operation, scheduling, migration and other operations of distributed applications on multiple devices.

[0082] The basic software service subsystem set can be composed of subsystems such as event notification, telephone, multimedia, etc., and can provide public and general software services.

[0083] The enhanced software service subsystem set can be composed of subsystems such as smart screen proprietary services, wearable proprietary services, and Internet of Things (IoT) proprietary services, and can provide differentiated capability-enhanced software services for different devices.

[0084] The hardware service subsystem set can be composed of subsystems such as location services, biometric recognition, wearable proprietary hardware services, IoT proprietary hardware services, etc., and can provide hardware services.

[0085] It should be noted that according to the deployment environment of different device forms, the basic software service subsystem set, the enhanced software service subsystem set, and the hardware service subsystem set can be trimmed at the subsystem granularity internally, and each subsystem can be trimmed at the functional granularity internally. The embodiments of the present application do not make any limitations on this.

[0086] Figure 2 Not shown in the figure, the kernel layer may include a kernel subsystem and a driver subsystem. The operating system can adopt a multi-kernel design. Based on the kernel subsystem, the operating system supports selecting a suitable OS kernel for different resource-constrained devices; the kernel abstract layer (KAL) provides basic kernel capabilities for the upper layer by shielding the differences of multiple kernels, including process management / thread management, memory management, file system, network management, and peripheral management, etc. The driver framework in the driver subsystem is the basis for the opening of the operating system hardware ecosystem and can provide unified peripheral access capabilities and a driver development and management framework.

[0087] Figure 3 It is another structural block diagram of the software of the terminal device applicable to the method for managing system services provided by the embodiments of the present application.

[0088] As Figure 3 shown, in some embodiments, the Android operating system from top to bottom is respectively an application layer, an application framework layer, an Android runtime, system libraries, and a kernel layer.

[0089] In some embodiments, the terminal device 100 further includes hardware, such as a GPU, a CPU, a display screen, etc.

[0090] The application layer may include a series of applications. As Figure 3 shown, the application layer may include system applications and third-party applications. System applications can be understood as some applications that come with the system, such as applications like camera, gallery, calendar, call, map, Bluetooth, video, and music. Third-party applications can be understood as non-system applications and can be applications downloaded and installed from an application store, etc.

[0091] The application framework layer provides APIs and programming frameworks for the applications in the application layer. The application framework layer includes some predefined functions. As Figure 3 shown, the application framework layer may include a system service management module, etc. For a detailed description of the system service management module, reference can be made to Figure 2The relevant content in [reference] is not elaborated here for the sake of brevity.

[0092] Figure 3 Not shown in [figure], the Android runtime may include a core library and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android operating system.

[0093] The core library can include two parts: one is the functional functions that need to be called by the Java language, and the other is the core library of the Android operating system.

[0094] The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0095] Figure 3 Not shown in [figure], the system library can include multiple functional modules. For example: status monitoring service, surface manager, media libraries, 3D graphics processing library (e.g., OpenGLES), 2D (2 dimensions) graphics engine (e.g., SGL), etc.

[0096] The kernel layer is the layer between hardware and software. Figure 3 Not shown in [figure], the kernel layer may include a power management service, a sensor service (also called a sensor driver), a display service (also called a display driver), a camera driver, an audio driver, etc. The embodiments of the present application do not make any restrictions on this.

[0097] In the embodiments of the present application, as Figure 2 or Figure 3 shown, the terminal device may include a system service management module, so that the terminal device has the ability to implement the method for managing system services provided by the present application.

[0098] It should be understood that Figure 1 , Figure 2 and Figure 3 are only examples and should not impose any limitations on the embodiments of the present application.

[0099] Figure 4 is a schematic flowchart of the method for managing system services provided by the embodiments of the present application.

[0100] As Figure 4As shown, method 400 may include step 410 to step 440. The steps of method 400 may be executed by a terminal device, or may be executed by components (such as chips, chip systems, etc.) configured in the terminal device, or may also be implemented by a logic module or software capable of implementing all or part of the functions of the terminal device. This embodiment of the present application does not make any limitations in this regard. The terminal device may have a structure such as Figure 1 , Figure 2 or Figure 3 shown, and this embodiment of the present application does not make any limitations in this regard. The following will make a detailed description of each step in Figure 4 .

[0101] In step 410, obtain the invocation situation of the first system service.

[0102] It can be understood that the first system service is any system service among non-basic system services. Non-basic system services are system services other than the preset basic system services. For the relevant descriptions of basic system services and non-basic system services, reference can be made to the relevant content above. For the sake of brevity, it will not be elaborated here.

[0103] In step 420, obtain the occurrence situation of one or more events related to the first system service.

[0104] Among them, the one or more events are configured in the configuration file corresponding to the first system service. Whether the occurrence of any event among the one or more events triggers the first system service to run or triggers the first system service to end running is also configured in the configuration file corresponding to the first system service.

[0105] In step 430, obtain the state of silent running.

[0106] Among them, the state of silent running includes being in silent running or not being in silent running.

[0107] In this embodiment of the present application, the system service may actively declare to start silent running or actively declare to end silent running. When the first system service declares to start silent running but does not declare to end silent running, the state of silent running is being in silent running; or, when the first system service declares to end silent running, or has never declared to start silent running, the state of silent running is not being in silent running.

[0108] The terminal device may utilize such as Figure 2 or Figure 3The system service management module shown obtains the invocation situation of the first system service, the occurrence situation of one or more events related to the first system service, and the silent running state of the first system service respectively. That is to say, the system service management module provided by this application can have the ability to obtain the invocation situation of the first system service, and also has the ability to obtain the occurrence situation of one or more events related to the first system service, and also has the ability to obtain the silent running state of the first system service.

[0109] Figure 5 It is a schematic diagram of various triggering methods for changing the state of the system service provided by the embodiment of this application.

[0110] Such as Figure 5 As shown, in the method for managing system services provided by the embodiment of this application, various triggering methods that can change the system service state are comprehensively considered.

[0111] The first triggering method: An application process (including processes of system applications and third-party applications) invokes a system service.

[0112] An application process can invoke one or more system services, and a system service can also be invoked by one or more application processes. When an application process invokes the first system service, the first system service will run, that is, the first system service will enter the working state. For example, some application processes can invoke the camera service to implement functions related to the camera service (including but not limited to the photographing function or the video recording function).

[0113] The second triggering method: The occurrence of an event related to the system service.

[0114] A system service can correspond to one or more related events. One or more events related to the first system service are pre-configured, and it is also pre-configured that the occurrence of any one of these one or more events triggers the first system service to run or end running. By way of example and not limitation, each system service can correspond to a configuration file, in which one or more events related to the system service are configured, and it is configured whether the occurrence of any one of these events triggers the system service to run or triggers the system service to end running. For example, the network connection event and the network disconnection event are related to the network service. When the network connection event occurs, the network service can be triggered to run; when the network disconnection event is triggered, the network service can be triggered to end running.

[0115] The third triggering method: The system service can actively declare to start silent running or actively declare to end silent running.

[0116] In the method for providing management system services provided in the embodiments of the present application, an interface for declaring the start and end of silent operation is provided for the system service. When the system service needs to perform silent operation, the system service can actively declare the start of silent operation through the above interface, so that the system service can enter the working state; when the system service wants to end the silent operation, the system service can actively declare the end of silent operation through the above interface, so that the system service can end the silent operation. For example, when the upgrade service needs to perform silent operation, the upgrade service can actively declare the start of silent operation through the above interface; after the upgrade is completed, the system service can actively declare the end of silent operation through the above interface.

[0117] Therefore, considering the above three triggering methods, the terminal device can use the system service management module to execute any of the steps 410 to 430 above.

[0118] For example, the terminal device can use the system service management module to execute the above step 410, that is, the terminal device can use the system service management module to obtain the invocation situation of the first system service, and then subsequently, in combination with the invocation situation of the first system service, determine whether the first system service is in the working state. When the first system service is invoked by at least one application process, it can be determined that the state of the first system service is the working state; when no application process invokes the first system service, the first system service does not necessarily enter the idle state, and other aspects can also be combined to determine whether the first system service is in the idle state.

[0119] Again, for example, the terminal device can use the system service management module to execute the above step 420, that is, the terminal device can use the system service management module to obtain the occurrence situation of one or more events related to the first system service. That is to say, when an event occurs, the terminal device can, based on the configuration file corresponding to the first system service, determine whether the event is related to the first system service. When the event is related to the first system service, based on the configuration file, determine whether the occurrence of the event triggers the operation of the first system service or triggers the end of the operation of the first system service. When it is determined that the occurrence of the event triggers the operation of the first system service, it can be determined that the state of the first system service is the working state. When it is determined that the occurrence of the event triggers the end of the operation of the first system service, the first system service does not necessarily enter the idle state, and other aspects can also be combined to determine whether the first system service enters the idle state.

[0120] For another example, the terminal device may use the system service management module to execute step 430 above. That is, the terminal device may use the system service management module to obtain the status of the first system service running silently. That is, when the first system service needs to run silently, the first system service may actively declare to the system service management module to start silent running, so that the system service management module knows that the first system service enters the working state; when the first system service wants to end silent running, the first system service may actively declare to the system service management module to end silent running, so that the first system service can end silent running, but the first system service does not necessarily enter the idle state, and other aspects can be combined to further determine whether the first system service is in the idle state. That is, when the first system service declares to start silent running but does not declare to end silent running, the status of silent running is in the state of silent running; or, when the first system service declares to end silent running, or has never declared to start silent running, the status of silent running is not in the state of silent running. When the status of silent running is not in the state of silent running, the first system service does not necessarily enter the idle state, and other aspects can be combined to further determine whether the first system service is in the idle state.

[0121] It can be understood that this application does not impose any restrictions on the execution order of step 410, step 420, and step 430. That is, step 410, step 420, and step 430 may be executed simultaneously or may not be executed simultaneously, and this application does not impose any restrictions on this.

[0122] In step 440, based on the called situation, the occurrence situation of the one or more events, and the status of silent running, determine the status of the first system service.

[0123] Among them, the status of the first system service includes the working state or the idle state. The first system service being in the working state can be understood as the first system service is running; the first system service being in the idle state can be understood as the first system service is not running.

[0124] The terminal device may use the system service management module to determine the status of the first system service based on the called situation of the first system service, the occurrence situation of the one or more events, and the status of silent running of the first system service.

[0125] In a possible implementation, based on the called situation, the occurrence of the one or more events, and the silent running state, determine the state of the first system service, including: when the first system service is called, or, when the occurrence of any one of the one or more events triggers the first system service to run, or, when the silent running state is in a silent running state, determine that the state of the first system service is a working state.

[0126] When the called situation is being called, that is, when the first system service is called by at least one application process, the terminal device can determine that the state of the first system service is a working state.

[0127] When the occurrence of any one of the one or more events related to the first system service triggers the first system service to run, the terminal device can determine that the state of the first system service is a working state.

[0128] When the silent running state of the first system service is in a silent running state, that is, when the first system service actively declares to start silent running but has not declared to end silent running, it can be determined that the state of the first system service is a working state.

[0129] That is to say, based on any one of the called situation of the first system service, the occurrence of the one or more events, or the silent running state of the first system service, the terminal device can determine whether the state of the first system service is a working state.

[0130] In a possible implementation, based on the called situation of the first system service, the occurrence of the one or more events, and the silent running state, determine the state of the first system service, including: when the first system service is not called, and, the occurrence of any one of the one or more events triggers the first system service to end running or no event occurs among the one or more events, and, the first system service declares to end silent running or the first system service does not declare to start silent running, determine that the state of the first system service is an idle state.

[0131] When the called situation is not being called (that is, the first system service is not called by any application process), and, the occurrence of any one of the one or more events related to the first system service triggers the first system service to end running or no event occurs among the one or more events, and, the silent running is not in a silent running state, the terminal device can determine that the state of the first system service is an idle state.

[0132] That is to say, the terminal device can determine whether the status of the first system service is the idle state by combining the three items of the called situation of the first system service, the occurrence of the one or more events, and the silent running state of the first system service.

[0133] In a possible implementation manner, step 410 of the above method 400, obtaining the called situation of the first system service, includes: obtaining the call count of the first system service; when the call count is zero, determining that the called situation is not called; or, when the call count is greater than zero, determining that the called situation is called.

[0134] Figure 6 It is a schematic diagram of an application process calling a system service provided by an embodiment of the present application. To facilitate a better understanding of the method for managing system services provided by the embodiments of the present application, the following combines Figure 6 to briefly describe the process of an application calling a system service.

[0135] Step 1: The application process queries the system service.

[0136] As Figure 6 shown, the application process of the system application and / or the application process of the third-party application can query the system service from the system service management module when it is necessary to call a certain system service.

[0137] Step 2: The system service management module loads the system service.

[0138] The system service management module can load the system service in response to the query of the application process for the system service.

[0139] Step 3: The system service management module returns the system service.

[0140] The system service management module can return the system service to the application process when it loads the corresponding system service.

[0141] Step 4: The application process calls the system service.

[0142] The application process can call the corresponding system service according to the system service returned by the system service management module.

[0143] Figure 7 It is a schematic diagram of obtaining the call count of the first system service provided by an embodiment of the present application.

[0144] Each service component corresponds to a server node in the Binder driver, that is, a Binder entity object. As Figure 7 shown, the service component of the first system service corresponds to a server node in the kernel space.

[0145] Each client component corresponds to a server reference in the Binder driver, that is, a Binder reference object. As Figure 7 shown, the proxy of client a component corresponds to a server reference in the kernel space, and the proxy of client b component also corresponds to a server reference in the kernel space.

[0146] As Figure 7 shown, in the user space, the proxy of client a component calls the first system service through process object a. In the kernel space, it is the reference relationship between the server reference corresponding to the proxy of client a component in the kernel space and the server node corresponding to the service component of the first system service in the kernel space. Similarly, in the user space, the proxy of client b component calls the first system service through process object b. In the kernel space, it is the reference relationship between the server reference corresponding to the proxy of client b component in the kernel space and the server node corresponding to the service component of the first system service in the kernel space.

[0147] The terminal device can use the system service management module to obtain and count the number of server nodes corresponding to the service components of the first system service in the kernel space that are referenced, that is, the number of server references associated with the server nodes. This number is also the call count of the first system service. When the call count is zero, the terminal device can determine that the call situation is not called, that is, the first system service is not called. Or, when the call count is greater than zero, the terminal device can determine that the call situation is called, that is, the first system service is called. As mentioned above, when the first system service is called, the first system service is in a working state. However, when the first system service is not called, the first system service is not necessarily in an idle state.

[0148] In a possible implementation manner, step 420 of the above method 400, obtaining the occurrence situation of an event related to the first system service, includes: detecting an event related to the first system service.

[0149] Figure 8 It is a schematic diagram of detecting system events provided by an embodiment of the present application.

[0150] As Figure 8As shown, the terminal device can use the system service management module to detect system events (hereinafter referred to as events). System events can include, but are not limited to, the Internet access event, network connection event, network disconnection event, etc. as shown in the figure. When a certain event occurs, the system service management module of the terminal device can receive a notification message about the occurrence of the event. Thus, the system service management module can determine whether the event is related to the first system service based on the pre-configured and stored configuration file of the first system service. When the event is related to the first system service, based on the configuration file, it is determined whether the occurrence of the event triggers the first system service to run or triggers the first system service to end running. When it is determined that the occurrence of the event triggers the first system service to run, the state of the first system service can be determined to be the working state. When it is determined that the occurrence of the event triggers the first system service to end running, the first system service does not necessarily enter the idle state, and other aspects can be combined to further determine whether the first system service enters the idle state. For example, taking the network service as an example of the first system service, the related events of the network service can include the network connection event. For example, if it is configured in the configuration file that the occurrence of the Internet access event can trigger the network service to run, then based on this configuration file, when the network connection event occurs, the terminal device can determine that the network service enters the working state.

[0151] Figure 9 It is a schematic diagram of the system service declaration for starting silent operation and declaring the end of silent operation provided by the embodiments of the present application.

[0152] In step 430 of the above method 400, the state of the first system service running silently is obtained. The prerequisite for this step is that the system service management module can provide an interface for the system service to declare starting silent operation and ending silent operation. As Figure 9 shown, when the system service needs to run silently, the system service can actively declare starting silent operation through the above interface. In this way, the system service management module knows at what time the system service starts silent operation and enters the working state; when the system service wants to end silent operation, the system service can actively declare ending silent operation through the above interface. In this way, the system service management module knows at what time the system service ends silent operation.

[0153] In a possible implementation manner, the above method 400 further includes: updating the status identifier according to the status of the first system service determined most recently, where the status identifier is used to record the status of the first system service.

[0154] That is to say, after the status of the first system service is determined most recently, the terminal device can use the system service management module to record the status of the first system service.

[0155] In a possible implementation, the status identifier is updated according to the status of the first system service determined most recently, including: when the status identifier is empty or the status of the first system service recorded is the working state, when it is determined most recently that the invoked situation is not invoked, and when no event occurs in the one or more events or the occurrence of any event in the one or more events triggers the first system service to end running, and when the silent running state is not in the silent running state, the status identifier is updated to the idle state.

[0156] That is to say, after the terminal device is powered on and running, when the status identifier is empty or the status of the first system service has been determined and recorded as the working state, the system service management module continuously obtains the invoked situation of the first system service, the occurrence situation of one or more events related to the first system service, and the silent running state of the first system service. When it is determined most recently that the invoked situation is not invoked, and when no event occurs in the one or more events related to the first system service or the occurrence of any event in the one or more events triggers the first system service to end running, and when the first system service has never declared to start silent running or has declared to end silent running, the terminal device can use the system service management module to update the status of the first system service to the idle state.

[0157] In a possible implementation, the status identifier is updated according to the status of the first system service determined most recently, including: when the status identifier is empty or the status of the first system service recorded is the idle state, when it is determined most recently that the invoked situation is invoked, or when the occurrence of any event in the one or more events triggers the first system service to run, or when the silent running state is in the silent running state, the status identifier is updated to the working state.

[0158] That is to say, after the terminal device is powered on and running, when the status flag is empty or the status of the first system service has been determined and recorded as the idle state, the system service management module continuously obtains the invocation situation of the first system service, the occurrence situation of events related to the first system service, and the silent running status of the first system service. When it is determined that the invocation situation is an invocation for the last time, the terminal device can use the system service management module to update the status of the first system service to the working state; or, when it is determined that the occurrence of any event in the events related to the first system service triggers the running of the first system service for the last time, the terminal device can use the system service management module to update the status of the first system service to the working state; or, when the first system service actively reports the start of silent running to the system service management module for the last time but does not report the end of silent running, the terminal device can use the system service management module to update the status of the first system service to the working state.

[0159] In a possible implementation manner, the method 400 further includes: when the status of the first system service is the idle state, releasing the system resources occupied by the first system service.

[0160] When the first system service is in the idle state, the terminal device can release the system resources corresponding to the first system service to avoid waste of system resources, so that other system services or application processes can utilize this part of the system resources.

[0161] Based on the above solution, the terminal device determines the status of the non-basic system service by obtaining the invocation situation of the non-basic system service, the occurrence situation of events related to the non-basic system service, and the silent running status of the non-basic system service, and combining the above three items. For example, it is in the working state or in the idle state, so as to accurately determine the status of each system service. In addition, the terminal device modifies the status of each system service in real time according to the above three situations. Furthermore, on the premise of being able to grasp the status of each system service in real time, the terminal device can manage the system resources corresponding to each system service based on the status of each system service. For example, when the first system service is in the idle state, the terminal device can release the system resources corresponding to the first system service to avoid waste of system resources, so that other system services or application processes can utilize this part of the system resources.

[0162] The embodiment of the present application further provides a terminal device, which includes corresponding modules for executing the steps in any of the above Figures 4 to 9 embodiments. The modules included in the terminal device can be implemented in software and / or hardware manners.

[0163] An embodiment of the present application further provides a terminal device, which includes a memory and a processor. The memory is used to store a program, and the processor is used to call and execute the program so that the terminal device executes the above-mentioned Figures 4 to 9 steps in any one of the embodiments.

[0164] The present application also provides a chip system, which includes at least one processor for implementing the functions involved in the steps of any one of the above-mentioned Figures 4 to 9 embodiments.

[0165] In a possible design, the chip system further includes a memory for storing program instructions and data, and the memory is located inside or outside the processor.

[0166] The chip system may be composed of chips or may include chips and other discrete devices.

[0167] An embodiment of the present application further provides a readable storage medium, on which a program is stored. When the program is executed by a terminal device, the terminal device executes the above-mentioned Figures 4 to 9 steps in any one of the embodiments.

[0168] An embodiment of the present application further provides a program product, including a program. When the program is run by a terminal device, the terminal device executes the above-mentioned Figures 4 to 9 steps in any one of the embodiments.

[0169] It should be understood that the processor in the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. In the implementation process, the steps of the above method embodiments may be completed by the integrated logic circuit in the hardware of the processor or instructions in the form of software. The above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application may be directly embodied as being executed and completed by the hardware decoding processor, or executed and completed by a combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.

[0170] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories.

[0171] The terms "unit", "module", etc. used in this specification may be used to represent an entity related to a device, hardware, firmware, a combination of hardware and software, software, or software in execution.

[0172] Those of ordinary skill in the art will realize that the various illustrative logical blocks and steps described in connection with the embodiments disclosed herein can be implemented in electronic hardware, or in a combination of software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of this application. In several embodiments provided in this application, it should be understood that the disclosed devices, equipment, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings or direct couplings or communication connections shown or discussed with each other can be through some interfaces. The indirect couplings or communication connections of devices or modules can be in electrical, mechanical, or other forms.

[0173] The modules described as separate components may or may not be physically separated. The components shown as modules may or may not be physical modules, that is, they can be located in one place, or they can be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0174] In addition, in each embodiment of this application, the functional modules can be integrated in a processing module, or each module can exist physically alone, or two or more units can be integrated in one module.

[0175] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to enable a device to execute all or part of the steps of the methods described in each embodiment of this application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks, or optical discs that can store program codes.

[0176] As described above, it is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of changes or substitutions, which should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims described above.

Claims

1. A method for managing system services, characterized in that, Including: Obtain the call situation of the first system service by the application process, where the first system service is a system service other than the preset basic system service, and the application process includes the processes of system applications and third-party applications; the first system service includes a network service; Obtain the occurrence situation of one or more events related to the first system service, where the one or more events are configured in the configuration file corresponding to the first system service, and the occurrence of the one or more events triggers the first system service to run or end running; the events include Internet access events, network connection events, and network disconnection events; Based on the configuration file, determine whether the occurrence of the event triggers the first system service to run; If the event is the network connection event, determine that the first system service is triggered to run, and determine that the state of the first system service is the working state; if the event is the network disconnection event, determine that the first system service ends running, and combine the call situation of the first system service by the application process and the silent running state to determine whether the first system service enters the idle state; Obtain the silent running state of the first system service; Based on the call situation of the application process, the occurrence situation of the one or more events, and the silent running state, determine the state of the first system service, and the state includes the working state or the idle state.

2. The method according to claim 1, characterized in that The determining the state of the first system service based on the call situation of the application process, the occurrence situation of the one or more events, and the silent running state includes: When the first system service is called, or when the occurrence of any one of the one or more events triggers the first system service to run, or when the silent running state is in the silent running state, determine that the state of the first system service is the working state.

3. The method according to claim 1, characterized in that The determining the state of the first system service based on the call situation of the application process, the occurrence situation of the one or more events, and the silent running state includes: When the first system service is not called, and the occurrence of any one of the one or more events triggers the first system service to end running or no event occurs among the one or more events, and the silent running state is not in the silent running state, determine that the state of the first system service is the idle state.

4. The method according to any one of claims 1 to 3, characterized in that, The obtaining the call situation of the first system service by the application process includes: Obtain the call count of the first system service; When the call count is zero, determine that the call situation of the application process is not called; or, When the call count is greater than zero, determine that the call situation of the application process is called.

5. The method according to any one of claims 1 to 3, characterized in that, The obtaining the occurrence situation of one or more events related to the first system service includes: Detect the one or more events related to the first system service.

6. The method according to any one of claims 1 to 3, characterized in that The method further includes: Update the status identifier according to the most recently determined state of the first system service, and the status identifier is used to record the state of the first system service.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: When the status of the first system service is the idle state, release the system resources occupied by the first system service.

8. The method according to any one of claims 1 to 3, characterized in that The silent running state includes being in silent running or not being in silent running, and when the first system service declares to start silent running but does not declare to end silent running, the silent running state is being in silent running; or when the first system service declares to end silent running, or has never declared to start silent running, the silent running state is not being in silent running.

9. A terminal device, characterized in that, It includes a processor and a memory, where the memory is used to store a program; the processor is used to call the program so that the terminal device executes the method described in any one of claims 1 to 8.

10. A readable storage medium, on which a program is stored, characterized in that, When the program is executed, it causes the terminal device to execute the method described in any one of claims 1 to 8.

11. A program product, characterized in that, It includes a program that, when run, causes the terminal device to execute the method described in any one of claims 1 to 8.

Images