CN108984321B - Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium - Google Patents
Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium Download PDFInfo
- Publication number
- CN108984321B CN108984321B CN201810701460.5A CN201810701460A CN108984321B CN 108984321 B CN108984321 B CN 108984321B CN 201810701460 A CN201810701460 A CN 201810701460A CN 108984321 B CN108984321 B CN 108984321B
- Authority
- CN
- China
- Prior art keywords
- binder
- server
- communication
- client
- set threshold
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The application discloses a mobile terminal, a method for limiting interprocess communication of the mobile terminal and a storage medium, wherein the method for limiting interprocess communication comprises the following steps: acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; judging whether the first quantity is smaller than a first set threshold value; and if so, limiting binder communication between the background client and the server. By the method, the busy degree of the server can be reduced, and the fluency of the system is ensured.
Description
Technical Field
The present application relates to the field of mobile terminal technologies, and in particular, to a mobile terminal, a method for limiting inter-process communication of the mobile terminal, and a storage medium.
Background
In the Android operating system, data transmission is often required between an application and a service, and a mode of inter-process communication can be generally adopted, for example, transmission can be performed through a Binder mechanism, so that data of an opposite side is acquired.
In the process of communicating by using the Binder mechanism, usually one server communicates with a plurality of clients, which burdens the server, and affects the fluency of the service or system when the interprocess communication is too busy.
Disclosure of Invention
The technical scheme adopted by the application is as follows: a method for limiting interprocess communication is provided, which comprises the following steps: acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; judging whether the first quantity is smaller than a first set threshold value; and if so, limiting binder communication between the background client and the server.
Another technical scheme adopted by the application is as follows: there is provided a mobile terminal including: the obtaining module is used for obtaining a first number of available binder threads of the server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; the judging module is used for judging whether the first quantity is smaller than a first set threshold value or not; and the limiting module is used for limiting binder communication between the background client and the server.
Another technical scheme adopted by the application is as follows: there is provided a mobile terminal comprising a processor and a memory, wherein the memory is for storing a computer program for performing the method as described above when executed by the processor.
Another technical scheme adopted by the application is as follows: there is provided a computer storage medium for storing a computer program for implementing the method as described above when executed by a processor.
The method for limiting interprocess communication provided by the application comprises the following steps: acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; judging whether the first quantity is smaller than a first set threshold value; and if so, limiting binder communication between the background client and the server. Through the mode, the communication of the background client side is limited based on the service condition of the binder thread of the server side, and the normal communication of the foreground client side is not affected, so that the busy degree of the server side can be reduced, and the fluency of the system is ensured.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts. Wherein:
FIG. 1 is a flowchart illustrating a first embodiment of a method for restricting interprocess communication provided by the present application;
FIG. 2 is a schematic illustration of interprocess communication;
FIG. 3 is a schematic diagram of a Binder communication mechanism;
FIG. 4 is an interaction diagram of a client and a server;
FIG. 5 is a flowchart illustrating a second embodiment of a method for restricting interprocess communication provided by the present application;
FIG. 6 is an interaction diagram of FIG. 5;
FIG. 7 is a flowchart illustrating a third embodiment of a method for restricting interprocess communication provided by the present application;
FIG. 8 is the interaction diagram of FIG. 7;
FIG. 9 is a flowchart illustrating a fourth embodiment of a method for restricting interprocess communication provided by the present application;
FIG. 10 is a flowchart illustrating a fifth embodiment of a method for restricting interprocess communication provided by the present application;
FIG. 11 is a flowchart illustrating a sixth embodiment of a method for restricting interprocess communication provided by the present application;
FIG. 12 is a flowchart illustrating a seventh embodiment of a method for restricting interprocess communication provided by the present application;
fig. 13 is a schematic structural diagram of an embodiment of a mobile terminal provided in the present application;
fig. 14 is a schematic structural diagram of another embodiment of a mobile terminal provided in the present application;
FIG. 15 is a schematic structural diagram of an embodiment of a computer storage medium provided in the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not limiting of the application. It should be further noted that, for the convenience of description, only some of the structures related to the present application are shown in the drawings, not all of the structures. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The terms "first", "second", etc. in this application are used to distinguish between different objects and not to describe a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in an embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
Referring to fig. 1, fig. 1 is a schematic flowchart of a first embodiment of a method for limiting inter-process communication provided by the present application, where the method includes:
step 11: a first number of available binder threads of a server is obtained.
The binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server.
The Binder is a mode of inter-process communication (IPC) in the Android system, and is one of the most important characteristics in the Android system. The four major components in Android, Activity, Service, Broadcast receiver, ContentProvider, App, etc., operate in different processes, which are bridges for communication between these processes. As its name "adhesive" is used to bond components of a system together as a bridge between the components.
As shown in fig. 2, fig. 2 is a schematic diagram of a principle of inter-process communication, and each Android process can only run in a virtual address space owned by its own process. For example, the virtual address space corresponds to 4GB, where 3GB is the user space and 1GB is the kernel space, and the size of the kernel space can be adjusted by parameter configuration. For user space, different processes are not shared with each other, while kernel space is shareable. The Client process communicates with the Server process, and the underlying communication work is completed by using the kernel memory space sharable among the processes, and the Client process and the Server process often adopt methods such as ioctl (a function for managing an I/O channel of a device in a device driver) and the like to interact with the drive of the kernel space.
Referring to fig. 3, fig. 3 is a schematic diagram of a Binder communication mechanism, in which the Binder communication employs a C/S architecture, and from a component perspective, includes a Client (Client), a Server (Server), a ServiceManager (service management) and a Binder driver, where the ServiceManager is used for managing various services in the system.
Wherein, the Client process is a process using service; the Server process is a process for providing service; the ServiceManager process is used for converting the Binder name in a character form into a reference to the Binder in the Client, so that the Client can obtain the reference to the Binder entity in the Server through the Binder name; the Binder driver is responsible for establishing Binder communication between processes, transmitting the Binder between the processes, managing the reference count of the Binder, transmitting and interacting data packets between the processes and the like.
In the communication process based on the binder mechanism, the following three processes are mainly included:
registration service (addService): the Server process registers Service to the ServiceManager first. The process comprises the following steps: the Server is a client and the ServiceManager is a Server.
Get service (getService): before a Client process uses a certain Service, the Client process needs to acquire the corresponding Service from the ServiceManager. The process comprises the following steps: the Client is a Client and the ServiceManager is a server.
Using the service: the Client establishes a communication path with the Server process where the Service is located according to the obtained Service information, and then can directly interact with the Service. The process comprises the following steps: the client is a client and the server is a server.
It can be understood that the interactions among the Client, the Server and the Service Manager in fig. 3 are all represented by dotted lines, because they are not directly interacted with each other, but are interacted with the Binder driver, thereby implementing an IPC communication mode. The Binder driver is positioned in the kernel space, and the Client, the Server and the Service Manager are positioned in the user space. The Binder driver and the ServiceManager can be regarded as basic frameworks of an Android platform, the Client and the Server are application layers of the Android, and developers can directly carry out IPC communication by means of the basic platform framework of the Android by only customizing the Client and the Server.
Further, when the client communicates with the server in a Binder, the server may start some Binder threads to respond to the Binder request of the client.
In particular, Binder communication is actually communication between threads located in different processes. If process S is the Server side, providing a Binder entity, thread T1 sends a request from Client process C1 to process S via the Binder' S reference. S in order to handle this request, thread T2 needs to be started, while thread T1 is in a wait state to receive return data. When the T2 finishes processing the request, the processing result is returned to T1, and T1 is awakened to obtain the processing result. In this process, T2 appears as if T1 was acting in process S, performing remote tasks on behalf of T1, and giving T1 the sensation of traversing to S to execute a piece of code and returning to C1. To make this ride-through more realistic, the driver will assign some attributes of T1 to T2, and in particular to the priority nic of T1, so that T2 will use a similar time to complete the task as T1.
For the Server process S, many clients may initiate requests at the same time, and in order to improve efficiency, a thread pool is often developed and the received binder requests are processed concurrently.
It will be appreciated that communication between two processes typically uses multiple threads. For example, the Android system specifies that a SystemServer process can create 32 Binder threads at most for interprocess data communication; the SurfaceFlinger process can create 4 Binder threads at most for interprocess data communication; the program application process can create up to 8 Binder threads for interprocess data communication.
Based on the principle of the binder mechanism, it is known that the client and the server may be any two processes, which may be an application or a service, for example, communication between applications or communication between applications.
In addition, in the intelligent terminal, multiple applications may acquire the same service at the same time, so that one server may perform inter-process communication with multiple clients at the same time, and in this case, because the number of times of communication of the server is large, the thread usage amount is large, and the communication is too frequent, a system is stuck, in this embodiment, the influence of the busyness of the client on the server is mainly measured by acquiring the number of binder threads used for communication between a specific client and the server, so as to limit the client.
Optionally, in this embodiment, the server may be a system server.
Specifically, as shown in fig. 4, fig. 4 is an interaction schematic diagram of a client and a server, and the communication process between the client and the server mainly includes three processes, where the client initiates a communication request to the server, the server responds to the communication request initiated by the client, and data interaction is performed between the client and the server.
It can be understood that when the client initiates a binder request to the server, the binder thread of the server is not occupied yet, and when the server starts to respond, one binder thread is started to respond.
Taking the total number of binder threads of the server as an example, as shown in the following table:
| server binder thread count | Number of threads used in binder | Number of idle counters |
| 32 | 20 | 12 |
Among the 20 used binder threads, there may be multiple clients, including foreground clients and background clients. It can be understood that when the number of available binder threads of the server is too small or exhausted, the binder request sent by the client cannot be responded, so that normal binder communication cannot be performed between the client and the server, and further the operation of the client is affected.
Step 12: and judging whether the first quantity is smaller than a first set threshold value.
If the determination result in step 12 is yes, the server normally responds to the binder request sent by the client, and performs inter-process communication between the client and the server.
When the determination result of step 12 is no, step 13 is executed.
The first set threshold may be set empirically, and may also refer to the total number of binder threads of the server, and optionally, the first set threshold is generally smaller, and may be, for example, 10% of the total number of binder threads. In addition, the number of the remaining available binder threads of the server can be obtained when the system is unsmooth, crashed and the like. Assuming that the total number of binder threads of a server is 32, the first set threshold may be set to 0-10.
In one embodiment, the first predetermined threshold is zero, and step 12 is specifically: it is determined whether the first number is zero. It can be understood that, in this embodiment, it is equivalent to determining whether the available binder thread of the server is exhausted.
Step 13: and limiting binder communication between the background client and the server.
The background client refers to a client running in the background, and generally refers to a program operated by a user as a foreground program, and a program which is not operated by the user but is running is also referred to as a background program. The program here is also referred to as a client.
For example, software a and software B are run in the same row on the mobile phone, where software a runs in the foreground, that is, the user is operating software a to perform corresponding interaction, and software B runs in the background, and in combination with step 13, software a keeps running, binder communication between software a and the server is also kept, and binder communication between software B and the server is limited.
The method for limiting the binder communication between the background client and the server includes various ways, for example, ways of directly closing the background client, prohibiting the background client from sending a binder request to the server, prohibiting the server from responding to the binder request sent by the background client, adding the binder request sent by the background client into a waiting queue, and the like may be used.
It is understood that the client and the server in the above embodiments are self-definable, and thus the above manner can be applied to any application or service.
Optionally, in an embodiment, the number of available binder threads of the server may be counted each time a binder thread of the server is used and released. For example, the number of available binder threads is recorded as N, after a client sends a binder request to a server, the server initiates a binder thread to respond to the binder request, that is, the current available binder thread is N-1, and after one communication between the client and the server is finished, a binder thread is released, that is, the current available binder thread is N + 1.
The method for limiting inter-process communication provided by the embodiment comprises the following steps: acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; judging whether the first quantity is smaller than a first set threshold value; and if so, limiting binder communication between the background client and the server. Through the mode, the communication of the background client side is limited based on the service condition of the binder thread of the server side, and the normal communication of the foreground client side is not affected, so that the busy degree of the server side can be reduced, and the fluency of the system is ensured.
Referring to fig. 5, fig. 5 is a flowchart illustrating a second embodiment of a method for restricting inter-process communication according to the present application, where the method includes:
step 51: a first number of available binder threads of a server is obtained.
The binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server.
Step 52: and judging whether the first quantity is smaller than a first set threshold value.
If the determination result in step 52 is yes, step 53 is executed.
If the determination result in step 52 is negative, the server normally responds to the binder request sent by the client, and performs inter-process communication between the client and the server.
Step 53: and acquiring a second number of binder threads used by the binder communication between the target background client and the server.
When a plurality of clients running in the background are available, the number of binder threads used for binder communication between each background client and the server can be acquired respectively.
Step 54: and judging whether the second quantity is larger than a second set threshold value.
If the determination result in step 54 is yes, step 55 is executed.
Step 55: and limiting binder communication between the target background client and the server.
It can be understood that the present embodiment is different from the above embodiments in that the present embodiment does not limit all background clients, and limits those background clients occupying more binder threads.
For example, in this embodiment, the second set threshold is 5, then, when the number of available binder threads of the server is small, the background client needs to be limited at this time, and the number of binder threads used by the current background a client and background B client is obtained, where the a client uses 3 binder threads and the B client uses 6 binder threads, and then the a client does not need to be limited, but only the B client is limited.
Optionally, in an embodiment, step 55 may specifically include: when the target background client side sends the binder request to the server side, the binder request is added to the tail end of the waiting queue so as to suspend responding to the binder request sent by the target background client side
With reference to fig. 6, in a specific example, when the client sends the first binder request to the server, it is detected that the number of available binder threads of the server is greater than the first set threshold, and the response requirement is met, and at this time, the first binder request is responded to. When the client sends a second binder request to the server, the second binder request is added into the waiting queue when the number of the available binder threads of the server is detected to be smaller than a first set threshold value and does not meet the response requirement. And if the number of the available binder threads of the server is detected to be larger than the first set threshold value again, sending a second binder request in the waiting queue to the server, and responding to the second binder request by the server.
After the available binder thread of the server is greater than the first set threshold, the response requirement is met, and generally, the binder request in the waiting queue is responded first, and then the binder request currently sent by the client is responded.
It is to be understood that, in the foregoing embodiment, the client is a background client, and further, the client may be a background client in which the number of used binder threads in the background client is greater than the second set threshold.
The method and the device have the advantages that the existing binder communication of the background client is kept, and the background client is forbidden to further communicate with the server.
Optionally, in another embodiment, step 55 may specifically include: and searching and killing the target background client to release the binder thread used by the target client.
The method and the device have the advantages that the client side occupying more binder threads is directly checked and killed, and after a large number of binder threads are released, binder communication between other client sides and the server side can be guaranteed.
In addition, the two implementation modes can be combined, and a limiting mode of prohibiting communication or killing can be selectively adopted for the background client. The following were used:
referring to fig. 7, fig. 7 is a schematic flowchart of a third embodiment of a method for limiting inter-process communication provided in the present application, where the method includes:
step 71: a first number of available binder threads of a server is obtained.
The binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server.
Step 72: and judging whether the first quantity is smaller than a first set threshold value.
If the determination result in step 72 is yes, the server normally responds to the binder request sent by the client, and performs inter-process communication between the client and the server.
When the determination result of step 72 is no, step 73 is executed.
Step 73: and acquiring a second number of binder threads used by the binder communication between the target background client and the server.
Step 74: and judging whether the second quantity is larger than a set threshold value.
If the determination result of step 74 is yes, step 75 is executed, and if the determination result of step 74 is no, step 76 is executed.
Step 75: and searching and killing the target background client to release the binder thread used by the target client.
Step 76: and when the target background client sends the binder request to the server, adding the binder request to the tail end of the waiting queue to suspend responding to the binder request sent by the target background client.
With reference to fig. 8, in a specific example, when the client sends the first binder request to the server, it is detected that the number of available binder threads of the server is greater than the first set threshold, and the response requirement is met, and at this time, the first binder request is responded to. When the client sends a second binder request to the server, the client adds the second binder request into the waiting queue when detecting that the number of the available binder threads of the server is smaller than a first set threshold value and does not meet the response requirement and the number of the binder threads used by the client is smaller than a second set threshold value. When the client sends a third binder request to the server, the client is checked and killed to release all binder threads used by the client when the client detects that the number of available binder threads of the server is smaller than a first set threshold and does not meet the response requirement and the number of binder threads used by the client is larger than a second set threshold.
Referring to fig. 9, fig. 9 is a schematic flowchart of a fourth embodiment of a method for restricting inter-process communication according to the present application, where the method includes:
step 91: a first number of available binder threads of a server is obtained.
The binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server.
And step 92: and judging whether the first quantity is smaller than a first set threshold value.
If the determination result in step 92 is yes, the server normally responds to the binder request sent by the client, and performs inter-process communication between the client and the server.
When the determination result of step 92 is no, step 93 is executed.
Step 93: and acquiring the memory occupancy rate of the target background client.
It can be understood that when the memory occupancy rate is high, the influence on the fluency of the system is serious.
Step 94: and judging whether the memory occupancy rate is greater than a third set threshold value.
When the determination result of step 94 is yes, step 95 is executed.
Step 95: and limiting binder communication between the target background client and the server.
It can be understood that the difference between the present embodiment and the above embodiments is that the present embodiment does not limit all background clients, and limits those background clients that occupy more memory, that is, the operation of the background clients is ensured, and the fluency of the system can be improved.
Referring to fig. 10, fig. 10 is a schematic flowchart of a fifth embodiment of a method for limiting inter-process communication provided in the present application, where the method includes:
step 101: when a client side initiates a communication request to a server side, a first time point is recorded.
Step 102: and recording the second time point when the server side responds to the communication request initiated by the client side.
Step 103: and acquiring the service waiting time based on the first time point and the second time point.
The service waiting time is a time period between the first time point and the second time point.
Step 104: and saving the service waiting time so as to monitor the communication of the service end based on the service waiting time.
Referring to fig. 11, fig. 11 is a schematic flowchart of a sixth embodiment of a method for limiting inter-process communication provided in the present application, where the method includes:
step 111: and recording the second time point when the server side responds to the communication request initiated by the client side.
Step 112: and recording a third time point when the interprocess communication between the client and the server is completed.
Step 113: and acquiring the communication service time based on the second time point and the third time point.
The communication service time is a time period between the second time point and the third time point.
Step 114: and saving the communication service time so as to monitor the communication of the service terminal based on the communication service time.
Referring to fig. 12, fig. 12 is a schematic flowchart of a seventh embodiment of a method for limiting inter-process communication provided in the present application, where the method includes:
step 121: when a client side initiates a communication request to a server side, a first time point is recorded.
Step 122: and recording a third time point when the interprocess communication between the client and the server is completed.
Step 123: and acquiring the total time of the inter-process communication based on the first time point and the third time point.
The total time of inter-process communication is the time period between the first time point and the third time point.
Step 124: and saving the total time for acquiring the interprocess communication so as to monitor the communication of the server based on the total time for acquiring the interprocess communication.
The embodiments of fig. 10-12 described above may be implemented in combination with other embodiments described above, which obtain the duration of the communication from three different aspects, including the service waiting duration, the communication service duration, and the total duration.
Specifically, an average value or a total time length of each time length may be obtained. As shown in the following table:
for example, the average value of the service waiting time periods is the average value of a1, b1, and c 1; the average value of the communication service duration is the average value of a2, b2 and c 2; the total inter-process communication duration is the average of a3, b3, and c 3.
Alternatively, other statistical methods of statistics may be used to make statistics on the data, such as variance.
In addition, when the communication times, the service waiting time length, the communication service time length and the total inter-process communication time length are counted and monitored, a histogram can be drawn for visual display, and the busyness degree of the system can be further obtained by using the histogram, so that the system can be optimized through subsequent limitation measures on the client side, and the fluency of the system is ensured.
Referring to fig. 13, fig. 13 is a schematic structural diagram of an embodiment of a mobile terminal provided in the present application, where the mobile terminal 130 includes an obtaining module 131, a determining module 132, and a limiting module 133.
The obtaining module 131 is configured to obtain a first number of available binder threads of the server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; the judging module 132 is configured to judge whether the first quantity is smaller than a first set threshold; the limiting module 133 is configured to limit binder communication between the background client and the server if the determination result of the determining module 132 is yes.
Referring to fig. 14, fig. 14 is a schematic structural diagram of another embodiment of the mobile terminal provided in the present application, where the mobile terminal 140 includes a processor 141 and a memory 142, and the processor 141 and the memory 142 may be coupled by a data bus.
Wherein the memory 142 is adapted to store a computer program which, when being executed by the processor 141, is adapted to carry out the method steps of:
acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; judging whether the first quantity is smaller than a first set threshold value; and if so, limiting binder communication between the background client and the server.
Referring to fig. 15, fig. 15 is a schematic structural diagram of an embodiment of a computer storage medium provided in the present application, where the computer storage medium 150 is used to store a computer program 151, and the computer program 151 is used to implement the following method steps when being executed by a processor:
acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by the client to realize communication between the client and the server; judging whether the first quantity is smaller than a first set threshold value; and if so, limiting binder communication between the background client and the server.
It is understood that the steps performed by the virtual module in fig. 13 and the steps of the method implemented by the computer programs in the embodiments of fig. 14 and 15 when executed by the processor are similar to the embodiments of the mobile terminal and the method for limiting inter-process communication, and are not described herein again.
Embodiments of the present application may be implemented in software functional units and may be stored in a computer readable storage medium when sold or used as a stand-alone product. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The above description is only for the purpose of illustrating embodiments of the present application and is not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings of the present application or are directly or indirectly applied to other related technical fields, are also included in the scope of the present application.
Claims (12)
1. A method for restricting interprocess communication, comprising:
acquiring a first number of available binder threads of a server; the binder thread is provided by the server and used for responding to a binder request sent by a client to realize communication between the client and the server; wherein, the available binder thread is an idle binder thread in the total binder thread;
judging whether the first quantity is smaller than a first set threshold value;
if yes, acquiring a second number of binder threads used by the target background client side for binder communication with the server side;
judging whether the second quantity is larger than a second set threshold value or not;
and if the second quantity is greater than a second set threshold, limiting binder communication between the target background client and the server.
2. The method of restricting inter-process communication of claim 1,
the step of limiting binder communication between the target background client and the server comprises the following steps:
and when the target background client side sends a binder request to the server side, adding the binder request to the tail end of the waiting queue to pause and respond to the binder request sent by the target background client side.
3. The method of restricting inter-process communication of claim 2,
after the step of judging whether the first quantity is smaller than a first set threshold, the method further comprises:
if not, the binder request in the waiting queue is responded first, and then the binder request sent by the client side is responded.
4. The method of restricting inter-process communication of claim 1,
the step of limiting binder communication between the target background client and the server comprises the following steps:
and searching and killing the target background client to release the binder thread used by the target background client.
5. The method of restricting inter-process communication of claim 1,
the step of judging whether the first quantity is smaller than a first set threshold specifically includes:
and judging whether the first quantity is zero or not.
6. The method of restricting inter-process communication of claim 1,
the step of limiting binder communication between the target background client and the server comprises the following steps:
acquiring the memory occupancy rate of a target background client;
judging whether the memory occupancy rate is greater than a third set threshold value;
and if so, limiting binder communication between the target background client and the server.
7. The method of restricting inter-process communication of claim 1,
the method further comprises the following steps:
when the client side initiates a communication request to the server side, recording a first time point;
recording a second time point when the server side responds to the communication request initiated by the client side;
acquiring service waiting time based on the first time point and the second time point;
and saving the service waiting time so as to monitor the communication of the server side based on the service waiting time.
8. The method of restricting inter-process communication of claim 7,
the method further comprises the following steps:
recording a third time point when the inter-process communication between the client and the server is completed;
acquiring communication service time based on the second time point and the third time point;
and saving the communication service time so as to monitor the communication of the server based on the communication service time.
9. The method of restricting inter-process communication of claim 8,
the method further comprises the following steps:
acquiring total inter-process communication time based on the first time point and the third time point;
and saving the total time of the communication between the acquisition processes so as to monitor the communication of the server based on the total time of the communication between the acquisition processes.
10. A mobile terminal, comprising:
the obtaining module is used for obtaining a first number of available binder threads of the server; the binder thread is provided by the server and used for responding to a binder request sent by a client to realize communication between the client and the server; wherein, the available binder thread is an idle binder thread in the total binder thread;
the judging module is used for judging whether the first quantity is smaller than a first set threshold value or not;
the obtaining module is further configured to obtain a second number of binder threads used by the target background client for binder communication with the server when the first number is smaller than a first set threshold;
the judging module is further configured to judge whether the second quantity is greater than a second set threshold;
and the limiting module is used for limiting the binder communication between the target background client and the server when the second quantity is greater than a second set threshold.
11. A mobile terminal, characterized in that it comprises a processor and a memory, wherein the memory is adapted to store a computer program which, when executed by the processor, is adapted to carry out the method according to any of claims 1-9.
12. A computer storage medium for storing a computer program which, when executed by a processor, is adapted to carry out the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810701460.5A CN108984321B (en) | 2018-06-29 | 2018-06-29 | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810701460.5A CN108984321B (en) | 2018-06-29 | 2018-06-29 | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108984321A CN108984321A (en) | 2018-12-11 |
| CN108984321B true CN108984321B (en) | 2021-03-19 |
Family
ID=64539712
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810701460.5A Active CN108984321B (en) | 2018-06-29 | 2018-06-29 | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108984321B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527476B (en) * | 2019-09-19 | 2024-03-26 | 华为技术有限公司 | Resource scheduling method and electronic equipment |
| CN114077519B (en) * | 2020-08-21 | 2022-11-18 | 荣耀终端有限公司 | System service recovery method and device and electronic equipment |
| CN115202902B (en) * | 2022-07-01 | 2023-08-22 | 荣耀终端有限公司 | Method for controlling process interaction and related device |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107800768A (en) * | 2017-09-13 | 2018-03-13 | 平安科技（深圳）有限公司 | Open platform control method and system |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100474852C (en) * | 2003-07-28 | 2009-04-01 | 华为技术有限公司 | Method for communicating between telecommunication equipment service terminal and customer terminal |
| CN101127685B (en) * | 2007-09-20 | 2011-05-25 | 中兴通讯股份有限公司 | An inter-process communication device and inter-process communication method |
| US9804994B2 (en) * | 2013-03-15 | 2017-10-31 | Microsoft Technology Licensing, Llc | Application architecture supporting multiple services and caching |
| CN103986762B (en) * | 2014-05-15 | 2018-03-27 | 京信通信系统（中国）有限公司 | A kind of method and device for carrying out process status detection |
| US9875182B1 (en) * | 2015-05-26 | 2018-01-23 | EMC IP Holding Company LLC | Lock free container packing |
| CN104850460A (en) * | 2015-06-02 | 2015-08-19 | 上海斐讯数据通信技术有限公司 | Service program thread management method |
| CN106776080A (en) * | 2016-12-29 | 2017-05-31 | 北京奇虎科技有限公司 | The connection method for building up and device of worker thread |
| CN107608785A (en) * | 2017-08-15 | 2018-01-19 | 深圳天珑无线科技有限公司 | Process management method, mobile terminal and readable storage medium |
-
2018
- 2018-06-29 CN CN201810701460.5A patent/CN108984321B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107800768A (en) * | 2017-09-13 | 2018-03-13 | 平安科技（深圳）有限公司 | Open platform control method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108984321A (en) | 2018-12-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3475856B1 (en) | Warm start technique for cloud-hosted functions | |
| WO2019128535A1 (en) | Message management method and device, and storage medium | |
| CN108984321B (en) | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium | |
| US9201693B2 (en) | Quota-based resource management | |
| US7386859B2 (en) | Method and system for effective management of client and server processes | |
| AU2017434691B2 (en) | Method and device for handling timeout of system service | |
| CN109032812B (en) | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium | |
| CN109117280B (en) | Electronic device, method for limiting inter-process communication thereof and storage medium | |
| CN109547282B (en) | Overload protection method and device, computer readable storage medium and server | |
| CN109117279B (en) | Electronic device, method for limiting inter-process communication thereof and storage medium | |
| CN109002364B (en) | Method for optimizing inter-process communication, electronic device and readable storage medium | |
| CN109117278B (en) | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium | |
| CN109032814B (en) | Mobile terminal, method for monitoring interprocess communication of mobile terminal and storage medium | |
| CN108429703B (en) | DHCP client-side online method and device | |
| CN108924128A (en) | A kind of mobile terminal and its method for limiting, the storage medium of interprocess communication | |
| CN110096352B (en) | Process management method, device and computer readable storage medium | |
| CN109117340B (en) | Mobile terminal, method for monitoring interprocess communication of mobile terminal and storage medium | |
| CN109039952B (en) | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium | |
| CN114296916B (en) | Method, device and medium for improving RDMA release performance | |
| CN109062706B (en) | Electronic device, method for limiting inter-process communication thereof and storage medium | |
| CN109032813B (en) | Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium | |
| CN112131029B (en) | Broadcast processing method, apparatus, computer device and storage medium | |
| CN109062707B (en) | Electronic device, method for limiting inter-process communication thereof and storage medium | |
| CN109062705B (en) | Method for monitoring interprocess communication, electronic device and readable storage medium | |
| CN109144745B (en) | Method for monitoring interprocess communication, electronic device and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |