进程间通信的优化方法、电子装置以及可读存储介质与流程

文档序号:16262914发布日期:2018-12-14 21:43阅读:130来源:国知局
进程间通信的优化方法、电子装置以及可读存储介质与流程
本发明涉及电子设备
技术领域
,特别是涉及一种进程间通信的优化方法、电子装置及计算机可读存储介质。
背景技术
目前,随着科学技术的不断发展,智能手机等电子装置日渐成为人们日常生活的必需品。安卓系统是智能手机等电子装置的一种常见的操作系统,安卓系统中的两个进程之间通常需要进行通信,进程之间的用户空间是不能共享的,因此两个进程之间的通信通常需要binder机制来实现通信。在进程间通信繁忙时,导致电子装置的系统出现卡顿甚至崩溃的情况,严重影响用户体验。技术实现要素:本申请实施例采用的一个技术方案是:提供一种进程间通信的优化方法,该优化方法包括:获取服务端的可用binder线程的第一数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信;根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别;将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高。本申请实施例采用的另一个技术方案是:提供一种电子装置,电子装置包括:获取模块,用于获取服务端的可用binder线程的第一数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信;查找模块,用于根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别;设置模块,用于将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高。本申请实施例采用的又一个技术方案是:提供一种电子装置,该电子装置包括处理器和与处理器连接的存储器,存储器用于存储计算机程序,处理器用于执行计算机程序以实现上述的优化方法。本申请实施例采用的又一个技术方案是:一种计算机可读存储介质,计算机可读存储介质用于存储计算机程序,计算机程序能够被执行以实现上述的方法。本申请实施例通过获取服务端的可用binder线程的第一数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信;根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别;将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高,能够避免服务端过于繁忙导致的系统卡顿或者崩溃,且能够提升系统的性能。附图说明图1是本申请第一实施例的进程间通信的优化方法的流程示意图;图2是本申请实施例中进程间通信的原理示意图;图3是binder通信机制的原理示意图;图4是客户端和服务端的交互示意图;图5是本申请第二实施例的进程间通信的优化方法的流程示意图;图6是本申请第三实施例的进程间通信的优化方法的流程示意图;图7是本申请实施例电子装置的模块示意图;图8是本申请实施例电子装置的硬件结构示意图。具体实施方式下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是,此处所描述的具体实施例仅用于解释本申请,而非对本申请的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。本申请中的术语“第一”、“第二”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。请参阅图1,图1是本申请第一实施例的进程间通信的优化方法的流程示意图。在本实施例中,进程间通信的优化方法可以包括以下步骤:步骤101:获取服务端的可用binder线程的第一数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信。其中,binder机制是安卓系统中进程间通讯(ipc)的一种方式。安卓系统中的四大组件分别为:activity(工作流)、service(服务)、broadcast(广播接收器)、contentprovider(内容提供者)、不同的app(应用程序)。这四大组件都运行在不同的进程中,binder机制是这些进程间通讯的桥梁。如图2所示,图2是本申请实施例中进程间通信的原理示意图,每个安卓系统的进程,只能运行在自己进程所拥有的虚拟地址空间。虚拟地址空间包括彼此独立的用户空间和内核空间。对于用户空间,客户端进程和服务端进程之间彼此是不能共享的,而客户端进程和服务端进程之间的内核空间却是可共享的。客户端进程与服务端进程的每一次通信都要通过位于内核空间的binder驱动程序来实现。基于上述binder机制的原理,不难理解,客户端进程和服务端进程可以是任意两个进程,可以是应用,也可以是服务,例如,可以是应用与应用之间的通信,也可以是应用与服务之间的通信。进一步参阅图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可以看做是安卓平台的基础架构,而client和server是安卓的应用层,开发人员只需自定义实现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。为了使这种穿越更加真实,binder驱动会将线程t1的一些属性赋给线程t2,特别是线程t1的优先级nice值,这样线程t2会使用和t1类似的时间完成任务。对于server进程s,可能会有许多client同时发起请求,为了提高效率往往开辟线程池(多个线程)并发处理收到的binder请求。可以理解的,两个进程之间的通信一般会使用到多个线程。例如,android系统规定systemserver进程最多可以创建32个binder线程用于进程间数据通信;surfaceflinger进程最多可以创建4个binder线程用于进程间数据通信;程序应用进程最多可以创建8个binder线程用于进程间数据通信。另外,在电子装置中,多个应用可能同时获取同一服务,所以,一个服务端可能同时与多个客户端之间进行进程间通信,在这种情况下,由于服务端的通信次数多、线程使用量较大、通信过于频繁,会造成系统的卡顿,本实施例主要是通过获取服务端可用的binder线程的数量来衡量服务端的瞬时繁忙程度,然后根据服务端的瞬时繁忙程度来动态的调整服务端在系统中的优先级别。可选的,在本实施例中,该服务端可以是系统服务端。具体地,如图4所示,图4是客户端和服务端的交互示意图,在客户端与服务端的通信过程中,主要包括三个过程,客户端向服务端发起通信请求、服务端响应客户端发起的通信请求、客户端和服务端之间进行数据交互。其中,经过上述的过程才算是一个完整的通信过程。可以理解的,在客户端向服务端发起binder请求时,还未占用服务端的binder线程,当服务器开始响应时,就会开启一个binder线程进行响应,此时客户端开始耗用服务端的binder线程。以服务端的binder线程的总数量是32个为例,如下表所示:其中,已使用的20个binder线程中可能是多个客户端使用的,其中包括前台客户端和后台客户端。可以理解的,当服务端的可用binder线程的数量过少的、或者耗尽时,会导致系统不流畅,甚至崩溃。步骤102:根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别。其中,在电子装置的操作系统中,每个进程都有相应的优先级,优先级决定它何时运行和接收多少cpu时间,服务端和客户端作为一种进程也不例外。例如,优先级共32级,是从0到31的数值,称为基本优先级别(baseprioritylevel)。系统按照不同的优先级调度进程的运行,0-15级是普通优先级,进程的优先级可以动态变化,高优先级进程优先运行,只有高优先级进程不运行时,才调度低优先级进程运行,优先级相同的进程按照时间片轮流运行。16-31级是实时优先级,实时优先级与普通优先级的最大区别在于相同优先级进程的运行不按照时间片轮转,而是先运行的进程就先控制cpu,如果它不主动放弃控制,同级或低优先级的进程就无法运行。用户可以预先设定第一数量与优先级别的对应关系表,电子装置接收用户设定的第一数量与优先级别对应关系表。在对应关系表中,第一数量的数值越大,对应的优先级别越高。第一数量是指服务端可用的binder线程数量,优先级别为服务端的优先级别。根据获取的第一数量找到对应的优先级别,即第一目标优先级别,第一目标优先级别是用于调整服务端的优先级别的目标数值。请参阅下表一,表一是一种实例中第一数量与优先级别的对应关系表。第一数量优先级别320311…………229130031第一数量越小,说明服务端可用的线程数量越少,服务端越繁忙,此时需要将服务端调整至较高的优先级别,使其能够获得更多的系统资源,不至于出现卡顿或者崩溃的现象;反之,第一数量越大,说明服务端可用的线程数量越多,服务端越空闲,此时需要将服务端调整至较低的优先级别,避免服务端耗用过多系统资源;第一数量是瞬时值,即随时间动态变化,因此,对应的优先级别也是动态变化的。根据服务端可用的binder线程数量查找到的对应的优先级作为第一目标优先级别,便于后续设定服务端的优先级别。步骤103:将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高。其中,将服务端的优先级别设定为步骤102中得到的第一目标优先级别。下面结合表一且通过具体的例子进行说明。在第一时间点获取到的服务端可用的binder线程数量为31,则将服务端的优先级别设定为1。在第二时间点获取到的服务端可用的binder线程数量为2,则将服务端的优先级别设定为29。在第三时间节点获取到的服务端可用的binder线程数量为31,则将服务端的优先级别设定为1。通过上述方式,根据实时获取的瞬时服务端可用的binder线程的数量,动态的设定服务端的优先级别,在服务端可用binder线程较少时,将服务端的优先级别设定为较大值,缓解服务端的繁忙程度,在服务端可用binder线程较多时,将服务端的优先级别设定为较小的值,避免服务端占用过多的系统资源,根据瞬时的指标进行动态的设定服务端的优先级别,能够实时保证系统运行的流畅性。请参阅图5,图5是本申请第二实施例的进程间通信的优化方法的流程示意图。在本实施例中,进程间通信的优化方法可以包括以下步骤:步骤501:获取服务端的可用binder线程的第一数量,并获取客户端耗用的binder线程的第二数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信。其中,获取特定客户端耗用的binder线程数量,如前所述,服务端可能同时与多个客户端通信,多个客户端耗用的binder线程可能不一样。例如,表二是在某个时间点客户端与其对应消耗的binder线程数量的对应关系表。客户端第二数量客户端a10客户端b1客户端c10客户端d10例如,获取客户端b耗用的binder线程数量为1。即第二数量为1。根据表二中所举的例子若服务端的binder线程的总数量为32,那么服务端可用的线程数量为binder线程的总数量-客户端a耗用的binder线程数量-客户端b耗用的binder线程数量-客户端c耗用的线程数量-客户端d耗用的binder线程数量=32-10-1-10-10=1。即第一数量为1。步骤502:根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别,且根据第二数量在第二数量与优先级别对应关系表中查找对应的第二目标优先级别。其中,第一目标优先级别的查找可以参见上文实施例的描述。根据表一中的对应关系,可以查找出第一数量1对应的优先级别是30,即第一目标优先级别是30。请参阅表三,表三是一种客户端耗用的binder线程数量与客户端优先级别的对应关系表。其中,第二数量越大,对应的第二目标优先级别越低。即在客户端b消耗的binder线程数量越大时,将客户端b的优先级别设置的越低,以减少该客户端b耗用的系统资源,减轻服务端的繁忙程度,对系统性能进行优化。根据表三中的对应关系客户端b耗用的binder线程数量1,对应的第二目标优先级别是32。步骤503:将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高,将客户端的优先级别设定为第二目标优先级别,其中,第二数量越大,对应的第二目标优先级别越低。通过上述方式,根据实时获取的瞬时服务端可用的binder线程的数量,动态的设定服务端的优先级别,在服务端可用binder线程较少时,将服务端的优先级别设定为较大值,缓解服务端的繁忙程度,在服务端可用binder线程较多时,将服务端的优先级别设定为较小的值,避免服务端占用过多的系统资源,根据瞬时的指标进行动态的设定服务端的优先级别,能够实时保证系统运行的流畅性;进一步地,根据客户端瞬时耗用的binder线程数量动态的设定客户端的优先级别,使得耗用binder线程数量较多时,将客户端的优先级别设定为较低,降低其获取系统资源的能力,减小服务端的压力。请参阅图6,图6是本申请第三实施例的进程间通信的优化方法的流程示意图。在本实施例中,进程间通信的优化方法可以包括以下步骤:步骤601:获取服务端的可用binder线程的第一数量,并获取客户端耗用的binder线程的第二数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信。步骤602:根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别,并判断第二数量是否大于设定数量。步骤603:将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高;以及在判断到第二数量大于设定数量时,限制客户端与服务端之间的binder通信。其中,例如,如表二所示,获取客户端a耗用的binder线程数量为10。若设定数量为8,那么客户端a耗用的binder线程数量10大于8。电子装置会对客户端a进行限制,限制其与服务端之间的通信。具体的限制方式可以为对客户端a进行关闭处理。在其他实施例中,限制客户端a与服务端之间的通信还可以为:限制客户端a使用binder线程的数量。限制客户端a耗用的binder线程数量具体可以为:每当客户端a向服务端发送binder请求时,截获binder请求,并将binder请求加入等待队列的末端,其中,在设定时间之后处理等待队列中的binder请求。将客户端a向服务端发送的binder请求截获,截获是指拦截binder请求使其暂时不会发送至服务端,并且获取该binder请求,将其加入等待队列的末端,在设定时间之后在对该binder请求进行处理,相当于建立一种缓冲机制,可以缓解服务端的压力,避免出现系统卡顿或者崩溃的现象。在一种情况下,可以在设定时间之后将等待队列首端的binder请求发送至服务端,以允许服务端响应binder请求,并进行与客户端之间的binder通信。在另一种情况下,在设定时间之后,返回获取客户端所耗用的binder线程的第二数量,并重新判断在设定时间之后获取第二数量是否大于设定数量。若是,即该客户端a仍然耗用了过多的binder线程,则将binder请求保留在等待队列中。若否,即客户端a此时耗用的binder线程不多,则将等待队列首端的binder请求发送至服务端,以允许服务端响应binder请求,并进行与客户端之间的binder通信。通过上述方式,在根据服务端的可用binder线程数量动态调整服务端的优先级别的情况下,进一步对耗用binder线程较多的客户端进行限制,限制其耗用服务端的binder线程数量或者直接对其进行关闭查杀,从而达到缓解服务端繁忙的目的,实现系统的优化和性能提升。请参阅图7,图7是本申请实施例电子装置的模块示意图。在本实施例中,电子装置70可以包括以下模块:获取模块71,用于获取服务端的可用binder线程的第一数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信。查找模块72,用于根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别。设置模块73,用于将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高。上述各个模块执行的步骤的具体内容可以参见上文的描述,此处不再赘述。请参阅图8,图8是本申请实施例电子装置的硬件结构示意图。在本实施例中,电子装置80包括处理器81和存储器82。存储器82与处理器81电连接。存储器82用于存储计算机程序,处理器81用于执行该计算机程序以实现上述任意一实施例的方法。本发明实施例还提供一种计算机可读存储介质,该计算机可读存储介质用于存储计算机程序,该计算机程序能够被处理器执行以实现上述实施例中提供的方法。可以理解的,在本实施例中的可读存储介质存储的计算机程序,所用来执行的方法与上述实施例提供的方法类似,其原理和步骤相同,这里不再赘述。其中,该存储介质可以为u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。本发明上述任意一实施中的电子装置可以为智能手机、可穿戴式智能设备、平板电脑、掌上电脑、数字pda或者其他电子装置。本申请实施例通过获取服务端的可用binder线程的第一数量;其中,binder线程由服务端提供,并用于响应客户端发送的binder请求以实现客户端与服务端之间的通信;根据第一数量在第一数量与优先级别对应关系表中查找对应的第一目标优先级别;将服务端的优先级别设定为第一目标优先级别,其中,第一数量越小,对应的第一目标优先级别越高,能够避免服务端过于繁忙导致的系统卡顿或者崩溃,且能够提升系统的性能以上所述仅为本申请的实施方式,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的
技术领域
,均同理包括在本申请的专利保护范围内。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1