CN109144745B - 进程间通信的监控方法、电子装置以及可读存储介质 - Google Patents

Abstract

本申请公开了一种进程间通信的监控方法，该监控方法包括：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数；判断累计总通信次数是否大于预设总通信次数阈值；若是，则将当前服务端在系统中的第一优先级别调整为第二优先级别，其中，第二优先级别高于第一优先级别。本申请还公开了一种电子装置和一种可读存储介质。通过上述方式，本申请避免服务端过于繁忙导致的系统卡顿或者崩溃，能够提升系统的性能。

Description

进程间通信的监控方法、电子装置以及可读存储介质

技术领域

本发明涉及电子设备技术领域，特别是涉及一种进程间通信的监控方法、电子装置及计算机可读存储介质。

背景技术

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

安卓系统是智能手机等电子装置的一种常见的操作系统，安卓系统中的两个进程之间通常需要进行通信，进程之间的用户空间是不能共享的，因此两个进程之间的通信通常需要Binder机制来实现通信。在进程间通信繁忙时，导致电子装置的系统出现卡顿甚至崩溃的情况，严重影响用户体验。

发明内容

本申请实施例采用的一个技术方案是：提供一种进程间通信的监控方法，该监控方法包括：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数；判断累计总通信次数是否大于预设总通信次数阈值；若是，则将当前服务端在系统中的第一优先级别调整为第二优先级别，其中，第二优先级别高于第一优先级别。

本申请实施例采用的另一个技术方案是：提供一种电子装置，该电子装置包括：监控模块，用于在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数；判断模块，用于判断累计总通信次数是否大于预设总通信次数阈值；执行模块，用于在判断模块判断到累计总通信次数大于预设总通信次数阈值后，将当前服务端在系统中的第一优先级别调整为第二优先级别，其中，第二优先级别高于第一优先级别。

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

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

本申请实施例通过在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数；判断累计总通信次数是否大于预设总通信次数阈值；若是，则将当前服务端在系统中的第一优先级别调整为第二优先级别，其中，第二优先级别高于第一优先级别，避免服务端过于繁忙导致的系统卡顿或者崩溃，能够提升系统的性能。

附图说明

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

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

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

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

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

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

图7是本申请第四实施例的进程间通信的监控方法的流程示意图；

图8是本申请第五实施例的进程间通信的监控方法的流程示意图；

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

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

具体实施方式

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

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

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

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

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

步骤101：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数，以及监控至少一个客户端中各个客户端的累计通信次数。

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

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

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

进一步参阅图3，图3是Binder通信机制的原理示意图，Binder通信采用C/S架构，从组件视角来说，包含Client进程(客户端进程)、Server进程(服务端进程)、ServiceManager(服务管理)以及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请求时，将对应的客户端的累计通信次数加一。

在服务端关闭时，将服务端的累计总通信次数清零，在下一次该服务端启动时，重新从零开始累计总通信次数。

在对应的客户端关闭时，将该对应的客户端的累通信次数清零，在下一次该对应的客户端启动时，重新从零开始累计通信次数。

当然，监控服务端的累计总通信次数时，也可以是每当服务端完成一次通信时，将累计的累计总通信次数加一。监控各个客户端的累计通信次数时，也可以是每当有客户端完成一次通信时，将对应的客户端的累计通信次数加一。

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

在监控时可以将各个客户端的累计通信次数的相关数据记录在对应关系表中，具体请参阅下表一。

客户端	累计通信次数
		客户端A	8
客户端B	9
		客户端C	7
客户端D	10

应理解，上表中的累计通信次数是实时变化的，上面的数据是反映某一时刻的数据。

步骤102：判断累计总通信次数是否大于预设总通信次数阈值。

在步骤102中，若判断结果为是，则说明此时服务端处于繁忙状态，可能会导致电子装置的系统出现卡顿崩溃等现象，则执行步骤103。

在步骤102中，若判断结果为否，则返回步骤101，继续进行监控。

其中，预设总通信次数阈值可以为根据以往的数据统计分析出的结果。例如，每当在系统出现卡顿或者崩溃时，记录此时服务端的累计总通信次数，对多次记录的这种累计总通信次数求平均值得到预设总通信次数阈值。

步骤103：将当前服务端在系统中的第一优先级别调整为第二优先级别，将至少一个客户端中累计通信次数大于预设通信次数的客户端的优先级别调低，其中，第二优先级别高于第一优先级别。

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

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

在服务端的累计通信次数过多时，将服务端的优先级别调高，使其能够从系统获得更大的资源，避免出现卡顿或者崩溃的现象。

下面对客户端的优先级别的调整进行说明。

