Method for managing IPC threads, and terminal

Abstract

The present application relates to the technical field of terminals. Provided are a method for managing IPC threads, and a terminal. The method comprises: acquiring a waiting thread queue corresponding to a process, wherein the waiting thread queue comprises one or more IPC threads, and each IPC thread in the waiting thread queue is used for the process to communicate with other processes; acquiring a first number of IPC threads in a first state in the waiting thread queue and a second number of IPC threads in a second state in the waiting thread queue, wherein the IPC threads in the first state are actively created by the process, and the IPC threads in the second state are created by the process in response to a binder-driven request; and if the sum of the first number and the second number is greater than or equal to a first threshold, terminating at least some of the IPC threads in the second state. The technical solution provided in the present application can improve the utilization of system resources by IPC threads.

Description

Method for managing IPC thread and terminal

[0001] The present application claims priority to the Chinese patent application No. 202411336900.3, filed on September 23, 2024, and entitled "Method for managing IPC thread and terminal", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of terminals, and in particular to a method for managing inter process communication (IPC) threads and a terminal. BACKGROUND

[0003] Multiple processes are usually running in a terminal. In order to achieve mutual independence between processes, each process is isolated from each other. However, different processes often need to cooperate with each other, so communication is needed between different processes. IPC is a set of programming interfaces that can realize the transmission or exchange of information between different processes in an operating system.

[0004] In the prior art, a process can create an IPC thread corresponding to the process, which can be used for communication between the process and another process. When the process ends, the terminal recycles the IPC thread corresponding to the process, thereby releasing system resources. However, before the process stops cross-process communication, the number of IPC threads corresponding to the process will increase, thereby seriously occupying system resources of the terminal. SUMMARY

[0005] Therefore, the present application provides a method for managing IPC threads and a terminal, which can improve the occupation of system resources by IPC threads.

[0006] To achieve the above purpose, in a first aspect, the present application provides a method for managing IPC threads, the method comprising: obtaining a waiting thread queue corresponding to a process, the waiting thread queue comprising one or more IPC threads, each IPC thread in the waiting thread queue being used for communication between the process and other processes; obtaining a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, the IPC threads in the first state being actively created by the process, and the IPC threads in the second state being created by the process in response to a request of a binder driver; and terminating at least part of the IPC threads in the second state if the sum of the first number and the second number is greater than or equal to a first threshold.

[0007] In the embodiments of the present application, the terminal can acquire a waiting thread queue corresponding to a process, acquire a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, wherein the IPC threads in the first state are created by the process actively, and the IPC threads in the second state are created by the process in response to a request of the binder driver. In a case where a sum of the first number and the second number is greater than or equal to a first threshold value, the terminal can terminate at least part of the IPC threads in the second state, so as to terminate the IPC threads of the process during cross-process communication of the process, thereby reducing the number of the IPC threads running on the terminal and saving system resources of the terminal.

[0008] The binder driver is a virtual device driver used to connect a client process and a server process.

[0009] In some embodiments, the IPC threads in the second state are idle threads or non-main threads that have been in the waiting thread queue for a first time length greater than or equal to a second threshold value.

[0010] That is, the IPC threads in the second state are idle threads that have not been woken up for a long time and are created by the process in response to a request of the binder driver.

[0011] In some embodiments, if the sum of the first number and the second number is greater than or equal to the first threshold value, the terminal terminates at least part of the IPC threads in the second state, including: if the sum of the first number and the second number is greater than or equal to the first threshold value, the terminal terminates a third number of the IPC threads in the second state in the waiting thread queue, the third number being a difference between the sum of the first number and the second number and the first threshold value.

[0012] In some embodiments, the third number is greater than 1 and less than or equal to the second number. In some embodiments, the third number is greater than or equal to the first number + the second number - the first threshold value, and the third number is less than or equal to the second number.

[0013] In some embodiments, the at least part of the IPC threads in the second state are at a head end of the waiting thread queue.

[0014] In some embodiments, the terminating the IPC thread at least partially in the second state comprises: deleting the IPC thread at least partially in the second state from the waiting thread queue if the sum of the first number and the second number is greater than or equal to the first threshold; waking up the IPC thread at least partially in the second state; and instructing the process to exit the IPC thread at least partially in the second state.

[0015] In some embodiments, before the deleting the IPC thread at least partially in the second state from the waiting thread queue, the method further comprises: adding a mark information to the IPC thread at least partially in the second state, the mark information being used to indicate that the IPC thread at least partially in the second state is a thread that is not woken up due to a timeout.

[0016] When it is needed to exit the IPC thread, instructing the process to exit the IPC thread can improve the stability of the process and improve the abnormality caused by terminating the IPC thread, such as being unable to recycle the system resources occupied by the IPC thread, and being unable to continue to execute some tasks of the process that depend on the IPC thread.

[0017] In some embodiments, the terminal can end the IPC thread at least partially in the second state, or in other words, forcibly exit the IPC thread at least partially in the second state.

[0018] In some embodiments, the terminal can acquire the waiting thread queue corresponding to the process, including: acquiring the waiting thread queue corresponding to the process when a trigger condition is met; and wherein the trigger condition comprises at least one of the following: a timer being woken up; the system resources used by the terminal being greater than or equal to a third threshold; the total number of IPC threads created in the terminal being greater than or equal to a fourth threshold; and the power consumption of the terminal being greater than or equal to a fifth threshold.

[0019] The terminal can acquire the waiting thread queue corresponding to the process in response to the timer being woken up, acquire a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, wherein the IPC threads in the first state are created by the process actively, and the IPC threads in the second state are created by the process in response to a request of a binder driver. In a case where the sum of the first number and the second number is greater than or equal to a first threshold, the terminal can terminate the IPC thread at least partially in the second state, which realizes the termination of the number of IPC threads included in the terminal triggered by the timer multiple times or periodically, and further saves the system resources of the terminal for a long time or continuously.

[0020] Alternatively, the terminal can obtain a waiting thread queue corresponding to the process when the usage state of the system resource reaches a preset state, obtain a first number of IPC threads in the first state and a second number of IPC threads in the second state in the waiting thread queue, wherein the IPC thread in the first state is actively created by the process, and the IPC thread in the second state is created by the process in response to the request of the binder driver. In the case where the sum of the first number and the second number is greater than or equal to the first threshold value, the terminal can terminate at least part of the IPC threads in the second state, thereby dynamically reducing the number of IPC threads included in the terminal according to the usage state of the system resource of the terminal, and further saving the system resource of the terminal.

[0021] In some embodiments, the first threshold value is a preset fixed value; or the first threshold value is inversely related to at least one of the system resource used by the terminal, the total number of IPC threads created in the terminal, and the power consumption of the terminal.

