CN109039952A - 一种移动终端及其进程间通信的限制方法、存储介质 - Google Patents

Abstract

本申请公开了一种移动终端及其进程间通信的限制方法、存储介质，该进程间通信的限制方法包括：在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数；判断通信次数是否大于设定阈值；若是，将binder请求加入等待队列的末端；其中，客户端在进程间通信过程中优先响应等待队列的首端的binder请求。通过上述方式，能够减小服务端的繁忙程度，保证***的流畅性。

Description

一种移动终端及其进程间通信的限制方法、存储介质

技术领域

本申请涉及移动终端技术领域，特别是涉及一种移动终端及其进程间通信的限制方法、存储介质。

背景技术

Android操作***中，应用与服务间经常需要进行数据传输，一般可以采用进程间通信的方式，例如，可以通过Binder机制进行传输，从而获取对方的数据。

在利用Binder机制进行通信的过程中，通常一个服务端会与多个客户端进行通信，这样会加重服务端的负担，当进程间通信过于繁忙时，会影响服务或者***的流畅性。

发明内容

本申请采用的一个技术方案是：提供一种进程间通信的限制方法，该限制方法包括：在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数；判断通信次数是否大于设定阈值；若是，将binder请求加入等待队列的末端；其中，客户端在设定时间段后对等待队列中的binder请求进行响应。

本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括：获取模块，用于在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数；判断模块，用于判断通信次数是否大于设定阈值；等待模块，用于在判断模块的判断结果为是时，将binder请求加入等待队列的末端；其中，客户端在进程间通信过程中优先响应等待队列的首端的binder请求。

本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括处理器和存储器，其中，存储器用于存储计算机程序，计算机程序在被处理器执行时，用于实现如上述的方法。

本申请采用的另一个技术方案是：提供一种计算机存储介质，该计算机存储介质用于存储计算机程序，计算机程序在被处理器执行时，用于实现如上述的方法。

区别于现有技术的情况，本申请提供的进程间通信的限制方法包括：在服务端与客户端基于binder机制进行进程间通信的过程中，获取服务端与客户端之间的通信次数，并通过限制客户端与服务端之间的通信次数，从而能够减小服务端的繁忙程度，保证***的流畅性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：

图1是本申请提供的进程间通信的限制方法第一实施例的流程示意图；

图2是进程间通信的原理示意图；

图3是Binder通信机制的原理示意图；

图4是客户端和服务端的交互示意图；

图5是本申请提供的进程间通信的限制方法第二实施例的流程示意图；

图6是客户端、服务端、等待队列的交互示意图；

图7是客户端A、客户端B、服务端、等待队列的交互示意图；

图8是本申请提供的进程间通信的限制方法第三实施例的流程示意图；

图9是本申请提供的进程间通信的限制方法第四实施例的流程示意图；

图10是本申请提供的进程间通信的限制方法第五实施例的流程示意图；

图11是本申请提供的进程间通信的限制方法第六实施例的流程示意图；

图12是本申请提供的移动终端一实施例的结构示意图；

图13是本申请提供的移动终端另一实施例的结构示意图；

图14是本申请提供的计算机存储介质一实施例的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

参阅图1，图1是本申请提供的进程间通信的限制方法第一实施例的流程示意图，该方法包括：

步骤11：在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数。

Binder是Android***中进程间通讯(IPC)的一种方式，也是Android***中最重要的特性之一。Android中的四大组件Activity(工作流)，Service(服务)，Broadcast(广播接收器)，ContentProvider(内容提供者)，不同的App(应用程序)等都运行在不同的进程中，它是这些进程间通讯的桥梁。正如其名“粘合剂”一样，它把***中各个组件粘合到了一起，是各个组件的桥梁。

如图2所示，图2是进程间通信的原理示意图，每个Android的进程，只能运行在自己进程所拥有的虚拟地址空间。举例而言，对应一个4GB的虚拟地址空间，其中3GB是用户空间，1GB是内核空间，当然内核空间的大小是可以通过参数配置调整的。对于用户空间，不同进程之间彼此是不能共享的，而内核空间却是可共享的。Client进程向Server进程通信，恰恰是利用进程间可共享的内核内存空间来完成底层通信工作的，Client端与Server端进程往往采用ioctl(一种设备驱动程序中对设备的I/O通道进行管理的函数)等方法跟内核空间的驱动进行交互。

进一步参阅图3，图3是Binder通信机制的原理示意图，Binder通信采用C/S架构，从组件视角来说，包含Client(客户端)、Server(服务端)、ServiceManager(服务管理)以及binder驱动，其中ServiceManager用于管理***中的各种服务。

其中，Client进程为使用服务的进程；Server进程为提供服务的进程；ServiceManager进程的作用是将字符形式的Binder名字转化成Client中对该Binder的引用，使得Client能够通过Binder名字获得对Server中Binder实体的引用；Binder驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。

在基于binder机制的通信过程中，主要包括以下三个过程：

注册服务(addService)：Server进程要先注册Service到ServiceManager。该过程：Server是客户端，ServiceManager是服务端。

获取服务(getService)：Client进程使用某个Service前，须先向ServiceManager中获取相应的Service。该过程：Client是客户端，ServiceManager是服务端。

使用服务：Client根据得到的Service信息建立与Service所在的Server进程通信的通路，然后就可以直接与Service交互。该过程：client是客户端，server是服务端。

可以理解的，图3中的Client、Server、Service Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder驱动进行交互的，从而实现IPC通信方式。其中Binder驱动位于内核空间，Client、Server、Service Manager位于用户空间。Binder驱动和ServiceManager可以看做是Android平台的基础架构，而Client和Server是Android的应用层，开发人员只需自定义实现client、Server端，借助Android的基本平台架构便可以直接进行IPC通信。

基于上述binder机制的原理，我们知道，客户端和服务端可以是任意两个进程，可以是应用，也可以是服务，例如，可以是应用与应用之间的通信，也可以是应用与服务之间的通信。

另外，在智能终端中，多个应用可能同时获取同一服务，所以，一个服务端可能同时与多个客户端之间进行进程间通信，在这种情况下，由于服务端的通信次数多、线程使用量较大、通信过于频繁，会造成***的卡顿，本实施例主要是通过获取一个客户端与一个服务端之间的通信次数来衡量该客户端对服务端的繁忙程度所造成的影响，从而对该客户端进行限制。

可选的，在本实施例中，该服务端可以是***服务端。

可选的，在获取客户端与服务端之间的通信次数时，可以采用累计的方式，具体地，如图4所示，图4是客户端和服务端的交互示意图，在客户端与服务端的通信过程中，主要包括三个过程，客户端向服务端发起通信请求、服务端响应客户端发起的通信请求、客户端和服务端之间进行数据交互。

其中，经过上述的过程才算是一个完成的通信过程，因此，可以通过上述三个节点中的任意一个来累计通信次数。

可选的，步骤11可以具体为：在客户端向服务端发起通信请求时，累计通信次数。

可选的，步骤11可以具体为：在服务端响应客户端发起的通信请求时，累计通信次数。

可选的，步骤11可以具体为：在客户端和服务端的进程间通信完成时，累计通信次数。

在一具体的实施例中，服务端可能因为繁忙等原因没有响应客户端的通信请求，亦或是客户端由于崩溃等原因没有能够与服务端完成通信，因此，在该实施例中，可以在客户端和服务端的进程间通信完成时，再累计通信次数。这样也可以避免误累计导致统计的通信次数过多。

可以理解的，由于累计了通信次数，所以在客户端向服务端发送binder请求时，直接可以通过累计的通信次数来进行后续的判断。值得注意的是，这里的通信次数只针对同一客户端与同一服务端之间的通信。

步骤12：判断通信次数是否大于设定阈值。

在步骤12的判断结果为是时，执行步骤13。

在步骤12的判断结果为否时，服务端响应客户端发送的binder请求，进行客户端与服务端之间的进程间通信。

其中，设定阈值可以是根据经验设置的，例如，通过获取一段时间内多个客户端与服务端之间的通信次数的平均值，当通信次数达到某个临界值时，***容易出现不流畅、崩溃等现象。

步骤13：将binder请求加入等待队列的末端；其中，客户端在设定时间段后对等待队列中的binder请求进行响应。

其中，等待队列(pending)中的binder请求并不会立即被服务端响应，相当于建立了一个缓冲的机制，会在一段时间后或者服务端不繁忙的时候进行响应。

下面通过一个具体的例子进行说明，该例子中根据时间先后顺序进行说明：

1、应用程序A(客户端)的第一进程与***服务(服务端)进行binder通信，累计1次；

2、应用程序A的第二进程与***服务进行binder通信，累计2次；

3、应用程序A的第二进程与***服务进行binder通信，累计3次；

4、应用程序A的第三进程与***服务进行binder通信，累计4次；

5、应用程序A的第一进程与***服务进行binder通信，累计5次。

在上述的例子中，已经进行的通信次数为5次，若预设的设定阈值也是5次，那么结合步骤11，若客户端再次向服务端发送binder请求，就将该binder请求加入等待队列。

可以理解的，上述实施例中的客户端和服务端是可以自行定义的，因此上述方式可以适用于任意应用程序或者服务，对其通信次数进行监控。

区别于现有技术，本实施例提供的进程间通信的限制方法通过获取服务端与客户端之间的通信次数，从而对服务端的繁忙程度进行监控，并利用监控的结果对通信次数较多的客户端进行限制。通过上述方式，一方面能够快速有效的获取到服务端的繁忙程度，对***的优化提供数据支持，另一方面能够很好的从客户端的角度来限制通信次数，有效的减小服务端的负担，减小了服务端的繁忙程度，保证了***的流程性。

参阅图5，图5是本申请提供的进程间通信的限制方法第二实施例的流程示意图，该方法包括：

步骤51：在当前时间周期内，每当客户端向服务端发送binder请求时，累计通信次数。

可选的，在另一实施例中，步骤51还可以是：在当前时间周期内，每当客户端向服务端发送binder请求时，对相应的客户端进行标记。在后续的操作中，仅需通过判断标记的数量是否大于设定阈值即可。

步骤52：在客户端向服务端发送binder请求时，获取当前时间周期的累计通信次数。

值得注意的是，这里的通信次数是同一客户端与该服务端的通信次数。

其中，该binder请求是当前时间发送的，且该当前时间在上述的当前时间周期内。

可选的，在客户端与服务端的通信过程中，可以划分为多个时间周期，一般每个时间周期的时间长度是相等的。进一步，在每个时间周期内可以对通信次数进行累计，而在周期结束时，对累计的通信次数进行清零，从下一个周期开始重新累计。

步骤53：判断累计通信次数是否大于设定阈值。

步骤54：将binder请求加入等待队列的末端；其中，客户端在设定时间段后对等待队列中的binder请求进行响应。

如图6所示，图6是客户端、服务端、等待队列的交互示意图，假设每个周期内设置的通信次数阈值为10次，那么，在第N时间周期内，客户端与服务端每进行一次通信，就累计一次。

在第N时间周期内，该客户端向服务端发送第11次binder请求(即图6中的通信请求11)，获取到本周期内通信次数为10次，大于设定的阈值，那么将该binder请求加入等待队列。另外，在本周期结束时，将累计的通信次数清零。

在第N+1时间周期开始时，服务端优先处理等待队列中的binder请求。

如图7所示，图7是客户端A、客户端B、服务端、等待队列的交互示意图，在客户端A与客户端B同时与服务端进行通信的过程中，假设两种客户端的设定的阈值都是10次。

在第N时间周期内，该客户端向服务端发送第11次binder请求(即图6中的通信请求11)，获取到本周期内通信次数为10次，大于设定的阈值，那么将该binder请求加入等待队列。

但是，在本周期内，客户端B与服务端之间的通信次数还未达到10次，所以，即使客户端A发送的binder请求被加入等待队列，但客户端B仍然可以与服务端之间进行通信，即客户端B向服务端发送的binder请求不加入等待队列。

另外，在本周期结束时，将累计的通信次数清零。

在第N+1时间周期开始时，服务端优先处理等待队列中的binder请求。

可选的，在下一周期开始时，将等待队列中首端的binder请求作为客户端向服务端发送的binder请求，返回步骤51。

参阅图8，图8是本申请提供的进程间通信的限制方法第三实施例的流程示意图，该方法包括：

步骤81：在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数。

步骤82：判断服务端是否满足预设条件。

其中，在步骤82的判断结果为是时，执行步骤83。

步骤83：判断通信次数是否大于设定阈值。

步骤84：将binder请求加入等待队列的末端；其中，客户端在进程间通信过程中优先响应等待队列的首端的binder请求。

可以理解的，获取客户端在发送binder请求之前与服务端的通信次数的目的在于监控服务端繁忙程度，因此，可以增加其他的判断条件来判断服务端是否繁忙。

可选的，步骤82中的预设条件为服务端的可用线程的数量小于设定阈值。可以理解的，两个进程之间的通信一般会使用到多个线程。例如，Android***规定SystemServer进程最多可以创建32个Binder线程用于进程间数据通信；SurfaceFlinger进程最多可以创建4个Binder线程用于进程间数据通信；程序应用进程最多可以创建8个Binder线程用于进程间数据通信。

因此，可以在服务端的线程使用数量满足要求的时候再判断通信次数是否大于设定阈值，例如，一个服务端共有32个线程，其中16个线程被使用，可用线程剩余16个，即当被使用线程大于一半的时候开始判断通信次数是否大于设定阈值。

当然，预设条件还可以是CPU的占用率，同时与同一服务端通信的客户端的数量、通信频率等等，这里不再一一列举。

可以理解的，本实施例是通过统计通信次数，再获取检测服务端是否繁忙的其他指标，将通信次数作为一个基础指标。这样能够通过多重条件来判断服务端的繁忙程度，进而来限制客户端的通信，有利于实现移动终端的流畅性，还能够防止客户端被误禁用，造成用户的使用不便。

下面通过几种实施例对通信过程中的各个阶段的时间长度进行监控，以判断服务端的繁忙程度的方式进行介绍。

参阅图9，图9是本申请提供的进程间通信的限制方法第四实施例的流程示意图，该方法包括：

步骤91：在客户端向服务端发起通信请求时，记录第一时间点。

步骤92：在服务端响应客户端发起的通信请求时，记录第二时间点。

步骤93：基于第一时间点和第二时间点，获取服务等待时间。

这里的服务等待时间即为第一时间点和第二时间点之间的时间段。

步骤94：保存服务等待时间，以便基于服务等待时间对服务端的通信进行监控。

参阅图10，图10是本申请提供的进程间通信的限制方法第五实施例的流程示意图，该方法包括：

步骤101：在服务端响应客户端发起的通信请求时，记录第二时间点。

步骤102：在客户端和服务端的进程间通信完成时，记录第三时间点。

步骤103：基于第二时间点和第三时间点，获取通信服务时间。

这里的通信服务时间即为第二时间点和第三时间点之间的时间段。

步骤104：保存通信服务时间，以便基于通信服务时间对服务端的通信进行监控。

参阅图11，图11是本申请提供的进程间通信的限制方法第六实施例的流程示意图，该方法包括：

步骤111：在客户端向服务端发起通信请求时，记录第一时间点。

步骤112：在客户端和服务端的进程间通信完成时，记录第三时间点。

步骤113：基于第一时间点和第三时间点，获取进程间通信总时间。

这里的进程间通信总时间即为第一时间点和第三时间点之间的时间段。

步骤114：保存获取进程间通信总时间，以便基于获取进程间通信总时间对服务端的通信进行监控。

上述图9-图11的实施例可以与上述其他实施例相结合进行实施，其从三个不同的方面获取到通信的时长，其中包括服务等待时长、通信服务时长和总时长。

其中，具体可以获取每次时长的平均值或者总时长。如下表所示：

通信次数	服务等待时长	通信服务时长	进程间通信总时长
				1	a1	a2	a3
2	b1	b2	b3
				3	c1	c2	c3

例如，服务等待时长的平均值就是a1、b1和c1的平均值；通信服务时长的平均值就是a2、b2和c2的平均值；进程间通信总时长就是a3、b3和c3的平均值。

可选的，还可以利用统计学的其他统计方法对上述数据进行统计，例如方差。

另外，在对上述的通信次数、服务等待时长、通信服务时长和进程间通信总时长进行统计和监控时，可以绘制直方图进行直观的展示，利用直方图进一步获取到***的繁忙程度，从而能够通过后续的对客户端的限制措施，对***进行优化，保证***的流畅性。

参阅图12，图12是本申请提供的移动终端一实施例的结构示意图，该移动终端120包括获取模块121、判断模块122和等待模块123。

其中，获取模块121用于在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数；判断模块122用于判断通信次数是否大于设定阈值；等待模块123用于在判断模块122的判断结果为是时，将binder请求加入等待队列的末端；其中，客户端在进程间通信过程中优先响应等待队列的首端的binder请求。

可选的，获取模块121具体用于在当前时间周期内，每当客户端向服务端发送binder请求时，累计通信次数，以及获取当前时间周期的累计通信次数。

可选的，获取模块121具体用于在客户端向服务端发起通信请求时、或在服务端响应客户端发起的通信请求时、或在客户端和服务端的进程间通信完成时，累计通信次数。

参阅图13，图13是本申请提供的移动终端另一实施例的结构示意图，该移动终端130包括处理器131和存储器132，其中，处理器131和存储器132可以通过一条数据总线耦接。

其中，存储器132用于存储计算机程序，计算机程序在被处理器131执行时，用于实现如下方法步骤：

在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数；判断通信次数是否大于设定阈值；若是，将binder请求加入等待队列的末端；其中，客户端在进程间通信过程中优先响应等待队列的首端的binder请求。

参阅图14，图14是本申请提供的计算机存储介质一实施例的结构示意图，该计算机存储介质140用于存储计算机程序141，计算机程序141在被处理器执行时，用于实现如下方法步骤：

在客户端向服务端发送binder请求时，获取客户端在发送binder请求之前与服务端的通信次数；判断通信次数是否大于设定阈值；若是，将binder请求加入等待队列的末端；其中，客户端在进程间通信过程中优先响应等待队列的首端的binder请求。

可以理解的，上述图13和图14实施例中的计算机程序在被处理器执行时，所实现的方法步骤与上述移动终端及其进程间通信的限制方法的实施例类似，这里不再赘述。

本申请的实施例以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (12)

1.一种进程间通信的限制方法，其特征在于，包括：

在客户端向服务端发送binder请求时，获取所述客户端在发送所述binder请求之前与所述服务端的通信次数；

判断所述通信次数是否大于设定阈值；

若是，将所述binder请求加入等待队列的末端；其中，所述客户端在设定时间段后对所述等待队列中的binder请求进行响应。

2.根据权利要求1所述的进程间通信的限制方法，其特征在于，

所述在客户端向服务端发送binder请求时，获取所述客户端在发送所述binder请求之前与所述服务端的通信次数的步骤之前，包括：

在当前时间周期内，每当所述客户端向所述服务端发送binder请求时，累计通信次数；

所述，获取所述客户端在发送所述binder请求之前与所述服务端的通信次数的步骤，包括：

获取当前时间周期的累计通信次数；

所述判断所述通信次数是否大于设定阈值的步骤，包括：

判断所述累计通信次数是否大于设定阈值。

3.根据权利要求2所述的进程间通信的限制方法，其特征在于，

所述方法进一步包括：

在当前周期结束时，将所述累计通信次数清零；

在下一周期开始时，将所述等待队列中首端的binder请求作为所述客户端向所述服务端发送的binder请求，返回所述在当前时间周期内，每当所述客户端向所述服务端发送binder请求时，累计通信次数的步骤。

4.根据权利要求2所述的进程间通信的限制方法，其特征在于，

所述方法进一步包括：

在当前时间周期内，每当客户端向所述服务端发送binder请求时，对相应的客户端进行标记；

所述判断所述通信次数是否大于设定阈值的步骤，包括：

判断当前binder请求所对应的客户端的标记次数是否大于设定阈值。

5.根据权利要求1所述的进程间通信的限制方法，其特征在于，

所述判断所述通信次数是否大于设定阈值的步骤之后，还包括：

若否，所述服务端响应所述客户端发送的binder请求，进行所述客户端与所述服务端之间的进程间通信。

6.根据权利要求1所述的进程间通信的限制方法，其特征在于，

所述判断所述通信次数是否大于设定阈值的步骤之前，还包括：

判断所述服务端是否满足预设条件；

若是，执行所述判断所述通信次数是否大于设定阈值的步骤；

其中，所述预设条件为所述服务端的可用线程的数量小于设定阈值。

7.根据权利要求1所述的进程间通信的限制方法，其特征在于，

所述方法进一步包括：

在所述客户端向所述服务端发起通信请求时，记录第一时间点；

在所述服务端响应所述客户端发起的通信请求时，记录第二时间点；

基于所述第一时间点和所述第二时间点，获取服务等待时间；

保存所述服务等待时间，以便基于所述服务等待时间对所述服务端的通信进行监控。

8.根据权利要求7所述的进程间通信的限制方法，其特征在于，

所述方法进一步包括：

在所述客户端和所述服务端的进程间通信完成时，记录第三时间点；

基于所述第二时间点和所述第三时间点，获取通信服务时间；

保存所述通信服务时间，以便基于所述通信服务时间对所述服务端的通信进行监控。

9.根据权利要求8所述的进程间通信的限制方法，其特征在于，

所述方法进一步包括：

基于所述第一时间点和所述第三时间点，获取进程间通信总时间；

保存所述获取进程间通信总时间，以便基于所述获取进程间通信总时间对所述服务端的通信进行监控。

10.一种移动终端，其特征在于，包括：

获取模块，用于在客户端向服务端发送binder请求时，获取所述客户端在发送所述binder请求之前与所述服务端的通信次数；

判断模块，用于判断所述通信次数是否大于设定阈值；

等待模块，用于在所述判断模块的判断结果为是时，将所述binder请求加入等待队列的末端；其中，所述客户端在设定时间段后对所述等待队列中的binder请求进行响应。

11.一种移动终端，其特征在于，包括处理器和存储器，其中，所述存储器用于存储计算机程序，所述计算机程序在被所述处理器执行时，用于实现如权利要求1-9任一项所述的方法。

12.一种计算机存储介质，其特征在于，用于存储计算机程序，所述计算机程序在被处理器执行时，用于实现如权利要求1-9任一项所述的方法。