System service control method, electronic device, and readable storage medium

Abstract

The application provides a system service control method, an electronic device and a readable storage medium. A system service management module receives a stop running request from a system service. In response to the stop running request, the system service management module determines a first node corresponding to the system service and a second node corresponding to the first node. The system service management module deletes the second node. The system service management module updates a reference count of the first node according to the number of the deleted second nodes. The system service updates the reference count of the system service, and stops running when the reference count of the system service is less than a count threshold. In the application, the system service can actively request to stop running, reduce the occupation of the electronic device resources by the system service, and increase the available resources of the electronic device.

Description

Technical Field

[0001] This application relates to the field of system service technology, and in particular to a control method, electronic device and readable storage medium for system services. Background Technology

[0002] As electronic devices become increasingly functional, the number of system services they provide also grows, offering users a wide variety of services. Currently, many system services on electronic devices are persistent. These persistent services consume significant amounts of the device's resources and can even cause foreground applications to lag or stutter.

[0003] There is an urgent need for a method to control the operation of system services and reduce the resource consumption of electronic devices by system services. Summary of the Invention

[0004] This application provides a system service control method, an electronic device, and a readable storage medium. The system service can actively request to stop running, releasing the resources occupied by the system service, which can reduce the system service's occupation of electronic device resources.

[0005] In a first aspect, embodiments of this application provide a method for controlling a system service. The executing entity of this method can be an electronic device or a chip within an electronic device. The following description uses an electronic device as an example. The electronic device includes: a system service, a system service management module, and a service request terminal. The system service management module includes: a first node corresponding to the system service and a second node corresponding to the service request terminal, wherein the first node and the second node correspond to each other.

[0006] In some embodiments, the service requester may be an application in the electronic device.

[0007] It should be understood that during the process of a service requesting client sending a request to the system service to use the system service, the system service management module can create a first node corresponding to the system service and a second node corresponding to the service requesting client, and establish a mapping relationship between the first node and the second node, that is, the first node and the second node correspond to each other. The correspondence between the first node and the second node indicates that the service requesting client corresponding to the second node requests the system service corresponding to the first node.

[0008] Electronic devices can run service processes, and system services can run within these service processes. Each service process can contain at least one system service. In some embodiments, this service process can contain at least two system services, where multiple system services run within the same service process. Regardless of whether multiple system services run within the same service process or a single system service runs within a single service process, in this embodiment, the system service can actively request to stop running.

[0009] In this method, the system service can send a stop-run request to the system service management module. In response to the stop-run request, the system service management module determines the first node corresponding to the system service and the second node corresponding to the first node. The system service management module can delete the second node, and can update the reference count of the first node based on the number of deleted second nodes. Because the first node corresponds to the system service, the system service can update its reference count based on the reference count of the first node, and stops running when the reference count of the system service is less than a counting threshold.

[0010] In this system, for each additional service requester requesting to use (or reference) the system service, the system service's reference count is incremented by 1. Similarly, when the system service management module deletes the second node, it indicates a decrease in the number of service requests using the system service. Therefore, the system service management module can update the reference count of the first node based on the number of deleted second nodes, and the system service can also update its reference count. When the system service's reference count falls below a threshold, it indicates that all service requests have ended referencing the system service, and the system service can stop running. For example, the threshold could be 1.

[0011] In this embodiment, a system service can actively request to stop running, and the system service management module can release the system service. In this embodiment, when multiple system services (i.e., system services) or a single system service are running in a service process, and the service process is not stopped, any one of the system services can actively stop running, which can reduce the system services' occupation of electronic device resources and increase the available resources of the electronic device.

[0012] In one possible implementation, when all service requesters terminate their references to the system service, the system service can send a stop-run request to the system service management module. Here, "when all service requesters terminate their references to the system service" indicates that no service requester is currently referencing the system service provided by the system service; therefore, the system service can request to stop running, which will not affect the tasks executed by the service requesters and avoid service requester task anomalies. For example, if multiple service requesters reference the system service, and all of these service requesters terminate their references to the system service, the system service can send a stop-run request to the system service management module.

[0013] In one possible implementation, the system service can, based on the characteristics of its task execution, send a stop-run request to the system service management module when it determines that it will not execute a task. When the system service is not executing a task, meaning no service requesting client is currently using the system service provided by the system service, the system service can request to stop running, thus preventing task exceptions on service requesting clients.

[0014] For example, the system service is an upgrade system service. If the upgrade system service completes its upgrade task and determines that it will not perform any more upgrade tasks in the short term, it can request to stop running. Upgrade tasks may include, but are not limited to, system version upgrades and system application version upgrades.

[0015] For example, the system service is a Bluetooth system service. When the Bluetooth system service determines that the Bluetooth switch of the electronic device is turned off, or that the electronic device has not established a Bluetooth connection with other electronic devices, the Bluetooth system service determines not to perform any tasks, and therefore the Bluetooth system service can request to stop running. For instance, a user can operate the Bluetooth switch or Bluetooth control of the electronic device to turn off the Bluetooth switch, thus enabling the electronic device to disable Bluetooth communication.

[0016] For example, the system service is a Wi-Fi system service. When the Wi-Fi system service determines that the Wi-Fi switch of the electronic device is turned off, or that the electronic device has not established a Wi-Fi connection with other electronic devices, the Wi-Fi system service determines not to perform any tasks, and therefore the Wi-Fi system service can request to stop running. For instance, a user can operate the Wi-Fi switch or Wi-Fi control of the electronic device to turn off the Wi-Fi switch, thus enabling the electronic device to disable its Wi-Fi function.

[0017] For example, the system service is a system service for providing distributed services. When the system service determines that the communication switch of the electronic device is turned off, or that the electronic device has not established a communication connection with other electronic devices, the system service determines not to perform the task. For example, the distributed service may include any of the following: distributed camera, distributed clipboard, distributed gallery, distributed canvas. For example, a user can operate the communication switch of the electronic device to turn it off. The communication switch may include, but is not limited to, a Wi-Fi switch, a Bluetooth switch, a mobile cellular network switch, etc., enabling the electronic device to disable its ability to communicate with other electronic devices.

[0018] In some embodiments, taking a distributed camera as an example, an electronic device may include a distributed camera application. When the distributed camera application is running, it can call the distributed camera system service to implement the functions of the distributed camera application.

[0019] It should be understood that different types of system services use different conditions to determine whether to not execute a task. In some embodiments, the trigger conditions for each system service to determine whether to execute a task can be preset. The system service can detect whether to execute a task based on its own trigger conditions. When the system service determines that it will not execute a task, it can send a stop running request to the Binder driver.

[0020] In this implementation, the system service can actively request to stop running when it is determined that all service requesters have ended their reference to the system service, or when the system service determines not to perform a task based on its own task characteristics. This does not affect the normal execution of the system service and can also increase the available resources of the electronic device.