[0022] The smaller the first threshold value is, the smaller the total number of the IPC threads in the first state and the IPC threads in the second state that the terminal can maintain is, the more the IPC threads in the second state that the terminal terminates are, and the more the system resource that can be saved is.

[0023] In some embodiments, the timer is configured to be woken up every second time interval since the binder driver initialization is completed.

[0024] In some embodiments, the process is a process in a non-frozen state, and / or the process is a process not in a white list.

[0025] Since at least part of the system resource occupied by the process in the frozen state has been released, in the case where the terminal includes the process in the frozen state and the process in the non-frozen state, only the IPC threads of the process in the non-frozen state can be managed, and the IPC threads of the process in the frozen state do not need to be additionally managed.

[0026] The white list is used to indicate at least one process whose IPC thread is not terminated before the cross-process communication is completed, and the process identifier of the at least one process can be included in the white list. In some embodiments, the terminal can set the white list in advance. In some embodiments, the terminal can detect the total number of IPC threads included in the process, and if the total number is less than a sixth threshold value, the number of IPC threads relied on by the process for cross-process communication is small, and the system resource occupied is less, so the process identifier of the process is added to the white list, so that the IPC thread of the process is not managed according to the method provided in the present application.

[0027] In a second aspect, an apparatus for managing an IPC thread is provided. The apparatus has the functions of the methods described above and the functions of the terminal behavior in the possible implementation manners of the methods described above. The functions can be implemented by hardware, or by corresponding software executed by hardware. The hardware or software includes one or more modules or units corresponding to the functions. For example, a transceiving module or unit, a processing module or unit, an obtaining module or unit, and the like.

[0028] In a third aspect, a terminal is provided. The terminal includes a memory and a processor. The memory is configured to store a computer program. The processor is configured to execute the method described in any one of the first aspect when the computer program is invoked.

[0029] In a fourth aspect, a chip system is provided. The chip system includes a processor coupled with a memory. The processor executes a computer program stored in the memory to implement the method described in any one of the first aspect.

[0030] The chip system can be a single chip or a chip module composed of multiple chips.

[0031] In a fifth aspect, a computer readable storage medium is provided. The computer readable storage medium stores a computer program. The computer program is executed by a processor to implement the method described in any one of the first aspect.

[0032] In a sixth aspect, a computer program product is provided. The computer program product, when running on a terminal, causes the terminal to execute the method described in any one of the first aspect.

[0033] It can be understood that the beneficial effects of the second aspect to the sixth aspect can be referred to the related description of the first aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0034] FIG. 1 is a structural schematic diagram of a terminal provided by an embodiment of the present application;

[0035] FIG. 2 is a software structure block diagram of a terminal provided by an embodiment of the present application;

[0036] FIG. 3 is a structural block diagram of a binder driver provided by an embodiment of the present application;

[0037] FIG. 4 is a flowchart of a cross-process communication method provided by an embodiment of the present application;

[0038] FIG. 5 is a flowchart of a method for managing an IPC thread provided by an embodiment of the present application;

[0039] FIG. 6 is a flowchart of another method for managing an IPC thread according to an embodiment of the present application;

[0040] FIG. 7 is a flowchart of another method for managing an IPC thread according to an embodiment of the present application;

[0041] FIG. 8 is a flowchart of another method for managing an IPC thread according to an embodiment of the present application. DETAILED DESCRIPTION

[0042] The method for managing an IPC thread pool provided by the embodiments of the present application can be applied to a terminal such as a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), and the like. The embodiments of the present application do not make any limitation on the specific type of the terminal.

[0043] FIG. 1 is a schematic structural diagram of a terminal 100 according to an embodiment of the present application. The terminal 100 can include a processor 110, a memory 120, a communication module 130, and the like.

[0044] The processor 110 can include one or more processing units, and the memory 120 is configured to store program codes and data. In the embodiments of the present application, the processor 110 can execute computer execution instructions stored in the memory 120, to control and manage the actions of the terminal 100.

[0045] The communication module 130 can be used for communication between various internal modules of the terminal 100, or communication between the terminal 100 and other external terminals, or communication between the terminal 100 and a network or other external terminals. For example, the communication module 130 can provide a wireless communication solution applied to the terminal 100, including wireless local area networks (WLAN) (such as a wireless fidelity (Wi-Fi) network), Bluetooth (BT), a global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, and the like. Alternatively, the communication module 130 can provide a wireless communication solution applied to the terminal 100, including 2G / 3G / 4G / 5G, and the like.

[0046] Optionally, the terminal 100 can further include a display screen 140, which can display images or videos in a human-computer interaction interface, and the like.

[0047] Optionally, the terminal 100 can further include peripheral devices 150, such as a mouse, a keyboard, a speaker, a microphone, and the like.

[0048] It should be understood that the structure of the terminal 100 is not limited in the embodiments of the present application, except for the various components or modules listed in FIG. 1. In other embodiments of the present application, the terminal 100 can further include more or less components than those shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0049] Please refer to FIG. 2, which is a software structure block diagram of a terminal 100 provided in the embodiments of the present application.

[0050] The terminal 100 includes a user state and a kernel state. The distinction between the user state and the kernel state is made at the level of the operating system of the terminal 100, and the two states are designed for the safety and management of the operating system.

[0051] The user state is a state in which a user program runs, has lower system permissions, and can only run in a specific space defined by the operating system, for example, cannot directly access hardware devices or execute privileged instructions, and all accesses to hardware need to be performed through operations. The kernel state is a state in which an operating system program runs and hardware is operated, has higher system permissions, and can access resources of the operating system, such as a CPU, memory, and input / output resources. In some embodiments, when a user program in the user state needs the operating system to help complete some work that it does not have the permission and ability to complete, the user program falls into the kernel state through a system call, and the operating system completes the corresponding work.

[0052] The user state includes a client process and a server process. The client process and the server process are any two processes in the terminal 100, and the client process and the server process are relative concepts. For example, the user state includes any first process and a second process, when the first process is used to receive or process data of the second process, the first process is a server process, and the second process is a client process. In some embodiments, the data in the user state of the client process and the server process is not shared, and the two processes cannot directly communicate with each other. In some embodiments, the client process and the server process can be processes of different application programs. In some embodiments, the client process and the server process include an IPC module. The IPC module can provide a binder-based IPC communication mechanism and an IPC thread pool, and complete cross-process data transmission and reception by encapsulating operations on a binder file node. The IPC thread pool is a submodule of the IPC module, and mainly cooperates with the binder driver to complete user state thread creation and data reading and writing. The IPC thread pool includes one or more IPC threads, and each IPC thread can be used for communication between other processes (such as a client process) and a process (such as a server process) to which the IPC thread belongs. In some embodiments, the IPC thread pool includes two types of IPC threads. One type of IPC thread is actively created by the server process, that is, an IPC thread in a BINDER_LOOPER_STATE_ENTERED state. The other type of IPC thread is created by the binder driver according to a cross-process communication request of the server process, that is, an IPC thread in a BINDER_LOOPER_STATE_REGISTERED state.

