CN109117280A - 电子装置及其限制进程间通信的方法、存储介质 - Google Patents

Abstract

本申请公开了一种限制进程间通信的方法，该方法包括：在客户端向服务端发送binder请求时，截获binder请求，并获取当前客户端消耗服务端的binder线程数量、服务端的binder线程总数量；计算binder线程数量与binder线程总数量的比值，并判断比值是否大于设定比值；若是，则将截获的binder请求加入等待队列末端；其中，在设定时间段之后处理等待队列中的binder请求。本申请还公开了一种电子装置和一种存储介质。通过上述方式，本申请能够将客户端消耗的binder线程数量与服务端总的binder线程数量的比值限定在设定比值，从而可以保证系统的流畅性。

Description

电子装置及其限制进程间通信的方法、存储介质

技术领域

本发明涉及电子设备技术领域，特别是涉及一种电子装置及其限制进程间通信的方法、存储介质。

背景技术

目前，随着科学技术的不断发展，智能手机等电子装置日渐成为人们日常生活的必需品。

安卓系统是智能手机等电子装置的一种常见的操作系统，安卓系统中的两个进程之间通常需要进行通信，进程之间的用户空间是不能共享的，因此两个进程之间的通信通常需要Binder机制来实现通信。现有的电子装置没有对进程间采用Binder机制进行通信情况的监控机制，且无法对进程间通信进程进行优化，导致系统流畅度不高。

发明内容

本申请实施例采用的一个技术方案是：提供一种限制进程间通信的方法，该方法包括：在客户端向服务端发送binder请求时，截获binder请求，并获取当前客户端消耗服务端的binder线程数量、服务端的binder线程总数量；计算binder线程数量与binder线程总数量的比值，并判断比值是否大于设定比值；若是，则将截获的binder请求加入等待队列末端；其中，在设定时间段之后处理等待队列中的binder请求。

本申请实施例采用的另一个技术方案是：提供一种电子装置，该电子装置包括：获取模块，用于在客户端向服务端发送binder请求时，截获binder请求，并获取当前客户端消耗服务端的binder线程数量、服务端的binder线程总数量；计算模块，用于计算binder线程数量与binder线程总数量的比值；判断模块，用于判断比值是否大于设定比值；执行模块，用于在比值大于设定比值时，将截获的binder请求加入等待队列末端；其中，在设定时间段之后处理等待队列中的binder请求。

本申请实施例采用的又一个技术方案是：提供一种电子装置，该电子装置包括处理器和存储器，存储器与处理器电连接，存储器用于存储计算机程序，处理器用于调用计算机程序以实现上述的方法。

本申请实施例采用的又一个技术方案是：一种存储介质，存储介质用于存储计算机程序，计算机程序能够被执行以实现上述的方法。

本申请实施例通过在客户端向服务端发送binder请求时，截获binder请求，并获取当前客户端消耗服务端的binder线程数量、服务端的binder线程总数量；计算binder线程数量与binder线程总数量的比值，并判断比值是否大于设定比值；若是，则将截获的binder请求加入等待队列末端；其中，在设定时间段之后处理等待队列中的binder请求，能够将客户端消耗服务端的binder线程数量与binder线程总数量限定在设定比值，从而可以保证系统的流畅性。

附图说明

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

图2是本申请实施例中进程间通信的原理示意图；

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

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

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

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

图7是本申请实施例电子装置的模块示意图；

图8是本申请实施例电子装置的硬件结构示意图。

具体实施方式

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

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

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

请参阅图1，图1是本申请第一实施例限制进程间通信的方法的流程示意图。

在本实施例中，限制进程间通信的方法可以包括以下步骤：

步骤101：在客户端向服务端发送binder请求时，截获该binder请求，并获取当前该客户端消耗该服务端的binder线程数量、该服务端的binder线程总数量。