[0021] In one possible implementation, when an electronic device uses inter-process communication (IPC) technology to implement cross-process communication, the system service management module includes a Binder driver.

[0022] The system service can send a stop request to the Binder driver. The Binder driver determines the first node corresponding to the system service, and determines the second node corresponding to the first node based on the association between the first node and the second node. For example, the Binder driver can use data structures such as red-black trees, map linked lists, and arrays to store the association between the first node and the second node.

[0023] In some embodiments, when the Binder driver stores the association between the first node and the second node in a red-black tree, the red-black tree can store information about the first node, which may include the second node corresponding to the first node. The first node and the second node correspond, and it can be understood that the system service corresponding to the second node references the system service corresponding to the first node.

[0024] The Binder driver can delete the second node, and the Binder driver updates the reference count of the first node based on the number of deleted second nodes. In this embodiment, for example, the Binder driver reduces the reference count of the first node based on the number of deleted second nodes. It should be understood that in the Binder driver, the first node corresponds to a system service. The reference count of the first node can represent the reference count of the system service, that is, it can represent the number of service requesters referencing (or using) the system service.

[0025] After updating the reference count of the first node, the Binder driver can send a reference count update indication to the system service. This indication specifies the amount by which the system service's reference count has decreased. In response to the reference count update indication, the system service updates its own reference count. When the system service's reference count falls below a threshold, the system service stops running and invokes a stop function to release the resources it occupies.

[0026] In some embodiments, the counting threshold can be 1. In this embodiment, when the reference count of the system service is 0, the system service stops running and a stop running function is called to release the resources occupied by the system service.

[0027] In some embodiments, the system service management module's ability to release the system service can be understood as: the system service management module can release the resources occupied by the system service. Resources may include, but are not limited to: memory resources, central processing unit (CPU) resources, network resources, etc.

[0028] In one possible implementation, after the Binder driver updates the reference count of the first node based on the number of deleted second nodes, the Binder driver can delete the first node when the reference count of the first node is less than the counting threshold.

[0029] In some embodiments, the counting threshold can be 1. In this embodiment, after the Binder driver updates the reference count of the first node according to the number of deleted second nodes, the Binder driver can delete the first node when the reference count of the first node is 0.

[0030] In one possible implementation, in response to a request from a system service to stop running, the Binder driver can determine a first node corresponding to the system service and a second node corresponding to the first node. After determining the second node corresponding to the first node, the Binder driver can send a notification message to the service requesting client, the notification message indicating that the system service request should stop running. The service requesting client can release the second node; in some embodiments, the service requesting client can call a release function to release the resources occupied by the second node.

[0031] In this implementation, the Binder driver can synchronize the system service request to stop running with the service requesting end. In this way, the service requesting end can be aware that the system service has stopped running and can perform corresponding operations to avoid task abnormalities on the service requesting end.

[0032] In one possible implementation, the Binder driver may not synchronize the system service request to the requesting client, thus keeping the requesting client unaware of the system service shutdown. This implementation, to avoid task exceptions on the requesting client, is suitable for the following scenarios:

[0033] Firstly, the service request client is configured to reacquire the handle of the system service each time it is used. This ensures that even if the system service stops running, the next time the service request client uses the system service, it will reacquire the handle and use the system service to execute tasks, guaranteeing successful task execution.

[0034] Secondly, the service requester can pre-register a listening service in the System Capability Manager (SAMgr) to monitor for the system service stopping. For example, the service requester registers a listening service with the SAMgr, and this listening service is used to monitor for the system service stopping. After the SAMgr releases the system service, it sends a notification message to the service requester indicating that the system service has stopped running.

[0035] In this way, although the Binder driver does not notify the service requesting end that uses the system service when the system service actively requests to stop running, the service requesting end can use SAMgr to determine that the system service has stopped running, and enable the service requesting end to reacquire the handle when using the system service the next time. Therefore, even if the Binder driver does not notify the service requesting end that uses the system service, it will not affect the execution of the task of the service requesting end.

[0036] In some embodiments, in response to a request from a service provider to stop running, the Binder driver can determine a first node corresponding to the service provider and a second node corresponding to the first node. After determining the second node corresponding to the first node, the Binder driver can send a notification message to the SAMgr, which instructs the service provider to request to stop running. The SAMgr can release the second node; in some embodiments, the SAMgr can call a release function to release the resources occupied by the second node.

[0037] In one possible implementation, the electronic device has a first interface deployed therein, and the system service calls the first interface to send the stop-run request to the Binder driver. In another possible implementation, the electronic device has a second interface deployed therein, and the Binder driver instructs the second node to call the second interface to send a notification message to the service requesting end.

[0038] In some embodiments, the first interface and the second interface may be deployed in the system service layer of the electronic device, or deployed between user space and kernel space.

[0039] Secondly, embodiments of this application provide an electronic device that may include a processor and a memory. The memory stores computer-executable program code, which includes instructions; when the processor executes the instructions, the instructions cause the electronic device to perform the method described in the first aspect.

[0040] Thirdly, embodiments of this application provide an electronic device that may include units, modules, or circuits for performing the methods provided in the first aspect above.

[0041] Fourthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in the first aspect above.

[0042] Fifthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect.

[0043] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the processor can execute the method described in the first aspect using the communication interface.

[0044] The beneficial effects of the various possible implementations of the second to sixth aspects mentioned above can be found in the beneficial effects of the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of a cross-process communication method;

[0046] Figure 2 A flowchart illustrating a system service control method according to an embodiment of this application;

[0047] Figure 3 A flowchart illustrating a system service control method according to another embodiment of this application;

[0048] Figure 4 A flowchart illustrating a system service control method according to another embodiment of this application;

[0049] Figure 5 A flowchart illustrating a system service control method according to another embodiment of this application;

[0050] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] To facilitate understanding, the relevant terms and concepts involved in the embodiments of this application will be introduced below:

[0052] System service (Sa): This can be understood as a system program that provides specific functions and services. For example, system services may include: system services for monitoring system resource usage, system services for providing network services, system services for managing files, and system services for providing security protection, etc.

[0053] For example, system resource usage could include central processing unit (CPU) usage, memory usage, and disk space usage. System services providing network services could include Bluetooth services and Wi-Fi services. File management could include backup files, compressed files, and encrypted files. Security protection could include antivirus, firewall, and intrusion detection, but this application embodiment does not limit the system services.

[0054] In some embodiments, various types of system services can be deployed in an electronic device. For example, taking Android as an example, Android system services provide Java interfaces and native interfaces for applications (APPs) in the electronic device to call system services. Based on the implementation language of the system services, system services can be divided into Java system services and native system services. The system service control method provided in this application embodiment can be applied to native system services, Java system services, and other types of system services. In some embodiments, the local interface can be referred to as the native interface.

[0055] Persistent: Currently, system services can be persistent services, which can be understood as system services continuously running in memory during the operation of an electronic device, even after the system service has completed its task. In some embodiments, system services can run in the background.

[0056] In some embodiments, some system services may not be resident services; these system services can run in memory when needed. For example, a distributed camera service is only run when an electronic device is networked with another electronic device, at which point the distributed camera service runs in memory. It should be understood that the system service control methods provided in the embodiments of this application can be applied regardless of whether the system service is resident or not.

[0057] A process is the basic unit of dynamic execution in an operating system. System services can run within processes. In some embodiments, a process running a system service can be called a service process. The following embodiments use "process" as an example for illustration.

[0058] In some embodiments, at least one system service can run within a single process. For example, in Android, native system services can run in a local daemon process. Examples include media playback service (MediaPlayerService), camera service (CameraService), and audio service (AudioFlinger), among others.

[0059] A handle is a special type of smart pointer. For example, when an app needs to reference a memory block or object managed by another system (such as a database or operating system), it needs to obtain a handle to that memory block or object. In some embodiments, an app referencing a memory block or object managed by another system can be understood as the app using that memory block or object.

[0060] In this application embodiment, the electronic device is a device that deploys system services. The electronic device can be referred to as user equipment (UE), terminal, etc. For example, the electronic device can be a mobile phone, tablet, personal digital assistant (PDA), handheld device with wireless communication function, computing device, in-vehicle device or wearable device, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in smart home, etc. The form of the electronic device is not specifically limited in this application embodiment.

[0061] As electronic devices become increasingly functional, the number of system services they run also grows. Currently, numerous system services run in the background, consuming significant amounts of the device's resources. In some cases, background processes of system services may even preempt resources from foreground applications, causing them to lag or stutter. These resources can include, but are not limited to, memory, CPU, network, and input / output (I / O) resources.

[0062] Currently, there is no mechanism in electronic devices for system services to actively stop running when a system service completes its task.

[0063] In some embodiments, from the perspective of the Android operating system, a control mechanism for Java system services is designed. For example, an app in an electronic device can bind to a Java system service by calling the `bindService` function, indicating that the app can use the Java system service. The app can unbind from the Java system service by calling the `unbindService` function, indicating that the app stops using the Java system service. In some embodiments, using a system service can also be referred to as referencing a system service or calling a system service.

[0064] The Activity Manager Service (AMS) can be used to manage Java system services. When an app calls the `bindService` function to bind to a Java system service, AMS can determine that an app is referencing that service and increment its reference count. When another app calls `bindService` to bind to the service, AMS increments the reference count again. When an app calls `unbindService` to unbind the service, AMS decrements the reference count. In this way, AMS can update the reference count of the Java system service based on app binding and unbinding operations.

[0065] When the reference count of a Java system service is 0, AMS can adjust the adj value of the process hosting that Java system service. The adj value of a process represents its priority. For example, when the reference count of a Java system service is 0, AMS can increase the adj value of the process hosting that Java system service to lower the process's priority. In this example, when the electronic device's memory is less than the memory threshold, AMS can kill the low-priority process.

[0066] In the example above, if the app continuously holds a handle to the Java system service, the reference count of the Java system service will not be zero. Therefore, AMS cannot manage the process containing the Java system service or the Java system service itself. Furthermore, AMS manages Java system services by killing the process containing the Java system service. When multiple Java system services are running in that process, AMS cannot individually stop one Java system service.

[0067] In some embodiments, the lifecycle of a system service is related to the process in which the system service resides. When the process in which the system service resides terminates, the system service running in that process can stop running, and the electronic device can release the resources occupied by these system services. Here, the process in which the system service resides can be understood as the process running that system service.

[0068] For example, the media playback service, camera service, and audio service run in a single process, which can be a local daemon. Currently, when any one of these three system services completes its task, the service does not stop running; it continues to run in memory, consuming resources of the electronic device. In some embodiments, when the local daemon is destroyed due to a runtime error or is forcibly killed, the lifecycle of the three system services (media playback, camera, and audio) ends, and they can stop running.

[0069] In some embodiments, conditions for process termination can be preset, such as the electronic device reaching a set value for a preset property. The electronic device can activate a property monitoring mechanism, and when the process meets the stop condition, the electronic device can stop the process, the system services running in the process can stop running, and the electronic device can release the resources occupied by these system services.

[0070] In the above system service control methods, when multiple system services run in a process, the system services depend on the process to die or stop. When the process dies or stops, the system services in the process will stop running. Electronic devices cannot control the operation of a single system service.

[0071] To allow electronic devices to control the operation of each system service individually, some embodiments may employ a scheme where "one system service runs in one process." This way, when a system service completes its task, the electronic device can kill the process containing that service, thus stopping the service. However, with numerous system services in an electronic device, having each service run in a separate process would result in an increased number of processes running simultaneously, leading to higher power consumption.

[0072] To address the above problems, embodiments of this application provide a system service control method. When at least one system service is running in a process, any system service within that process can be stopped without the process being terminated or stopped, thus releasing the resources occupied by that system service. This allows for individual control of a single system service and reduces the resource consumption of electronic devices by system services, thereby improving the system's operating speed. It should be understood that in the embodiments of this application, "Sa" is used as an abbreviation for system service.

[0073] To better understand the control method of the system services provided in this application, the principle of cross-process communication is first briefly introduced:

[0074] Because each process has its own independent resources, other processes cannot arbitrarily access the resources of different processes. Therefore, different processes cannot communicate directly, leading to the development of inter-process communication (IPC) technologies. Currently, both inter-process communication (IPC) and remote procedure call (RPC) technologies can be used to implement inter-process communication. The difference lies in that IPC technology uses a Binder driver and can be used for inter-process communication within a device, while RPC technology uses a software bus driver and can be used for inter-device inter-process communication.

[0075] In some embodiments, electronic devices may use IPC technology, RPC technology or other communication technologies to achieve inter-process communication within the device. The following embodiments use IPC technology to achieve inter-process communication within the device as an example for illustration.

[0076] Figure 1 This is a schematic diagram of inter-process communication. (Refer to...) Figure 1 The electronic device may include: a service requesting client, a service providing server, a system ability manager (SAMgr), and a driver. In some embodiments, the electronic device may include at least one service requesting client and at least one service providing server. Figure 1 The following example illustrates the concept of a service requester and a service provider.

[0077] In some embodiments, when the electronic device uses IPC technology, the driver in the electronic device can be a Binder driver. When the electronic device uses RPC technology, the driver in the electronic device can be a soft bus. Figure 1 Taking the Binder driver as an example.

[0078] In some embodiments, the service provider can be regarded as a Binder service process, and the service requester can be regarded as a Binder client process. The Binder service process is responsible for handling requests from the Binder client process, and the Binder client process can call the service running in the Binder service process through the interface provided by the Binder driver.