[0053] In some embodiments, the life cycle of a process and a thread can include new, ready, running, blocked, and death.

[0054] For example, new means newly created thread and allocating memory to the thread, ready means the thread is ready for execution and waits for execution, running means the thread has acquired the use of the processor and is in the process of execution, blocked means the running thread temporarily gives up the use of the processor and waits for execution again, and death means the thread is terminated. In some embodiments, the way to terminate a thread can include exiting the thread and ending the thread, wherein exiting the thread is a normal way to terminate the thread, and ending the thread is a forced way to terminate the thread.

[0055] In some embodiments, a process can be converted from a running state to a frozen state by freezing the process. The frozen state is a special form of the blocked state, which means that the operating system puts the process into a "controllable" suspended state, so that the process suspends execution and no longer responds to user input. When the process is in the frozen state, the execution process of the process is suspended, at least part of the system resources occupied by the process is released, and when the process is reactivated, the terminal can quickly restore it to the running state before freezing. In some embodiments, the terminal can freeze at least part of the processes when the system resources are insufficient, or when the operating system is in a hibernation state, or when the operating system is in a suspended state. In some embodiments, the terminal can freeze a process by sending a signal to the process to suspend the process, or send a signal to the process to resume the process. In some embodiments, the operating system of the terminal includes a freezing subsystem through which the process is frozen. Of course, in actual applications, the terminal can freeze the process in other ways.

[0056] The kernel mode includes a binder driver. The binder driver is a virtual device driver for connecting a client process and a server process, including transferring data between processes, implementing management and control of an IPC thread pool, and mainly performing functions such as abstraction of a binder file node to a user mode, maintenance of information such as an IPC communication process, a thread, and a node, and IPC data operation. The client process and the server process in the user mode can communicate with the binder driver in the kernel mode, and thus the communication between the client process and the server process is implemented through the binder driver. In some embodiments, a process can communicate with the binder driver through an input / output control (ioclt). For example, the ioclt includes a BINDER_WRITE_READ command and a BINDER_THREAD_EXIT command; the BINDER_WRITE_READ command can indicate data for storing a read-write operation, and is used for the client process or the server process to transfer data to the binder driver; and the BINDER_THREAD_EXIT command can be used to notify the binder driver to exit an IPC thread, so as to release system resources occupied by the IPC process. In some embodiments, a process can control the binder driver through a corresponding driver protocol of the binder driver, and / or the binder driver can control the process through the driver protocol. For example, the driver protocol can include BR_SPAWN_LOOPER, which is used for the binder driver to inform the server process to create a new IPC thread.

[0057] In some embodiments, the binder driver belongs to a basic system architecture of the terminal 100, i.e., is implemented by a developer of an operating system of the terminal 100; and the client process and the server process belong to an application layer, and are implemented by developers of the client process and the server process respectively.

[0058] Referring to FIG. 3, a structural block diagram of a binder driver is provided according to an embodiment of the present application.

[0059] The binder driver includes one or more binder_procs. Each binder_proc belongs to a process. The binder_proc is a submodule of the binder driver, and is a data object of the process in the binder driver, and mainly maintains relevant information of the process. For example, the relevant information can include a maximum number of threads MAX_THREADS that can be included in an IPC thread pool of the process.

[0060] In some embodiments, the binder driver includes binder threads. A binder thread is a sub-module of a binder proc, and there are multiple binder thread data objects under one binder proc, which are abstractions of IPC threads in the IPC thread pool in the binder driver. For example, FIG. 3 shows that binder proc 1 includes binder thread 1 and binder thread 2, indicating that the IPC thread pool corresponding to the binder proc 1 includes two IPC threads: binder thread 1 and binder thread 2.

[0061] In some embodiments, the binder driver includes a waiting thread queue waiting_threads (not shown in FIG. 3), which includes one or more idle binder threads in the IPC thread pool. In some embodiments, a binder thread can enter the end of the waiting_threads queue when it is just created or when it just completes a previous task, until there is a new task, the binder driver removes the binder thread at the head of the waiting_threads queue from the waiting_threads, and the binder thread processes the new task.

[0062] It should be understood that the binder driver can include more or less data structures related to cross-process communication. The specific structure of the binder driver is not limited in the embodiments of the present application.

[0063] Please refer to FIG. 4, which is a flowchart of a method of cross-process communication provided by the embodiments of the present application. The method can be implemented by the terminal shown in FIG. 1, the software structure described in FIG. 2, or the binder driver shown in FIG. 3.

[0064] S401, the server process initializes to create an IPC thread pool and actively creates an IPC thread, the server process registers a service handle in a service manager through the binder driver, and the IPC thread of the server process is blocked in the binder driver to wait for a response to an external request.

[0065] The service management process is a manager of the binder driver, and includes a service registration function and a service query function. The service registration function is a service that accepts registration of a service end process. The service query function is a service that provides a service handle of a service queried by a client process to the client process. The service handle is a reference for identifying and managing a service. The client process can interact with a service end process that provides the service by obtaining the service handle of the service, and use the service.

[0066] In some embodiments, the service management process runs in a user mode.

[0067] In some embodiments, the service management process can initialize a registration of a manager handle to the binder driver before S401.

[0068] In some embodiments, the service end process can actively create an IPC thread when initializing the creation of an IPC thread pool, and the IPC thread can be a master thread in the IPC thread pool. In some embodiments, the service end process can actively create more IPC threads after S401. In some embodiments, the IPC thread pool includes one master thread and at least one non-master thread.

[0069] S402, the client process obtains a service handle of a service published by the service end process in the service management process through the binder driver.

[0070] Through the above S401-S402, the client process has obtained the service handle of the service end process, i.e., has established a connection with the service end process, and thus in subsequent steps, the client process and the service end process can implement cross-process communication based on the service handle.

[0071] S403, the client process sends data to the binder driver through the service handle, and the binder driver finds the service end process through the service handle and obtains an idle IPC thread from the waiting thread queue. If the number of IPC threads in the waiting thread queue is sufficient, S404 is executed. If an idle IPC thread is not obtained from the waiting thread queue, and the number of IPC threads belonging to the service end process does not exceed the maximum IPC thread number limit, S405 is executed.

[0072] In some embodiments, the client process can send the data to the binder driver through the service handle, and the data can be sent to a shared memory corresponding to the service end process. In some embodiments, the shared memory is allocated by the binder driver to the service end process.