其中，Binder机制是安卓系统中进程间通讯(IPC)的一种方式。安卓系统中的四大组件分别为：Activity(工作流)、Service(服务)、Broadcast(广播接收器)、ContentProvider(内容提供者)、不同的App(应用程序)。这四大组件都运行在不同的进程中，Binder机制是这些进程间通讯的桥梁。

如图2所示，图2是本申请实施例中进程间通信的原理示意图，每个安卓系统的进程，只能运行在自己进程所拥有的虚拟地址空间。虚拟地址空间包括彼此独立的用户空间和内核空间。对于用户空间，客户端和服务端之间彼此是不能共享的，而客户端和服务端之间的内核空间却是可共享的。客户端与服务端的每一次通信都要通过位于内核空间的Binder驱动程序来实现。

基于上述binder机制的原理，不难理解，客户端和服务端可以是任意两个进程，可以是应用，也可以是服务，例如，可以是应用与应用之间的通信，也可以是应用与服务之间的通信。其中，客户端是指客户端进程，服务端是指服务端进程。

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

其中，Client进程为使用服务的进程。

Server进程为提供服务的进程。

Service Manager进程的作用是将字符形式的Binder名字转化成Client中对该Binder的引用，使得Client能够通过Binder名字获得对Server中Binder实体的引用。

Binder驱动程序负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。

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

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

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

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

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

在电子装置中，多个应用可能同时获取同一服务，所以，一个服务端可能与多个客户端之间进行进程间通信，在这种情况下，由于服务端的通信次数多、线程使用量较大、通信过于频繁，会造成系统的卡顿。本实施例主要是通过获取一客户端消耗一服务端的binder线程数量和该服务端的线程总数量，然后计算前者与后者的比值，通过该比值来衡量该客户端对服务端的繁忙程度所造成的影响，从而对该客户端进程限制，保证系统的流畅运行。

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

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

其中，经过上述的过程才算是一个完成的通信过程。在上述过程中服务端在响应binder请求时，具体是通过服务端的binder线程来对其进行响应。因此，每当服务端响应客户端的binder请求时就会有一个binder线程被唤醒，在一次通信完成后，该binder线程又恢复至空闲状态。

因此，在步骤101之前，可以对客户端对服务端的binder线程的消耗情况进行实时监控。

具体地，可以在服务端的binder线程被唤醒时，将唤醒binder线程的客户端消耗服务端的binder线程数量加一。

在binder线程恢复空闲状态时，将唤醒binder线程的客户端消耗服务端的binder线程数量减一。

在步骤101中获取当前该客户端消耗该服务端的binder线程数量时，读取客户端消耗服务端的binder线程数量的数值即可。

其中，该服务端的binder线程总数量，可以是服务端当前可用的binder线程总数量，即服务端当前处于空闲状态的binder线程数量，其为实时变化的值。

在其他实施例中，该服务端的binder线程总数量也可以是服务端的最大binder线程总数量。例如，每一服务端的对应的最大binder线程数量通常是固定值，通常可以为32个或者16个。

可以理解的，由于记录了客户端消耗服务端的binder线程数量和服务端的线程总数量，在客户端向服务端发送binder请求时，获取此时的客户端消耗服务端的binder线程数量和服务端的线程总数量的数值，然后进行后续的计算和判断。

在客户端向服务端发送binder请求时，截获binder请求，截获是指拦截并获取，客户端发送的binder请求暂时不会到达服务端，先保存下来，通过后续的计算和判断之后决定是否将截获的binder请求发送至服务端。

步骤102：计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的比值，并判断比值是否大于设定比值。

其中，设定比值可以是根据以往记录的相关数据进行设置的。例如，在系统出现卡顿时(例如，CPU占用率较高、内存占用率较高、系统总负载较大时)，记录此时客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的比值，获取一段时间内记录的比值的平均值并作为设定比值进行保存。

可选地，比值以百分比的形成呈现。

若步骤102的判断结果为是，则执行步骤103。

若步骤102的判断结果为否，则执行步骤104。

步骤103：将截获的binder请求加入等待队列末端；其中，在设定时间段后处理等待队列中的binder请求。