举例而言，结合表一进行说明，若预设通信次数是8次，那么在客户端A、客户端B、客户端C、客户端D中，客户端A的累计通信次数是8次(小于或者等于8次)，客户端B的累计通信次数是9次(大于8次)，客户端C的累计通信次数是7次(小于或者等于8次)，客户端D的累计通信次数是10次(大于8次)，则对客户端B和客户端D进行降低优先级别处理。

在服务端的累计通信次数过多时，将至少一个客户端中通信次数过多的一部分客户端进行降低优先级别处理，可以进一步在服务端繁忙时，减小通信次数过多的客户端对服务端的影响，进一步提高系统的流畅性。

通过上述方式，从服务端启动开始累计总通信次数，在累计总通信次数过大时，将该服务端在系统的中的优先级别调高，可以避免服务端繁忙导致的系统崩溃或者卡顿，进一步，将通信次数过多的客户端的优先级别调低，能够有效优化电子装置的系统性能，提升电子装置操作系统的流畅性。

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

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

步骤501：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数，以及监控至少一个客户端中各个客户端实时的内存占用率。

其中，参见下表二，每个客户端在运行时都会占用系统的内存，各个客户端占用的内存可能不一样，占用的内存越大则说明其对服务端的繁忙程度影响越大。

客户端	内存占用率
		客户端A	10％
客户端B	15％
		客户端C	25％
客户端D	35％

上表中反映的是实时的内存占用率，各个客户端的内存占用率随时间的变化而变化。

步骤502：判断累计总通信次数是否大于预设总通信次数阈值。

在步骤501中，若是，则执行步骤503。

在步骤502中，若否，则返回步骤501。

步骤503：将当前服务端在系统中的第一优先级别调整为第二优先级别，将至少一个客户端中内存占用率大于预设占用率的客户端的优先级别调低，其中，第二优先级别高于第一优先级别。

其中，将至少一个客户端的内存占用率与预设占用率进行逐一比较，将客户端分成两部分。第一部分客户端的内存占用率大于预设占用率，第二部分的内存占用率小于或者等于预设占用率，将第一部分客户端进行降低优先级别处理。

举例而言，结合表二进行说明，若预设占用率是20％，那么客户端A的内存占用率10％小于或者等于预设占用率，客户端B的内存占用率15％小于或者等于预设占用率，客户端C的内存占用率25％大于预设占用率，客户端D的内存占用率35％大于预设占用率。此时，将客户端C和客户端D进行降低优先级别处理。

通过上述方式，服务端的通信次数过大时，将服务端的优先级别调高，对内存占用率过大的客户端进行降低优先级别处理，可以提高服务端获取系统资源的能力，同时可以降低内存占用过大的客户端对服务端binder线程的耗损，可以避免服务端繁忙导致的系统崩溃或者卡顿，能够有效优化电子装置的系统性能，提升电子装置操作系统的流畅性。

请参阅图6，图6是本申请第三实施例的进程间通信的监控方法的流程示意图。

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

步骤601：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数，以及监控至少一个客户端中各个客户端实时的CPU占用率。

其中，参见下表三，每个客户端在运行时都会占用系统的CPU，各个客户端占用的CPU程度可能不一样，CPU占用率越大则说明其对服务端的繁忙程度影响越大。

客户端	CPU占用率
		客户端A	10％
客户端B	15％
		客户端C	25％
客户端D	35％

上表中反映的是实时的CPU占用率，各个客户端的CPU占用率随时间的变化而变化。

步骤602：判断累计总通信次数是否大于预设总通信次数阈值。

在步骤601中，若是，则执行步骤603。

在步骤602中，若否，则返回步骤601。

步骤603：将当前服务端在系统中的第一优先级别调整为第二优先级别，将至少一个客户端中CPU占用率大于预设占用率的客户端的优先级别调低，其中，第二优先级别高于第一优先级别。

其中，将至少一个客户端的CPU占用率与预设占用率进行逐一比较，将客户端分成两部分。第一部分客户端的CPU占用率大于预设占用率，第二部分的CPU占用率小于或者等于预设占用率，将第一部分客户端进行降低优先级别处理。

举例而言，结合表三进行说明，若预设占用率是20％，那么客户端A的CPU占用率10％小于或者等于预设占用率，客户端B的CPU占用率15％小于或者等于预设占用率，客户端C的CPU占用率25％大于预设占用率，客户端D的CPU占用率35％大于预设占用率。此时，将客户端C和客户端D进行降低优先级别处理。