[0073] S404, the binder driver wakes up an IPC thread from the waiting thread queue, and the IPC thread receives the data sent by the client process and processes it.

[0074] In some embodiments, the IPC thread of the server process receives the data sent by the client process, which can be obtained from the shared memory of the server process.

[0075] S405, the binder driver requests the server process to create a new IPC thread.

[0076] S406, the server process creates a new IPC thread in response to the request of the binder driver and receives the data sent by the client process.

[0077] As described above, the server process can create an IPC thread pool belonging to the server process, which includes one or more IPC threads, and each IPC thread is used to implement the cross-process communication between the server process and the client process. Before the server process ends, in order to meet the cross-process communication with multiple client processes, the server process can actively create more IPC threads, or can create more IPC threads in response to the request of the binder driver, which will cause the number of IPC threads in the IPC thread pool to increase, thereby seriously occupying the system resources of the terminal.

[0078] In order to solve at least part of the above technical problems, the present application provides a method for managing IPC threads, which can identify the state of each IPC thread belonging to the server process during the cross-process communication of the server process, and terminate at least part of the IPC threads created by the server process in response to the request of the binder driver, thereby reducing the occupation of system resources by the IPC threads and saving system resources.

[0079] The technical solutions of the present application will be described in detail below with specific examples. The following specific examples can be combined with each other, and the same or similar concepts or processes can not be described in some examples.

[0080] Please refer to FIG. 5, which is a flowchart of a method for managing IPC threads provided by an embodiment of the present application. The method can be implemented by the terminal shown in FIG. 1, the software structure shown in FIG. 2, or the binder driver shown in FIG. 3. It should be noted that the method is not limited to the specific order described in FIG. 5 and the following description. It should be understood that in some embodiments, the order of some steps in the method can be exchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0081] S501, the terminal obtains a waiting thread queue corresponding to a process, the waiting thread queue including one or more IPC threads, and each IPC thread in the waiting thread queue being used for the process to communicate with other processes.

[0082] In some embodiments, one or more trigger conditions can be set in advance, and when the terminal detects that the trigger conditions are met, the terminal acquires the waiting thread queue corresponding to the process, and then starts to perform S501-S503 to manage the IPC threads in the terminal.

[0083] For example, the terminal can perform S501-S503 every few minutes, every few hours, or every few days; or the terminal can perform S501-S503 at a specific time every day, or the terminal can perform S501-S503 when the terminal is in a specific state such as insufficient memory or insufficient power.

[0084] In some embodiments, the trigger conditions can be set by a relevant technician, and the terminal includes the trigger conditions before being shipped, or the terminal can acquire the trigger conditions from a provider of an operating system by updating the operating system; or the trigger conditions can be set by a user of the terminal during use of the terminal.

[0085] In some embodiments, the process can be any process in the terminal.

[0086] In some embodiments, the process can be a process in a non-frozen state. Since at least part of the system resources occupied by a process in a frozen state have been released, in a case where the terminal includes processes in a frozen state and processes in a non-frozen state, only the IPC threads of the processes in the non-frozen state can be managed, and the IPC threads of the processes in the frozen state are not additionally managed.

[0087] In some embodiments, the process can be a process not in a white list. The white list is used to indicate at least one process that does not terminate the IPC threads before the cross-process communication ends, and the white list can include a process identifier of the at least one process. In some embodiments, the terminal can set the white list in advance. In some embodiments, the terminal can detect a total number of IPC threads included by a process, and if the total number is less than a sixth threshold value, the process relies on a small number of IPC threads and occupies a small amount of system resources, and thus the process identifier of the process is added to the white list, so that the IPC threads of the process are not managed according to the method provided in the present application. The sixth threshold value is a positive integer, and the sixth threshold value can be the maximum number of IPC threads corresponding to the processes in the white list. In some embodiments, the sixth threshold value can be set in advance according to the number of IPC threads relied on by a plurality of processes for cross-process communication. In some embodiments, the terminal can add a white list submitted by a user, or add a process identifier submitted by a user to the white list.

[0088] It can be understood that the above multiple conditions for the process can be combined. For example, the process can be a process in a non-frozen state and not in a whitelist.

[0089] In some embodiments, the waiting thread queue can be acquired from an IPC thread pool belonging to the process, and for the waiting thread queue, the IPC thread pool and the IPC thread in the IPC thread pool, the process can be the aforementioned server process.

[0090] S502, the terminal acquires a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, the IPC threads in the first state being actively created by the process, and the IPC threads in the second state being created by the process in response to a request of the binder driver.

[0091] The waiting thread queue of the process includes the IPC threads in the first state and the IPC threads in the second state.

[0092] The IPC threads in the first state are actively created by the process, and the importance of the IPC threads in the first state is relatively high. For example, the IPC threads in the first state can include the first IPC thread created in the process startup process, i.e., the main thread in the IPC thread pool.

[0093] The IPC threads in the second state are created by the process in response to a request of the binder driver. In some embodiments, the importance of the IPC threads in the second state is relatively lower than that of the IPC threads in the first state.

[0094] In some embodiments, the IPC threads in the second state are non-main threads created by the process in response to a request of the binder driver, idle (or without tasks), and entering the waiting thread queue for a first duration greater than or equal to a second threshold. The second threshold can be a maximum duration for the IPC thread to exist in the waiting thread queue. That is, the IPC threads in the second state are idle threads created by the process in response to a request of the binder driver and not woken up for a long time.

[0095] In some embodiments, the terminal can start recording a first time when any IPC thread of the process enters the waiting thread queue when the IPC thread enters the waiting thread queue, and determine a second time at the time of performing S502, and determine a difference between the second time and the first time as the first duration. In some embodiments, the second threshold can be any duration set in advance, for example, 2 minutes.

[0096] The terminal can determine the first number of IPC threads in the first state and the second number of IPC threads in the second state by traversing the waiting thread queue of the process.

[0097] In S503, if the sum of the first number and the second number is greater than or equal to the first threshold, the terminal terminates the IPC threads in the second state.

[0098] The first threshold represents the maximum number of IPC threads that can be simultaneously run by the terminal. When the sum of the first number and the second number is greater than or equal to the first threshold, it means that the total number of IPC threads in the first state and the second state has exceeded the maximum number of IPC threads that can be simultaneously run by the terminal, and since the IPC threads in the second state are less important, the terminal can terminate at least part of the IPC threads in the second state, thereby significantly reducing the number of IPC threads run by the terminal during the cross-process communication of the process, thereby saving the system resources occupied by the at least part of the IPC threads in the second state.

[0099] In some embodiments, the first threshold can be a preset value. The smaller the first threshold, the smaller the total number of IPC threads in the first state and the second state that the terminal can maintain, the more the terminal terminates the IPC threads in the second state, and the more system resources that can be saved.

[0100] In some embodiments, the first threshold can be dynamically adjusted by the terminal according to the state of the terminal, so as to dynamically increase or decrease the total number of IPC threads in the first state and the second state in the waiting thread pool according to the state of the terminal. The terminal can ensure good performance of the terminal on the basis of saving system resources. In some embodiments, the first threshold is inversely related to at least one of the system resources used by the terminal, the total number of IPC threads created in the terminal, and the power consumption of the terminal. For example, the more system resources used by the terminal, the smaller the first threshold, so that the terminal terminates more IPC threads in the second state, thereby saving more system resources. The more the total number of IPC threads created in the terminal, the smaller the first threshold, so that the terminal terminates more IPC threads in the second state, thereby reducing the total number of IPC threads created in the terminal and saving more system resources. The greater the power consumption of the terminal, the smaller the first threshold, so that the terminal terminates more IPC threads in the second state, thereby reducing power consumption.

[0101] In some embodiments, the terminal can terminate the IPC threads in the second state at least partially at the head of the waiting thread queue. In which, the closer the IPC threads in the waiting thread queue are to the head of the waiting thread queue, the longer the IPC threads have been in the waiting thread queue, i.e. the longer the IPC threads have been idle.

[0102] In some embodiments, the terminal can terminate the third number of IPC threads in the second state from the waiting thread queue, the third number being greater than 1 and less than or equal to the second number. In some embodiments, the third number is greater than or equal to the first number + the second number - the first threshold, and the third number is less than or equal to the second number. For example, the first number = 50, the second number = 210, the first threshold = 200, and the third number = the first number + the second number - the third number = 60, so the terminal terminates 60 IPC threads in the second state, so that the number of IPC threads actually running on the terminal is the same as the maximum number of IPC threads that can be simultaneously run on the terminal, i.e. both are 200. It can be understood that during the execution of S503, the terminal can also create new IPC threads or reduce the number of currently running IPC threads through other means, so even if the third number = the first number + the second number - the third number, after the execution of S503, the number of IPC threads actually running on the terminal and the maximum number of IPC threads that can be simultaneously run on the terminal can differ, rather than being exactly the same.

[0103] In some embodiments, the terminal can terminate the third number of IPC threads in the second state at the head of the waiting thread queue.

[0104] In some embodiments, the terminal can delete the at least partially second-state IPC threads from the waiting thread queue, wake up the at least partially second-state IPC threads, and instruct the process to which the waiting thread queue belongs to exit the at least partially second-state IPC threads. As described above, the IPC threads are all created by the process to which the IPC thread belongs, so when it is necessary to exit the IPC thread, instructing the process to exit the IPC thread can improve the stability of the process and improve the abnormality caused by terminating the IPC thread, such as being unable to recycle the system resources occupied by the IPC thread, and some tasks of the process that depend on the IPC thread being unable to continue to execute.

[0105] In some embodiments, the terminal can end the at least partially second-state IPC threads, or in other words, forcibly exit the at least partially second-state IPC threads. Alternatively, in other embodiments, the terminal can also terminate the at least partially second-state IPC threads through other means.

[0106] In some embodiments, before the terminal terminates the IPC thread in the second state, the terminal can add marking information to the IPC thread in the second state, the marking information indicating that the IPC thread is a timeout-waking-up failure IPC thread, or in other words, an aged IPC thread.

[0107] In some embodiments, after performing S503, the terminal can update the total number of the IPC thread pool corresponding threads of the process, i.e., subtract the number of terminated threads in S503 from the total number of the IPC thread pool corresponding threads of the process before performing S503.

[0108] In the embodiments of the present application, the terminal can obtain the waiting thread queue corresponding to the process, obtain a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, wherein the IPC threads in the first state are actively created by the process, and the IPC threads in the second state are created by the process in response to the request of the binder driver. In the case where the sum of the first number and the second number is greater than or equal to the first threshold value, the terminal can terminate at least part of the IPC threads in the second state, so as to terminate the IPC threads of the process during the cross-process communication of the process, thereby reducing the number of IPC threads running on the terminal and saving the system resources of the terminal.

[0109] Please refer to FIG. 6, which is a flow chart of another method for managing IPC threads provided by the embodiments of the present application. The method can be an embodiment of the method shown in FIG. 5, and the management of IPC threads is triggered by a set timer. In some embodiments, the management of IPC threads can be triggered multiple times or infinitely times by the timer. It should be noted that the method is not limited to the specific order described in FIG. 6 and the following description, and it should be understood that in some embodiments, the order of some steps in the method can be exchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0110] S601, the terminal obtains a waiting thread queue corresponding to a process in response to the timer being woken up, the waiting thread queue including one or more IPC threads, each IPC thread in the waiting thread queue being used for communication between the process and other processes.

[0111] The timer is a program component, which can be used to execute a specific task at a specified time point. In the embodiments of the present application, the method for managing IPC threads can be triggered by the timer at a specified time point. In some embodiments, the timer can be implemented in user mode or kernel mode as shown in FIG. 2 or FIG. 3.

[0112] In some embodiments, the timer is configured to be woken up every second time length since the binder driver initialization is completed. In some embodiments, the binder driver initialization can include setting a device name corresponding to the binder driver and an operation method of the binder driver, so that the process in the user mode can use the binder driver according to the operation method and the device name. For example, the device name corresponding to the binder driver can be binder. For example, the operation method of the binder driver can include binder open and binder ioctl, wherein binder open is used to open the binder driver, and binder ioctl is used to control the binder driver or communicate with the binder driver. Through the timer, the method for managing the IPC thread provided in the present application can be performed every second time length since the binder driver initialization, and the IPC thread of the terminal can be managed.

[0113] In some embodiments, the second time length can be any fixed time length set in advance, such as 2 minutes. When the second time length is shorter, the frequency of performing the management of the IPC thread is higher, and more system resources can be saved, such as more memory and power. Alternatively, in some other embodiments, the second time length can be set according to the total amount of system resources of the terminal, so that the second time length is more suitable for the terminal. When the terminal has a smaller total amount of system resources, the value of the second time length is smaller, and the method for managing the IPC thread provided in the present application is performed more frequently, so as to save more system resources. For example, when the memory of the terminal is smaller or the battery capacity is smaller, the value of the second time length is smaller, so as to save memory, reduce power consumption, and improve the endurance of the terminal.

[0114] In some embodiments, the timer can also be configured to be woken up in other ways. For example, the terminal can receive a second time length submitted by a user. For example, the timer can be configured to be woken up only a limited number of times, such as 1 time.