在步骤103中，将步骤101中截获的binder请求加入等待队列末端。

其中，在设定时间段后处理等待队列中的binder请求具体可以为：在设定时间段后将等待队列中的binder请求发送至服务端，以允许服务端对等待队列中的binder请求进行响应并与客户端进行进程间通信。

等待(pending)队列中的binder请求并不会立即被服务端响应，而是在设定时间段之后再将等待队列中的binder请求发送至服务端，相当于建立了一个缓冲的机制，会在设定时间段之后或者服务端不繁忙的时候允许服务端对binder请求做出响应，并进行服务端与客户端之间的进程间通信。

或者，在另一种实施方式中，在设定时间段后处理等待队列中的binder请求具体可以为：在设定时间段之后将等待队列中的binder请求作为客户端向服务端发送binder请求，返回步骤101，即返回在客户端向服务端发送binder请求时，截获binder请求，并获取当前该客户端消耗该服务端的binder线程数量、该服务端的binder线程总数量的步骤，重新获取并计算比值，然后判断比值与设定比值的大小关系，根据判断结果决定是否响应binder请求或者保留在等待队列中。

步骤104：将截获的binder请求发送至服务端，以允许服务端响应客户端发送的binder请求并与客户端进行进程间通信。

如果客户端消耗的binder线程数量占服务端的总binder线程数量的比值小于设定比值，那么说明不会影响服务端的繁忙程度，服务端响应客户端发送binder请求，进行客户端与服务端之间的正常通信即可。

下面通过一个具体的实例进行说明。

1、客户端A的第一进程、第二进程、第三进程正在与服务端进行binder通信，当客户端A的第四进程此时向服务端发送binder请求时，客户端A消耗的该服务端的binder线程为3个，假设此时服务端的可用的binder线程总数量为5个，那么比值为60％，若设定的比值是50％，此时第四进程此时向服务端发送binder请求将会被加入到等待队列中。

2、客户端A的第一进程正在与服务端进程通信，当客户端A的第二进程此时向服务端发送binder请求时，客户端A消耗的该服务端的线程数量为1个，假设此时服务端可用的线程总数量为5个，那么比值为20％，若设定的比值是50％，此时该binder请求将会被继续发送至服务端，以允许服务端对该binder请求作出响应，并进行与客户端A的进程间通信。

在本实施例中，通过获取并计算客户端消耗服务端的binder线程数量与服务端的binder线程总数量的比值，来衡量是否会由于服务端过于繁忙导致系统卡顿或崩溃，并将该比值限制在设定比值从而保证系统的流畅运行；通过该比值来衡量服务端的繁忙相较于单纯的根据客户端消耗服务端的binder线程数量来衡量更加客观准确，更能反映服务端的繁忙程度。

监控客户端已使用的binder线程是否进入空闲状态。若是，则利用进入空闲状态的binder线程处理等待队列中客户端发送的binder请求。

其中，在每次该客户端与服务端通信完成后，该客户端已经使用的binder线程会从唤醒状态重新恢复至空闲状态。监控该客户端使用过的binder线程恢复空闲状态的状态变化，在监控到这种状态变化时，利用该binder线程来处理等待队列中由该客户端发送的binder请求。

通过上述方式，可以在系统空闲时，迅速的处理加入等待队列中的binder请求，提升系统的流畅性，进一步地，处理该客户端通信的binder线程进入空闲状态时，优先找到等待队列中相同客户端发送的binder请求，能够进一步提高处理binder请求的效率，提升系统流畅性。

如图5所示，图5是本申请第二实施例限制进程间通信的方法的流程示意图。

在本实施例中，限制进程间通信的方法可以包括以下步骤：

步骤501：在客户端向服务端发送binder请求时，截获该binder请求，并获取当前该客户端消耗该服务端的binder线程数量、该服务端的binder线程总数量。

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

若在步骤502中判断结果为是，即服务端满足预设条件，则执行步骤503。

若在步骤502中判断结果为否，即服务端不满足预设条件，则执行步骤505。

可选地，预设条件包括服务端的可用线程的数量小于设定线程数量、服务端的重要级别大于预设级别中的至少一者。

可以理解的，两个进程之间的通信一般会使用到多个线程。例如，Android系统规定System Server进程最多可以创建32个Binder线程用于进程间数据通信；SurfaceFlinger进程最多可以创建4个Binder线程用于进程间数据通信；程序应用进程最多可以创建8个Binder线程用于进程间数据通信。

因此，可以在服务端的线程使用数量满足要求的时候再进行后续的计算和判断，例如，一个服务端共有32个线程，其中16个线程被使用，可用线程剩余16个，即当被使用线程大于一半的时候开始后续的判断。

每个进程都有相应的优先级，优先级决定它何时运行和接收多少CPU时间，服务端作为一种进程也不例外。

例如，优先级共32级，是从0到31的数值，称为基本优先级别(Base PriorityLevel)。系统按照不同的优先级调度进程的运行，0-15级是普通优先级，进程的优先级可以动态变化，高优先级进程优先运行，只有高优先级进程不运行时，才调度低优先级进程运行，优先级相同的进程按照时间片轮流运行。16-31级是实时优先级，实时优先级与普通优先级的最大区别在于相同优先级进程的运行不按照时间片轮转，而是先运行的进程就先控制CPU，如果它不主动放弃控制，同级或低优先级的进程就无法运行。

服务端的重要级别可以是指其在系统中的优先级别，在其他实施例中，服务端的重要级别也可以是预先设定的重要级别。

由于越重要的服务端往往对系统的流畅性影响越大，在服务端的重要级别大于设定级别时，才进行后续的计算和判断，一方面可以有效的限制客户端与重要的服务端进行通信，来提升系统的流畅性，另一方面，不用对所有的服务端都进行监控可以减少不必要的流程。

步骤503：计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的比值，并判断比值是否大于设定比值。

若在步骤503中判断结果为是，则执行步骤504。

若在步骤504中判断结果为否，则执行步骤505。

步骤504：将截获的binder请求加入等待队列末端；其中，在设定时间段后处理等待队列中的binder请求。

步骤505：将截获的binder请求发送至服务端，以允许服务端响应客户端发送的binder请求并与客户端进行进程间通信。

步骤503-505的说明具体可以参见上文的描述，此处不再赘述。

如图6所示，图6是本申请第三实施例限制进程间通信的方法的流程示意图。

在本实施例中，限制进程间通信的方法可以包括以下步骤：

步骤601：在客户端向服务端发送binder请求时，截获该binder请求，并获取当前该客户端消耗该服务端的binder线程数量、该服务端的binder线程总数量。

步骤602：判断当前系统的使用情况是否符合预设情况。

若在步骤602中判断结果为是，即当前系统的使用情况符合预设情况，则执行步骤603。

若在步骤602中判断结果为否，即当前系统的使用情况不符合预设情况，则执行步骤605。

预设情况可以是当前系统的运行状态繁忙的情况，可选地，预设情况可以包括：当前系统正在运行的进程数大于设定进程数、当前系统正在运行的线程数大于设定线程数、当前系统总负载大于设定负载中的至少一者。可以理解的是预设情况还可以包括其他可以反映系统当前运行的繁忙程度较大的情况，例如，当前系统的CPU占用率大于设定值、当前系统的内存占用率大于设定值等等。

通过上述方式，可以仅在当前系统运行较繁忙时，才进行后续的计算和判断，一方面可以在系统繁忙时有效的限定客户端消耗的binder线程数量与服务端binder线程总数量的比值，来提升系统的流畅性，另一方面，在系统比较空闲时可以不进行限制，减少不必要的流程。

步骤603：计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的比值，并判断比值是否大于设定比值。

若在步骤603中判断结果为是，则执行步骤604。

若在步骤604中判断结果为否，则执行步骤605。

步骤604：将截获的binder请求加入等待队列末端；其中，在设定时间段后处理等待队列中的binder请求。

步骤605：将截获的binder请求发送至服务端，以允许服务端响应客户端发送的binder请求并与客户端进行进程间通信。

步骤603-605的说明具体可以参见上文的描述，此处不再赘述。

可选地，在上述任意一实施例的基础之上，增加监控并记录通信的时间节点的流程，具体而言，可以进一步增加以下步骤：

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

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

根据第一时间点和第二时间点，获取服务等待时间。

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

保存服务等待时间，以便基于服务等待时间对后续的操作系统的优化和验证提供数据支持。

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

根据第一时间点和第三时间点，获取进程间通信总时间。

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

保存获取的进程间通信总时间，对后续的操作系统的优化和验证提供数据支持。

其从三个不同的方面获取到通信的时长，其中包括服务等待时长、通信服务时长和总时长。

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

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

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

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

另外，在对上述的通信次数、服务等待时长、通信服务时长和进程间通信总时长进行统计和监控时，可以根据通信次数、服务等待时长、通信服务时长和进程间通信总时长生成直方图。

上述的通信次数、服务等待时长、通信服务时长、进程间通信总时长以及直方图可以进一步上传至服务器，以便于开发人员基于这些数据对操作系统进行优化和验证。

可选地，在上述任意一实施例的基础之上，增加监控并记录瞬时binder线程数量的流程，具体而言，可以进一步增加以下步骤：

在服务端的binder线程被唤醒时，记录该服务端的标识信息，该客户端的标识信息，将客户端消耗服务端的binder线程数量的数值加一；

在该binder线程进入空闲状态时，将客户端消耗服务端的binder线程数量的数值减一；

将客户端消耗服务端的binder线程数量的数值、客户端的标识信息、服务端的标识信息对应关联形成对应关系表，以便于在客户端向服务端发送binder请求时，可以通过客户端和服务端的标识信息在对应关系表中查找出对应的客户端消耗服务端的binder线程数量的实时值。

请参阅图7，图7是本申请实施例电子装置的模块示意图。

在本实施例中，电子装置70可以包括以下模块：

获取模块71，用于在客户端向服务端发送binder请求时，截获该binder请求，并获取当前该客户端消耗该服务端的binder线程数量、该服务端的binder线程总数量。

计算模块72，用于计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的比值。

判断模块73，用于判断比值是否大于设定比值。

执行模块74，用于在比值大于设定比值时，将截获的binder请求加入等待队列末端；其中，在设定时间段后处理等待队列中的binder请求。

上述各个模块执行的步骤的具体内容可以参见上文的描述，此处不再赘述。

请参阅图8，图8是本申请实施例电子装置的硬件结构示意图。

在本实施例中，电子装置80包括处理器81和存储器82。

存储器82与处理器81电连接。

存储器82用于存储计算机程序，处理器81用于执行该计算机程序以实现上述任意一实施例的方法。

本发明实施例还提供一种计算机可读的存储介质，该计算机可读的存储介质用于存储计算机程序，该计算机程序能够被处理器执行以实现上述实施例中提供的方法。可以理解的，在本实施例中的可读存储介质存储的计算机程序，所用来执行的方法与上述实施例提供的方法类似，其原理和步骤相同，这里不再赘述。

其中，该存储介质可以为U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本发明上述任意一实施中的电子装置可以为智能手机、可穿戴式智能设备、平板电脑、掌上电脑、数字PDA或者其他电子装置。

本申请实施例通过在客户端向服务端发送binder请求时，截获binder请求，并获取当前客户端消耗服务端的binder线程数量、服务端的binder线程总数量；计算binder线程数量与binder线程总数量的比值，并判断比值是否大于设定比值；若是，则将截获的binder请求加入等待队列末端；其中，在设定时间段之后处理等待队列中的binder请求，能够将客户端消耗服务端的binder线程数量与binder线程总数量限定在设定比值，从而可以保证系统的流畅性。

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