通过上述方式，从服务端启动时开始累计服务端的总通信次数，在服务端的通信次数过大时，对服务端进行提升优先级别处理，对CPU占用率过大的客户端进行降低优先级别处理，一方面可以提高服务端获取系统资源的能力，另一方面，可以减轻CPU占用率过大的客户端对服务端资源的耗损，进而可以避免服务端繁忙导致的系统崩溃或者卡顿，能够有效优化电子装置的系统性能，提升电子装置操作系统的流畅性。

在上述第二实施例和第三实施例中，内存占用率和CPU占用率均是属于对电子装置系统资源的占用率，在其他实施例中，可以是将至少一个客户端中系统资源占用率大于预设占用率的客户端进行降低优先级别处理，系统资源的占用率不限于内存占用率和CPU占用率，还可以是指其他表征客户端耗用系统资源的参数。

请参阅图7，图7是本申请第四实施例的进程间通信的监控方法的流程示意图。

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

步骤701：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数，以及获取至少一个客户端中各个客户端的重要级别。

其中，用户预先为每一客户端设置相应的重要级别，具体可以参见下表四，表四是一种客户端与重要级别的对应关系表。

客户端	重要级别
		客户端A	1
客户端B	2
		客户端C	3
客户端D	4

其中，重要级别的数值越大表示该客户端越重要，反之，重要级别的数值越小表示该客户端越不重要。

步骤702：判断累计总通信次数是否大于预设总通信次数阈值。

在步骤701中，若是，则执行步骤703。

在步骤702中，若否，则返回步骤701。

步骤703：将当前服务端在系统中的第一优先级别调整为第二优先级别，将至少一个客户端中重要级别小于预设级别的客户端的优先级别调低，其中，第二优先级别高于第一优先级别。

其中，将至少一个客户端的重要级别与预设级别进行逐一比较，将客户端分成两部分。第一部分客户端的重要级别大于或者等于预设级别，第二部分的重要级别小于预设级别，将第二部分客户端进行降低优先级别处理。

举例而言，结合表四进行说明，若预设级别为3，则客户端A的重要级别1小于预设级别3，客户端B的重要级别2小于预设级别3，客户端C的重要级别3等于预设级别3，客户端D的重要级别4大于预设级别3，那么将客户端A和客户端B进行降低优先级别处理。

通过上述方式，从服务端启动开始累计服务端的总通信次数，服务端的通信次数过大时，对服务端进行提升优先级别的处理，对重要级别较小的(不重要的)客户端进行降低优先级别处理，一方面可以提升服务端获取系统资源的能力，另一方面，可以降低不重要的客户端对服务端资源的耗损，可以避免服务端繁忙导致的系统崩溃或者卡顿，能够有效优化电子装置的系统性能，提升电子装置操作系统的流畅性。

在上述的第一实施例至第四实施例中，第三步均是对符合预设条件的一部分客户端进行调低优先级别处理，例如，预设条件是重要级别小于预设级别、CPU占用率大于预设占用率、内存占用率大于预设占用率、累计通信次数大于预设通信次数，在其他实施例中，预设条件可以为其他条件，例如，对至少一个客户端中运行在后台的客户端进行降低优先级别的处理。应理解，预设条件可以不是单一的条件，预设条件可以包括上述的多种条件中的组合形式。例如，对累计通信次数大于预设通信次数且运行在后台的客户端进行降低优先级别处理。

请参阅图8，图8是本申请第五实施例的进程间通信的监控方法的流程示意图。

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

步骤801：在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数，以及监控至少一个客户端中各个客户端的累计通信次数，以及监控各个客户端的运行状态，运行状态包括前台运行和后台运行。

其中，客户端可能运行在前台，也可能运行在后台，监控各个客户端的运行状态，前台运行的客户端是指当前电子装置用户正在进行交互的客户端，后台运行的客户端是指当前电子装置用户未进行交互的客户端，换言之，后台客户端是用户未直接接触的客户端。

请参阅表五，表五是一种客户端与运行状态、累计通信次数的对应关系表。

客户端	累计通信次数	运行状态
			客户端A	8	后台运行
客户端B	9	后台运行
			客户端C	7	后台运行
客户端D	10	前台运行

步骤802：判断累计总通信次数是否大于预设总通信次数阈值。

在步骤801中，若是，则执行步骤803。

在步骤802中，若否，则返回步骤801。

步骤803：将当前服务端在系统中的第一优先级别调整为第二优先级别，将至少一个客户端中累计通信次数大于预设通信次数且运行在后台的客户端的优先级别调低，其中，第二优先级别高于第一优先级别。

其中，结合表五进行说明，若预设通信次数是8，那么在客户端A、客户端B、客户端C、客户端D中：

客户端A的累计通信次数是8次(小于或者等于8次)，客户端A运行在后台，那么客户端A保持当前的优先级别。

