CN109039952B

CN109039952B - Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium

Info

Publication number: CN109039952B
Application number: CN201810700058.5A
Authority: CN
Inventors: 周明君; 方攀; 陈岩
Original assignee: Oppo Chongqing Intelligent Technology Co Ltd
Current assignee: Oppo Chongqing Intelligent Technology Co Ltd
Priority date: 2018-06-29
Filing date: 2018-06-29
Publication date: 2022-06-07
Anticipated expiration: 2038-06-29
Also published as: CN109039952A

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: when a client sends a binder request to a server, acquiring the communication frequency between the client and the server before sending the binder request; judging whether the communication times are larger than a set threshold value or not; if yes, adding the binder request to the tail end of the waiting queue; wherein, the client side preferentially responds to the binder request at the head end of the waiting queue in the interprocess communication process. By the method, the busy degree of the server can be reduced, and the fluency of the system is ensured.

Description

Mobile terminal, limiting method for interprocess communication of mobile terminal and storage medium

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 communication by using the Binder mechanism, usually one server communicates with multiple 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: when a client sends a binder request to a server, acquiring the communication frequency between the client and the server before sending the binder request; judging whether the communication times are larger than a set threshold value or not; if yes, adding the binder request to the tail end of the waiting queue; and the client side responds to the binder request in the waiting queue after a set time period.

Another technical scheme adopted by the application is as follows: there is provided a mobile terminal including: the acquiring module is used for acquiring the communication frequency between the client and the server before sending the binder request when the client sends the binder request to the server; the judging module is used for judging whether the communication frequency is greater than a set threshold value or not; the waiting module is used for adding the binder request to the tail end of the waiting queue when the judgment result of the judging module is yes; wherein, the client side preferentially responds to the binder request at the head end of the waiting queue in the interprocess communication process.

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.

Different from the situation of the prior art, the limiting method for interprocess communication provided by the application comprises the following steps: in the process of inter-process communication between the server and the client based on the binder mechanism, the communication frequency between the server and the client is acquired, and the communication frequency between the client and the server is limited, so that the busy degree of the server can be reduced, and the smoothness 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 a schematic diagram of the interaction of a client, a server, and a wait queue;

FIG. 7 is an interaction diagram of a client A, a client B, a server and a wait queue;

FIG. 8 is a flowchart illustrating a third embodiment of a method for restricting interprocess communication provided by the present application;

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 block diagram of an embodiment of a mobile terminal provided herein;

fig. 13 is a schematic structural diagram of another embodiment of a mobile terminal provided in the present application;

FIG. 14 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: when the client sends the binder request to the server, the communication frequency between the client and the server before sending the binder request is obtained.

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 it is exactly how to use the shared kernel memory space between processes to complete the bottom layer communication work, and the Client and Server processes often adopt methods such as ioctl (a function in the device driver to manage the I/O channel of the device) to interact with the driver 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.

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 usage amount of threads is large, and 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 times of communication between the client and the server, so as to limit the client.

Optionally, in this embodiment, the server may be a system server.

Optionally, when the number of times of communication between the client and the server is obtained, an accumulative method may be adopted, specifically, as shown in fig. 4, fig. 4 is an interaction diagram of the client and the server, in the communication process between the client and the server, three processes are mainly included, 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.

The communication process is completed through the above process, and therefore, the number of times of communication can be accumulated by any one of the three nodes.

Optionally, step 11 may specifically be: and when the client initiates a communication request to the server, accumulating the communication times.

Optionally, step 11 may specifically be: and when the server side responds to the communication request initiated by the client side, accumulating the communication times.

Optionally, step 11 may specifically be: and when the interprocess communication between the client and the server is completed, accumulating the communication times.

In one embodiment, the server may not respond to the communication request of the client due to busy reasons, or the client may not be able to complete communication with the server due to breakdown reasons, and therefore, in this embodiment, the number of times of communication may be accumulated when the inter-process communication between the client and the server is completed. Therefore, the excessive communication times caused by the error accumulation can be avoided.

It can be understood that, because the number of communications is accumulated, when the client sends the binder request to the server, subsequent determination can be directly performed through the accumulated number of communications. It is noted that the number of communications is only for communications between the same client and the same server.