Claims (13)

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

在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端消耗所述服务端的binder线程数量、所述服务端的binder线程总数量；

计算所述binder线程数量与所述binder线程总数量的比值，并判断所述比值是否大于设定比值；

若是，则将截获的所述binder请求加入等待队列末端；其中，在设定时间段之后处理所述等待队列中的binder请求。

2.根据权利要求1所述的方法，其特征在于，所述在设定时间段之后处理所述等待队列中的binder请求的步骤，包括：

在设定时间段后将所述等待队列中的binder请求发送至所述服务端，以允许所述服务端对所述等待队列中的binder请求进行响应并与所述客户端进行进程间通信。

3.根据权利要求1所述的方法，其特征在于，所述在设定时间段之后处理所述等待队列中的binder请求的步骤，包括：

在设定时间段之后将所述等待队列首端的binder请求作为客户端向服务端发送binder请求，返回在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端消耗所述服务端的binder线程数量、所述服务端的binder线程总数量的步骤。

4.根据权利要求1所述的方法，其特征在于，所述在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端消耗的binder线程数量、所述服务端的binder线程总数量的步骤之前，包括：

在所述服务端的binder线程被唤醒时，将唤醒所述binder线程的客户端消耗所述服务端的binder线程数量加一；

在所述binder线程恢复空闲状态时，将唤醒所述binder线程的客户端消耗所述服务端的binder线程数量减一。

5.根据权利要求1所述的方法，其特征在于，所述判断所述比值是否大于设定比值的步骤之后，还包括：

若否，则将截获的所述binder请求发送至所述服务端，以允许所述服务端响应所述客户端发送的binder请求并与所述客户端进行进程间通信。

6.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

监控所述客户端已使用的binder线程是否进入空闲状态；

若是，则利用进入空闲状态的binder线程处理所述等待队列中所述客户端发送的binder请求。

7.根据权利要求1所述的方法，其特征在于，

在所述判断所述比值是否大于设定比值的步骤之前，还包括：

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

若所述服务端满足所述预设条件，则执行所述判断所述比值是否大于设定比值的步骤；

若所述服务端不满足所述预设条件，则将截获的所述binder请求发送至所述服务端，以允许所述服务端响应所述客户端发送的binder请求并与所述客户端进行进程间通信。

8.根据权利要求7所述的方法，其特征在于，所述预设条件包括所述服务端的可用线程的数量小于设定线程数量、所述服务端的重要级别大于预设级别中的至少一者。

9.根据权利要求1所述的方法，其特征在于，

在所述判断所述比值是否大于设定比值的步骤之前，还包括：

判断当前系统的使用情况是否符合预设情况；

若当前系统的使用情况符合预设情况，则执行所述判断所述比值是否大于设定比值的步骤；

若当前系统的使用情况不符合预设情况，则将截获的所述binder请求发送至所述服务端，以允许所述服务端响应所述客户端发送的binder请求并与所述客户端进行进程间通信。

10.根据权利要求9所述的方法，其特征在于，所述预设情况包括：当前系统正在运行的进程数大于设定进程数、当前系统正在运行的线程数大于设定线程数、当前系统总负载大于设定负载中的至少一者。

11.一种电子装置，其特征在于，所述电子装置包括：

获取模块，用于在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端消耗所述服务端的binder线程数量、所述服务端的binder线程总数量；

计算模块，用于计算所述binder线程数量与所述binder线程总数量的比值；

判断模块，用于判断所述比值是否大于设定比值；

执行模块，用于在所述比值大于所述设定比值时，将所述binder请求加入等待队列末端；其中，在设定时间段之后处理所述等待队列中的binder请求。

12.一种电子装置，其特征在于，所述电子装置包括处理器和存储器，所述存储器与所述处理器电连接，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序以实现权利要求1-10任意一项所述的方法。

13.一种存储介质，其特征在于，所述存储介质存储有计算机程序，该计算机程序能够被执行以实现权利要求1-10任意一项所述的方法。