[0115] S602, the terminal obtains a first number of IPC threads in a first state and a second number of IPC threads in a second state in a waiting thread queue, the IPC threads in the first state are actively created by the process, and the IPC threads in the second state are created by the process in response to a request of the binder driver.

[0116] In some embodiments, the IPC thread in the second state is a non-main thread created by the process in response to a request of the binder driver, idle, and entering the thread queue for a first duration greater than or equal to a second threshold. The second threshold is less than or equal to the second duration. For example, the second threshold and the second duration are both 2 minutes.

[0117] In some embodiments, the terminal can perform S602 in the same or similar manner as that for performing S502 to obtain the first number of the IPC threads in the first state and the second number of the IPC threads in the second state in the thread queue.

[0118] S603, if the sum of the first number and the second number is greater than or equal to a first threshold, the terminal terminates the IPC threads in the second state.

[0119] In some embodiments, the terminal can perform S603 in the same or similar manner as that for performing S503 to terminate the IPC threads in the second state.

[0120] In the embodiments of the present application, the terminal can be woken up in response to the timer, obtain a thread queue corresponding to a process, and obtain a first number of IPC threads in a first state and a second number of IPC threads in a second state in the thread queue. The IPC threads in the first state are created by the process, and the IPC threads in the second state are created by the process in response to a request of the binder driver. If the sum of the first number and the second number is greater than or equal to a first threshold, the terminal can terminate the IPC threads in the second state, thereby achieving the reduction of the number of the IPC threads included in the terminal through the timer triggered multiple times or periodically, and further saving the system resources of the terminal for a long time or continuously.

[0121] Please refer to FIG. 7, which is a flowchart of another method for managing IPC threads provided by the embodiments of the present application, which can be an example of the method shown in FIG. 6.

[0122] S701, the binder driver creates a timer, and configures the timer to be woken up every second duration after the binder driver is initialized.

[0123] In some embodiments, the timer can be implemented through a specific function interface.

[0124] In some embodiments, the binder driver can perform S701 before S601.

[0125] S702, the binder driver records a timestamp of the IPC thread joining the wait thread queue.

[0126] In some embodiments, the timestamp of the IPC thread can be the system clock when the IPC thread joins the wait thread queue. The system clock is a unit used to measure the time of the operating system. In some embodiments, the system clock when the IPC thread joins the wait thread queue is the first time point in the foregoing. In some embodiments, the binder driver can record the above-mentioned timestamp through the binder_wait_for_work function.

[0127] In some embodiments, the binder driver can perform S702 before S601.

[0128] S703, when the timer is woken up, the binder driver marks the part of the IPC processes in the wait thread queue as aged and wakes up.

[0129] In some embodiments, when the timer is woken up, the binder driver determines the first number of binder_threads in the wait thread queue in the BINDER_LOOPER_STATE_ENTERED (i.e. the first state of the IPC thread) and the second number of binder_threads in the wait thread queue in the BINDER_LOOPER_STATE_REGISTERED, idle, and the first time length of entering the wait thread queue being greater than or equal to the second threshold value (such as 2 minutes) (i.e. the second state of the IPC thread). If the sum of the first number and the second number is greater than or equal to the first threshold value, the binder driver adds the BINDER_LOOPER_STATE_AGED flag to the at least part of the binder_threads in the wait thread queue in the BINDER_LOOPER_STATE_REGISTERED, idle, and the first time length of entering the wait thread queue being greater than or equal to the second threshold value, removes the binder_threads carrying the BINDER_LOOPER_STATE_AGED flag from the wait thread queue and wakes up.

[0130] The binder_thread in the BINDER_LOOPER_STATE_ENTERED is created by a process to which the binder_thread belongs, the binder_thread in the BINDER_LOOPER_STATE_REGISTERED is created by the process in response to a request of the binder driver, and the BINDER_LOOPER_STATE_AGED is used to indicate that the corresponding binder_thread is an aged binder_thread.

[0131] In some embodiments, the waiting thread queue in S703 can be a waiting thread queue of a process belonging to a non-frozen state and / or not in a whitelist.

[0132] In some embodiments, when the timer is woken up, the binder driver refreshes the time stamp of the IPC thread in the waiting thread queue, and the time indicated by the refreshed time stamp is the second time in the foregoing. The difference between the second time and the first time is the first time length.

[0133] In some embodiments, S703 can correspond to part of S601, S602 and S603 in the foregoing, that is, the terminal, in response to the timer being woken up, acquires the waiting thread queue corresponding to the process, acquires the first number of IPC threads in the first state and the second number of IPC threads in the second state in the waiting thread queue, and if the sum of the first number and the second number is greater than or equal to the first threshold, the terminal adds the BINDER_LOOPER_STATE_AGED label to at least part of the IPC threads in the second state in the waiting thread queue, deletes and wakes up the IPC thread carrying the BINDER_LOOPER_STATE_AGED label.

[0134] S704, the binder driver sends a BR_FINISHED command to the process in the user space based on the binder_thread (for example, binder_thread_1 shown in FIG. 7) carrying the BINDER_LOOPER_STATE_AGED label.

[0135] The BR_FINISHED command is used to indicate that the interaction between the binder driver and the user space ends. The binder driver sends the BR_FINISHED command to the process in the user space based on the binder_thread carrying the BINDER_LOOPER_STATE_AGED label, that is, instructs the process to end the binder_thread.

[0136] S705, after the user-mode process receives BR_FINISHED based on the binder_thread, the user-mode process sets the return value of the binder_thread as TIMED_OUT (i.e., timeout), thereby normally exiting the binder_thread.

[0137] In some embodiments, after the user-mode process receives BR_FINISHED based on the binder_thread, the user-mode process can determine that the binder_thread has timed out, and thus terminate the loop of reading data through the IPC thread, or can be understood as stopping using the binder_thread.

[0138] In some embodiments, S704-S705 can correspond to at least part of S603 in the foregoing, i.e., the binder instructs the user-mode process to exit at least part of the binder_thread of the non-main thread in the BINDER_LOOPER_STATE_REGISTERED, idle, entering the first duration of the waiting thread queue greater than or equal to the second threshold.

[0139] In some embodiments, after the binder driver terminates at least part of the binder_thread corresponding to the process in S705, the binder driver can update the value of requested_threads_started corresponding to the IPC thread pool, so that the updated value of requested_threads_started corresponds to the number of binder_threads included in the IPC thread pool after S705 is executed.

[0140] In some embodiments, S703-S705 can be encapsulated into a functional module, the entry of the functional module is the timer in the foregoing, the name of the functional module is binder_thread_gc, and the callback function is binder_gc_proc. When the timer is awakened, binder_thread_gc is called through the callback function binder_gc_proc, thereby executing the steps of S703-S705, identifying and exiting at least part of the IPC thread in the BINDER_LOOPER_STATE_REGISTERED, idle, entering the waiting thread queue for the first duration greater than or equal to 2 minutes, thereby releasing the system resources occupied by the IPC thread.

