进程通信监控方法、电子装置及计算机可读存储介质与流程

本发明涉及电子设备
技术领域：
，特别是涉及一种进程通信监控方法、电子装置及计算机可读存储介质。
背景技术：
目前，随着科学技术的不断发展，智能手机等电子装置日渐成为人们日常生活的必需品。安卓系统是智能手机等电子装置的一种常见的操作系统，安卓系统中的两个进程之间通常需要进行通信，进程之间的用户空间是不能共享的，因此两个进程之间的通信通常需要binder机制来实现通信。现有的电子装置没有对进程间采用binder机制进行通信情况的监控机制，无法对进程间通信的优化和验证提供有效的数据支持。技术实现要素：本申请实施例采用的一个技术方案是：提供一种进程通信监控方法，该方法包括：在客户端进程与服务端进程之间通过binder驱动程序进行进程间通信的过程中，记录客户端进程向服务端进程发起通信请求的第一时间节点，以及记录服务端进程回复通信请求的第二时间节点；根据第一时间节点和第二时间节点计算通信的消耗时长并保存，消耗时长为从第一时间节点到第二时间节点的时长；判断消耗时长是否大于预设时长，若是，则记录当前服务端进程的使用情况和当前系统使用情况。本申请实施例采用的另一个技术方案是：提供一种电子装置，该电子装置包括：记录模块，用于在客户端进程与服务端进程之间通过binder驱动程序进行进程间通信的过程中，记录客户端进程向服务端进程发起通信请求的第一时间节点，以及记录服务端进程回复通信请求的第二时间节点；计算模块，用于根据第一时间节点和第二时间节点计算通信的消耗时长并保存，消耗时长为从第一时间节点到第二时间节点的时长；判断模块，用于判断消耗时长是否大于预设时长；若判断模块判断到消耗时长大于预设时长，则记录模块进一步记录当前服务端进程的使用情况和当前系统使用情况。本申请实施例采用的又一个技术方案是：提供一种电子装置，该电子装置包括处理器和与处理器连接的存储器，存储器用于存储计算机程序，处理器用于执行计算机程序以实现上述的监控方法。本申请实施例采用的又一个技术方案是：一种计算机可读存储介质，计算机可读存储介质用于存储计算机程序，计算机程序能够被执行以实现上述的方法。本申请实施例通过在客户端进程与服务端进程之间通过binder驱动程序进行进程间通信的过程中，记录客户端进程向服务端进程发起通信请求的第一时间节点，以及记录服务端进程回复通信请求的第二时间节点；根据第一时间节点和第二时间节点计算通信的消耗时长并保存，消耗时长为从第一时间节点到第二时间节点的时长；判断消耗时长是否大于预设时长，若是，则记录当前服务端进程的使用情况和当前系统使用情况，能够有效的监控进程间通信的消耗时长，为后续的系统优化和验证提供有效的数据支持，且能够在监控消耗时长过长时，即通信效率过低时，进一步记录当前服务端进程的使用情况和当前系统使用情况，从而能够有效的记录慢传输时的关键数据，在保证有效监控的情况下利于减小监控数据的数据量，节省监控数据的存储消耗和传输消耗。附图说明图1是本申请第一实施例的进程通信监控方法的流程示意图；图2是本申请实施例中进程间通信的原理示意图；图3是binder通信机制的原理示意图；图4是本申请实施例服务端进程与客户端进程通信过程的时间轴示意图；图5是本申请第二实施例的进程通信监控方法的部分流程示意图；图6是本申请实施例时间段与通信次数对应关系的柱状图；图7是本申请第三实施例的进程通信监控方法的部分流程示意图；图8是本申请实施例电子装置的模块示意图；图9是本申请实施例电子装置的硬件结构示意图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。每个安卓系统的进程，只能运行在自己进程所拥有的虚拟地址空间。虚拟地址空间包括彼此独立的用户空间和内核空间。对于用户空间，不同进程之间彼此是不能共享的，而不同进程之间的内核空间却是可共享的。不同的两个进程(例如，客户端进程与服务端进程)的每一次通信都要通过位于内核空间的binder驱动程序来实现。本申请在电子装置端实现安卓系统的进程间通信的通信效率的监控。具体参见下文的描述。请参阅图1，图1是本申请第一实施例的进程通信监控方法的流程示意图。在本实施例中，进程通信监控方法可以包括以下步骤：步骤101：在客户端进程和服务端进程之间通过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通信。请参阅图4，图4是本申请实施例服务端进程与客户端进程通信过程的时间轴示意图。在每次客户端进程与服务端进程进行通信过程中，可以有两个通信阶段和三个关键的时间节点。三个时间节点分别是第一时间节点t1、第二时间节点t2以及第三时间节点t3。第一时间节点t1是客户端进程向服务端进程发起通信请求的时间节点，其是通信开始的时间节点。第二时间节点t2是服务端进程回复通信请求的时间节点，其是通信结束的时间节点。第三时间节点t3是服务端进程被唤醒时的时间节点。这三个时间节点按时间先后顺序依次是第一时间节点t1、第三时间节点t3以及第二时间节点t2。两个通信阶段分别第一通信阶段和第二通信阶段。第一通信阶段是第一时间节点到第三时间节点，第二通信阶段是第三时间节点到第二时间节点。步骤102：根据第一时间节点和第二时间节点计算通信的消耗时长并保存，消耗时长为从第一时间节点到第二时间节点的时长。承前所述，第一时间节点是通信开始的时间节点，第二时间节点是通信结束的时间节点。从第一时间节点到第三时间节点的时间差即为通信的消耗时长。将通信的消耗时长保存至监控数据。每间隔一定时间将监控数据上传至服务器，或者，在监控数据的数据量超过预定数据量时将监控数据上传至服务器。例如，每隔5分钟将监控数据上传至服务器，或者，每当监控数据的数据量超过5m时，将监控数据上传至服务器。电子装置的服务商能够根据服务器接收到的监控数据对电子装置的操作系统进行优化或者验证等。监控数据也可以不上传至服务器，而是由电子装置根据监控数据执行相应的操作来对电子装置的性能进行优化。例如，对通信的消耗时长过大的客户端进程进行关闭处理，或者，对通信的消耗时长过大的客户端进程的资源使用进行限制处理。从而可以达到优化系统性能的目的，使用户使用电子装置时更加流畅。再例如，对通信的消耗时长过大的服务端进程进行系统资源的优先分配。具体而言，可以对通信的消耗时长过大的服务端进程进行提升优先级的处理。每个进程都有相应的优先级，优先级决定它何时运行和接收多少cpu时间。例如，优先级共32级，是从0到31的数值，称为基本优先级别(baseprioritylevel)。系统按照不同的优先级调度进程的运行，0-15级是普通优先级，进程的优先级可以动态变化，高优先级进程优先运行，只有高优先级进程不运行时，才调度低优先级进程运行，优先级相同的进程按照时间片轮流运行。16-31级是实时优先级，实时优先级与普通优先级的最大区别在于相同优先级进程的运行不按照时间片轮转，而是先运行的进程就先控制cpu，如果它不主动放弃控制，同级或低优先级的进程就无法运行。在一种实施例中，可以对通信的消耗时长过小的服务端进程降低优先级的处理，或者也可以根据通信的消耗时长动态的调整服务端进程的优先级别。通信的消耗时长越长则将对应的服务端进程的优先级别调整的越高，通信的消耗时长越短则将对应的服务端进程的优先级别调整的越低。步骤103：判断消耗时长是否大于预设时长。其中，若是，即若消耗时长大于预设时长，则说明客户端进程与服务端进程之间通信的传输效率低，触发慢传输统计，执行步骤104。其中，若否，即若消耗时长小于或者等于预设时长，则返回步骤101。步骤104：记录当前服务端进程的使用情况和当前系统使用情况；以及计算从第一时间节点到第三时间节点的时长并保存，计算从第三时间节点到第二时间节点的时长并保存。其中，服务端进程的使用情况包括：当前服务端进程可供使用的线程数、当前服务端进程的binder实体节点数量、当前服务端进程的binder引用数量中的至少一者。当前系统使用情况包括：当前运行的cpu及其频率、当前系统正在运行的进程和线程的数量、当前系统的总负载中的至少一者。其中，当前系统使用情况和服务端进程的使用情况可以包括其他信息，本申请对此不做限定。例如，当前系统的使用情况还可以包括：内存的占用率和cpu的占用率等。可选地，可以进一步将记录的当前系统使用情况和服务端进程的使用情况保存至监控数据，从而可以在出现慢传输的情况时，结合慢传输时的系统使用情况和服务端进程的使用情况，对系统进行优化或验证。例如，将监控数据上传至服务器，以使得电子装置的服务商能够根据监控数据对电子装置的操作系统进行优化或验证。应理解，电子装置也可以在本地根据监控数据执行相应的操作，从而对系统性能进行有针对性的优化。例如，根据当前系统的使用情况分析是否由于当前系统运行的进程数量过多导致慢传输，若是则可以关闭一部分不重要的进程。再例如，根据当前服务端进程的使用情况分析是否由于服务端进程可供使用的线程数过少导致慢传输，若是则可以关闭一部分正在使用服务端进程的线程的客户端进程，从而实现对电子装置的系统性能的优化，使电子装置的运行更加流畅。在消耗时长大于预设时长时，计算从第一时间节点到第三时间节点的时长并保存，计算从第三时间节点到第二时间节点的时长并保存至监控数据。也就是说，在慢传输时，将第一通信阶段和第二通信阶段的各自消耗的时长进行保存至监控数据。电子装置可以分析是第一通信阶段还是第二通信阶段消耗的时长过长，导致整个一次通信的消耗时间过长，然后做出相应的处理对系统性能进行优化。例如，从第一时间节点到第三时间节点的时长为第一时长，第三时间节点到第二时间节点的时长第二时长，电子装置比较第一时长和第二时长的大小关系，若第一时长大于第二时长，则说明是第一通信阶段的消耗时间过长导致整个一次通信的消耗时间过长，即说明从客户端进程发出通信请求到服务端进程被唤醒的消耗时间过长，那么可以认为是系统使用情况负荷较大(例如，当前系统正在运行的进程和线程的数量过大、当前系统的总负载过大、当前系统的内存占用率过大、cpu使用率过高等)，导致服务端进程唤醒等待时间长，那么电子装置可以提升服务端进程的优先级或者关闭重要级别低的进程来解决传输慢的问题；若第一时长小于第二时长，则说明是第二通信阶段的消耗时间过长导致整个一次通信的消耗时间过长，即说明从服务端进程被唤醒到服务端回复通信请求的消耗时间过长，那么可以认为是服务端进程可用的线程数量耗尽或者过低导致的整一次通信的消耗时间过长，电子装置可以对消耗服务端进程的线程数量较大的客户端进程进行关闭处理，或者对消耗服务端进程的线程数量较大的客户端进程进行限制线程使用数量的处理。请参阅图5，图5是本申请第二实施例的进程通信监控方法的部分流程示意图。与本申请第一实施例的进程通信监控方法的不同之处在于，在步骤102之后，本实施例的进程间通信监控方法还可以包括以下步骤：步骤201：根据通信的消耗时长计算预定时间内多次通信的平均消耗时长并保存。其中，例如，预定时间之内进行了n次通信，第一次通信的消耗时长是t1，第二次通信的消耗时长是t2，第三次通信的消耗时长是t3，那么n次通信消耗的平均消耗时长为(t1+t2+t3)/n。然后，将平均消耗时长保存到监控数据，监控数据可以上传至服务器，具体参见上文的描述。通过上述方式，记录一段时间内多次通信的平均消耗时长，该平均消耗时长可以体现服务端进程的长时间的特性，例如，经常性的传输较慢或者经常性的传输较快，电子装置可以根据一段时间内多次通信的平均消耗时长来对电子装置的系统性能进行优化。例如，根据多次通信的平均消耗时长调整服务端进程在系统中获取硬件资源的优先级。关于进程优先级的说明具体可以参见上文的描述。具体而言，电子装置可以在平均消耗时长大于预设的平均消耗时长阈值时，将服务端进程的优先级增大。步骤202：记录不同时间段的客户端进程与服务端进程之间的通信的次数并保存至时间段与通信次数的对应关系表。其中，可以将时间轴划分成多个时间段，多个时间段按时间先后顺序排列，然后统计在每个时间段的通信了多少次。划分的多个时间段的时长可以相等，当然，多个时间段的时长也可以不相等。例如，第一时间段内通信了n1次，第二时间段通信了n2次，第三时间段通信了n3次。根据不同时间段的通信次数生成时间段与通信次数的对应关系表。下面结合实例进行说明。例如，将0-4ms划分为第一时间段(0～1ms)，第二时间段(1～2ms)，第三时间段(2-3ms)。表一本申请实施例一种时间段与通信次数的对应关系表时间段通信次数0～1ms3次1～2ms5次2-3ms4次通过记录各个时间段的通信次数，并保存至监控数据，电子装置可以根据时间段与通信次数的对应关系表确定哪一段时间通信次数少，在通信次数少的时间段提高服务端进程的优先级，在通信次数多的时间段降低服务端进程的优先级。进而，可以优化电子装置的性能。监控数据可以上传至服务器以便于服务商根据监控数据对电子装置的性能进行优化或者验证。请参阅图6，图6是本申请实施例时间段与通信次数对应关系的柱状图。可选地，可以进一步根据时间段与通信次数的对应关系表生成柱状图。如图6所示，柱状图的每一根柱的宽度表征时间段，柱状图的每一根柱的高度表征对应的通信次数。进一步地，可以将柱状图保存至监控数据并上传至服务器，从而可以便于服务商的研发人员直观的分析操作系统的性能并进行相应的优化。在上述实施例中，步骤202可以在步骤201之前或者之后，本申请实施例对此不做限定。请参阅图7，图7是本申请第三实施例的进程通信监控方法的部分流程示意图。与本申请第一实施例的进程通信监控方法的不同之处在于，在本实施例中，进程间通信监控方法可以进一步包括以下步骤：步骤301：获取服务端进程的重要级别。其中，获取服务端进程的重要级别具体可以为：获取服务端进程的标识信息；根据服务端进程的标识信息在预存的服务端进程的标识信息与重要级别的对应关系表中查找对应的重要级别。重要级别可以是用户预先设置的重要级别，重要级别与服务端进程一一对应，其对应关系存储在服务端进程的标识信息与重要级别的对应关系表中。服务端进程的标识信息可以是服务端进程的唯一识别码等。例如，三个服务端进程的标识信息分别为a、b、c，服务端进程a的重要级别为1，服务端进程b的重要级别为2，服务端进程c的重要级别为3。具体参见下表二。表二本申请实施例一种服务端进程的标识信息与重要级别的对应关系表服务端进程的标识信息重要级别a1b2c3步骤302：判断重要级别是否大于预设级别。在步骤302中，若是，即若服务端进程的重要级别大于预设级别，则执行步骤303。若否，即若服务端进程的重要级别小于或者等于预设级别，则返回步骤301。步骤303：监控服务端进程可用的binder线程的数量，在服务端进程的binder线程被唤醒时，保存将binder线程唤醒的客户端进程的标识信息以及保存binder线程被唤醒后执行的任务的标识信息。其中，通过对重要的服务端进程(例如，systemserver系统服务)进行额外的监控，能够有效的保证这些进程的正常运行，避免系统崩溃等严重故障，且针对这些重要的进程进行监控可以减小监控数据占用的空间，从而节省监控数据传输的网络消耗或者存储消耗。当然，可以将监控到的服务端进程可用的binder线程的数量，将binder线程唤醒的客户端进程的标识信息以及binder线程被唤醒后执行的任务的标识信息，保存至监控数据并上传至服务器，便于服务商根据监控数据，对电子装置的操作系统进行优化。步骤304：在服务端进程可用的binder线程的数量小于预设数量时，保存当前与服务端进程通信的所有的客户端进程的标识信息。其中，具体可以是在服务端进程可用的binder线程的数量耗尽时，即可用数量为零时，保存当前与服务端进程通信的所有的客户端进程的标识信息。通过保存此时与服务端进程通信的所有的客户端进程的标识信息可以便于后续在服务端进程的资源耗尽时，或者通信消耗时长较长时，将这些客户端进程进行关闭处理或者资源限制处理，便于优化电子装置的系统性能。不难理解，在上述各个实施例中，不同实施例中的特征可以相互组合形成新的实施例，此处不一一列举。请参阅图8，图8是本申请实施例电子装置的模块示意图。在本实施例中，电子装置40可以包括以下模块：记录模块41，用于在客户端进程与服务端进程之间通过binder驱动程序进行进程间通信的过程中，记录客户端进程向服务端进程发起通信请求的第一时间节点，以及记录服务端进程回复通信请求的第二时间节点。计算模块42，用于根据第一时间节点和第二时间节点计算每次通信的消耗时长并保存，消耗时长为从第一时间节点到第二时间节点的时长。判断模块43，用于判断消耗时长是否大于预设时长。若判断模块43判断到消耗时长大于预设时长，则记录模块41进一步记录当前服务端进程的使用情况和当前系统使用情况。上述各个模块执行的步骤的具体内容可以参见上文的描述，此处不再赘述。请参阅图9，图9是本申请实施例电子装置的硬件结构示意图。在本实施例中，电子装置50包括处理器51和存储器52。存储器52与处理器51电连接。存储器52用于存储计算机程序，处理器51用于执行该计算机程序以实现上述任意一实施例的方法。本发明实施例还提供一种计算机可读存储介质，该计算机可读存储介质用于存储计算机程序，该计算机程序能够被处理器执行以实现上述实施例中提供的方法。可以理解的，在本实施例中的可读存储介质存储的计算机程序，所用来执行的方法与上述实施例提供的方法类似，其原理和步骤相同，这里不再赘述。其中，该存储介质可以为u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。本发明上述任意一实施中的电子装置可以为智能手机、可穿戴式智能设备、平板电脑、掌上电脑、数字pda或者其他电子装置。本申请实施例通过在客户端进程与服务端进程之间通过binder驱动程序进行进程间通信的过程中，记录客户端进程向服务端进程发起通信请求的第一时间节点，以及记录服务端进程回复通信请求的第二时间节点；根据第一时间节点和第二时间节点计算通信的消耗时长并保存，消耗时长为从第一时间节点到第二时间节点的时长；判断消耗时长是否大于预设时长，若是，则记录当前服务端进程的使用情况和当前系统使用情况，能够有效的监控进程间通信的消耗时长，为后续的系统优化和验证提供有效的数据支持，且能够在监控消耗时长过长时，即通信效率过低时，进一步记录当前服务端进程的使用情况和当前系统使用情况，从而能够有效的记录慢传输时的关键数据，在保证有效监控的情况下利于减小监控数据的数据量，节省监控数据的存储消耗和传输消耗。以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
，均同理包括在本申请的专利保护范围内。当前第1页12