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

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

背景技术：

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

安卓系统是智能手机等电子装置的一种常见的操作系统，安卓系统中的两个进程之间通常需要进行通信，进程之间的用户空间是不能共享的，因此两个进程之间的通信通常需要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进程(服务端)、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、servicemanager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与binder驱动程序进行交互的，从而实现ipc通信方式。其中binder驱动程序位于内核空间，client、server、servicemanager位于用户空间。binder驱动和servicemanager可以看做是安卓平台的基础架构，而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请求发送至服务端。

预先可以为各个客户端分配对应的份额，每一客户端有对应的标识信息，该标识信息用于区分不同的客户端，因此可以预先将不同的客户端对应的份额保存至标识信息与份额的对应关系表中。

在获取该客户端所占的份额时，先获取该客户端的标识信息，然后根据标识信息在该对应关系表中查找到对应的份额即可。其中，该客户端是指当前正在向服务端发送binder请求的客户端。

类似地，在获取当前与服务端通信的所有客户端所占的总份额时，先获取当前与服务端通信的所有客户端的标识信息，再根据当前与服务端通信的所有客户端各自的标识信息在对应关系表中查找各自对应的份额并进行求和以得到总份额即可。其中，当前与服务端通信的所有客户端包括上述的“该客户端”。

客户端的份额大小可以表征其获取服务端资源的权重大小，份额越大代表该客户端获取服务端资源的权利越大。

步骤102：计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的比值，且计算份额与总份额的第二比值。

步骤103：判断第一比值是否大于第二比值。

可以理解的是，在不同时间点，哪些客户端在与服务端通信具有实时性，即与服务端通信的所有客户端的数量和标识信息是变化的，因此与服务端通信的所有客户端所占的总份额也是变化的，那么该客户端的份额与总份额的第二比值也是实时变化的，即第二比值是动态变化的。第二比值相当于一个动态变化的阈值。

可选地，第一比值和第二比值均可以以百分比的形成呈现。

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

若步骤103的判断结果为否，则执行步骤105。

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

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

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

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

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

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

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

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

假设预先设定的客户端a对应的份额是10％，客户端b的份额是40％、客户端c的份额是30％、客户端d的份额是30％。

1、客户端a的第一进程、第二进程、第三进程正在与服务端进行binder通信，当客户端a的第四进程此时向服务端发送binder请求时，客户端a消耗的该服务端的binder线程为3个，假设此时服务端的可用的binder线程总数量为5个，那么第一比值为60％；假设除了客户端a之外客户端b也在与服务端通信，那么第二比值＝(客户端a对应的份额10％)÷(客户端a对应的份额10％+客户端b对应的份额40％)＝20％，即第一比值大于第二比值，第四进程此时向服务端发送binder请求将会被加入到等待队列中。

2、客户端a的第一进程正在与服务端进程通信，当客户端a的第二进程此时向服务端发送binder请求时，客户端a消耗的该服务端的线程数量为1个，假设此时服务端可用的线程总数量为6个，那么第一比值为16.6％；假设除了客户端a之外客户端c也在与服务端通信，那么第二比值＝(客户端a对应的份额10％)÷(客户端a对应的份额10％+客户端c对应的份额30％)＝25％，即第一比值小于第二比值，此时该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中判断结果为否，即服务端不满足预设条件，则执行步骤506。

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

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

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

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

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

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

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

步骤503：计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的第一比值，且计算份额与总份额的第二比值。

步骤504：判断第一比值是否大于第二比值。

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

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

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

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

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

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

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

步骤601：在客户端向服务端发送binder请求时，截获该binder请求，并获取当前该客户端消耗该服务端的binder线程数量、该服务端的binder线程总数量，以及获取该客户端所占的份额、当前与服务端通信的所有客户端所占的总份额。

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

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

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

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

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

步骤603：计算该客户端消耗该服务端的binder线程数量与该服务端的binder线程总数量的第一比值，且计算份额与总份额的第二比值。

步骤604：判断第一比值是否大于第二比值。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如，服务等待时长的平均值就是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-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

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

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