Step 12: and judging whether the communication frequency is greater than a set threshold value.

If the determination result in step 12 is yes, step 13 is executed.

And if the judgment result in the step 12 is negative, the server responds to the binder request sent by the client to perform interprocess communication between the client and the server.

The set threshold may be set according to experience, for example, by obtaining an average value of the number of communications between the plurality of clients and the server over a period of time, when the number of communications reaches a certain critical value, the system is prone to phenomena such as unsmooth communications, breakdown, and the like.

Step 13: adding the binder request to the end of the waiting queue; and the client side responds to the binder request in the waiting queue after a set time period.

The binder request in the waiting queue (pending) is not immediately responded by the server, which is equivalent to establishing a buffering mechanism, and the binder request can be responded after a period of time or when the server is not busy.

The following is illustrated by a specific example, which is illustrated according to chronological order:

1. carrying out binder communication between a first process of an application program A (client) and a system service (server) for 1 time in a cumulative manner;

2. carrying out binder communication between the second process of the application program A and the system service, and accumulating for 2 times;

3. carrying out binder communication between the second process of the application program A and the system service, and accumulating for 3 times;

4. carrying out binder communication between the third process of the application program A and the system service, and accumulating for 4 times;

5. the first process of application A communicates binder with system services, totaling 5 times.

In the above example, the number of times of communication has been performed is 5, and if the preset threshold is also 5 times, the client adds the binder request to the waiting queue if the client sends the binder request to the server again in combination with step 11.

It is understood that the client and the server in the above embodiments are self-definable, and thus the above manner may be applied to any application or service to monitor the communication times thereof.

Different from the prior art, the inter-process communication limiting method provided in this embodiment monitors the busy level of the server by acquiring the number of times of communication between the server and the client, and limits the client with a large number of times of communication by using a monitoring result. Through the method, on one hand, the busy degree of the server can be rapidly and effectively acquired, data support is provided for optimization of the system, on the other hand, the communication times can be well limited from the perspective of the client, the burden of the server is effectively reduced, the busy degree of the server is reduced, and the flow performance of the system is guaranteed.

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: and in the current time period, accumulating the communication times when the client sends a binder request to the server.

Optionally, in another embodiment, step 51 may also be: and marking the corresponding client when the client sends a binder request to the server in the current time period. In the subsequent operation, the judgment of whether the number of the marks is larger than the set threshold value is only needed.

Step 52: and when the client sends the binder request to the server, acquiring the accumulated communication times of the current time period.

It should be noted that the number of communications here is the number of communications between the same client and the server.

Wherein, the binder request is sent at the current time, and the current time is within the current time period.

Optionally, in the communication process between the client and the server, the time period may be divided into a plurality of time periods, and the time length of each time period is generally equal. Further, the number of communications may be accumulated for each time period, and at the end of the period, the accumulated number of communications may be cleared and accumulated again from the next period.

Step 53: and judging whether the accumulated communication times is greater than a set threshold value.

Step 54: adding the binder request to the end of the waiting queue; and the client side responds to the binder request in the waiting queue after a set time period.

As shown in fig. 6, fig. 6 is an interaction diagram of the client, the server, and the wait queue, and if the threshold of the number of communications set in each period is 10, the number of communications performed by the client and the server is accumulated once in the nth time period.

In the nth time period, the client sends an 11 th binder request (i.e., the communication request 11 in fig. 6) to the server, and if the number of times of communication in this period is acquired as 10 times and is greater than the set threshold, the binder request is added to the waiting queue. At the end of this period, the accumulated number of communications is cleared.

At the beginning of the (N + 1) th time period, the server preferentially processes the binder requests in the waiting queue.

As shown in fig. 7, fig. 7 is an interaction diagram of a client a, a client B, a server, and a waiting queue, and in the process of simultaneously communicating with the server by the client a and the client B, it is assumed that the set thresholds of both the clients are 10 times.

In the nth time period, the client sends an 11 th binder request (i.e., the communication request 11 in fig. 6) to the server, and if the number of times of communication in this period is acquired as 10 times and is greater than the set threshold, the binder request is added to the waiting queue.

However, in this period, the number of times of communication between the client B and the server has not reached 10 times, so even if the binder request sent by the client a is added to the waiting queue, the client B can still communicate with the server, that is, the binder request sent by the client B to the server is not added to the waiting queue.

At the end of this period, the accumulated number of communications is cleared.

Optionally, when the next period starts, the binder request at the head end in the wait queue is used as the binder request sent by the client to the server, and the step 51 is returned.

Referring to fig. 8, fig. 8 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 81: when the client sends the binder request to the server, the communication frequency between the client and the server before sending the binder request is obtained.

Step 82: and judging whether the server side meets a preset condition or not.

If the determination result in step 82 is yes, step 83 is executed.

Step 83: and judging whether the communication frequency is greater than a set threshold value.

Step 84: adding the binder request to the end of the waiting queue; wherein, the client side preferentially responds to the binder request at the head end of the waiting queue in the interprocess communication process.

It can be understood that the purpose of acquiring the number of times of communication between the client and the server before sending the binder request is to monitor the degree of busy of the server, and therefore, other judgment conditions can be added to judge whether the server is busy.

Optionally, the preset condition in step 82 is that the number of available threads of the server is less than a set threshold. 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.

Therefore, it can be determined whether the number of communication times is greater than the set threshold when the number of thread usage of the server meets the requirement, for example, one server has 32 threads in total, 16 threads are used, and the remaining 16 available threads, that is, when the number of used threads is greater than half, it is determined whether the number of communication times is greater than the set threshold.

Of course, the preset condition may also be the occupancy rate of the CPU, the number of clients simultaneously communicating with the same server, the communication frequency, and the like, which are not listed here.

It can be understood that, in the embodiment, the number of communications is counted, and then other indexes for detecting whether the server is busy are obtained, and the number of communications is used as a basic index. Therefore, the busy degree of the server can be judged through multiple conditions, the communication of the client side is limited, the fluency of the mobile terminal is facilitated, and the situation that the client side is forbidden by mistake and the use of a user is inconvenient can be prevented.

In the following, the time length of each stage in the communication process is monitored through several embodiments, so as to introduce a manner of determining how busy the server is.

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: when a client side initiates a communication request to a server side, a first time point is recorded.

And step 92: and recording the second time point when the server side responds to the communication request initiated by the client side.

Step 93: 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 94: 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. 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: and recording the second time point when the server side responds to the communication request initiated by the client side.

Step 102: and recording a third time point when the interprocess communication between the client and the server is completed.

Step 103: 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 104: 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. 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: when a client side initiates a communication request to a server side, a first time point is recorded.

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 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 114: 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. 9-11 may be implemented in combination with other embodiments described above, and 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:

number of communications	Service wait duration	Duration of communication service	Total duration of inter-process communication
				1	a1	a2	a3
2	b1	b2	b3
				3	c1	c2	c3

For example, the average value of the service waiting time period 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 duration of the inter-process communication 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 the histogram, so that the system can be optimized through subsequent limiting measures on the client side, and the fluency of the system is ensured.

Referring to fig. 12, fig. 12 is a schematic structural diagram of an embodiment of a mobile terminal provided in the present application, where the mobile terminal 120 includes an obtaining module 121, a determining module 122, and a waiting module 123.

The obtaining module 121 is configured to obtain, when the client sends a binder request to the server, the number of times of communication between the client and the server before sending the binder request; the judging module 122 is configured to judge whether the number of times of communication is greater than a set threshold; the waiting module 123 is configured to add the binder request to the end of the waiting queue when the determination result of the determining module 122 is yes; wherein, the client side preferentially responds to the binder request at the head end of the waiting queue in the interprocess communication process.

Optionally, the obtaining module 121 is specifically configured to, in the current time period, accumulate the number of communications each time the client sends a binder request to the server, and obtain the accumulated number of communications in the current time period.

Optionally, the obtaining module 121 is specifically configured to accumulate the communication times when the client initiates a communication request to the server, or when the server responds to the communication request initiated by the client, or when the inter-process communication between the client and the server is completed.

Referring to fig. 13, fig. 13 is a schematic structural diagram of another embodiment of the mobile terminal provided in the present application, where the mobile terminal 130 includes a processor 131 and a memory 132, where the processor 131 and the memory 132 may be coupled through a data bus.

Wherein the memory 132 is adapted to store a computer program which, when being executed by the processor 131, is adapted to carry out the method steps of:

when a client sends a binder request to a server, acquiring the communication times between the client and the server before sending the binder request; judging whether the communication times are larger than a set threshold value or not; if yes, adding the binder request to the tail end of the waiting queue; wherein, the client side preferentially responds to the binder request at the head end of the waiting queue in the interprocess communication process.

Referring to fig. 14, fig. 14 is a schematic structural diagram of an embodiment of a computer storage medium provided in the present application, the computer storage medium 140 is used for storing a computer program 141, and the computer program 141, when executed by a processor, is used for implementing the following method steps:

when a client sends a binder request to a server, acquiring the communication frequency between the client and the server before sending the binder request; judging whether the communication times are larger than a set threshold value or not; if yes, adding the binder request to the tail end of the waiting queue; wherein, the client side preferentially responds to the binder request at the head end of the waiting queue in the interprocess communication process.

It is understood that, when the computer programs in the embodiments of fig. 13 and fig. 14 are executed by the processor, the steps of the implemented method are similar to the embodiments of the mobile terminal and the limiting method for 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

1. A method for restricting interprocess communication, comprising:

in the current time period, when a client sends a binder request to a server, accumulating the communication times, wherein the accumulated communication times are the accumulated communication times of the same client and the same server;

when the client sends a binder request to the server, acquiring the accumulated communication times of the current time period;

judging whether the accumulated communication times is greater than a set threshold value;

if so, adding the binder request to the tail end of the waiting queue; the client side responds to the binder requests in the waiting queue after a set time period;

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.

2. The method of restricting inter-process communication of claim 1,

the method further comprises the following steps:

clearing the accumulated communication times when the current period is finished;

and when the next period starts, taking the binder request at the head end of the waiting queue as the binder request sent by the client to the server, and returning to the step of accumulating the communication times when the client sends the binder request to the server in the current time period.

3. The method of restricting inter-process communication of claim 1,

the method further comprises:

in the current time period, marking the corresponding client whenever the client sends a binder request to the server;

the step of judging whether the number of times of communication is greater than a set threshold includes:

and judging whether the marking frequency of the client corresponding to the current binder request is greater than a set threshold value.

4. The method of restricting inter-process communication of claim 1,

after the step of judging whether the number of times of communication is greater than the set threshold, the method further includes:

if not, the server side responds to the binder request sent by the client side, and inter-process communication between the client side and the server side is carried out.

5. The method of restricting inter-process communication of claim 1,

before the step of judging whether the communication frequency is greater than the set threshold, the method further comprises:

judging whether the server side meets a preset condition or not;

if yes, executing the step of judging whether the communication frequency is greater than a set threshold value;

the preset condition is that the number of the available threads of the server is smaller than a set threshold value.

6. The method of restricting inter-process communication of claim 5,

the method further comprises:

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.

7. The method of restricting inter-process communication of claim 6,

the method further comprises:

acquiring total inter-process communication time based on the first time point and the third time point;

and saving the total time of the inter-process communication so as to monitor the communication of the server side based on the total time of the inter-process communication.

8. A mobile terminal, comprising:

the acquisition module is used for accumulating the communication times when the client sends a binder request to the server in the current time period, wherein the accumulated communication times are the accumulated communication times of the same client and the same server; when the client sends a binder request to the server, acquiring the accumulated communication times of the current time period;

the judging module is used for judging whether the accumulated communication times is greater than a set threshold value;

the waiting module is used for adding the binder request to the tail end of the waiting queue when the judgment result of the judging module is yes; the client side responds to the binder request in the waiting queue after a set time period;

the obtaining module is further configured to record a first time point when the client initiates a communication request to the server; when the server side responds to the communication request initiated by the client side, recording a second time point; 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.

9. 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-7.

10. 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 7.