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

本申请涉及移动终端
技术领域：
，特别是涉及一种移动终端及其进程间通信的限制方法、存储介质。
背景技术：
：android操作系统中，应用与服务间经常需要进行数据传输，一般可以采用进程间通信的方式，例如，可以通过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是图1一具体实施例的交互示意图；图6是本申请提供的进程间通信的限制方法第二实施例的流程示意图；图7是图6一具体实施例的交互示意图；图8是本申请提供的进程间通信的限制方法第三实施例的流程示意图；图9是本申请提供的进程间通信的限制方法第四实施例的流程示意图；图10是本申请提供的进程间通信的限制方法第五实施例的流程示意图；图11是本申请提供的进程间通信的限制方法第六实施例的流程示意图；图12是本申请提供的移动终端一实施例的结构示意图；图13是本申请提供的移动终端另一实施例的结构示意图；图14是本申请提供的计算机存储介质一实施例的结构示意图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。参阅图1，图1是本申请提供的进程间通信的限制方法第一实施例的流程示意图，该方法包括：步骤11：在客户端向服务端发送binder请求时，获取客户端已使用的binder线程的第一数量。其中，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通信时，服务端会起一些binder线程来响应客户端的binder请求。具体地，binder通信实际上是位于不同进程中的线程之间的通信。假如进程s是server端，提供binder实体，线程t1从client进程c1中通过binder的引用向进程s发送请求。s为了处理这个请求需要启动线程t2，而此时线程t1处于接收返回数据的等待状态。t2处理完请求就会将处理结果返回给t1，t1被唤醒得到处理结果。在这过程中，t2仿佛t1在进程s中的代理，代表t1执行远程任务，而给t1的感觉就是象穿越到s中执行一段代码又回到了c1。为了使这种穿越更加真实，驱动会将t1的一些属性赋给t2，特别是t1的优先级nice，这样t2会使用和t1类似的时间完成任务。对于server进程s，可能会有许多client同时发起请求，为了提高效率往往开辟线程池并发处理收到的binder请求。可以理解的，两个进程之间的通信一般会使用到多个线程。例如，android系统规定systemserver进程最多可以创建32个binder线程用于进程间数据通信；surfaceflinger进程最多可以创建4个binder线程用于进程间数据通信；程序应用进程最多可以创建8个binder线程用于进程间数据通信。基于上述binder机制的原理，我们知道，客户端和服务端可以是任意两个进程，可以是应用，也可以是服务，例如，可以是应用与应用之间的通信，也可以是应用与服务之间的通信。另外，在智能终端中，多个应用可能同时获取同一服务，所以，一个服务端可能同时与多个客户端之间进行进程间通信，在这种情况下，由于服务端的通信次数多、线程使用量较大、通信过于频繁，会造成系统的卡顿，本实施例主要是通过获取一特定客户端与一个服务端之间的通信所使用的binder线程的数量来衡量该客户端对服务端的繁忙程度所造成的影响，从而对该客户端进行限制。可选的，在本实施例中，该服务端可以是系统服务端。具体地，如图4所示，图4是客户端和服务端的交互示意图，在客户端与服务端的通信过程中，主要包括三个过程，客户端向服务端发起通信请求、服务端响应客户端发起的通信请求、客户端和服务端之间进行数据交互。可以理解的，在客户端向服务端发起binder请求时，还未占用服务端的binder线程，当服务器开始响应时，就会开启一个binder线程进行响应。以服务端的binder线程的总数量是32个为例，如下表所示：服务端binder线程总数已使用binder线程数空闲binder线程数322012其中，已使用的20个binder线程中可能是多个客户端使用的，在本实施例中，第一数量是特定的某一个客户端所使用的binder线程的数量，例如，其中的10个binder线程是客户端a使用的，那么这里的第一数量就是10个。步骤12：判断第一数量是否大于第一设定阈值。在步骤12的判断结果为是时，执行步骤13。在步骤12的判断结果为否时，服务端响应客户端发送的binder请求，进行客户端与服务端之间的进程间通信。其中，第一设定阈值可以是根据经验设置的，例如，通过获取一段时间内多个客户端与服务端之间的通信所使用的binder线程的数量的平均数，或者一般系统出现不流畅、崩溃等现象时，客户端所使用的最高binder线程数量。例如，根据统计，每次系统出现崩溃时，某一客户端与服务端的通信中所使用的binder线程数量均达到了20个之多，那么可以将20作为第一设定阈值。步骤13：将binder请求加入等待队列的末端，以暂停响应客户端发送的binder请求。其中，等待队列(pending)中的binder请求并不会立即被服务端响应，相当于建立了一个缓冲的机制，当然，服务端会在满足一定的条件后再相应等待队列中的binder请求，例如，可以在一段时间后或者服务端不繁忙的时候进行响应。结合图5，下面通过一个具体的例子进行说明，该例子中根据时间先后顺序进行说明：1、应用程序a(客户端)向系统服务(服务端)发送第一binder请求，占用系统服务1个binder线程；2、应用程序a向系统服务发送第二binder请求，占用系统服务1个binder线程；……10、应用程序a向系统服务发送第十binder请求，占用系统服务1个binder线程；经过上述10次binder通信，共占用服务端10个binder线程，在本实施例中，预设的第一设定阈值为10，因此，在接下来的第十一次binder请求时：11、应用程序a向系统服务发送第十一binder请求，检测到当前应用程序a所使用的binder线程的数量已达10个，则将该第十一binder请求加入等待队列。可以理解的，上述实施例中的客户端和服务端是可以自行定义的，因此上述方式可以适用于任意应用程序或者服务。区别于现有技术，本实施例基于某一客户端的binder线程的使用情况，从而限制binder线程使用数量较大的客户端与服务端之间的通信次数，一方面能够快速有效的获取到服务端的繁忙程度，对系统的优化提供数据支持，另一方面能够很好的从客户端的角度来限制binder线程的使用数量，有效的减小服务端的负担，减小了服务端的繁忙程度，保证了系统的流畅性。参阅图6，图6是本申请提供的进程间通信的限制方法第二实施例的流程示意图，该方法包括：步骤61：在客户端向服务端发送binder请求时，获取客户端已使用的binder线程的第一数量。其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信。步骤62：判断第一数量是否大于第一设定阈值。在步骤62的判断结果为是时，执行步骤63，在步骤62的判断结果为否时，执行步骤64。步骤63：将binder请求加入等待队列的末端，以暂停响应客户端发送的binder请求。步骤64：获取服务端未被客户端使用的可用binder线程的第二数量。步骤65：判断第二数量是否小于第二设定阈值。可以理解的，一个服务端可能同时与多个客户端进行binder通信，因此，即使在某特定客户端所使用的binder线程的数量较少时，但可能服务端的其他binder线程可能被其他客户端所使用，因此，服务端的可用binder线程数量依然较小，在这种情况下，如果再对binder请求进行响应，可能会导致服务端的繁忙。在步骤65的判断结果为是时，执行步骤66，在步骤65的判断结果为否时，执行步骤67。步骤66：将binder请求加入等待队列的末端，以暂停响应客户端发送的binder请求。步骤67：检测等待队列中是否具有客户端发送的binder请求。可以理解的，由于服务端的繁忙，可能在等待队列中已经有在等待的binder请求，所以，在新的binder请求发送来之后，应当考虑按照发送的时间先后顺序对binder请求进行响应。在步骤67的检测结果为是时，执行步骤68，在步骤67的检测结果为否时，执行步骤69。步骤68：将客户端当前发送的binder请求加入等待队列末端，并响应等待队列前端的客户端发送的binder请求。例如，客户端a已经有发送的两个binder请求在等待队列中，若此时客户端a再次发送binder请求，且检测到的结果是满足响应要求的，则此时暂时将当前发送的binder请求加入等待队列，而将等待队列中之前发送的两个binder请求中时间较先的binder请求进行响应。步骤69：直接响应客户端当前发送的binder请求。结合图7，在一具体的例子中，当客户端a向服务端发送第一binder请求时，检测到客户端a已使用的binder线程的数量不满足要求，将第一binder请求加入等待队列；当客户端a向服务端发送第二binder请求时，检测到客户端a已使用的binder线程的数量不满足要求，将第二binder请求加入等待队列；当客户端a向服务端发送第三binder请求时，检测到客户端a已使用的binder线程的数量满足要求，此时，依然将第三binder请求加入等待队列，而对等待队列中的第一binder请求进行响应。参阅图8，图8是本申请提供的进程间通信的限制方法第三实施例的流程示意图，该方法包括：步骤81：检测客户端已使用的binder线程的是否进入空闲状态。步骤82：利用进入空闲状态的binder线程响应等待队列中客户端发送的binder请求。在本实施例中，系统不断的检测服务端中已经被使用的binder线程是否进入空闲状态，即通信完成，若是，将利用该binder线程去响应等待队列中与之前使用的客户端相同的客户端所发送的binder请求。例如，binder线程t1被客户端a所使用进行binder通信，在线程t1空闲之后，其会优先去响应等待队列中客户端a发送的binder请求，再等待队列中没有客户端a发送的binder请求时，才会去响应其他客户端发送的binder请求。其中，在一可选的实施例中，步骤82可以具体为：检测等待队列中是否具有客户端发送的binder请求；若是，利用进入空闲状态的binder线程响应等待队列中客户端发送的binder请求。下面通过几种实施例对通信过程中的各个阶段的时间长度进行监控，以判断服务端的繁忙程度的方式进行介绍。参阅图9，图9是本申请提供的进程间通信的限制方法第四实施例的流程示意图，该方法包括：步骤91：在客户端向服务端发起通信请求时，记录第一时间点。步骤92：在服务端响应客户端发起的通信请求时，记录第二时间点。步骤93：基于第一时间点和第二时间点，获取服务等待时间。这里的服务等待时间即为第一时间点和第二时间点之间的时间段。步骤94：保存服务等待时间，以便基于服务等待时间对服务端的通信进行监控。参阅图10，图10是本申请提供的进程间通信的限制方法第五实施例的流程示意图，该方法包括：步骤101：在服务端响应客户端发起的通信请求时，记录第二时间点。步骤102：在客户端和服务端的进程间通信完成时，记录第三时间点。步骤103：基于第二时间点和第三时间点，获取通信服务时间。这里的通信服务时间即为第二时间点和第三时间点之间的时间段。步骤104：保存通信服务时间，以便基于通信服务时间对服务端的通信进行监控。参阅图11，图11是本申请提供的进程间通信的限制方法第六实施例的流程示意图，该方法包括：步骤111：在客户端向服务端发起通信请求时，记录第一时间点。步骤112：在客户端和服务端的进程间通信完成时，记录第三时间点。步骤113：基于第一时间点和第三时间点，获取进程间通信总时间。这里的进程间通信总时间即为第一时间点和第三时间点之间的时间段。步骤114：保存获取进程间通信总时间，以便基于获取进程间通信总时间对服务端的通信进行监控。上述图9-图11的实施例可以与上述其他实施例相结合进行实施，其从三个不同的方面获取到通信的时长，其中包括服务等待时长、通信服务时长和总时长。其中，具体可以获取每次时长的平均值或者总时长。如下表所示：通信次数服务等待时长通信服务时长进程间通信总时长1a1a2a32b1b2b33c1c2c3例如，服务等待时长的平均值就是a1、b1和c1的平均值；通信服务时长的平均值就是a2、b2和c2的平均值；进程间通信总时长就是a3、b3和c3的平均值。可选的，还可以利用统计学的其他统计方法对上述数据进行统计，例如方差。另外，在对上述的通信次数、服务等待时长、通信服务时长和进程间通信总时长进行统计和监控时，可以绘制直方图进行直观的展示，利用直方图进一步获取到系统的繁忙程度，从而能够通过后续的对客户端的限制措施，对系统进行优化，保证系统的流畅性。参阅图12，图12是本申请提供的移动终端一实施例的结构示意图，该移动终端120包括获取模块121、判断模块122和等待模块123。其中，获取模块121用于在客户端向服务端发送binder请求时，获取客户端已使用的binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断模块122用于判判断第一数量是否大于第一设定阈值；等待模块123用于在判断模块122的判断结果为是时，将binder请求加入等待队列的末端，以暂停响应客户端发送的binder请求。参阅图13，图13是本申请提供的移动终端另一实施例的结构示意图，该移动终端130包括处理器131和存储器132，其中，处理器131和存储器132可以通过一条数据总线耦接。其中，存储器132用于存储计算机程序，计算机程序在被处理器131执行时，用于实现如下方法步骤：在客户端向服务端发送binder请求时，获取客户端已使用的binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否大于第一设定阈值；若是，将binder请求加入等待队列的末端，以暂停响应客户端发送的binder请求。参阅图14，图14是本申请提供的计算机存储介质一实施例的结构示意图，该计算机存储介质140用于存储计算机程序141，计算机程序141在被处理器执行时，用于实现如下方法步骤：在客户端向服务端发送binder请求时，获取客户端已使用的binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否大于第一设定阈值；若是，将binder请求加入等待队列的末端，以暂停响应客户端发送的binder请求。可以理解的，上述图12中的虚拟模块所执行的步骤，以及图13和图14实施例中的计算机程序在被处理器执行时，所实现的方法步骤与上述移动终端及其进程间通信的限制方法的实施例类似，这里不再赘述。本申请的实施例以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
，均同理包括在本申请的专利保护范围内。当前第1页12