客户端B的累计通信次数是9次(大于8次)，客户端B运行在后台，那么客户端B会被降低优先级别处理。

客户端C的累计通信次数是7次(小于或者等于8次)，客户端C运行在后台，那么客户端C保持当前的优先级别。

客户端D的累计通信次数是10次(大于8次)，客户端D运行在前台，那么客户端D保持当前的优先级别。

通过上述方式，从服务端启动开始，累计服务端的总通信次数，服务端的总通信次数过大时，对服务端进行提升优先级别的处理，对累计通信次数过大的且运行在后台的客户端进行降低优先级别的处理，一方面可以提升服务端获取系统资源的能力，另一方面，可以避免运行在后台的且通信次数过多的客户端对服务端资源的耗损，进而可以避免服务端繁忙导致的系统崩溃或者卡顿，能够有效优化电子装置的系统性能，提升电子装置操作系统的流畅性，进一步由于不会对运行在前台的程序进行降低优先级别的处理，能够避免对用户正在交互的客户端降低优先级别导致影响用户的使用。

在以上各个实施例中，在降低客户端优先级别时可以记录客户端的标识信息，在下次该服务端启动后，若判断到服务端的累计总通信次数小于或者等于预设总通信次数阈值时，根据客户端的标识信息找到对应的客户端并使其恢复至降低前的优先级别。

通过这样的方式，在服务端恢复空闲时，将调低优先级别的客户端恢复至调低前的优先级别，可以在优化系统性能的情况下，尽量避免影响系统的稳定性。

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

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

监控模块91，用于在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数。

判断模块92，用于判断累计总通信次数是否大于预设总通信次数阈值。

执行模块93，用于在判断模块92判断到累计总通信次数大于预设总通信次数阈值后，将当前服务端在系统中的第一优先级别调整为第二优先级别，其中，第二优先级别高于第一优先级别。

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

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

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

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

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

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

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

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

本申请实施例通过在服务端与至少一个客户端进行binder通信的过程中，监控服务端与至少一个客户端的累计总通信次数；判断累计总通信次数是否大于预设总通信次数阈值；若是，则将当前服务端在系统中的第一优先级别调整为第二优先级别，其中，第二优先级别高于第一优先级别，避免服务端过于繁忙导致的系统卡顿或者崩溃，能够提升系统的性能。

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

Claims (10)

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

在服务端与至少一个客户端进行binder通信的过程中，监控所述服务端与所述至少一个客户端进行binder通信过程中所述服务端的累计总通信次数，每当所述服务端响应来自所述至少一个客户端的binder请求时，将所述累计总通信次数加一；

判断所述累计总通信次数是否大于预设总通信次数阈值；

若是，则将当前所述服务端在系统中的第一优先级别调整为第二优先级别，将所述至少一个客户端中符合预设条件的客户端的优先级别调低，其中，所述第二优先级别高于第一优先级别。

2.根据权利要求1所述的监控方法，其特征在于，所述将所述至少一个客户端中符合预设条件的客户端的优先级别调低，包括：

将所述至少一个客户端中系统资源占用率大于预设占用率的客户端的优先级别调低。

3.根据权利要求2所述的监控方法，其特征在于，所述系统资源占用率包括内存占用率、CPU占用率中的至少一者。

4.根据权利要求1所述的监控方法，其特征在于，所述监控方法包括：

监控所述至少一个客户端中各个客户端的累计通信次数。

5.根据权利要求4所述的监控方法，其特征在于，所述将所述至少一个客户端中符合预设条件的客户端的优先级别调低，包括：

将所述至少一个客户端中所述累计通信次数大于预设通信次数的客户端的优先级别调低。

6.根据权利要求4所述的监控方法，其特征在于，所述监控所述至少一个客户端中各个客户端的累计通信次数的步骤，包括：

每当有客户端发送binder请求时，将对应的客户端的累计通信次数加一。

7.根据权利要求1所述的监控方法，其特征在于，所述将所述至少一个客户端中符合预设条件的客户端的优先级别调低，包括：

将所述至少一个客户端中重要级别低于预设级别的客户端的优先级别调低。

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

监控模块，用于在服务端与至少一个客户端进行binder通信的过程中，监控所述服务端与所述至少一个客户端进行binder通信过程中所述服务端的累计总通信次数，用于每当所述服务端响应来自所述至少一个客户端的binder请求时，将所述累计总通信次数加一；

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

执行模块，用于在所述判断模块判断到所述累计总通信次数大于预设总通信次数阈值后，将当前所述服务端在系统中的第一优先级别调整为第二优先级别，将所述至少一个客户端中符合预设条件的客户端的优先级别调低，其中，所述第二优先级别高于第一优先级别。

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

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

Images