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

Abstract

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

Description

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

技术领域

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

背景技术

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

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

发明内容

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

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

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

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

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

附图说明

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

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

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

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

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

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

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

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

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

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

具体实施方式

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

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

步骤101：在客户端向服务端发送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通信。

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

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

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

可选地，可以在每当客户端向服务端发送binder请求时，将累计通信次数的数值加一，且在每当服务端接收到binder请求时，将累计总通信次数的数值加一。

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

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

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

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

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

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

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

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

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

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

步骤102：计算累计通信次数和累计总通信次数的第一比值，计算份额与总份额的第二比值。

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

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

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

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

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

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

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

如果第一比值超过第二比值，则说明该客户端若与服务端进行此次通信可能会对服务端产生较大的影响，那么电子装置会将截获的binder请求加入等待队列的末端，暂时不允许该客户端与服务端进行通信。

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

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

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

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

假设预先设定的客户端A对应的份额是10％，客户端B的份额是40％、客户端C的份额是50％。

1、客户端A向服务端发送通信请求1，此时该客户端A累计通信次数1次，若该服务端累计总通信次数2次，则第一比值为50％；假设当前除了客户端A之外还有客户端C正在与服务端通信，那么当前的第二比值＝(客户端A对应的份额10％)÷(客户端A对应的份额10％+客户端C的份额50％)＝16.6％，此时第一比值大于第二比值。那么通信请求1将会被加入当前的等待队列的末端。

2、客户端A向服务端发送通信请求2，此时该客户端A累计通信次数2次，若该服务端累计总通信次数为20次，则第一比值为10％；假设当前除了客户端A之外还有客户端B正在与服务端通信，那么当前的第二比值＝(客户端A对应的份额10％)÷(客户端A对应的份额10％+客户端B的份额40％)＝20％，此时第一比值小于第二比值。那么通信请求2将会被发送至服务端，以允许服务端对通信请求2做出响应，并与客户端A进行进程间通信。

在本实施例中，通过获取并计算客户端的累计通信次数与服务端的累计总通信次数的第一比值，获取并计算该客户端所占的份额和当前与该服务端通信的所有客户端所占的总份额的第二比值，来衡量是否会由于服务端过于繁忙导致系统卡顿或崩溃，并将该第一比值限制在实时变化的第二比值从而保证系统的流畅运行；通过该第一比值来衡量服务端的繁忙相较于单纯的根据客户端的累计通信次数来衡量更加客观准确，更能反映服务端的繁忙程度，并且由于第二比值是实时变化的量更能反映系统当时的实时情况，从而更加准确对第一比值进行限制，实现系统的有效优化。

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

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

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

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

步骤501：在当前时间周期内，每当客户端向服务端发送binder请求时，将累计通信次数的数值加一，且在每当服务端接收到binder请求时，将累计总通信次数的数值加一。

在本实施例中，将时间分割成多个时间周期，在每个时间周期内累计客户端的通信次数，以及累计服务端通信的总次数。每当时间周期结束时将累计的次数进行清零，并在下个时间周期重新计数。

每当客户端向服务端发送binder请求时，说明客户端与服务端通信一次，将累计通信次数加一。

每当服务端收到binder请求时，说明服务端通信一次，将累计总通信次数加一。值得注意的是服务端收到的binder请求可以是来自上述的客户端的或者其他客户端的，其累计的是服务端总的通信次数。

步骤502：当前时间周期内，在客户端向服务端发送binder请求时，截获该binder请求，并获取累计通信次数的数值和累计总通信次数的数值，以及获取该客户端所占的份额、当前与服务端通信的所有客户端所占的总份额。

在当前时间周期内，且在客户端向服务端发送binder请求的时间节点，获取当前的累计通信次数的数值和累计总通信次数的数值。在客户端向服务端发送binder请求时，截获该binder请求。关于截获binder请求的描述具体可以参见上文的描述此处不再赘述。

步骤503：计算累计通信次数和累计总通信次数的第一比值，且计算该份额与总份额的第二比值。

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

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

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

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

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

其中步骤503-506与第一实施例中的说明类似，具体参见上文的描述，此处不再赘述。

如图6所示，图6是客户端、服务端、等待队列的交互示意图。

在第N个时间周期内，客户端与服务端每进行一次通信，就将累计通信次数加一。

假设预先设定的客户端A的份额为10％，客户端B的份额为20％、客户端C的份额为30％，客户端D的份额为50％。

在客户端A向服务端发送通信请求1时，客户端A的累计通信次数为1，服务端的累计总通信次数为5，第一比值为20％。假设此时除了客户端A还有客户端B在与服务端通信，那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端B的份额20％)＝33.3％。此时，第一比值小于第二比值。

在客户端向服务端发送通信请求2时，客户端的累计通信次数为2，服务端的累计总通信次数为6，比值为33.3％。假设此时除了客户端A还有客户端C在与服务端通信。那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端C的份额30％)＝25％。此时，第一比值大于第二比值。

在客户端向服务端发送通信请求3时，客户端的累计通信次数为3，服务端的累计总通信次数为15，比值为20％。假设此时除了客户端A还有客户端B在与服务端通信，那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端B的份额20％)＝33.3％。此时，第一比值小于第二比值。

在客户端向服务端发送通信请求4时，客户端的累计通信次数为4，服务端的累计总通信次数为20，比值为20％。假设此时除了客户端A还有客户端B在与服务端通信，那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端B的份额20％)＝33.3％。此时，第一比值小于第二比值。

在客户端向服务端发送通信请求5时，客户端的累计通信次数为5，服务端的累计总通信次数为25，比值仍然为20％。假设此时除了客户端A还有客户端B在与服务端通信，那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端B的份额20％)＝33.3％。此时，第一比值小于第二比值。

在客户端向服务端发送通信请求6时，客户端的累计通信次数为6，服务端的累计总通信次数为26，比值为23.1％。假设此时除了客户端A还有客户端B在与服务端通信，那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端B的份额20％)＝33.3％。此时，第一比值小于第二比值。

在客户端向服务端发送通信请求7时，客户端的累计通次数为7，服务端的累计中通信次数为27，比值为25.9％。假设此时除了客户端A还有客户端D在与服务端通信，那么此时第二比值＝(客户端A的份额10％)÷(客户端A的份额10％+客户端D的份额50％)＝16.6％。此时，第一比值大于第二比值。

那么在第N个周期内，通信请求2和通信请求7会加入等待队列。通信请求1、通信请求3-6将会被发送至服务端，服务端会对通信请求1、通信请求3-6响应，以使服务端和客户端进行通信。

在第N个周期结束时，将累计通信次数和累计通信总次数清零。

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

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

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

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

步骤701：在客户端向服务端发送binder请求时，截获该binder请求，并获取当前客户端与服务端的累计通信次数、当前服务端的累计总通信次数，以及获取该客户端所占的份额、当前与服务端通信的所有客户端所占的总份额。

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

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

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

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

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

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

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

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

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

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

步骤703：计算累计通信次数和累计总通信次数的第一比值，且计算该份额与总份额的第二比值。

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

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

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

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

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

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

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

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

步骤801：在客户端向服务端发送binder请求时，截获该binder请求，并获取当前客户端与服务端的累计通信次数、当前服务端的累计总通信次数，以及获取该客户端所占的份额、当前与服务端通信的所有客户端所占的总份额。

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

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

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

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

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

步骤803：计算累计通信次数和累计总通信次数的第一比值，且计算该份额与总份额的第二比值。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

获取模块91，用于在客户端向服务端发送binder请求时，截获该binder请求，并获取当前客户端与服务端的累计通信次数、当前服务端的累计总通信次数，以及获取该客户端所占的份额、当前与服务端通信的所有客户端所占的总份额。

计算模块92，用于计算累计通信次数和累计总通信次数的第一比值，且计算该份额与总份额的第二比值。

判断模块93，用于判断第一比值是否大于第二比值。

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

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

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

在本实施例中，电子装置10包括处理器11和存储器12。

存储器12与处理器11电连接。

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

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

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

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

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

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

Claims (14)

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

在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端与所述服务端的累计通信次数、当前所述服务端的累计总通信次数，以及获取所述客户端所占的份额、当前与所述服务端通信的所有客户端所占的总份额；

计算所述累计通信次数和所述累计总通信次数的第一比值，且计算所述份额与所述总份额的第二比值；

判断所述第一比值是否大于第二比值；

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

2.根据权利要求1所述的方法，其特征在于，所述获取所述客户端所占的份额、当前与所述服务端通信的所有客户端所占的总份额包括：

根据所述客户端的标识信息在标识信息与份额的对应关系表中查找对应的份额以得到所述客户端的份额；

根据当前与所述服务端通信的所有客户端各自的标识信息在所述对应关系表中查找各自对应的份额并进行求和以得到所述总份额。

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

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

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

在设定时间段之后将所述等待队列中的binder请求作为客户端向服务端发送binder请求，返回所述在客户端向服务端发送binder请求时，截获所述binder请求并获取当前所述客户端与所述服务端的累计通信次数、当前所述服务端的累计总通信次数的步骤。

5.根据权利要求1所述的方法，其特征在于，所述在客户端向服务端发送binder请求时，截获所述binder请求并获取当前所述客户端与所述服务端的累计通信次数、当前所述服务端的累计通信次数之前包括：

在当前时间周期内，每当所述客户端向所述服务端发送binder请求时，将累计通信次数的数值加一，且在每当所述服务端接收到binder请求时，将累计总通信次数的数值加一；

所述在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端与所述服务端的累计通信次数、当前所述服务端的累计总通信次数的步骤，包括：

在当前时间周期内，且在所述客户端向所述服务端发送binder请求时，截获所述binder请求，并获取所述累计通信次数的数值和所述累计总通信次数的数值。

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

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

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

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

所述判断所述第一比值是否大于第二比值的步骤之后，所述方法还包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

获取模块，用于在客户端向服务端发送binder请求时，截获所述binder请求，并获取当前所述客户端与所述服务端的累计通信次数、当前所述服务端的累计总通信次数，以及获取所述客户端所占的份额、当前与所述服务端通信的所有客户端所占的总份额；

计算模块，计算所述累计通信次数和所述累计总通信次数的第一比值，且计算所述份额与所述总份额的第二比值；

判断模块，用于判断所述第一比值是否大于所述第二比值；

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

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

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

Images