[0079] At least one system service can run within the Binder service process. In other words, the service provider can provide at least one system service. For example, a media playback service, a camera service, and an audio service can run in a single process. This process can be a local daemon, which can be considered the service provider. The media playback service, camera service, and audio service can be seen as the system services provided by the service provider.

[0080] A service requester can request and invoke system services. For example, a service requester can be an app on an electronic device. Apps can include, but are not limited to, third-party applications and system applications.

[0081] In some embodiments, the service requester, the service provider, and SAMgr may reside in the user space of the electronic device, while the Binder driver may reside in the kernel space of the electronic device.

[0082] In some embodiments, refer to Figure 1 The process by which a service requester uses a system service provided by another service requester may include:

[0083] Step 1: Register.

[0084] System services can first register with SAMgr. In some embodiments, system services can register with SAMgr by calling the addSystemAbility function after their respective processes (such as the Binder service process) have started.

[0085] SAMgr is responsible for managing these system services and providing relevant interfaces to service requesters.

[0086] Step 2, Request.

[0087] If a service requester wants to use a system service from a service provider, it can send a request to the Binder driver.

[0088] The Binder driver responds to requests from the service requester and can communicate with the service provider requested by the service requester.

[0089] In step 2, the Binder driver responds to a request from the service requester by forwarding the request to a system service running on the service provider. For example, the request could request CPU and memory usage. Correspondingly, the system service could be a service used to monitor the usage of system resources.

[0090] System services can process received requests and execute tasks. For example, a system service that monitors the usage of system resources can obtain CPU and memory usage information in response to a request from the Binder driver.

[0091] Step 3: Provide feedback on the task completion results.

[0092] After the system service completes its task, the service provider can return the task completion result to the service requester through the Binder driver. For example, the task completion result may include CPU usage and memory usage.

[0093] It should be noted that, Figure 1 The dashed lines represent the interactions between the service requester, the service provider, and SAMgr. In essence, the interactions between the service requester, the service provider, and SAMgr are all based on communication via the Binder driver.

[0094] In some embodiments, an interface can be set, such as an ioctl interface. The service requester, the service provider, and SAMgr can call the ioctl interface to communicate with the Binder driver, thereby enabling interaction between the service requester, the service provider, and SAMgr.

[0095] This application does not elaborate on the process of the service requester using the system services provided by the service requester, nor on the principle of cross-process communication. For details, please refer to the current description of the principle of cross-process communication.

[0096] In some embodiments, inter-process communication interfaces can be deployed on the Binder driver, and the service requesting end can communicate with the service provider by calling these interfaces.

[0097] The following describes the data structures in the Binder driver:

[0098] In some embodiments, the Binder driver may include a Binder entity object and a Binder reference object.

[0099] Binder Entity Object: Each system service corresponds to a Binder entity object in the Binder driver, which can be called a Binder_node. In other words, the Binder driver includes a Binder entity object for each system service. In some embodiments, the Binder entity object can be called the first node.

[0100] Reference Figure 1 , Figure 1 This example illustrates the concept of a Binder service process running three system services. Each system service corresponds to one Binder entity object, and the Binder service process (the service provider) can therefore correspond to three Binder entity objects. The Binder driver can include these three Binder entity objects corresponding to the Binder service process.

[0101] Binder Reference Object: Each service request client corresponds to a Binder reference object in the Binder driver. The Binder reference object can be called Binder_ref, where ref can be an abbreviation for reference. In some embodiments, the Binder reference object can be called a second node.

[0102] In some embodiments, the Binder driver can create a Binder entity object corresponding to each system service. In some embodiments, when a service requester requests to use a system service, the Binder driver can create a Binder reference object for that service requester and associate this Binder reference object with the Binder entity object of the system service it is using. For example, the Binder driver can store the mapping between the Binder reference object of the service requester and the Binder entity object of the system service it is using.

[0103] Reference Figure 1 Taking an app as an example, the Binder driver can include a Binder reference object corresponding to the app. Alternatively, if the app references a system service within the Binder service process, the Binder entity object of that system service in the Binder driver can correspond to the Binder reference object of the app. For example... Figure 1 The Binder entity object and the Binder reference object are connected, indicating that the Binder entity object of the system service can correspond to the Binder reference object of the APP.

[0104] In some embodiments, a Binder reference object can correspond to at least one Binder entity object. For example, an app can use at least one system service, and the app's Binder reference object in the Binder driver can correspond to the Binder entity object of that at least one system service in the Binder driver. For instance, a navigation app can use system service 1 for providing location services and system service 2 for playing audio. For example, system service 1 corresponds to Binder entity object 1, system service 2 corresponds to Binder entity object 2, and the navigation app corresponds to Binder reference object 1. In the Binder driver, this Binder reference object 1 can correspond to both Binder entity object 1 and Binder entity object 2.

[0105] In some embodiments, a Binder entity object can correspond to at least one Binder reference object. For example, a system service can be used by multiple apps simultaneously. The Binder entity object of this system service in the Binder driver can correspond to the Binder reference objects of these multiple apps in the Binder driver. For instance, if a navigation app and a video playback app both use system service 1 for providing location services, system service 1 corresponds to Binder entity object 1, the navigation app corresponds to Binder reference object 1, and the video playback app corresponds to Binder reference object 2. In the Binder driver, Binder entity object 1 can correspond to both Binder reference object 1 and Binder reference object 2.

[0106] The control method for the system services provided in this application will be described below with reference to specific embodiments. These embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0107] Figure 2 This is a flowchart illustrating a system service control method according to an embodiment of this application. (Refer to...) Figure 2 The system service control method provided in this application embodiment may include:

[0108] S201, the system service sends a stop-run request to the Binder driver.

[0109] In some embodiments, a first interface may be deployed in the electronic device, which a system service may call to send a stop request to the Binder driver. For example, the first interface may be a function interface; for instance, a system service may call the ReleaseSa function to send a stop request to the Binder driver through the first interface. In some embodiments, the first interface may be deployed in the system service layer of the electronic device. In some embodiments, the first interface may be deployed between the user space and kernel space of the electronic device. In some embodiments, the first interface may be deployed on the Binder driver.

[0110] In some embodiments, when all service requesters end their reference to the system service, the system service may send a stop-run request to the Binder driver.

[0111] When a service requester references a system service, it can send a request to the system service (or the service provider to which the system service belongs) through the Binder driver. (See also...) Figure 1 The description in [the document] states that when all service requesters cease referencing the system service, the system service can send a stop-run request to the Binder driver.

[0112] In some embodiments, a service requester can send a request to a system service through the Binder driver. In this example, because a service requester references the system service, the system service can execute the task requested by the first service requester. When the system service completes its task, if the service requester terminates its reference to the system service, the system service can send a stop-run request to the Binder driver.

[0113] In some embodiments, all service requesters terminate their reference to the system service, which can be understood as no service requester referencing the system service. When the system service completes its task, if no service requester uses the system service within a preset time, the system service can send a stop-run request to the Binder driver. The preset time provides a buffer period for the system service, thus avoiding the problem of the system service frequently switching between stopping and starting when another service requester requests to use the system service within a short period.

[0114] In some embodiments, SAMgr can manage system services. When a service requester requests to use a system service, SAMgr can count the number of references to that system service to obtain a reference count. Specifically, SAMgr increments the reference count by 1 for each additional service requester. Conversely, SAMgr decrements the reference count by 1 whenever a service requester stops using the system service.

[0115] In this embodiment of the application, the system service can obtain the reference count of the system service stored in SAMgr. When the reference count of the system service is 0, the system service can send a stop running request to the Binder driver.

[0116] In some embodiments, a system service can manage its own reference count. Specifically, the system service increments its reference count by 1 each time a new service requester requests to use it. Conversely, the system service decrements its reference count by 1 whenever a service requester stops using it.

[0117] In this embodiment of the application, the system service can determine its own reference count. When the reference count of the system service is 0, the system service can send a stop running request to the Binder driver.

[0118] In some embodiments, for example, the service requester may not actually need to request the system service to perform a task, but due to application startup settings or other reasons, once the service requester starts, it will obtain a handle to the system service and send a request to it. In these examples, the service requester does not actually use the system service, but there may still be situations where the service requester requests to use the system service. In this type of case, if the system service does not perform a task, it will not affect the normal operation of the service requester. However, if the system service is still running in memory, it will still consume resources of the electronic device.

[0119] Here's an example to illustrate this scenario: When an audio app starts up, it sends a request to the media playback service via the Binder driver to request access to that service. However, the audio app only actually uses the media playback service to play audio when it's playing the audio. Therefore, because the audio app holds a handle to the media playback service at startup, the media playback service believes there's always a client requesting its service, causing it to run continuously in memory and consume system resources.

[0120] Therefore, in order to solve this problem, in some embodiments, the system service can send a stop running request to the Binder driver when it determines that it will not perform a task, based on its own task characteristics.

[0121] For example, a system service may be a system service for providing version upgrades. In some embodiments, the system service for providing version upgrades may be referred to as an upgrade system service. After completing the version upgrade task, the upgrade system service can determine that it does not need to perform the version upgrade task for a period of time, and the upgrade system service may send a stop running request to the Binder driver. It should be understood that version upgrades may include, but are not limited to, system version upgrades, system APP version upgrades, etc. In some embodiments, a system version upgrade may also be referred to as a device-wide version upgrade.

[0122] For example, a system service may be a system service for providing Bluetooth communication. In some embodiments, the system service for providing Bluetooth communication may be referred to as the Bluetooth system service. For instance, when the Bluetooth system service determines that the Bluetooth switch of an electronic device is turned off, the Bluetooth system service determines that there is no need to perform the Bluetooth communication task, and therefore the Bluetooth system service may send a stop request to the Binder driver. The user can turn off the Bluetooth switch of the electronic device, for example, through a drop-down menu on the electronic device's desktop, which includes a Bluetooth control or Bluetooth switch. Taking the Bluetooth switch as an example, the user can operate the Bluetooth switch to turn off the Bluetooth switch of the electronic device, and correspondingly, the electronic device can disable the Bluetooth communication function. In this example, for instance, the service requesting end holds a handle to the system service upon startup, but the system service, based on its own task characteristics, determines that the user has turned off the Bluetooth function of the electronic device, and in reality, no service requesting end will use the Bluetooth system service. Therefore, the system service may send a stop request to the Binder driver.

[0123] For example, regarding the Bluetooth system service, even if the Bluetooth switch of an electronic device is turned on, but the electronic device is not connected to other electronic devices via Bluetooth, then no service requesting end will actually use the Bluetooth system service. Therefore, the Bluetooth system service can send a stop running request to the Binder driver.

[0124] For example, the system service may be a system service for providing Wi-Fi communication. In some embodiments, the system service for providing Wi-Fi communication may be referred to as the Wi-Fi system service. For instance, when the Bluetooth system service determines that the Wi-Fi switch of the electronic device is turned off, the Wi-Fi system service determines that there is no need to perform the task of Wi-Fi communication, and therefore the Wi-Fi system service may send a stop-run request to the Binder driver. The method by which the user turns off the Wi-Fi switch of the electronic device can be found in the relevant description of the Bluetooth switch. In this example, for instance, the service requesting client holds a handle to the system service upon startup, but the system service, based on its own task characteristics, determines that the Wi-Fi switch of the electronic device is turned off, and in reality, no service requesting client will use the Wi-Fi system service. Therefore, the system service may send a stop-run request to the Binder driver.

[0125] Similarly, for Wi-Fi system services, even if the Wi-Fi switch of an electronic device is turned on, but the electronic device is not connected to other electronic devices via Wi-Fi, then no service requesting end will actually use the Wi-Fi system service. Therefore, the Wi-Fi system service can send a stop running request to the Binder driver.

[0126] For example, the system service may be a system service for providing distributed services, which may include, but are not limited to, distributed cameras, distributed clipboards, distributed image libraries, distributed canvases, etc. In some embodiments, taking a distributed camera as an example, an electronic device may include a distributed camera application. When the distributed camera application is running, it can call the distributed camera system service to implement the functions of the distributed camera application.

[0127] Because distributed services require multiple electronic devices to network together, the networking methods can include, but are not limited to, Wi-Fi networking and Bluetooth networking. In this example, if the communication switch of an electronic device is turned off, the electronic device cannot connect to other electronic devices, and the electronic device determines that it does not need to perform tasks related to the distributed service, the system service used to provide the distributed service can send a stop request to the Binder driver. For example, the communication switch can include, but is not limited to, a Bluetooth switch, a Wi-Fi switch, and a mobile cellular network switch. The method for turning off the communication switch can be found in the description of the Bluetooth switch.

[0128] Additionally, for example, even if a user turns on the communication switch of an electronic device, the electronic device may not actually communicate with other electronic devices and may not actually perform tasks related to distributed services. Therefore, the system service used to provide distributed services may send a stop-run request to the Binder driver.

[0129] In some embodiments, trigger conditions can be pre-set for each system service to determine when it will not perform a task. A system service can then determine whether to perform a task based on its own trigger conditions. When a system service determines it will not perform a task, it can send a stop-run request to the Binder driver. For example, the trigger condition for an upgrade system service to determine when it will not perform a task could be: the upgrade task is completed. The trigger condition for a Bluetooth system service to determine when it will not perform a task could be: the Bluetooth switch of the electronic device is turned off, or the electronic device has not established a Bluetooth connection with other electronic devices. The trigger condition for a Wi-Fi system service to determine when it will not perform a task could be: the Wi-Fi switch of the electronic device is turned off, or the electronic device has not established a Wi-Fi connection with other electronic devices.

[0130] S202, the Binder driver determines the first node corresponding to the system service, and the second node corresponding to the first node.

[0131] In some embodiments, the Binder driver may store a first node corresponding to a system service, such as a Binder entity object. The Binder driver may also store a second node corresponding to the first node. In response to a stop request from a system service, the Binder driver may determine the first node corresponding to the system service and the second node corresponding to the first node within the Binder driver.

[0132] In some embodiments, the Binder driver can store the association between a first node and a second node, which is used to indicate the second node corresponding to the first node. In some embodiments, the Binder driver can use data structures such as red-black trees, map linked lists, and arrays to store the association between the first node and the second node.

[0133] In some embodiments, when the Binder driver stores the association between the first node and the second node in a red-black tree, the red-black tree may store information about the first node corresponding to the system service.

[0134] In some embodiments, the information of the first node may include: the information of the second node corresponding to the first node. The information of the second node may include the identifier of the second node and the creation time of the second node, etc. This application embodiment does not limit this.

[0135] In some embodiments, the information of the first node may include: information of the second node corresponding to the first node, and reference count information of the first node. The reference count information of the first node may include the reference count of the first node, which may be the same as the reference count of the system service. For example, each time a second node is added corresponding to the first node, the Binder driver can increment the reference count of the first node by 1. Whenever a service request releases the second node corresponding to the first node, the Binder driver can decrement the reference count of the first node by 1.

[0136] The Binder driver can determine the second node corresponding to the first node based on the information of the first node in the red-black tree.

[0137] S203, Binder driver deletes the second node.

[0138] For example, Binder entity object 1 can correspond to Binder reference object 1 and Binder reference object 2. Binder entity object 1 can be the first node, and both Binder reference object 1 and Binder reference object 2 can be the second node. In response to receiving a stop running request from the system service corresponding to Binder entity object 1, the Binder driver can delete Binder reference object 1 and Binder reference object 2 corresponding to Binder entity object 1.

[0139] S204, the Binder driver updates the reference count of the first node, and when the reference count of the first node is 0, the Binder driver deletes the first node.

[0140] Because each time a second node is added corresponding to a first node, the Binder driver increments the reference count of the first node by 1. When the Binder driver deletes a second node, it updates the reference count of the first node based on the number of second nodes deleted. For example, when the Binder driver deletes one second node, it decrements the reference count of the first node by 1. When the Binder driver deletes two second nodes, it decrements the reference count of the first node by 2.

[0141] When the reference count of the first node is 0, it indicates that no service requester is currently using the system service, and the Binder driver can delete the first node corresponding to the system service.

[0142] S205, the Binder driver sends a reference count update indication to the system service. The reference count change indication is used to indicate that the reference count of the system service should be updated.

[0143] In some embodiments, after the Binder driver updates the reference count of the first node, it can send a reference count update indication to the system service. The reference count change indication is used to instruct the system service to update its reference count.

[0144] In some embodiments, the reference count change indicator may include an amount that indicates a decrease or increase in the reference count of the system service. For example, if the Binder driver decrements the reference count of the first node by 1, the reference count change indicator may include an amount that indicates a decrease in the reference count of the system service by 1; that is, the reference count change indicator is used to instruct the system service to decrement its reference count by 1.

[0145] In some embodiments, when the SAMgr manages the reference count of the system service, after the Binder driver updates the reference count of the first node, it can send a reference count update instruction to the SAMgr to instruct the SAMgr to update the reference count of the system service.

[0146] S206, In response to the reference count change instruction, the system service updates the reference count of the system service, and when the reference count of the system service is 0, the system service stops running.

[0147] A system service can update its reference count based on a reference count change instruction. For example, a reference count change instruction may include an instruction to decrease the system service's reference count by 1, and the system service can decrement its reference count by 1 based on this instruction.

[0148] When the reference count of a system service reaches 0, it indicates that all service requesters have ended their references to the system service, and the system service can stop running. In some embodiments, the system service stopping can be understood as: the system service stops running and triggers system service recycling, releasing the resources occupied by the system service. In some embodiments, the system service stopping can be understood as: the system service exiting or being unloaded from the process.

[0149] In some embodiments, when the reference count of a system service is 0, the system service can invoke a stop function to trigger system service reclamation, thereby releasing the resources occupied by the system service. In some embodiments, the stop function may be, for example, the OnReleaseObject function.

[0150] In some embodiments, when SAMgr manages the reference count of a system service, SAMgr can update the reference count of the system service, and when the reference count of the system service is 0, SAMgr can call the OnReleaseObject function to trigger the recycling of the system service to release the resources occupied by the system service.

[0151] In this embodiment, when a system service determines that all service requesters have ended their references to the system service, or when the system service determines, based on its own task characteristics, not to execute a task, the system service can proactively initiate a stop-run request to the Binder driver. The Binder driver can update the reference count of the first node corresponding to the system service and trigger the system service to update its own reference count. When the reference count of the system service is 0, the system service can stop running and trigger the release of the resources occupied by the system service. In this embodiment, when multiple system services are running in a process, and without stopping the process, any system service can proactively stop running when it completes or stops its task. This ensures that other system services can execute their tasks without affecting them, and the electronic device can release the resources occupied by the system service, increasing the available resources of the electronic device.

[0152] In some embodiments, when a system service actively stops running, the Binder driver can also notify the service request client that uses the system service, so that the service request client can be aware that the system service has stopped running and can then perform corresponding operations to avoid task abnormalities on the service request client.

[0153] In this embodiment, reference is made to Figure 3 The system service control method provided in this application embodiment may include:

[0154] S301, the system service sends a stop-run request to the Binder driver.

[0155] S302, the Binder driver determines the first node corresponding to the system service, and the second node corresponding to the first node.

[0156] S301-S302 can be referred to in the description of S201-S202.

[0157] S303, the Binder driver sends a notification message to the service request end corresponding to the second node. The notification message is used to instruct the system service request to stop running.

[0158] In some embodiments, a second interface can be deployed in the electronic device. The Binder driver can call this second interface to send a notification message to the service requesting client corresponding to the second node. For example, the second interface can be a function interface; for instance, the Binder driver can instruct the second node to call back the OnSaRelease function to enable the Binder driver to send a notification message to the service requesting client corresponding to the second node through this second interface. The deployment method of the second interface can refer to the relevant description of the first interface.

[0159] Notification messages are used to indicate that a system service is requesting to stop running, or to indicate that a system service is about to stop running.

[0160] S304, the service requesting end releases the second node.

[0161] In some embodiments, the service requester can call the ReleaseHandle function to release the second node.

[0162] In some embodiments, the service requesting end releasing the second node can be understood as: the service requesting end releasing the handle of the system service, or the service requesting end marking the system service as invalid, and the service requesting end releasing the resources occupied by the second node.

[0163] In some embodiments, a system service may provide multiple sub-services, such as monitoring CPU usage, memory usage, and disk space usage. Monitoring CPU usage can be referred to as the first sub-service, monitoring memory usage as the second sub-service, and monitoring disk space usage as the third sub-service. When a service requester requests to use the first sub-service provided by the system service, in this example, the service requester releasing the second node can be understood as the service requester releasing the resources occupied by the first sub-service. Similarly, in S206 above, releasing the resources occupied by the system service can be understood as releasing the resources occupied by the first sub-service, the second sub-service, and the third sub-service.

[0164] S305, Binder driver deletes the second node.

[0165] S306, the Binder driver updates the reference count of the first node, and when the reference count of the first node is 0, the Binder driver deletes the first node.

[0166] S307, the Binder driver sends a reference count update indication to the system service. The reference count change indication is used to indicate that the reference count of the system service should be updated.

[0167] S308, In response to the reference count change instruction, the system service updates the reference count of the system service, and when the reference count of the system service is 0, the system service stops running.

[0168] S305-S308 can be referred to the descriptions in S203-S206.

[0169] In some embodiments, when a service requester senses that a system service has stopped running, different service requesters will perform different operations.

[0170] For example, a system service may provide a first sub-service, a second sub-service, and a third sub-service. A service requester requests to use the first sub-service provided by the system service. When the system service stops running, the Binder driver can notify the service requester. This allows the service requester to determine that the system service has stopped running. The next time the service requester requests to use the first sub-service, it can reacquire a handle to the system service to ensure the use of the first sub-service and guarantee the normal execution of the service requester's task.

[0171] For example, if the system service is Bluetooth, when the Bluetooth system service requests to stop running, the Binder driver can notify the service requesting client that uses the Bluetooth system service. This allows the service requesting client to determine that the Bluetooth system service is stopped and trigger the display to prevent the Bluetooth icon from appearing in the electronic device's status bar. Similarly, if the system service is Wi-Fi, when the Wi-Fi system service requests to stop running, the Binder driver can notify the service requesting client that uses the Wi-Fi system service. This allows the service requesting client to determine that the Wi-Fi system service is stopped and trigger the display to prevent the Wi-Fi icon from appearing in the electronic device's status bar.

[0172] In some embodiments, the structure of the electronic device provided in this application (such as...) Figure 1 As shown), combined with Figure 4 This application describes a control method for system services provided in its embodiments. Figure 4 A flowchart illustrating a system service control method according to another embodiment of this application.

[0173] Reference Figure 4 The system service control method provided in this application embodiment may include:

[0174] S401, The system service calls the ReleaseSa function to send a stop request to the Binder driver.

[0175] S402, the Binder driver determines the first node corresponding to the system service.

[0176] S403, the Binder driver determines the second node corresponding to the first node based on the red-black tree.

[0177] S404, the Binder driver instructs the second node to call back the OnSaRelease function to send a notification message to the service requesting end.

[0178] S405. The service requesting end calls the ReleaseHandle function to release the second node.

[0179] S406, Binder driver deletes the second node.

[0180] S407: The Binder driver updates the reference count of the first node, and deletes the first node when the reference count of the first node is 0.

[0181] S408, the Binder driver sends a reference count update instruction to the system service.

[0182] S409. The system service updates the reference count of the system service, and when the reference count of the system service is 0, the system service calls the OnReleaseObject function and stops running.

[0183] S401-S409 can be referred to the descriptions in S301-S308.

[0184] It should be understood that Figure 4 Other first nodes corresponding to the service provider are not shown; only the first node corresponding to one of the system services provided by the service provider is shown.

[0185] In this embodiment of the application, when a system service actively requests to stop running, the Binder driver can notify the service requesting end that uses the system service so that the service requesting end can be aware that the system service has stopped running. In this way, the service requesting end can perform corresponding operations and avoid the service requesting end's task from being abnormal.

[0186] In some embodiments, in the following scenarios, when a system service actively requests to stop running, the execution of the service requester's task will not be affected even if the Binder driver does not notify the service requester using the system service.

[0187] Example, Scenario 1:

[0188] In some embodiments, the service requesting client can be configured to reacquire a handle to the system service each time it uses the system service. It should be understood that if the system service stops running, the handle already acquired by the service requesting client becomes invalid. When using the system service, the service requesting client cannot continue to use the system service to perform tasks because the acquired handle is invalid, resulting in task exceptions. However, if the service requesting client is configured to reacquire a handle to the system service each time it uses the system service, then even if the system service stops running, the next time the service requesting client uses the system service, it will reacquire a handle to the system service and use it to perform tasks, ensuring successful task execution.

[0189] Example, Scenario 2:

[0190] In some embodiments, the service requester can pre-register a listening service in SAMgr, which is used to monitor for system service shutdowns. After registering the listening service in SAMgr, when the system service stops running, SAMgr can send a notification message to the service requester indicating that the system service has stopped. This allows the service requester to determine that the system service has stopped running.

[0191] In some embodiments, the service requester may register a listening service in SAMgr after installation, or the service requester may register a listening service in SAMgr upon first startup. This application embodiment does not impose any restrictions on this.

[0192] In the two scenarios above, although the Binder driver does not notify the service requesting end that uses the system service when the system service actively requests to stop running, the service requesting end can reacquire the handle the next time it uses the system service, or use SAMgr to determine that the system service has stopped running and reacquire the handle the next time it uses the system service. Therefore, even if the Binder driver does not notify the service requesting end that uses the system service, it will not affect the execution of the task of the service requesting end.

[0193] In one embodiment, in the two scenarios described above, since the Binder driver does not notify the service requesting client that uses the system service, SAMgr can release the second node to release the resources occupied by the second node.

[0194] In this embodiment, each time the service requester uses the system service provided by the system service, if the service requester is configured to reacquire the handle of the system service, or if the service requester can register a listening service in SAMgr in advance, the Binder driver may not notify the service requester using the system service when the system service stops running. This is because the system service can reacquire the handle the next time it is used, or it can use SAMgr to determine that the system service has stopped running so that it can reacquire the handle the next time it is used. Therefore, it does not affect the execution of the service requester's task.

[0195] In some embodiments, the above Figures 2 to 4 The embodiments described herein can be applied to native system services, Java system services, and other system services. In some embodiments, the electronic device may include a system service management module; for example, when the electronic device can use IPC technology, the system service management module may be a Binder driver.

[0196] In some embodiments, the system service control method provided in this application can also be applied to other system architectures, such as RPC communication system architectures. The electronic device may include a system service management module, which can be a soft bus. In some embodiments, when the system service is a Java system service, the system service management module can be AMS.

[0197] It should be understood that when the system service is another type of system service, the system service management module can be other modules in the electronic device. This application embodiment does not exhaustively list the system service management modules.

[0198] Reference Figure 5 The system service control method provided in this application embodiment may include:

[0199] S501, the system service sends a stop running request to the system service management module.

[0200] S501 can be referred to the description in S201.

