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

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