[0141] In the embodiment of the present application, in addition to that the binder_thread in the BINDER_LOOPER_STATE_REGISTERED state can be exited by the user-mode process through the BINDER_THREAD_EXIT, the binder_thread in the BINDER_LOOPER_STATE_REGISTERED state can also be exited by the binder driver when the binder_thread is timed out and not woken up, that is, the number of threads in the IPC thread is dynamically reduced, and the system resource of the terminal is saved.

[0142] For example, when the terminal is powered on, S701-S702 are executed to set the timer to 2 minutes and set the timestamp corresponding to the binder_thread, and then S703-S705 are executed every 2 minutes to exit the aged and idle binder_thread. After the terminal is powered on for 5 minutes, the number of IPC threads included in the terminal is acquired every 2 minutes, and the number of IPC threads is acquired for 8 times in succession, and the acquired number of IPC threads is 578, 574, 564, 564, 474, 200, 191 and 199. It can be seen that the number of IPC threads included in the terminal is reduced by about 65%.

[0143] For another example, the power consumption of the same terminal in the same time length is tested. In the case that the terminal does not use the method for managing the IPC thread provided in the present application (that is, the number of IPC threads is only increased and decreased through the BR_SPAWN_LOOPER and the BINDER_THREAD_EXIT), the power consumption of the terminal is 1307 mA. In the case that the terminal uses the method for managing the IPC thread provided in the present application (that is, the number of IPC threads is increased and decreased through the BR_SPAWN_LOOPER and the BINDER_THREAD_EXIT, and the number of IPC threads is dynamically reduced by the way of exiting the IPC thread which is timed out and not woken up), the power consumption of the terminal is 1276 mA. It can be seen that the method for managing the IPC thread provided in the present application saves the power of 31 mA for the terminal.

[0144] Please refer to FIG. 8, which is a flow chart of a method for managing the IPC thread provided in the embodiment of the present application. The method can be an implementation of the method shown in FIG. 5, and is used for triggering the management of the IPC thread when the use state of the system resource of the terminal reaches the preset state, wherein the frequency of the management of the IPC thread by the terminal is determined by the frequency of the use state of the system resource of the terminal reaching the preset state. It should be noted that the method is not limited to the specific order described in FIG. 8 and the following description, and it should be understood that in some embodiments, the order of some steps in the method can be exchanged according to actual needs, or some steps in the method can be omitted or deleted. The method includes the following steps:

[0145] S801, when the usage state of the system resource of the terminal reaches a preset state, acquiring a waiting thread queue corresponding to a process, the waiting thread queue including one or more IPC threads, each IPC thread in the waiting thread queue being used for the process to communicate with other processes.

[0146] In some embodiments, the usage state of the system resource of the terminal reaching the preset state can include at least one of the following: the system resource used by the terminal is greater than or equal to a third threshold value, the total number of the IPC threads created in the terminal is greater than or equal to a fourth threshold value, and the power consumption of the terminal is greater than or equal to a fifth threshold value.

[0147] The third threshold value represents the maximum value of the system resource that can be used by the terminal before triggering the method for managing the IPC thread provided in the present application. When the system resource used by the terminal is greater than or equal to the third threshold value, it indicates that the terminal has used a large amount of system resource, and therefore, in order to save the system resource, the IPC thread can be managed. The third threshold value can be a fixed value set according to the total amount of system resource included in the terminal, and the third threshold value is less than the total amount of system resource. For example, the third threshold value can be 80%, 70%, 60%, 50%, 40%, 30% or 20% of the total amount of system resource. Alternatively, in other embodiments, the third threshold value can also be other values.

[0148] The fourth threshold value represents the maximum number of IPC threads that can be created by the terminal before triggering the method for managing the IPC thread provided in the present application. When the total number of the IPC threads created in the terminal is greater than or equal to the fourth threshold value, it indicates that the IPC threads in the terminal have occupied a large amount of system resource, and therefore, in order to save the system resource, the IPC thread can be managed. The fourth threshold value can be a fixed value set according to the maximum number of IPC threads that can be created by the terminal, and the fourth threshold value is less than the maximum number. Since the system resource of the terminal is limited, the maximum number of IPC threads that can be created by the terminal based on the limited system resource is also limited. For example, the maximum number of IPC threads that can be created by the terminal is 1000, and the fourth threshold value can be 900, 800 or 700.

[0149] The fifth threshold value represents the maximum power consumption allowed by the terminal before triggering the method for managing the IPC thread provided in the present application. When the power consumption of the terminal is greater than or equal to the fifth threshold value, it indicates that the current power consumption of the terminal is large, and therefore, in order to reduce the power consumption and improve the endurance of the terminal, the IPC thread can be managed. The fifth threshold value can be a fixed value set according to the power consumption of the terminal, and the fifth threshold value is less than the maximum power consumption of the terminal. For example, the maximum power consumption of the terminal is 6W, and the fifth threshold value can be 4W or 3W.

[0150] In some embodiments, the third threshold value, the fourth threshold value and the fifth threshold value can be set by a related technician or a user. Alternatively, in some other embodiments, the terminal can also determine the third threshold value, the fourth threshold value and the fifth threshold value in other manners.

[0151] S802, the terminal acquires a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, the IPC threads in the first state being created by the process actively, and the IPC threads in the second state being created by the process in response to a request of the binder driver.

[0152] In some embodiments, the terminal can acquire the first number of the IPC threads in the first state and the second number of the IPC threads in the second state in the waiting thread queue in the same or similar manner as that of acquiring the first number of the IPC threads in the first state and the second number of the IPC threads in the second state in the waiting thread queue.

[0153] S803, if the sum of the first number and the second number is greater than or equal to the first threshold value, the terminal terminates at least part of the IPC threads in the second state.

[0154] In some embodiments, the terminal can terminate at least part of the IPC threads in the second state in the same or similar manner as that of terminating at least part of the IPC threads in the second state.

[0155] In the embodiments of the present application, when the usage state of the system resources of the terminal reaches a preset state, the terminal can acquire the waiting thread queue corresponding to the process, acquire a first number of IPC threads in a first state and a second number of IPC threads in a second state in the waiting thread queue, the IPC threads in the first state being created by the process actively, and the IPC threads in the second state being created by the process in response to a request of the binder driver. In the case that the sum of the first number and the second number is greater than or equal to the first threshold value, the terminal can terminate at least part of the IPC threads in the second state, thereby dynamically reducing the number of the IPC threads included in the terminal according to the usage state of the system resources of the terminal, and further saving the system resources of the terminal.

[0156] Based on the same inventive concept, as an implementation of the above method, the embodiments of the present application provide a method and device for managing IPC threads, the device embodiments correspond to the above method embodiments, for the convenience of reading, the details of the above method embodiments will not be described one by one, but it should be clear that the device in the embodiments can correspondingly implement all the contents in the above method embodiments.

[0157] In a possible implementation, the apparatus can correspond to the terminal in the method embodiments above, for example, can be a terminal, or a chip configured in the terminal. The apparatus is configured to perform each step or procedure corresponding to the terminal in the above method.

[0158] Based on the same inventive concept, the embodiments of the present application further provide a terminal. The terminal comprises a memory and a processor, the memory is configured to store a computer program, and the processor is configured to execute the method described in the above method embodiments when the computer program is invoked.

[0159] The terminal provided by the embodiments can execute the above method embodiments, and the implementation principle and technical effects are similar, which will not be described here.

[0160] Based on the same inventive concept, the embodiments of the present application further provide a chip system. The chip system comprises a processor, the processor is coupled with a memory, and the processor executes a computer program stored in the memory to implement the method described in the above method embodiments.

[0161] The chip system can be a single chip or a chip module composed of multiple chips.

[0162] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method described in the above method embodiments.

[0163] The embodiments of the present application further provide a computer program product, when the computer program product is run on a terminal, the terminal executes the method described in the above method embodiments.

[0164] The integrated units described above, if realized in the form of software function units and sold or used as independent products, can be stored in a computer readable storage medium. Based on this understanding, the embodiments of the present application can implement all or part of the procedures in the above method embodiments by a computer program to instruct related hardware, and the computer program can be stored in a computer readable storage medium. The computer program is executed by a processor to implement the steps of each method embodiment described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms, etc. The computer readable storage medium at least includes any entity or device capable of carrying the computer program code to the terminal, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium. For example, U disk, mobile hard disk, magnetic disk or optical disk, etc.

[0165] In the above embodiments, the description of each embodiment is focused on, and the parts not described or recorded in a certain embodiment can be referred to the related description of some embodiments.

[0166] Those skilled in the art can appreciate that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0167] In the embodiments provided in the present application, it should be understood that the disclosed apparatuses / devices and methods can be implemented by other ways. For example, the above-described apparatus / device embodiments are only schematic, and the division of the modules or units is only a logical function division, and there can be another division in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed units can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0168] It should be understood that when used in the specification and the appended claims of the present application, the term "comprising" indicates the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0169] It should also be understood that the term "and / or" used in the specification and the appended claims of the present application means any combination of one or more of the associated listed items and all possible combinations thereof, and includes these combinations.

[0170] As used in the specification and the appended claims of the present application, the term "if" can be interpreted as "when" or "upon" or "in response to a determination" or "in response to detecting" depending on the context. Similarly, the phrase "if it is determined" or "if [a described condition or event] is detected" can be interpreted as meaning "upon determining" or "in response to determining" or "upon detecting [a described condition or event]" or "in response to detecting [a described condition or event]" depending on the context.

[0171] In addition, in the description of the present application and the appended claims, the terms "first", "second", "third", etc. are used only to distinguish descriptions, and cannot be understood as indicating or implying relative importance.

[0172] The description of "one embodiment", "some embodiments", and the like in the present application description means that the specific features, structures, or characteristics described in connection with the embodiment are included in one or more embodiments of the present application. Therefore, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in further some embodiments", and the like appearing in different places in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "include", "contain", "have" and their variants mean "include but not limited to", unless otherwise specifically emphasized.

[0173] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for managing inter-process communication (IPC) threads, characterized in that, The method comprises: obtaining a waiting thread queue corresponding to a process, the waiting thread queue comprising one or more IPC threads, each of the IPC threads in the waiting thread queue being used for the process to communicate with other processes; obtaining a first number of IPC threads in the waiting thread queue in a first state and a second number of IPC threads in a second state, the IPC threads in the first state being actively created by the process, the IPC threads in the second state being created by the process in response to a request of a binder driver; terminating the IPC threads in the second state if a sum of the first number and the second number is greater than or equal to a first threshold.

2. The method of claim 1, wherein, The IPC threads in the second state are non-main threads with a first time length of entering the waiting thread queue being greater than or equal to a second threshold.

3. The method of claim 2, wherein, The terminating the IPC threads in the second state if the sum of the first number and the second number is greater than or equal to the first threshold comprises: terminating a third number of the IPC threads in the second state in the waiting thread queue if the sum of the first number and the second number is greater than or equal to the first threshold, the third number being a difference between the sum of the first number and the second number and the first threshold.

4. The method according to any of claims 1 to 3, characterized in that, The IPC threads in the second state are at a head of the waiting thread queue.

5. The method according to any of claims 1 to 4, characterized in that, The terminating the IPC threads in the second state if the sum of the first number and the second number is greater than or equal to the first threshold comprises: deleting the IPC threads in the second state from the waiting thread queue if the sum of the first number and the second number is greater than or equal to the first threshold; waking up the IPC threads in the second state; indicating the process to exit the IPC threads in the second state.

6. The method of claim 5, wherein, Before the deleting the IPC threads in the second state from the waiting thread queue, the method further comprises: adding mark information to the IPC threads in the second state, the mark information being used to indicate that the IPC threads in the second state are threads that are not woken up due to timeout.

7. The method according to any of claims 1 to 6, characterized in that The method is applied to a terminal, and the obtaining a waiting thread queue corresponding to a process comprises: obtaining the waiting thread queue corresponding to the process when a trigger condition is met; wherein the trigger condition comprises at least one of the following: a timer is woken up; a system resource used by the terminal is greater than or equal to a third threshold; a total number of IPC threads created in the terminal is greater than or equal to a fourth threshold; power consumption of the terminal is greater than or equal to a fifth threshold.

8. The method of claim 7, wherein, The first threshold is a preset fixed value, or the first threshold is inversely related to at least one of the system resource used by the terminal, the total number of the IPC threads created in the terminal, and the power consumption of the terminal.

9. The method according to claim 7 or 8, characterized in that, The timer is configured to be woken up every second time length since the binder driver is initialized.

10. The method according to any one of claims 1 to 9, characterized in that, The process is a process in a non-frozen state, and / or the process is a process not in a white list.

11. A terminal, characterized by comprising: Comprising: a memory for storing a computer program; and a processor for executing the computer program to perform the method of any one of claims 1-10 when the computer program is invoked.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, which when executed by a processor, implements the method of any one of claims 1-10.

13. A computer program product, characterised in that, The computer program product, when running on a terminal, causes the terminal to perform the method of any one of claims 1-10.

Images