[0201] S502, in response to the stop operation request, the system service management module determines the first node corresponding to the system service, and the second node corresponding to the first node.

[0202] In some embodiments, the system service management module may store a red-black tree. The system service management module can determine the second node corresponding to the first node based on the red-black tree, as can be seen from the relevant description of the Binder driver in S202.

[0203] S503, the system service management module deletes the second node.

[0204] S503 can be referred to the description in S203.

[0205] S504, the system service management module updates the reference count of the first node based on the number of deleted second nodes.

[0206] S505, the system service updates the reference count of the system service based on the reference count of the first node, and stops running when the reference count of the system service is less than the counting threshold.

[0207] In some embodiments, S504 may refer to the description in S204-S206.

[0208] For example, when the system service management module deletes a second node, it can decrement the reference count of the first node by 1. Since the first node corresponds to a system service, the system service can also decrement its own reference count by 1 based on the updated reference count of the first node. When the system service management module deletes two second nodes, it can decrement the reference count of the first node by 2. Correspondingly, the system service can also decrement its own reference count by 2 based on the updated reference count of the first node.

[0209] Each system service corresponds to a first node, and the reference count of the system service can be equal to the reference count of the first node. For example, when the system service management module deletes a second node, it can decrement the reference count of the first node by 1. Because the first node corresponds to a system service, the system service can update its reference count based on the reference count of the first node. For instance, if the reference count of the first node decreases from 2 to 1, the system service can decrease its own reference count from 2 to 1.

[0210] In this embodiment of the application, the system service may stop running when the reference count of the system service is less than a counting threshold. For example, the counting threshold may be 1, and the system service stops running when the reference count of the system service is 0, as described in S206.

[0211] The system service control method provided in this application embodiment has the same technical principles and effects as the above embodiments, and can be referred to the description in the above embodiments.

[0212] It should be noted that the data involved in this application (including but not limited to data used for analysis, data stored, data displayed, etc.) are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0213] In one embodiment, this application also provides an electronic device, referring to... Figure 6 The electronic device may include a processor 601 (e.g., CPU) and a memory 602. The memory 602 may include high-speed random-access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device. The memory 602 may store various instructions for performing various processing functions and implementing the method steps of this application.

[0214] Optionally, the electronic device involved in this application may further include: a power supply 603, a communication bus 604, and a communication port 605. The aforementioned communication port 605 is used to enable communication between the electronic device and other peripherals. In this embodiment, the memory 602 is used to store computer-executable program code, which includes instructions; when the processor 601 executes the instructions, the instructions cause the processor 601 of the electronic device to perform the actions described in the above method embodiment. The implementation principle and technical effects are similar and will not be repeated here.

[0215] It should be noted that the modules or components described in the above embodiments can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), etc. Furthermore, when a module is implemented through processing element scheduler code, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processors capable of calling program code, such as a controller. Additionally, these modules can be integrated together to implement a system-on-a-chip (SOC).

[0216] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0217] The term "multiple" in this document refers to two or more. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, the character " / " in this document generally indicates an "or" relationship between the preceding and following related objects; in formulas, " / " indicates a "division" relationship. Additionally, it should be understood that in the description of this application, words such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order.

[0218] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

[0219] It is understood that, in the embodiments of this application, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

Claims

1. A control method of a system service applied to an electronic device, the method comprising: The method includes: The system service management module receives a stop-run request from a system service, which is sent to the system service management module by the system service when it determines that it will not perform a task. In response to the stop operation request, the system service management module determines the first node corresponding to the system service and the second node corresponding to the first node; The system service management module deletes the second node; The system service management module updates the reference count of the first node based on the number of deleted second nodes; The system service updates its reference count based on the reference count of the first node, and stops running when the reference count of the system service is less than the counting threshold.

2. The method according to claim 1, characterized in that, The method further includes: A service process is run, in which at least one system service is running.

3. The method according to claim 1, characterized in that, The system services that determine not to perform tasks include: The system service is an upgrade system service. Once the upgrade system service has completed its upgrade task, it determines not to execute any further tasks; or... The system service is a Bluetooth system service. When the Bluetooth system service determines that the Bluetooth switch of the electronic device is turned off, or that the electronic device has not established a Bluetooth connection with other devices, the Bluetooth system service determines not to perform the task; or, The system service is a Wi-Fi system service. When the Wi-Fi system service determines that the Wi-Fi switch of the electronic device is turned off, or that the electronic device has not established a Wi-Fi connection with other electronic devices, the Wi-Fi system service determines not to perform the task; or, When the system service is a system service for providing distributed services, if the system service determines that the communication switch of the electronic device is turned off, or the electronic device has not established a communication connection with other electronic devices, the system service determines not to perform the task.

4. The method according to any one of claims 1-3, characterized in that, The system service management module includes: Binder driver; The system service management module determines the first node corresponding to the system service and the second node corresponding to the first node, including: The Binder driver determines the first node corresponding to the system service, and determines the second node corresponding to the first node based on the association between the first node and the second node; After updating the reference count of the first node, the method further includes: The Binder driver sends a reference count update indication to the system service, the reference count update indication being used to indicate the amount by which the reference count of the system service has decreased; The system service updates its reference count based on the reference count of the first node, and stops running when the reference count of the system service is less than a counting threshold, including: In response to the reference count update indication, the system service updates the reference count of the system service; When the reference count of the system service is less than the count threshold, the system service calls the stop function to release the resources occupied by the system service.

5. The method according to claim 4, characterized in that, The counting threshold is 1.

6. The method according to claim 4, characterized in that, After updating the reference count of the first node, the method further includes: When the reference count of the first node is 0, the Binder driver deletes the first node.

7. The method according to any one of claims 1-3 and 5-6, characterized in that, The electronic device includes a service request client, which is configured to re-acquire the handle of the system service each time it is referenced.

8. The method according to claim 7, characterized in that, The electronic device further includes: a system capability manager, and the method further includes: The service requester registers a listening service with the system capability manager, and the listening service is used to listen for the system service stopping. When the system service stops running, the system capability manager sends a notification message to the service requester that the system service has stopped running.

9. The method according to claim 4, characterized in that, The electronic device includes a service request terminal, and after determining the second node corresponding to the first node, it further includes: The Binder driver sends a notification message to the service requesting client, the notification message being used to instruct the system service request to stop running; The service requesting end releases the second node.

10. The method according to claim 4, characterized in that, The electronic device has a first interface deployed thereon, and the method further includes: The system service calls the first interface to send the stop running request to the Binder driver.

11. The method according to claim 9, characterized in that, The electronic device has a second interface deployed thereon, and the Binder driver sends a notification message to the service requesting client, including: The Binder driver instructs the second node to call the second interface and send the notification message to the service requesting end.

12. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed, implement the method as described in any one of claims 1-11.

14. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed, implement the method as described in any one of claims 1-11.

Images