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

Abstract

本申请公开了一种移动终端及其进程间通信的限制方法、存储介质，该进程间通信的限制方法包括：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断通信总次数是否增大；若是，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。通过上述方式，能够减小客户端或服务端的繁忙程度，保证系统的流畅性。

Description

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

技术领域

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

背景技术

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

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

发明内容

本申请采用的一个技术方案是：提供一种进程间通信的限制方法，该限制方法包括：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断通信总次数是否增大；若是，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括：获取模块，用于在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断模块，用于判断通信总次数是否增大；控制模块，用于在判断模块的判断结果为是时，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

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

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

本申请提供的进程间通信的限制方法包括：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断通信总次数是否增大；若是，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。通过上述方式，能够基于一段时间内的通信次数动态的调整客户端与服务端之间的通信频率，避免客户端与服务端之间的通信次数过多引起的系统繁忙，保证了系统的流畅性。

附图说明

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

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

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

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

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

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

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

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

图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驱动和Service Manager可以看做是Android平台的基础架构，而Client和Server是Android的应用层，开发人员只需自定义实现client、Server端，借助Android的基本平台架构便可以直接进行IPC通信。

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

另外，在智能终端中，多个应用可能同时获取同一服务，同一应用也可能同时获取多个不同的服务，所以，一个服务端可能同时与多个客户端之间进行binder通信，一个客户端也可能同时与多个服务端之间进行binder通信，在这种情况下，由于客户端或服务端的binder通信次数多，会造成系统的卡顿。

具体地，如图4所示，图4是客户端和服务端的交互示意图，在客户端与服务端的通信过程中，主要包括三个过程，客户端向服务端发起通信请求、服务端响应客户端发起的通信请求、客户端和服务端之间进行数据交互。

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

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

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

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

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

步骤12：判断通信总次数是否增大。

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

可选的，在一实施例中，步骤12具体为：判断设定时间周期内的通信总次数是否大于上一周期的通信总次数。

可以理解的，在步骤11中获取的通信总次数是设定时间周期内的，因此，可以周期性的获取服务端与客户端之间的通信次数。其中，一个时间周期的长短可以是默认是，也可以根据用户的需求进行设定，例如，一个时间周期可以是1分钟、10分钟等。

如下表所示：

时间周期	0-1min	1min-2min	2min-3min
				通信次数	10	12	8

例如，第一时间周期的通信次数为10次，第二时间周期的通信次数为12次，第三时间周期的通信次数为8次。假设当前的时间周期为第二时间周期，那么与第一时间周期相比，通信次数就增加了。

可选的，在一实施例中，可以设定一个阈值，当第二周期的通信次数大于第一周期的通信次数，且两者之间的次数差值大于或等于该阈值时，才认定为通信总次数增大。例如，可以设定该阈值为5，那么，第二时间周期的通信总次数需要达到15次，才能满足15-10≥5的要求，才能认定第二时间周期的通信总次数相比于第一时间周期增大了。通过这样的方式，可以在不同时间周期的通信次数变化较小时，不对通信频率进行调整。

步骤13：减小binder通信的最大通信频率。

其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

可选的，在本实施例中，通信频率是单位时间内，所有客户端与所有服务端之间的通信次数。

例如，在一实施例中，默认的最大通信频率为100次/min，那么，减小binder通信的最大通信频率，可以按照设定的规则来进行减小。

在一实施例中，可以根据通信次数增加的幅度相应的调整最大通信频率的减小幅度，例如，可以根据百分比相应调整。例如，若通信总次数增加10％，那么相应的可以将binder通信的最大通信频率减小10％。

在另一实施例中，可以预先设置通信总次数与最大通信频率的对应关系，以进行相应的调整。如下表所示：

通信总次数	10-20	20-30	30-40
				最大通信频率	10次/min	8次/min	6次/min

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

其中，在减小频率的时候，若单位时间内的通信次数达到最大值了，就可以将新的通信请求加入等待队列。例如，最大通信频率为10/min，那么，当前周期(1min)内的通信次数达到10次后，若再有客户端向服务端发送binder请求，那么，就将该binder请求加入等待队列，等到下一周期的时候再对等待队列中的binder请求进行响应。

本实施例提供的进程间通信的限制方法包括：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断通信总次数是否增大；若是，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。通过上述方式，能够基于一段时间内的通信次数动态的调整客户端与服务端之间的通信频率，避免客户端与服务端之间的通信次数过多引起的系统繁忙，保证了系统的流畅性。

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

步骤51：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数。

步骤52：判断通信总次数是否减小。

在步骤52的判断结果为是时，执行步骤53。

可选的，在一实施例中，步骤12具体为：判断设定时间周期内的通信总次数是否小于上一周期的通信总次数。

可以理解的，在步骤51中获取的通信总次数是设定时间周期内的，因此，可以周期性的获取服务端与客户端之间的通信次数。其中，一个时间周期的长短可以是默认是，也可以根据用户的需求进行设定，例如，一个时间周期可以是1分钟、10分钟等。

如下表所示：

时间周期	0-1min	1min-2min	2min-3min
				通信次数	10	12	8

例如，第一时间周期的通信次数为10次，第二时间周期的通信次数为12次，第三时间周期的通信次数为8次。假设当前的时间周期为第三时间周期，那么与第二时间周期相比，通信次数就减少了。

可选的，在一实施例中，可以设定一个阈值，当第三周期的通信次数小于第二周期的通信次数，且两者之间的次数差值大于或等于该阈值时，才认定为通信总次数增大。例如，可以设定该阈值为5，那么，第三时间周期的通信总次数需要达到7次，才能满足12-7≥5的要求，才能认定第三时间周期的通信总次数相比于第二时间周期减小了。通过这样的方式，可以在不同时间周期的通信次数变化较小时，不对通信频率进行调整。

步骤53：增大binder通信的最大通信频率。

其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

可选的，在本实施例中，通信频率是单位时间内，所有客户端与所有服务端之间的通信次数。

例如，在一实施例中，默认的最大通信频率为100次/min，那么，减小binder通信的最大通信频率，可以按照设定的规则来进行增大。

在一实施例中，可以根据通信次数减小的幅度相应的调整最大通信频率的增大幅度，例如，可以根据百分比相应调整。例如，若通信总次数减小10％，那么相应的可以将binder通信的最大通信频率增大10％。

可以理解的，可以将上述第一、第二实施例进行合并，例如，将步骤12和步骤52合并，形成下面的步骤：判断通信总次数是增大还是减小，在增大时，执行步骤13，在减小时，执行步骤53。这样就可以根据通信总次数动态的调整的binder通信的最大通信频率。

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

步骤61：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数。

步骤62：判断通信总次数是否增大。

在步骤62的判断结果为是时，进行步骤63。

步骤63：获取设定时间周期内，至少一个客户端中通信次数最高的目标客户端。

可选的，在客户端与服务端进行通信时，分别单独对每个客户端进行累计，例如，可以对不同的客户端进行标记。例如客户端A进行第一次通信，标记为A+1，客户端A进行第二次通信，标记A+2。这样，可以从多个客户端中获取在设定时间周期内，通信次数最高的客户端。

步骤64：减小目标客户端与至少一个服务端之间的通信频率。

由于目标客户端的通信次数最高，这样可以针对性的减小通信繁忙的客户端的通信频率，而保证通信次数较少的客户端的正常通信。

可选的，在另一实施例中，上述的目标客户端为在后台运行的客户端，这样可以保证前天客户端的正常运行。

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

步骤71：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数。

步骤72：判断通信总次数是否增大。

在步骤72的判断结果为是时，进行步骤73。

步骤73：获取设定时间周期内，至少一个服务端中通信次数最高的目标服务端。

可选的，在客户端与服务端进行通信时，分别单独对每个服务端进行累计，例如，可以对不同的服务端进行标记。例如服务端B进行第一次通信，标记为B+1，服务端B进行第二次通信，标记B+2。这样，可以从多个服务端中获取在设定时间周期内，通信次数最高的服务端。

步骤74：减小目标服务端与至少一个客户端之间的通信频率。

由于目标服务端的通信次数最高，这样可以针对性的减小通信繁忙的服务端的通信频率，而保证通信次数较少的服务端的正常通信。

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

步骤81：在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数。

步骤82：判断通信总次数是否增大。

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

步骤83：获取设定时间周期内，至少一个服务端中通信次数最高的目标服务端以及至少一个客户端中通信次数最高的目标客户端。

可选的，在客户端与服务端进行通信时，分别单独对每个服务端和每个客户端进行累计，例如，可以对不同的客户端进行标记。例如客户端A进行第一次通信，标记为A+1，客户端A进行第二次通信，标记A+2。这样，可以从多个客户端中获取在设定时间周期内，通信次数最高的客户端。可以对不同的服务端进行标记。例如服务端B进行第一次通信，标记为B+1，服务端B进行第二次通信，标记B+2。这样，可以从多个服务端中获取在设定时间周期内，通信次数最高的服务端。

步骤84：减小目标服务端与目标客户端之间的通信频率。

由于目标客户端和目标服务端的通信次数最高，这样可以针对性的减小通信繁忙的客户端和服务端的通信频率，而保证通信次数较少的客户端和服务端的正常通信。

参阅图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通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

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

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

在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断通信总次数是否增大；若是，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

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

在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；判断通信总次数是否增大；若是，减小binder通信的最大通信频率；其中，最大通信频率是单位时间内至少一个服务端与至少一个客户端之间允许进行的最大通信次数。

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

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

Claims (13)

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

在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；

判断所述通信总次数是否增大；

若是，减小binder通信的最大通信频率；其中，所述最大通信频率是单位时间内所述至少一个服务端与所述至少一个客户端之间允许进行的最大通信次数。

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

所述方法还包括：

判断所述通信总次数是否减小；

若是，增大binder通信的最大通信频率。

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

所述判断所述通信总次数是否增大的步骤，具体为：

判断所述设定时间周期内的通信总次数是否大于上一周期的通信总次数；

所述判断所述通信总次数是否减小的步骤，具体为：

判断所述设定时间周期内的通信总次数是否小于上一周期的通信总次数。

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

所述减小binder通信的最大通信频率的步骤，包括：

获取所述设定时间周期内，所述至少一个客户端中通信次数最高的目标客户端；

减小所述目标客户端与所述至少一个服务端之间的通信频率。

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

所述目标客户端为在后台运行的客户端。

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

所述减小binder通信的最大通信频率的步骤，包括：

获取所述设定时间周期内，所述至少一个服务端中通信次数最高的目标服务端；

减小所述目标服务端与所述至少一个客户端之间的通信频率。

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

所述减小binder通信的最大通信频率的步骤，包括：

获取所述设定时间周期内，所述至少一个服务端中通信次数最高的目标服务端以及所述所述至少一个客户端中通信次数最高的目标客户端；

减小所述目标服务端与所述目标客户端之间的通信频率。

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

所述限制方法进一步包括：

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

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

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

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

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

所述限制方法进一步包括：

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

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

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

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

所述限制方法进一步包括：

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

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

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

获取模块，用于在至少一个服务端与至少一个客户端基于binder机制进行binder通信的过程中，获取设定时间周期内的通信总次数；

判断模块，用于判断所述通信总次数是否增大；

控制模块，用于在判断模块的判断结果为是时，减小binder通信的最大通信频率；其中，所述最大通信频率是单位时间内所述至少一个服务端与所述至少一个客户端之间允许进行的最大通信次数。

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

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