CN109032812A - 一种移动终端及其进程间通信的限制方法、存储介质 - Google Patents
一种移动终端及其进程间通信的限制方法、存储介质 Download PDFInfo
- Publication number
- CN109032812A CN109032812A CN201810700003.4A CN201810700003A CN109032812A CN 109032812 A CN109032812 A CN 109032812A CN 201810700003 A CN201810700003 A CN 201810700003A CN 109032812 A CN109032812 A CN 109032812A
- Authority
- CN
- China
- Prior art keywords
- client
- server
- binder
- communication
- interprocess communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请公开了一种移动终端及其进程间通信的限制方法、存储介质，该进程间通信的限制方法包括：获取服务端的可用binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否小于第一设定阈值；若是，限制第一类客户端与服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。通过上述方式，能够减小服务端的繁忙程度，保证系统的流畅性。
Description
技术领域
本申请涉及移动终端技术领域，特别是涉及一种移动终端及其进程间通信的限制方法、存储介质。
背景技术
Android操作系统中，应用与服务间经常需要进行数据传输，一般可以采用进程间通信的方式，例如，可以通过Binder机制进行传输，从而获取对方的数据。
在利用Binder机制进行通信的过程中，通常一个服务端会与多个客户端进行通信，这样会加重服务端的负担，当进程间通信过于繁忙时，会影响服务或者系统的流畅性。
发明内容
本申请采用的一个技术方案是：提供一种进程间通信的限制方法，该限制方法包括：获取服务端的可用binder线程的第一数量；其中，binder 线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否小于第一设定阈值；若是，限制第一类客户端与服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括：获取模块，用于获取服务端的可用binder线程的第一数量；其中， binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断模块，用于判断第一数量是否小于第一设定阈值；限制模块，用于在判断模块的判断结果为是时，限制第一类客户端与服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
本申请采用的另一个技术方案是：提供一种移动终端，该移动终端包括处理器和存储器，其中，存储器用于存储计算机程序，计算机程序在被处理器执行时，用于实现如上述的方法。
本申请采用的另一个技术方案是：提供一种计算机存储介质，该计算机存储介质用于存储计算机程序，计算机程序在被处理器执行时，用于实现如上述的方法。
本申请提供的进程间通信的限制方法包括：获取服务端的可用 binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否小于第一设定阈值；若是，限制第一类客户端与服务端之间的 binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。通过上述方式，基于服务端的binder线程的使用情况，来对相对不重要的第一类客户端的通信进行限制，而不影响较为重要的第二类客户端的正常通信，从而能够减小服务端的繁忙程度，保证系统的流畅性。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：
图1是本申请提供的进程间通信的限制方法第一实施例的流程示意图；
图2是进程间通信的原理示意图；
图3是Binder通信机制的原理示意图；
图4是客户端和服务端的交互示意图；
图5是本申请提供的进程间通信的限制方法第二实施例的流程示意图；
图6是图5的交互示意图；
图7是本申请提供的进程间通信的限制方法第三实施例的流程示意图；
图8是图7的交互示意图；
图9是本申请提供的进程间通信的限制方法第四实施例的流程示意图；
图10是本申请提供的进程间通信的限制方法第五实施例的流程示意图；
图11是本申请提供的进程间通信的限制方法第六实施例的流程示意图；
图12是本申请提供的进程间通信的限制方法第七实施例的流程示意图；
图13是本申请提供的进程间通信的限制方法第八实施例的流程示意图；
图14是本申请提供的移动终端一实施例的结构示意图；
图15是本申请提供的移动终端另一实施例的结构示意图；
图16是本申请提供的计算机存储介质一实施例的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
参阅图1，图1是本申请提供的进程间通信的限制方法第一实施例的流程示意图，该方法包括：
步骤11：获取服务端的可用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、Service Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder 驱动进行交互的，从而实现IPC通信方式。其中Binder驱动位于内核空间，Client、Server、Service Manager位于用户空间。Binder驱动和Service Manager可以看做是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线程数 |
| 32 | 20 | 12 |
其中，已使用的20个binder线程中可能是多个客户端使用的，其中包括前台客户端和第一类客户端。可以理解的，当服务端的可用binder 线程的数量过少的、或者耗尽时，将无法响应客户端发送的binder请求，造成客户端与服务端之间无法进行正常的binder通信，进而影响客户端的运行。
可选的，在一实施例中，可以在服务端的binder线程每次被使用以及释放的时候统计服务端的可用binder线程的数量。例如，记可用binder 线程数量为N，当一个客户端发送binder请求给服务端后，该服务端发起一个binder线程来响应该binder请求时，即当前的可用binder线程为 N-1，当一个客户端与该服务端的一次通信结束之后，释放一个binder 线程，即当前的可用binder线程为N+1，通过这种方式，可以实时的记录服务端的可用binder线程的数量。
步骤12：判断第一数量是否小于第一设定阈值。
在步骤12的判断结果为是时，服务端正常响应客户端发送的binder 请求，进行客户端与服务端之间的进程间通信。
在步骤12的判断结果为否时，执行步骤13。
其中，第一设定阈值可以是根据经验设置的，另外可以参考服务端的binder线程的总数量，可选的，该第一设定阈值一般较小，例如，可以是binder线程总数量的10％。另外，可以获取系统出现不流畅、崩溃等现象时，服务端所剩余的可用binder线程的数量。假设一服务端的 binder线程的总数量为32个，那么，可以将第一设定阈值设置为0-10 个。
在一具体的实施例中，该第一设定阈值为零，步骤12具体为：判断第一数量是否为零。可以理解的，在该实施例中，相当于判断服务端的可用binder线程是否耗尽。
步骤13：限制第一类客户端与服务端之间的binder通信。
其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
可选的，可以预先根据客户端的重要程度对客户端进行分类，例如，可以用户自行手动进行分类。在一实施例中，可以将社交类客户端、金融类客户端等重要的客户端划分为第二类客户端，将一些游戏、新闻类的不重要的客户端划分为第一类客户端。当然，用户随时可以根据需求调整一个客户端的分类。
例如，手机上同行运行了A软件和B软件，其中，A软件为第一类客户端，而B软件为第二类客户端，结合步骤13的方式，此时，B软件较为重要，保持继续运行，B软件与服务端之间的binder通信也继续说保持，而限制A软件与服务端之间的binder通信。
其中，限制第一类客户端与服务端之间的binder通信的方式有多种，例如，可以直接关闭第一类客户端、禁止第一类客户端向该服务端发送 binder请求、禁止该服务端响应第一类客户端发送的binder请求、将第一类客户端发送的binder请求加入等待队列等等方式。
可以理解的，上述实施例中的客户端和服务端是可以自行定义的，因此上述方式可以适用于任意应用程序或者服务。
本实施例提供的进程间通信的限制方法包括：获取服务端的可用 binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否小于第一设定阈值；若是，限制第一类客户端与服务端之间的 binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。通过上述方式，基于服务端的binder线程的使用情况，来对相对不重要的第一类客户端的通信进行限制，而不影响较为重要的第二类客户端的正常通信，从而能够减小服务端的繁忙程度，保证系统的流畅性
参阅图5，图5是本申请提供的进程间通信的限制方法第二实施例的流程示意图，该方法包括：
步骤51：获取服务端的可用binder线程的第一数量。
其中，binder线程由服务端提供，并用于响应客户端发送的binder 请求以实现客户端与服务端之间的通信。
步骤52：判断第一数量是否小于第一设定阈值。
在步骤52的判断结果为否时，服务端正常响应客户端发送的binder 请求，进行客户端与服务端之间的进程间通信。
在步骤52的判断结果为是时，执行步骤53。
步骤53：判断第一类客户端中的目标客户端是否为后台客户端。
后台客户端是指在后台运行的客户端，通常把用户正在操作的程序称为前台程序，而用户没有操作但也在运行的程序称为后台程序。这里的程序也就是指客户端。
在步骤53的判断结果为是时，执行步骤54。
步骤54：限制目标客户端与服务端之间的binder通信。
可以理解的，本实施例区别于上述实施例的不同之处在于，本实施例并不限制所有的第一类客户端，而且限制那些第一类客户端中的后台客户端，这样可以保证前台的客户端正常的与服务端之间进行binder通信。
可选的，在一实施例中，步骤55可以具体包括：当目标第一类客户端向服务端发送binder请求时，将binder请求加入等待队列的末端，以暂停响应目标第一类客户端发送的binder请求
结合图6，在一具体的例子中，当客户端向服务端发送第一binder 请求时，检测到服务端的可用binder线程数量大于第一设定阈值，满足响应要求，此时对第一binder请求进行响应。当客户端向服务端发送第二binder请求时，检测到服务端的可用binder线程数量小于第一设定阈值，不满足响应要求，此时将第二binder请求加入等待队列。若再次检测到服务端的可用binder线程的数量大于第一设定阈值时，将等待队列中的第二binder请求发送给服务端，服务端响应该第二binder请求。
其中，在服务端的可用binder线程大于第一设定阈值后，满足响应要求，一般先响应等待队列中的binder请求，再响应客户端当前发送的 binder请求。
可以理解的，在上述的实施例中，该客户端为第一类客户端，进一步，该客户端可以是第一类客户端中在后台运行的客户端。
本实施例的有益效果在于，保持了第一类客户端已有的binder通信，禁止第一类客户端进一步与服务端的新的通信。
可选的，在另一实施例中，步骤55可以具体包括：对目标第一类客户端进行查杀，以释放目标客户端使用的binder线程。
本实施例的有益效果在于，直接对占用binder线程较多的客户端进行查杀，释放出大量的binder线程后，可以保证其他客户端与服务端之间的binder通信。
另外，还可以将上述两种实施方式进行结合，选择性的对第一类客户端采取禁止通信或查杀的限制方式。如下：
参阅图7，图7是本申请提供的进程间通信的限制方法第三实施例的流程示意图，该方法包括：
步骤71：获取服务端的可用binder线程的第一数量。
其中，binder线程由服务端提供，并用于响应客户端发送的binder 请求以实现客户端与服务端之间的通信。
步骤72：判断第一数量是否小于第一设定阈值。
在步骤72的判断结果为是时，服务端正常响应客户端发送的binder 请求，进行客户端与服务端之间的进程间通信。
在步骤72的判断结果为否时，执行步骤73。
步骤73：判断第一类客户端中的目标客户端是否为后台客户端。
在步骤73的判断结果为是时，执行步骤74，在步骤73的判断结果为否时，执行步骤75。
步骤74：对目标客户端进行查杀，以释放目标客户端使用的binder 线程。
步骤75：当目标客户端向服务端发送binder请求时，将binder请求加入等待队列的末端，以暂停响应目标第一类客户端发送的binder请求。
可以理解的，前台客户端为用户正在使用的客户端，直接查杀会影响用户体验，在本实施例中仅仅是限制前台客户端的进一步通信，而对于后台的客户端则直接查杀。
结合图8，在一具体的例子中，当客户端向服务端发送第一binder 请求时，检测到服务端的可用binder线程数量大于第一设定阈值，满足响应要求，此时对第一binder请求进行响应。当客户端向服务端发送第二binder请求时，检测到服务端的可用binder线程数量小于第一设定阈值，不满足响应要求，且该客户端为前台客户端，此时将第二binder请求加入等待队列。当客户端向服务端发送第三binder请求时，检测到服务端的可用binder线程数量小于第一设定阈值，不满足响应要求，且该客户端为后台客户端，此时对客户端进行查杀，释放出该客户端已使用的所有binder线程。
参阅图9，图9是本申请提供的进程间通信的限制方法第四实施例的流程示意图，该方法包括：
步骤91：获取服务端的可用binder线程的第一数量。
其中，binder线程由服务端提供，并用于响应客户端发送的binder 请求以实现客户端与服务端之间的通信。
步骤92：判断第一数量是否小于第一设定阈值。
在步骤92的判断结果为是时，服务端正常响应客户端发送的binder 请求，进行客户端与服务端之间的进程间通信。
在步骤92的判断结果为否时，执行步骤93。
步骤93：获取第一类客户端中的目标客户端与服务端进行binder 通信使用binder线程的第二数量。
其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
步骤94：判断第二数量是否大于第二设定阈值。
在步骤94的判断结果为是时，执行步骤95。
步骤95：限制目标客户端与服务端之间的binder通信。
步骤95与上述实施例的步骤13类似，这不再赘述。
可以理解的，本实施例区别于上述实施例的不同之处在于，本实施例并不限制所有的第一类客户端，而且限制那些占用binder线程数量较多的第一类客户端，可以保证部分第一类客户端的正常通信，同时又能提高系统的流畅度。
参阅图10，图10是本申请提供的进程间通信的限制方法第五实施例的流程示意图，该方法包括：
步骤101：获取服务端的可用binder线程的第一数量。
其中，binder线程由服务端提供，并用于响应客户端发送的binder 请求以实现客户端与服务端之间的通信。
步骤102：判断第一数量是否小于第一设定阈值。
在步骤102的判断结果为是时，服务端正常响应客户端发送的binder 请求，进行客户端与服务端之间的进程间通信。
在步骤102的判断结果为否时，执行步骤103。
步骤103：获取第一类客户端中的目标客户端的内存占用率。
其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
可以理解的，当内存占用率较高时，对系统的流畅度影响较为严重。
步骤104：判断内存占用率是否大于第三设定阈值。
在步骤104的判断结果为是时，执行步骤105。
步骤105：限制目标客户端与服务端之间的binder通信。
步骤105与上述实施例的步骤13类似，这不再赘述。
可以理解的，本实施例区别于上述实施例的不同之处在于，本实施例并不限制所有的第一类客户端，而且限制那些占用内存较多的第一类客户端，即保证了部分第一类客户端的运行，又能减小内存的占用率，还能提高系统的流畅度。
参阅图11，图11是本申请提供的进程间通信的限制方法第六实施例的流程示意图，该方法包括：
步骤111：在客户端向服务端发起通信请求时，记录第一时间点。
步骤112：在服务端响应客户端发起的通信请求时，记录第二时间点。
步骤113：基于第一时间点和第二时间点，获取服务等待时间。
这里的服务等待时间即为第一时间点和第二时间点之间的时间段。
步骤114：保存服务等待时间，以便基于服务等待时间对服务端的通信进行监控。
参阅图12，图12是本申请提供的进程间通信的限制方法第七实施例的流程示意图，该方法包括：
步骤121：在服务端响应客户端发起的通信请求时，记录第二时间点。
步骤122：在客户端和服务端的进程间通信完成时，记录第三时间点。
步骤123：基于第二时间点和第三时间点，获取通信服务时间。
这里的通信服务时间即为第二时间点和第三时间点之间的时间段。
步骤124：保存通信服务时间，以便基于通信服务时间对服务端的通信进行监控。
参阅图13，图13是本申请提供的进程间通信的限制方法第八实施例的流程示意图，该方法包括：
步骤131：在客户端向服务端发起通信请求时，记录第一时间点。
步骤132：在客户端和服务端的进程间通信完成时，记录第三时间点。
步骤133：基于第一时间点和第三时间点，获取进程间通信总时间。
这里的进程间通信总时间即为第一时间点和第三时间点之间的时间段。
步骤134：保存获取进程间通信总时间，以便基于获取进程间通信总时间对服务端的通信进行监控。
上述图11-图13的实施例可以与上述其他实施例相结合进行实施，其从三个不同的方面获取到通信的时长，其中包括服务等待时长、通信服务时长和总时长。
其中，具体可以获取每次时长的平均值或者总时长。如下表所示：
| 通信次数 | 服务等待时长 | 通信服务时长 | 进程间通信总时长 |
| 1 | a1 | a2 | a3 |
| 2 | b1 | b2 | b3 |
| 3 | c1 | c2 | c3 |
例如，服务等待时长的平均值就是a1、b1和c1的平均值；通信服务时长的平均值就是a2、b2和c2的平均值；进程间通信总时长就是a3、 b3和c3的平均值。
可选的，还可以利用统计学的其他统计方法对上述数据进行统计，例如方差。
另外，在对上述的通信次数、服务等待时长、通信服务时长和进程间通信总时长进行统计和监控时，可以绘制直方图进行直观的展示，利用直方图进一步获取到系统的繁忙程度，从而能够通过后续的对客户端的限制措施，对系统进行优化，保证系统的流畅性。
参阅图14，图14是本申请提供的移动终端一实施例的结构示意图，该移动终端140包括获取模块141、判断模块142和限制模块143。
其中，获取模块141用于获取服务端的可用binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断模块142用于判断第一数量是否小于第一设定阈值；限制模块143用于在判断模块142的判断结果为是时，限制第一类客户端与服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
参阅图15，图15是本申请提供的移动终端另一实施例的结构示意图，该移动终端150包括处理器151和存储器152，其中，处理器151 和存储器152可以通过一条数据总线耦接。
其中，存储器152用于存储计算机程序，计算机程序在被处理器141 执行时，用于实现如下方法步骤：
获取服务端的可用binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否小于第一设定阈值；若是，限制第一类客户端与服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
参阅图16，图16是本申请提供的计算机存储介质一实施例的结构示意图，该计算机存储介质160用于存储计算机程序161，计算机程序 161在被处理器执行时，用于实现如下方法步骤：
获取服务端的可用binder线程的第一数量；其中，binder线程由服务端提供，并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信；判断第一数量是否小于第一设定阈值；若是，限制第一类客户端与服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，第一类客户端的重要程度小于第二类客户端的重要程度。
可以理解的，上述图14中的虚拟模块所执行的步骤，以及图15和图16实施例中的计算机程序在被处理器执行时，所实现的方法步骤与上述移动终端及其进程间通信的限制方法的实施例类似，这里不再赘述。
本申请的实施例以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor) 执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。
Claims (14)
1.一种进程间通信的限制方法，其特征在于，包括：
获取服务端的可用binder线程的第一数量；其中，所述binder线程由所述服务端提供，并用于响应客户端发送的binder请求以实现所述客户端与所述服务端之间的通信；
判断所述第一数量是否小于第一设定阈值；
若是，限制第一类客户端与所述服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，所述第一类客户端的重要程度小于所述第二类客户端的重要程度。
2.根据权利要求1所述的进程间通信的限制方法，其特征在于，
所述限制第一类客户端与所述服务端之间的binder通信的步骤，包括：
判断所述第一类客户端中的目标客户端是否为后台客户端；
若是，限制所述目标客户端与所述服务端之间的binder通信。
3.根据权利要求2所述的进程间通信的限制方法，其特征在于，
所述限制所述目标客户端与所述服务端之间的binder通信的步骤，包括：
当所述目标客户端向所述服务端发送binder请求时，将所述binder请求加入等待队列的末端，以暂停响应所述目标客户端发送的binder请求。
4.根据权利要求3所述的进程间通信的限制方法，其特征在于，
所述判断所述第一数量是否小于第一设定阈值的步骤之后，还包括：
若否，先响应所述等待队列中的binder请求，再响应客户端发送的binder请求。
5.根据权利要求2所述的进程间通信的限制方法，其特征在于，
所述限制所述目标客户端与所述服务端之间的binder通信的步骤，包括：
对所述目标客户端进行查杀，以释放所述目标客户端使用的binder线程。
6.根据权利要求1所述的进程间通信的限制方法，其特征在于，
所述判断所述第一数量是否小于第一设定阈值的步骤，具体为：
判断所述第一数量是否为零。
7.根据权利要求1所述的进程间通信的限制方法，其特征在于，
所述限制第一类客户端与所述服务端之间的binder通信的步骤，包括：
获取所述第一类客户端中的目标客户端与所述服务端进行binder通信使用binder线程的第二数量；
判断所述第二数量是否大于第二设定阈值；
若是，限制所述目标客户端与所述服务端之间的binder通信。
8.根据权利要求1所述的进程间通信的限制方法，其特征在于，
所述限制第一类客户端与所述服务端之间的binder通信的步骤，包括：
获取所述第一类客户端中的目标客户端的内存占用率；
判断所述内存占用率是否大于第三设定阈值；
若是，限制所述目标客户端与所述服务端之间的binder通信。
9.根据权利要求1所述的进程间通信的限制方法，其特征在于，
所述方法还包括：
在所述客户端向所述服务端发起通信请求时，记录第一时间点；
在所述服务端响应所述客户端发起的通信请求时，记录第二时间点；
基于所述第一时间点和所述第二时间点，获取服务等待时间；
保存所述服务等待时间，以便基于所述服务等待时间对所述服务端的通信进行监控。
10.根据权利要求9所述的进程间通信的限制方法，其特征在于，
所述方法还包括：
在所述客户端和所述服务端的进程间通信完成时，记录第三时间点；
基于所述第二时间点和所述第三时间点，获取通信服务时间；
保存所述通信服务时间，以便基于所述通信服务时间对所述服务端的通信进行监控。
11.根据权利要求10所述的进程间通信的限制方法，其特征在于，
所述方法还包括：
基于所述第一时间点和所述第三时间点，获取进程间通信总时间；
保存所述获取进程间通信总时间，以便基于所述获取进程间通信总时间对所述服务端的通信进行监控。
12.一种移动终端，其特征在于，包括：
获取模块，用于获取服务端的可用binder线程的第一数量；其中，所述binder线程由所述服务端提供，并用于响应客户端发送的binder请求以实现所述客户端与所述服务端之间的通信；
判断模块，用于判断所述第一数量是否小于第一设定阈值；
限制模块，用于在判断模块的判断结果为是时，限制第一类客户端与所述服务端之间的binder通信；其中，客户端按照重要程度预先划分为第一类客户端和第二类客户端，所述第一类客户端的重要程度小于所述第二类客户端的重要程度。
13.一种移动终端，其特征在于，包括处理器和存储器，其中，所述存储器用于存储计算机程序，所述计算机程序在被所述处理器执行时，用于实现如权利要求1-11任一项所述的方法。
14.一种计算机存储介质，其特征在于，用于存储计算机程序，所述计算机程序在被处理器执行时，用于实现如权利要求1-11任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810700003.4A CN109032812B (zh) | 2018-06-29 | 2018-06-29 | 一种移动终端及其进程间通信的限制方法、存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810700003.4A CN109032812B (zh) | 2018-06-29 | 2018-06-29 | 一种移动终端及其进程间通信的限制方法、存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109032812A true CN109032812A (zh) | 2018-12-18 |
| CN109032812B CN109032812B (zh) | 2020-10-02 |
Family
ID=65520980
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810700003.4A Active CN109032812B (zh) | 2018-06-29 | 2018-06-29 | 一种移动终端及其进程间通信的限制方法、存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109032812B (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110941498A (zh) * | 2019-10-22 | 2020-03-31 | 贝壳技术有限公司 | 一种数据处理方法、装置和存储介质 |
| CN112527476A (zh) * | 2019-09-19 | 2021-03-19 | 华为技术有限公司 | 资源调度方法及电子设备 |
| CN115202902A (zh) * | 2022-07-01 | 2022-10-18 | 荣耀终端有限公司 | 控制进程交互的方法及相关装置 |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7451209B1 (en) * | 2003-10-22 | 2008-11-11 | Cisco Technology, Inc. | Improving reliability and availability of a load balanced server |
| CN104750555A (zh) * | 2015-03-31 | 2015-07-01 | 北京奇虎科技有限公司 | 一种Android程序中的进程管理方法和装置 |
| CN104850460A (zh) * | 2015-06-02 | 2015-08-19 | 上海斐讯数据通信技术有限公司 | 一种服务程序线程管理方法 |
| CN105740326A (zh) * | 2016-01-21 | 2016-07-06 | 腾讯科技（深圳）有限公司 | 浏览器的线程状态监测方法及装置 |
| CN106648865A (zh) * | 2016-12-15 | 2017-05-10 | 北京奇虎科技有限公司 | 智能终端及优化游戏运行环境的方法、系统 |
| CN106776080A (zh) * | 2016-12-29 | 2017-05-31 | 北京奇虎科技有限公司 | 工作线程的连接建立方法及装置 |
| CN107145389A (zh) * | 2017-03-09 | 2017-09-08 | 深圳市先河系统技术有限公司 | 一种系统进程监控方法及计算设备 |
| CN107544840A (zh) * | 2016-06-28 | 2018-01-05 | 北京优朋普乐科技有限公司 | 一种进程管理方法及装置 |
| CN107608785A (zh) * | 2017-08-15 | 2018-01-19 | 深圳天珑无线科技有限公司 | 进程管理方法、移动终端及可读储存介质 |
| CN107967177A (zh) * | 2017-11-30 | 2018-04-27 | 努比亚技术有限公司 | 基于核心进程的内存优化方法、移动终端及可读存储介质 |
-
2018
- 2018-06-29 CN CN201810700003.4A patent/CN109032812B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7451209B1 (en) * | 2003-10-22 | 2008-11-11 | Cisco Technology, Inc. | Improving reliability and availability of a load balanced server |
| CN104750555A (zh) * | 2015-03-31 | 2015-07-01 | 北京奇虎科技有限公司 | 一种Android程序中的进程管理方法和装置 |
| CN104850460A (zh) * | 2015-06-02 | 2015-08-19 | 上海斐讯数据通信技术有限公司 | 一种服务程序线程管理方法 |
| CN105740326A (zh) * | 2016-01-21 | 2016-07-06 | 腾讯科技（深圳）有限公司 | 浏览器的线程状态监测方法及装置 |
| CN107544840A (zh) * | 2016-06-28 | 2018-01-05 | 北京优朋普乐科技有限公司 | 一种进程管理方法及装置 |
| CN106648865A (zh) * | 2016-12-15 | 2017-05-10 | 北京奇虎科技有限公司 | 智能终端及优化游戏运行环境的方法、系统 |
| CN106776080A (zh) * | 2016-12-29 | 2017-05-31 | 北京奇虎科技有限公司 | 工作线程的连接建立方法及装置 |
| CN107145389A (zh) * | 2017-03-09 | 2017-09-08 | 深圳市先河系统技术有限公司 | 一种系统进程监控方法及计算设备 |
| CN107608785A (zh) * | 2017-08-15 | 2018-01-19 | 深圳天珑无线科技有限公司 | 进程管理方法、移动终端及可读储存介质 |
| CN107967177A (zh) * | 2017-11-30 | 2018-04-27 | 努比亚技术有限公司 | 基于核心进程的内存优化方法、移动终端及可读存储介质 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527476A (zh) * | 2019-09-19 | 2021-03-19 | 华为技术有限公司 | 资源调度方法及电子设备 |
| WO2021052415A1 (zh) * | 2019-09-19 | 2021-03-25 | 华为技术有限公司 | 资源调度方法及电子设备 |
| CN112527476B (zh) * | 2019-09-19 | 2024-03-26 | 华为技术有限公司 | 资源调度方法及电子设备 |
| CN110941498A (zh) * | 2019-10-22 | 2020-03-31 | 贝壳技术有限公司 | 一种数据处理方法、装置和存储介质 |
| CN110941498B (zh) * | 2019-10-22 | 2022-09-23 | 贝壳找房(北京)科技有限公司 | 一种数据处理方法、装置和存储介质 |
| CN115202902A (zh) * | 2022-07-01 | 2022-10-18 | 荣耀终端有限公司 | 控制进程交互的方法及相关装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109032812B (zh) | 2020-10-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10628216B2 (en) | I/O request scheduling method and apparatus by adjusting queue depth associated with storage device based on hige or low priority status | |
| WO2020181813A1 (zh) | 一种基于数据处理的任务调度方法及相关设备 | |
| CN109032812A (zh) | 一种移动终端及其进程间通信的限制方法、存储介质 | |
| US20200348977A1 (en) | Resource scheduling methods, device and system, and central server | |
| CN108984321A (zh) | 一种移动终端及其进程间通信的限制方法、存储介质 | |
| CN109618174A (zh) | 一种直播数据传输方法、装置、系统以及存储介质 | |
| CN106021358A (zh) | 一种异常信息记录方法及系统 | |
| CN109726005A (zh) | 用于管理资源的方法、服务器系统和计算机程序产品 | |
| CN108924128A (zh) | 一种移动终端及其进程间通信的限制方法、存储介质 | |
| CN108681481A (zh) | 业务请求的处理方法及装置 | |
| CN110555019A (zh) | 一种基于业务端的数据清洗方法 | |
| CN109117280A (zh) | 电子装置及其限制进程间通信的方法、存储介质 | |
| CN109117279A (zh) | 电子装置及其限制进程间通信的方法、存储介质 | |
| CN109002364A (zh) | 进程间通信的优化方法、电子装置以及可读存储介质 | |
| CN108028806A (zh) | 网络功能虚拟化nfv网络中分配虚拟资源的方法和装置 | |
| CN111282263A (zh) | 事件消息的处理方法、装置、电子设备及可读存储介质 | |
| CN109117278A (zh) | 一种移动终端及其进程间通信的限制方法、存储介质 | |
| CN109032814A (zh) | 一种移动终端及其进程间通信的监控方法、存储介质 | |
| CN109039952A (zh) | 一种移动终端及其进程间通信的限制方法、存储介质 | |
| US20130346908A1 (en) | Late instantiation of dependent objects | |
| KR101560879B1 (ko) | 철강 공정 미들웨어의 태스크 관리 및 서비스 실행을 위한 시스템 | |
| CN109117340A (zh) | 一种移动终端及其进程间通信的监控方法、存储介质 | |
| CN111352710B (zh) | 进程管理方法及装置、计算设备、存储介质 | |
| CN107329819A (zh) | 一种作业管理方法及装置 | |
| CN114726657A (zh) | 中断管理和数据收发管理的方法、装置及智能网卡 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |