一种移动终端及其进程间通信的监控方法、存储介质与流程

本申请涉及移动终端
技术领域：
，特别是涉及一种移动终端及其进程间通信的监控方法、存储介质。
背景技术：
：android操作系统中，应用与服务间经常需要进行数据传输，一般可以采用进程间通信的方式，例如，可以通过binder机制进行传输，从而获取对方的数据。在利用binder机制进行通信的过程中，通常一个服务端会与多个客户端进行通信，这样会加重服务端的负担，当进程间通信过于繁忙时，会影响服务或者系统的流畅性。技术实现要素：本申请采用的一个技术方案是：提供一种进程间通信的监控方法，该监控方法包括：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数；判断通信次数是否大于设定阈值；若是，限制第一客户端与服务端之间的通信；其中，第一客户端是至少一个客户端中与服务端通信次数最多的客户端。本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括：获取模块，用于在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数；判断模块，用于判断通信次数是否大于设定阈值；限制模块，用于在判断模块的判断结果为是时，限制第一客户端与服务端之间的通信；其中，第一客户端是至少一个客户端中与服务端通信次数最多的客户端。本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括处理器和存储器，其中，存储器用于存储计算机程序，计算机程序在被处理器执行时，用于实现如上述的方法。本申请采用的另一个技术方案是：提供一种计算机存储介质，该计算机存储介质用于存储计算机程序，计算机程序在被处理器执行时，用于实现如上述的方法。区别于现有技术的情况，本申请提供的进程间通信的监控方法包括：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数，通过限制与服务端通信次数最多的客户端的通信，能够减小服务端的繁忙程度，保证系统的流畅性。附图说明为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：图1是本申请提供的进程间通信的监控方法第一实施例的流程示意图；图2是进程间通信的原理示意图；图3是binder通信机制的原理示意图；图4是客户端和服务端的交互示意图；图5是本申请提供的进程间通信的监控方法第二实施例的流程示意图；图6是本申请提供的进程间通信的监控方法第三实施例的流程示意图；图7是本申请提供的进程间通信的监控方法第四实施例的流程示意图；图8是本申请提供的进程间通信的监控方法第五实施例的流程示意图；图9是本申请提供的进程间通信的监控方法第六实施例的流程示意图；图10是本申请提供的进程间通信的监控方法第七实施例的流程示意图；图11是本申请提供的移动终端一实施例的结构示意图；图12是本申请提供的移动终端另一实施例的结构示意图；图13是本申请提供的计算机存储介质一实施例的结构示意图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。参阅图1，图1是本申请提供的进程间通信的监控方法第一实施例的流程示意图，该方法包括：步骤11：在服务端与至少一个客户端基于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、servicemanager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与binder驱动进行交互的，从而实现ipc通信方式。其中binder驱动位于内核空间，client、server、servicemanager位于用户空间。binder驱动和servicemanager可以看做是android平台的基础架构，而client和server是android的应用层，开发人员只需自定义实现client、server端，借助android的基本平台架构便可以直接进行ipc通信。基于上述binder机制的原理，我们知道，客户端和服务端可以是任意两个进程，可以是应用，也可以是服务，例如，可以是应用与应用之间的通信，也可以是应用与服务之间的通信。另外，在智能终端中，多个应用可能同时获取同一服务，所以，一个服务端可能同时与多个客户端之间进行进程间通信，在这种情况下，由于服务端的通信次数多、线程使用量较大、通信过于频繁，会造成系统的卡顿，本实施例在于对一个服务的通信次数进行监控。可选的，在本实施例中，该服务端可以是系统服务端。具体地，如图4所示，图4是客户端和服务端的交互示意图，在客户端与服务端的通信过程中，主要包括三个过程，客户端向服务端发起通信请求、服务端响应客户端发起的通信请求、客户端和服务端之间进行数据交互。其中，经过上述的过程才算是一个完成的通信过程，因此，可以通过上述三个节点中的任意一个来累计通信次数。可选的，步骤11可以具体为：在至少一个客户端向服务端发起通信请求时，累计通信次数。可选的，步骤11可以具体为：在服务端响应至少一个客户端发起的通信请求时，累计通信次数。可选的，步骤11可以具体为：在至少一个客户端和服务端的进程间通信完成时，累计通信次数。在一具体的实施例中，服务端可能因为繁忙等原因没有响应客户端的通信请求，亦或是客户端由于崩溃等原因没有能够与服务端完成通信，因此，在该实施例中，可以在客户端和服务端的进程间通信完成时，再累计通信次数。这样也可以避免误累计导致统计的通信次数过多。可选的，在一实施例中，还可以仅仅累计某一特定的客户端与某一特定的服务端之间的通信次数，一对一进行统计。步骤12：判断通信次数是否大于设定阈值。在步骤12的判断结果为是时，执行步骤13。其中，设定阈值可以是根据经验设置的，例如，通过获取一段时间内通信次数的平均值，当通信次数达到某个临界值时，系统容易出现不流畅、崩溃等现象。通信次数从一方面能够反映出服务端的繁忙程度，特别是在多个客户端同时与同一个服务端进行通信时，通过监控其通信次数，能够为后续的系统优化提供数据支持。其中，后续的系统优化包括限制客户端的通信，具体可以对客户端进行查杀、冻结等等。下面通过一个具体的例子进行说明，该例子中根据时间先后顺序进行说明：1、应用程序a的第一进程与应用程序b的第一进程进行binder通信；2、应用程序a的第二进程与系统服务进行binder通信；3、应用程序c的第一进程与系统服务进行binder通信；4、应用程序d的第一进程与系统服务进行binder通信；5、应用程序d的第二进程与系统服务进行binder通信。在上述的例子中，总的通信次数为5次。其中，对于应用程序a来说，其通信次数为2次；对于应用程序b来说，其通信次数为1次；对于应用程序c来说，其通信次数为1次；对于应用程序d来说，其通信次数为2次；对于系统服务来说，其通信次数为4次。可选的，若对系统服务的通信进行监控，获取得到的通信次数即为4次。步骤13：限制第一客户端与服务端之间的通信；其中，第一客户端是至少一个客户端中与服务端通信次数最多的客户端。可选的，由于在步骤13中要限制第一客户端与服务端之间的通信，所以在步骤12中可以客户端与服务端进行通信的过程中，对客户端进行标记。具体地，步骤12可以是：在服务端与每个客户端进行通信时，累计通信次数，并对相应的客户端进行标记，将标记最多的客户端作为第一客户端。下面通过一个具体的例子进行说明，该例子中根据时间先后顺序进行说明：1、应用程序a的第一进程与系统服务进行binder通信，累计通信次数1次，并对应用程序a进行标记；2、应用程序a的第二进程与系统服务进行binder通信，累计通信次数2次，并再次对应用程序a进行标记；3、应用程序b的第一进程与系统服务进行binder通信，累计通信次数3次，并对应用程序b进行标记；4、应用程序c的第一进程与系统服务进行binder通信，累计通信次数4次，并对应用程序c进行标记；5、应用程序d的第一进程与系统服务进行binder通信，累计通信次数5次，并对应用程序d进行标记。在上述的例子中，总的通信次数为5次。其中，对于应用程序a来说，其标记有两个，通信次数为2次；对于其他应用程序来说均为1次；所以将应用程序a作为第一客户端，并限制应用程序a与系统服务之间的通信。可选的，在一实施例中，限制第一客户端与服务端之间的通信，主要的方式包括：限制第一客户端与服务端之间的通信次数、通信频率、线程使用数量。其中，通信次数是指第一客户端与服务端总的通信次数，例如，可以限制为5次，从第一客户端第一次与服务端通信开始累计，当两者之间的通信次数达到5次，则禁止第一客户端与服务端之间进行通信。其中，通信频率一般是只一段时间内的通信次数，例如，可以限制为每小时5次，从第一客户端第一次与服务端通信开始累计并计时，当一小时内两者之间的通信次数达到5次，则禁止第一客户端与服务端之间进行通信。一小时之后，则允许第一客户端与服务端之间的通信。其中，线程使用数量是指第一客户端与服务端在通信过程中使用的服务端的线程数量。以系统服务为例，一般有32个线程，假如设定的线程数量为10个，则仅允许第一客户端与服务端之间的通信最多能占用10个线程。可以理解的，上述实施例中的客户端和服务端是可以自行定义的，因此上述方式可以适用于任意应用程序或者服务，对其通信次数进行监控。区别于现有技术，本实施例提供的进程间通信的监控方法通过获取服务端与至少一个客户端之间的通信次数，从而对服务端的繁忙程度进行监控，并利用监控的结果对通信次数较多的客户端进行限制。通过上述方式，一方面能够快速有效的获取到服务端的繁忙程度，对系统的优化提供数据支持，另一方面能够很好的从客户端的角度来限制通信次数，有效的减小服务端的负担，减小了服务端的繁忙程度，保证了系统的流程性。参阅图5，图5是本申请提供的进程间通信的监控方法第二实施例的流程示意图，该方法包括：步骤51：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，在每次累计通信次数时，同时记录当前的时间点。步骤52：基于每次通信的时间点，获取设定时间段内的累计通信次数。这里以完成通信的时间点为例，对于同一服务端在一段时间内完成5次通信，如下表所示：通信次数完成通信的时间点第1次通信时间点1第2次通信时间点2第3次通信时间点3第4次通信时间点4第5次通信时间点5具体地，可以从某一特定的时间点开始进行累计，例如从时间点1或者时间点1之前的某一个时间点，然后时间段的长度可以任意设置，例如10分钟。举例而言，加入要累计从时间点1开始10分钟之内的通信次数，那么最后的统计时间截止的时间点就是时间点1+10分钟，若时间点1-5均在这段时间之内，那么累计的通信次数就是5次。另外，可以重复以前的步骤，这里仍然以10分钟为例，可以每10分钟统计一次，并可以将连续统计的次数进行比较分析。例如，在第一个10分钟内通信5次，第二个10分钟内通信10次，第三个10分钟通信20次，可以通过数据的变化进行对通信次数进行监控。参阅图6，图6是本申请提供的进程间通信的监控方法第三实施例的流程示意图，该方法包括：步骤61：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，判断服务端是否满足预设条件。其中，在步骤61的判断结果为是时，执行步骤62。步骤62：从服务端满足预设条件开始，累计设定时间段内服务端与至少一个客户端之间的通信次数。可以理解的，监控服务端的通信次数的目的在于监控其繁忙程度，因此，可以在服务端的繁忙程度满足一定的条件时，再开始监控。可选的，预设条件为服务端的可用线程的数量小于设定阈值。可以理解的，两个进程之间的通信一般会使用到多个线程。例如，android系统规定systemserver进程最多可以创建32个binder线程用于进程间数据通信；surfaceflinger进程最多可以创建4个binder线程用于进程间数据通信；程序应用进程最多可以创建8个binder线程用于进程间数据通信。因此，可以在服务端的线程使用数量满足要求的时候开始监控通信次数，例如，一个服务端共有32个线程，其中16个线程被使用，可用线程剩余16个，即当被使用线程大于一半的时候开始累计设定时间段内服务端与至少一个客户端之间的通信次数。当然，预设条件还可以是cpu的占用率，同时与同一服务端通信的客户端的数量、通信频率等等，这里不再一一列举。步骤63：将通信次数进行保存，以便基于通信次数对服务端的通信进行监控。参阅图7，图7是本申请提供的进程间通信的监控方法第四实施例的流程示意图，该方法包括：步骤71：在至少一个客户端向服务端发起通信请求时，记录第一时间点。步骤72：在服务端响应至少一个客户端发起的通信请求时，记录第二时间点。步骤73：基于第一时间点和第二时间点，获取服务等待时间。这里的服务等待时间即为第一时间点和第二时间点之间的时间段。步骤74：保存服务等待时间，以便基于服务等待时间对服务端的通信进行监控。参阅图8，图8是本申请提供的进程间通信的监控方法第五实施例的流程示意图，该方法包括：步骤81：在服务端响应至少一个客户端发起的通信请求时，记录第二时间点。步骤82：在至少一个客户端和服务端的进程间通信完成时，记录第三时间点。步骤83：基于第二时间点和第三时间点，获取通信服务时间。这里的通信服务时间即为第二时间点和第三时间点之间的时间段。步骤84：保存通信服务时间，以便基于通信服务时间对服务端的通信进行监控。参阅图9，图9是本申请提供的进程间通信的监控方法第六实施例的流程示意图，该方法包括：步骤91：在至少一个客户端向服务端发起通信请求时，记录第一时间点。步骤92：在至少一个客户端和服务端的进程间通信完成时，记录第三时间点。步骤93：基于第一时间点和第三时间点，获取进程间通信总时间。这里的进程间通信总时间即为第一时间点和第三时间点之间的时间段。步骤94：保存获取进程间通信总时间，以便基于获取进程间通信总时间对服务端的通信进行监控。上述图7-图9的实施例可以与上述其他实施例相结合进行实施，其从三个不同的方面获取到通信的时长，其中包括服务等待时长、通信服务时长和总时长。其中，具体可以获取每次时长的平均值或者总时长。如下表所示：通信次数服务等待时长通信服务时长进程间通信总时长1a1a2a32b1b2b33c1c2c3例如，服务等待时长的平均值就是a1、b1和c1的平均值；通信服务时长的平均值就是a2、b2和c2的平均值；进程间通信总时长就是a3、b3和c3的平均值。可选的，还可以利用统计学的其他统计方法对上述数据进行统计，例如方差。另外，在对上述的通信次数、服务等待时长、通信服务时长和进程间通信总时长进行统计和监控时，可以绘制直方图进行直观的展示，利用直方图进一步获取到系统的繁忙程度，从而能够通过后续的对客户端的限制措施，对系统进行优化，保证系统的流畅性。参阅图10，图10是本申请提供的进程间通信的监控方法第七实施例的流程示意图，该方法包括：步骤101：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数。步骤102：判断通信次数是否大于设定阈值。步骤103：获取服务端的使用情况。其中，服务端的使用情况至少包括服务端的可用线程数量、与客户端通信时客户端的数量、服务端的通信效率等等，还可以是cpu的占用情况。步骤104：判断服务端的使用情况是否满足设定条件。以可用线程数量为例，这里可以判断服务端的可用线程数量是否小于设定的阈值。步骤105：限制第一客户端与服务端之间的通信。可以理解的，本实施例是通过统计通信次数后，基于通信次数再获取检测服务端是否繁忙的其他指标，将通信次数作为一个基础指标。这样能够通过多重条件来判断服务端的繁忙程度，进而来限制客户端的通信，有利于实现移动终端的流畅性，还能够防止客户端被误禁用，造成用户的使用不便。参阅图11，图11是本申请提供的移动终端一实施例的结构示意图，该移动终端110包括获取模块111、判断模块112和限制模块113。其中，获取模块111用于在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数；判断模块112用于判断通信次数是否大于设定阈值；限制模块113用于在判断模块的判断结果为是时，限制第一客户端与服务端之间的通信；其中，第一客户端是至少一个客户端中与服务端通信次数最多的客户端。可选的，获取模块111具体用于在服务端与每个客户端进行通信时，累计通信次数，并对相应的客户端进行标记；将标记最多的客户端作为第一客户端。可选的，限制模块113具体用于限制第一客户端与服务端之间的通信次数、通信频率、线程使用数量。可选的，获取模块111具体用于在至少一个客户端向服务端发起通信请求时、或在服务端响应至少一个客户端发起的通信请求时、或在至少一个客户端和服务端的进程间通信完成时，累计通信次数。可选的，获取模块111还用于在每次累计通信次数时，同时记录当前的时间点；基于每次通信的时间点，获取设定时间段内的累计通信次数。参阅图12，图12是本申请提供的移动终端另一实施例的结构示意图，该移动终端120包括处理器121和存储器122，其中，处理器121和存储器122可以通过一条数据总线耦接。其中，存储器122用于存储计算机程序，计算机程序在被处理器121执行时，用于实现如下方法步骤：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数；判断通信次数是否大于设定阈值；若是，限制第一客户端与服务端之间的通信；其中，第一客户端是至少一个客户端中与服务端通信次数最多的客户端。可选的，计算机程序在被处理器121执行时，还用于实现如下方法步骤：在至少一个客户端向服务端发起通信请求时、或在服务端响应至少一个客户端发起的通信请求时、或在至少一个客户端和服务端的进程间通信完成时，累计通信次数。可选的，计算机程序在被处理器121执行时，还用于实现如下方法步骤：判断服务端是否满足预设条件；若是，从服务端满足预设条件开始，累计设定时间段内服务端与至少一个客户端之间的通信次数；其中，预设条件为服务端的可用线程的数量小于设定阈值。可选的，计算机程序在被处理器121执行时，还用于实现如下方法步骤：在至少一个客户端向服务端发起通信请求时，记录第一时间点；在服务端响应至少一个客户端发起的通信请求时，记录第二时间点；基于第一时间点和第二时间点，获取服务等待时间；保存服务等待时间，以便基于服务等待时间对服务端的通信进行监控。以及在至少一个客户端和服务端的进程间通信完成时，记录第三时间点；基于第二时间点和第三时间点，获取通信服务时间；保存通信服务时间，以便基于通信服务时间对服务端的通信进行监控。以及基于第一时间点和第三时间点，获取进程间通信总时间；保存获取进程间通信总时间，以便基于获取进程间通信总时间对服务端的通信进行监控。可选的，计算机程序在被处理器121执行时，还用于实现如下方法步骤：在服务端与至少一个客户端之间的通信次数大于设定次数阈值时，获取客户端的使用情况；将客户端的使用情况进行保存，以便基于客户端的使用情况对服务端的通信进行监控；其中，客户端的使用情况至少包括客户端的可用线程数量。参阅图13，图13是本申请提供的计算机存储介质一实施例的结构示意图，该计算机存储介质130用于存储计算机程序131，计算机程序131在被处理器执行时，用于实现如下方法步骤：在服务端与至少一个客户端基于binder机制进行进程间通信的过程中，获取服务端与至少一个客户端之间的通信次数；判断通信次数是否大于设定阈值；若是，限制第一客户端与服务端之间的通信；其中，第一客户端是至少一个客户端中与服务端通信次数最多的客户端。可以理解的，计算机程序131在被处理器执行时，所实现的方法步骤与上述移动终端的实施例类似，这里不再赘述。本申请的实施例以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
，均同理包括在本申请的专利保护范围内。当前第1页12