一种消息阻塞检测方法、装置及计算机存储介质与流程

本申请涉及电子通信技术领域，特别涉及一种消息阻塞检测方法、装置及计算机存储介质。

背景技术：

随着电子通信技术的快速发展，手机、平板、电脑等电子设备在人们日常的学习、工作和生活中得到广泛的应用，人们可以利用电子设备进行理财、信息浏览、生活事务等日常事件的处理。

目前，电子设备的事件反馈，界面绘制，广播处理等一般都是基于消息机制实现，当用户触发某一事件后，所述事件会以消息的形式进入相应的消息队列中；然后，处理器处理所述消息并返回所述消息的处理结果。但实际应用中消息队列中一般会存在多个待处理的消息，且电子设备一般是多线程处理的，这样就会因某一消息处理时间过长、线程之间的资源抢夺等导致消息队列发生阻塞，相应的，电子设备上的应用就无法及时响应用户操作，出现应用卡顿的现象，严重影响用户体验。但现有技术中无法准确定位出消息队列中阻塞发生的位置，导致应用卡顿的现象不能得到改善。

技术实现要素：

本申请实施例的目的是提供一种消息阻塞检测方法、装置及计算机存储介质，以准确定位出消息队列中阻塞发生的位置，进而可以解决电子设备上应用卡顿的问题。

为解决上述技术问题，本申请实施例是这样实现的：

一种消息阻塞检测方法，包括：

当处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间；

获取所述下一个消息的实际开始处理时间；

计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差；

检测所述时间差是否大于预设阻塞时间阈值；

当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述当前消息的处理阶段所述消息队列发生阻塞。

一种消息阻塞检测方法，包括：

当处理完成消息队列中的一个消息时，设置所述消息的下一个消息的期望结束处理时间；

获取所述下一个消息的实际开始处理时间；

计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差；

检测所述时间差是否大于预设阻塞时间阈值；

当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述下一个消息的处理阶段所述消息队列发生阻塞。

一种消息阻塞检测装置，包括：

期望开始时间设置模块，用于当处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间；

实际开始时间获取模块，用于获取所述下一个消息的实际开始处理时间；

第一计算模块，用于计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差；

第一检测模块，用于检测所述时间差是否大于预设阻塞时间阈值；

第一阻塞位置确定模块，用于当所述第一检测模块检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述当前消息的处理阶段所述消息队列发生阻塞。

一种消息阻塞检测装置，包括：

期望结束时间设置模块，用于当处理完成消息队列中的一个消息时，设置所述消息的下一个消息的期望结束处理时间；

实际结束时间获取模块，用于获取所述下一个消息的实际开始处理时间；

第二计算模块，用于计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差；

第二检测模块，用于检测所述时间差是否大于预设阻塞时间阈值；

第二阻塞位置确定模块，用于当所述第二检测模块检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述下一个消息的处理阶段所述消息队列发生阻塞。

一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现以下步骤：

当处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间；

获取所述下一个消息的实际开始处理时间；

计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差；

检测所述时间差是否大于预设阻塞时间阈值；

当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述当前消息的处理阶段所述消息队列发生阻塞。

一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现以下步骤：

当处理完成消息队列中的一个消息时，设置所述消息的下一个消息的期望结束处理时间；

获取所述下一个消息的实际开始处理时间；

计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差；

检测所述时间差是否大于预设阻塞时间阈值；

当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述下一个消息的处理阶段所述消息队列发生阻塞。

由以上本申请实施例提供的技术方案可见，本申请实施例通过处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间，在获取消息实际开始处理时间之后，计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差，接着，通过检测消息队列中消息的期望开始处理时间与实际开始处理时间的时间差是否大于预设阻塞时间阈值的方式，确定在时间差大于预设阻塞时间阈值对应的当前消息的处理阶段所述消息队列发生阻塞。与现有技术相比，利用本申请提供的技术方案可以准确定位出因消息处理时间过长、线程之间的资源抢夺等造成消息队列发生阻塞的消息位置，进而可以解决电子设备上应用卡顿的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的消息阻塞检测方法的一种实施例的流程示意图；

图2是本申请提供的消息队列中消息的期望开始处理时间与实际开始处理时间，以及时间差的一种实施例的统计示意图；

图3是本申请提供的消息阻塞检测方法的另一种实施例的流程示意图；

图4是本申请提供的消息阻塞检测装置的一种实施例的结构示意图；

图5是本申请提供的消息阻塞检测装置的另一种实施例的结构示意图。

具体实施方式

本申请实施例提供一种消息阻塞检测方法、装置及计算机存储介质。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

以下以几个具体的例子详细说明本申请实施例的具体实现。

以下首先介绍本申请一种消息阻塞检测方法的实施例。图1是本申请提供的消息阻塞检测方法的一种实施例的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图1所示，所述方法可以包括：

s110：当处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间。

在本申请实施例中，当处理消息队列中的当前消息时，可以设置所述当前消息的下一个消息的期望开始处理时间。具体的，所述期望开始处理时间可以为预设的无阻塞情况下，消息开始处理的时间，具体的，消息开始处理的时间可以为开始为消息获取执行线程的时间(实际应用中，会存在因线程之间的资源抢夺导致多次获取执行线程后该消息才获得执行线程)。此外，在实际应用中，消息队列中的消息时按照进入消息队列的时间先后按序排列处理的，相应的，某一消息开始处理的时间也可以为所述某一消息的前一个消息结束处理的时间。

在一个具体的实施例中，所述期望开始处理时间可以为设置所述期望开始处理时间的当前时间加上第一预设消息执行时间后的时间。在实际应用中，消息进入消息队列后，在无阻塞的情况下，响应处理消息一般都是即时的，相应的，在另一个具体的实施例中，所述期望开始处理时间可以设置为消息进入消息队列的时间加上第一预设消息执行时间后的时间。

具体的，所述第一预设消息执行时间可以为结合实际应用情况预设的无阻塞情况下消息开始执行到消息结束执行的时间减去设置所述期望开始处理时间的当前时间时所述当前消息已执行的时间。另外，对于不同类型的消息，消息的执行需要时间也可以有不同，相应的，可以结合所述当前消息的类型设置所述第一预设消息执行时间。

此外，需要说明的是，本申请实施例所述期望开始处理时间并不仅限于上述的设置所述期望开始处理时间的当前时间加上预设的消息执行需要时间后的时间或消息进入消息队列的时间加上预设的消息执行需要时间后的时间，在实际应用中，还可以结合具体的应用场景需求，设置其他时间，例如当用户通过预设操作触发某一事件，对于该事件对应消息的响应需要在预设时间段之后的应用场景中，所述期望开始处理时间可以为设置所述期望开始处理时间的当前时间加上预设的消息执行需要时间和预设时间段之后的时间等，但本申请实施例所述期望开始处理时间并不以上述为限。

在一些实施例中，本申请所述期望开始处理时间可以为时间点；在另一些实施例中，所述期望开始处理时间可以为相对的时长，例如假设某一消息队列的总处理时长为60ms，前两个消息(消息队列中的消息是按照进入消息队列的时间先后按序排列处理的)在不发生阻塞的情况下，处理需要的总时长为8ms，相应的，所述消息队列中第三个消息的期望开始处理时间可以设置为8ms。

s120：获取所述下一个消息的实际开始处理时间。

本申请实施例中，可以获取所述下一个消息的实际开始处理时间。在实际应用中，电子设备的系统对外可以提供统计应用中消息处理时间的接口，当需要进行消息处理时间统计时，可以通过对统计消息处理时间的接口进行相应的设置后，进行日志打印的方式获取消息实际开始处理时间。

具体的，以android系统为例，假设当前消息队列为android系统中某一应用程序对应的消息队列，android的looper类对外提供了可以统计消息处理时间的接口(printer接口)，相应的，可以通过对printer接口进行相应的设置后，进行日志打印的方式获取消息实际开始处理时间。

此外，需要说明的是，本申请实施例所述实际开始处理时间的获取方式并不仅限于上述的方式，在实际应用中，还可以包括其他方式，本申请实施例所述实际开始处理时间的获取方式并不以上述为限。

在一些实施例中，本申请所述实际开始处理时间可以为时间点；在另一些实施例中，所述实际开始处理时间可以为相对的时长。

s130：计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差。

在实际应用中，消息队列中没有发生阻塞的情况下，消息队列中消息的期望开始处理时间与实际开始处理时间相同；相应的，在获取所述下一个消息的实际开始处理时间之后，可以结合设置的消息的期望开始处理时间，计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差。

在一些实施例中，在步骤s130计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差之前，所述方法还可以包括：

比较所述下一个消息的期望开始处理时间与实际开始处理时间的大小，当所述实际开始处理时间大于所述期望开始处理时间时，执行计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差的步骤。

在一些实施例中，可以先通过比较所述消息队列中消息的实际开始处理时间与期望开始处理时间的大小来判断相应的消息是否按时开始处理，当所述实际开始处理时间大于所述期望开始处理时间时，可以判断相应的消息没有按时开始处理，相应的，可以执行计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差的步骤。此外，这里通过比较所述消息队列中消息的实际开始处理时间与所述期望开始处理时间的大小，可以排除按时开始处理的消息，减小后续的计算量。

s140：检测所述时间差是否大于预设阻塞时间阈值。

本申请实施例中，所述预设阻塞时间阈值可以为预先设置的可以保证界面的流畅的临界数值。在实际应用中，一般电子设备上应用的刷新帧率为60帧时，可以保证用户使用过程中界面的流畅度，相应的，刷新帧率为60帧时，帧间差值为16.6ms，因此，当消息队列中消息的期望开始处理时间与实际开始处理时间的时间差大于16.6ms时，应用的卡顿现象就会出现。相应的，在一个具体的实施例中，所述预设阻塞时间阈值可以设置为大于等于0，小于等于16.6ms的数值。

此外，需要说明的是，本申请实施例中所述预设阻塞时间阈值并不仅限于上述大于等于0，小于等于16.6ms的数值，在实际应用中，还可以结合实际应用情况和电子设备上应用的刷新帧率设置其他可以保证界面的流畅度的数值，本申请实施例所述预设阻塞时间阈值并不以上述为限。

本申请实施例中可以通过检测消息队列中消息的期望开始处理时间与实际开始处理时间的时间差是否大于预设阻塞时间阈值的方式，从消息队列中定位出消息队列阻塞发生的位置，相应的，当检测到所述时间差大于所述预设阻塞时间阈值时，可以执行步骤s150。

s150：当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述当前消息的处理阶段所述消息队列发生阻塞。

在实际应用中，消息队列中的消息按照进入消息队列的时间先后按序排列处理。本申请实施例中，当检测到所述时间差大于所述预设阻塞时间阈值时，可以确定大于所述预设阻塞时间阈值的时间差所对应的消息未及时开始处理，在所述消息处理之前消息队列中出现了阻塞，相应的，可以确定在大于所述预设阻塞时间阈值的时间差所对应的消息的上一个消息的处理阶段所述消息队列发生阻塞。

具体的，某一消息的处理阶段可以理解为从该消息开始处理到该消息结束处理的时间。具体的，可以包括开始为该消息获取执行线程资源、该消息获得执行线程资源后执行该消息、以及完成该消息的过程。

利用本申请上述步骤s110至s150可以从消息队列中准确的定位出造成消息队列阻塞的消息的位置，后续可以进行相应的改进，解决电子设备上应用卡顿的问题。

在实际应用中，由于程序本身逻辑复杂等原因会造成相应的消息处理时间过长，进而导致消息队列阻塞的情况。相应的，在一些实施例中，所述方法还可以包括：

获取所述消息队列发生阻塞所对应的消息的执行时间；

判断所述执行时间是否大于预设执行时间阈值

当判断出所述执行时间大于所述预设执行时间阈值时，确定大于所述预设执行时间阈值的执行时间所对应的消息的执行导致消息队列发生阻塞。

具体的，一种实施方式中，所述预设执行时间阈值可以为预先设置的保证界面的流畅的消息临界处理时间。这里通过获取造成阻塞的消息的处理时间，并判断处理时间是否大于预设执行时间阈值的方式，可以确定出消息是否是因为本身执行时间过长才造成程序阻塞，应用卡顿现象。相应的，当判断出消息的执行时间大于所述预设执行时间阈值时，可以判断所述消息的执行导致消息队列发生阻塞，造成应用卡顿现象。

具体的，消息的执行时间可以为消息获得执行线程资源开始执行消息到完成后，结束执行消息的时间。

在实际应用中，由于线程之间的资源抢夺会造成消息未及时开始执行，导致消息队列阻塞的情况。相应的，在一些实施例中，所述方法还可以包括：

当判断出所述执行时间小于等于所述预设执行时间阈值时，确定小于等于所述预设执行时间阈值的执行时间所对应的消息的处理阶段发生的线程之间的资源抢夺导致所述消息队列发生阻塞。

具体的，当判断出消息的执行时间小于等于所述预设执行时间阈值时，可以确定消息本身执行并不会造成消息队列阻塞，相应的，可以确定所述消息的处理阶段发生的线程之间的资源抢夺导致消息队列发生阻塞，造成应用卡顿现象。

在一些实施例中，所述方法还可以包括：

获取所述消息队列中的消息所对应的时间差，对所述消息队列中消息所对应的时间差进行统计分析处理，得到所述消息队列的阻塞信息。

具体的，所述对所述消息队列中消息所对应的时间差进行统计分析处理，得到所述消息队列的阻塞信息可以包括：统计所述消息队列中消息所对应的时间差的数值大小，当所述时间差最大时，可以得到所述时间差所对应的消息开始处理时被阻塞最严重，且阻塞发生在被阻塞最严重的消息上一个处理的消息处理期间的阻塞消息；以及可以包括：统计所述消息队列中消息所对应的时间差的数值大小，根据所述数值大小的变化趋势，可以得到当时间差值呈现递增趋势，则消息队列的阻塞现象趋于严重，以及当时间差值呈现递减趋势，则消息队列的阻塞现象趋于缓减的阻塞消息。

如图2所示，图2是本申请提供的消息队列中消息的期望开始处理时间与实际开始处理时间，以及时间差的一种实施例的统计示意图。从图中可见，d1＝0ms，d2＝12ms，d3＝18ms，d4＝24ms，相应的，可以判断消息2、消息3和消息4未及时开始处理，假设预设阻塞时间阈值为16ms，相应的，可以判断消息2和消息3处理阶段发生了堵塞；同时，消息4的期望开始处理时间与实际开始处理时间之间时间差最大，说明消息3处理过阶段堵塞最严重；且消息所对应的时间差的数值大小的变化趋势为递增趋势，说明消息队列的阻塞现象趋于严重。

由此可见，本申请一种消息阻塞检测方法的实施例通过处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间，在获取消息实际开始处理时间之后，计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差，接着，通过检测消息队列中消息的期望开始处理时间与实际开始处理时间的时间差是否大于预设阻塞时间阈值的方式，确定在时间差大于预设阻塞时间阈值对应的当前消息的处理阶段所述消息队列发生阻塞。后续，通过获取阻塞消息的处理时间，并判断处理时间是否大于预设执行时间阈值的方式，可以有效的区分出阻塞是因为消息本身处理时间过长还是线程之间的资源抢夺才造成的，便于后续有针对性的进行改进，解决电子设备上应用卡顿的问题。与现有技术相比，利用本申请提供的技术方案可以准确定位出因消息处理时间过长、线程之间的资源抢夺等造成消息队列发生阻塞的消息位置，进而可以解决电子设备上应用卡顿的问题。

以下介绍本申请一种消息阻塞检测方法的另一实施例。图3是本申请提供的消息阻塞检测方法的另一种实施例的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图3所示，所述方法可以包括：

s310：当处理完成消息队列中的一个消息时，设置所述消息的下一个消息的期望结束处理时间。

在本申请实施例中，当处理完成消息队列中的一个消息时，可以设置所述消息的下一个消息的期望结束处理时间。具体的，所述期望结束处理时间可以为预设的无阻塞情况下，消息结束处理的时间。

在一个具体的实施例中，所述期望结束处理时间可以为设置所述期望结束处理时间的当前时间加上第二预设消息执行时间后的时间。在实际应用中，消息进入消息队列后，在无阻塞的情况下，响应处理消息一般都是即时的，相应的，所述期望结束处理时间可以设置为消息进入消息队列的时间加上第二预设消息执行时间后的时间。具体的，所述第二预设消息执行时间可以为结合实际应用情况预设的无阻塞情况下消息开始执行到消息结束执行的时间。另外，对于不同类型的消息，消息的处理时间也可以有不同，相应的，可以结合所述下一个消息的类型设置所述第二预设消息执行时间。

此外，需要说明的是，本申请实施例所述期望结束处理时间并不仅限于上述的设置所述期望结束处理时间的当前时间加上第二预设消息执行时间后的时间或消息进入消息队列的时间加上第二预设消息执行时间后的时间，在实际应用中，还可以结合具体的应用场景需求，设置其他时间，例如当用户通过预设操作触发某一事件，对于该事件对应消息的响应需要在预设时间段之后的应用场景中，所述期望开始处理时间可以设置为设置所述期望结束处理时间的当前时间加上第二预设消息执行时间和预设时间段之后的时间，但本申请实施例所述期望结束处理时间并不以上述为限。

在一些实施例中，本申请所述期望结束处理时间可以为时间点；在另一些实施例中，所述期望结束处理时间可以为相对的时长，例如假设某一消息队列的总处理时长为60ms，前两个消息(消息队列中的消息是按照进入消息队列的时间先后按序排列的)在不发生阻塞的情况下，处理需要的总时长为8ms，相应的，所述消息队列中第二个消息期望结束处理的期望开始处理时间可以设置为8ms。

s320：获取所述下一个消息的实际开始处理时间。

本申请实施例中，可以获取所述下一个消息的实际开始处理时间。在实际应用中，电子设备的系统对外可以提供统计应用中消息处理时间的接口，当需要进行消息处理时间统计时，可以通过对统计消息处理时间的接口进行相应的设置后，进行日志打印的方式获取消息实际开始处理时间。

具体的，以android系统为例，假设当前消息队列为android系统中某一应用程序对应的消息队列，android的looper类对外提供了可以统计消息处理时间的接口(printer接口)，相应的，可以通过对printer接口进行相应的设置后，进行日志打印的方式获取消息实际结束处理时间。

此外，需要说明的是，本申请实施例所述实际结束处理时间的获取方式并不仅限于上述的方式，在实际应用中，还可以包括其他方式，本申请实施例所述实际结束处理时间的获取方式并不以上述为限。

在一些实施例中，本申请所述实际结束处理时间可以为时间点；在另一些实施例中，所述实际结束处理时间可以为相对的时长。

s330：计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差。

在实际应用中，消息队列中没有发生阻塞的情况下，消息队列中消息会按时开始处理，并按时处理完成，相应的，消息的期望结束处理时间与实际结束处理时间相同；相应的，在获取消息队列中消息的实际结束处理时间之后，可以结合设置的消息的期望结束处理时间，计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差。

在一些实施例中，在步骤s330计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差之前，所述方法还可以包括：

比较所述下一个消息的期望开始处理时间与实际开始处理时间的大小，当所述实际开始处理时间大于所述期望开始处理时间时，执行计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差的步骤。

在一些实施例中，可以先通过比较所述消息队列中消息的实际结束处理时间与期望结束处理时间来判断相应的消息是否按时处理完成，当所述实际结束处理时间大于所述期望结束处理时间时，可以判断相应的消息没有按时处理完成，相应的，可以执行计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差的步骤。此外，这里通过比较所述消息队列中消息的实际结束处理时间与期望结束处理时间的大小，可以排除按时处理完成的消息，减小后续的计算量。

s340：检测所述时间差是否大于预设阻塞时间阈值。

本申请实施例中，所述预设阻塞时间阈值可以为预先设置的可以保证界面的流畅的临界数值。在实际应用中，一般电子设备上应用的刷新帧率为60帧时，可以保证用户使用过程中界面的流畅度，相应的，刷新帧率为60帧时，帧间差值为16.6ms，因此，当消息队列中消息的期望结束处理时间与实际结束处理时间的时间差大于16.6ms时，应用的卡顿现象就会出现。相应的，在一个具体的实施例中，所述预设阻塞时间阈值可以设置为大于等于0，小于等于16.6ms的数值。

此外，需要说明的是，本申请实施例中所述预设阻塞时间阈值并不仅限于上述大于等于0，小于等于16.6ms的数值，在实际应用中，还可以结合实际应用情况和电子设备上应用的刷新帧率设置其他可以保证界面的流畅度的数值，本申请实施例所述预设阻塞时间阈值并不以上述为限。

本申请实施例中可以通过检测消息队列中消息的期望结束处理时间与实际结束处理时间的时间差是否大于预设阻塞时间阈值的方式，可以从消息队列中定位出消息队列阻塞发生的位置，相应的，当检测到所述时间差大于所述预设阻塞时间阈值时，可以执行步骤s350。

s350：当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述下一个消息的处理阶段所述消息队列发生阻塞。

本申请实施例中，当检测到所述时间差大于所述预设阻塞时间阈值时，可以确定大于所述预设阻塞时间阈值的时间差所对应的消息未及时处理完成，相应的，可以确定在大于所述预设阻塞时间阈值的时间差所对应的消息处理阶段所述消息队列发生阻塞。

具体的，某一消息的处理阶段可以理解为从该消息开始处理到该消息结束处理的时间。具体的，可以包括开始为该消息获取执行线程资源、该消息获得执行线程资源后执行该消息、以及完成该消息的过程

利用本申请上述步骤s310至s350可以从消息队列中准确的定位出造成消息队列阻塞的消息的位置，后续可以进行相应的改进，解决电子设备上应用卡顿的问题。

在实际应用中，由于程序本身逻辑复杂等原因会造成相应的消息处理时间过长，进而导致程序阻塞的情况。相应的，在一些实施例中，所述方法还可以包括：

获取所述消息队列发生阻塞所对应的消息的执行时间；

判断所述执行时间是否大于预设执行时间阈值；

当判断出所述执行时间大于所述预设执行时间阈值时，确定大于所述预设执行时间阈值的执行时间所对应的消息的执行导致消息队列发生阻塞。

具体的，一种实施方式中，所述预设执行时间阈值可以为预先设置的保证界面的流畅的消息临界处理时间。这里通过获取造成阻塞的消息的处理时间，并判断处理时间是否大于预设执行时间阈值的方式，可以确定出消息是否是因为本身执行时间过长才造成程序阻塞，应用卡顿现象。相应的，当判断出消息的执行时间大于所述预设执行时间阈值时，可以判断所述消息的执行导致消息队列发生阻塞，造成应用卡顿现象。

具体的，消息的执行时间可以为消息获得执行线程资源开始执行消息到完成后，结束执行消息的时间。

在实际应用中，由于线程之间的资源抢夺会造成消息未及时开始执行，导致消息队列阻塞的情况。相应的，在一些实施例中，所述方法还可以包括：

当判断出所述执行时间小于等于所述预设执行时间阈值时，确定小于等于所述预设执行时间阈值的执行时间所对应的消息的处理阶段发生的线程之间的资源抢夺导致所述消息队列发生阻塞。

具体的，当判断出消息的执行时间小于等于所述预设执行时间阈值时，可以确定消息本身执行并不会造成消息队列阻塞，相应的，可以确定所述消息的处理阶段发生的线程之间的资源抢夺导致消息队列发生阻塞，造成应用卡顿现象。

在一些实施例中，所述方法还可以包括：

获取所述消息队列中的消息所对应的时间差，对所述消息队列中消息所对应的时间差进行统计分析处理，得到所述消息队列的阻塞信息。

具体的，所述对所述消息队列中消息所对应的时间差进行统计分析处理，得到所述消息队列的阻塞信息可以包括：统计所述消息队列中消息所对应的时间差的数值大小，当所述时间差最大时，可以得到所述时间差所对应的消息开始处理时被阻塞最严重，且阻塞发生在被阻塞最严重的消息上一个处理的消息处理期间的阻塞消息；以及可以包括：统计所述消息队列中消息所对应的时间差的数值大小，根据所述数值大小的变化趋势，可以得到当时间差值呈现递增趋势，则消息队列的阻塞现象趋于严重，以及当时间差值呈现递减趋势，则消息队列的阻塞现象趋于缓减的阻塞消息。

由此可见，本申请一种消息阻塞检测方法的实施例通过处理完成消息队列中一个消息时，设置所述消息的下一个消息的期望结束处理时间，在获取消息实际结束处理时间之后，计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差，接着，检测消息队列中消息的期望结束处理时间与实际结束处理时间的时间差是否大于预设阻塞时间阈值，确定在时间差大于所述预设阻塞时间阈值所对应的所述下一个消息的处理阶段所述消息队列发生阻塞。后续，通过获取阻塞消息的执行时间，并判断执行时间是否大于预设执行时间阈值的方式，可以有效的区分出阻塞是因为消息本身执行时间过长还是线程之间的资源抢夺才造成的，便于后续有针对性的进行改进，解决电子设备上应用卡顿的问题。与现有技术相比，利用本申请提供的技术方案可以准确定位出因消息处理时间过长、线程之间的资源抢夺等造成消息队列发生阻塞的消息位置，进而可以解决电子设备上应用卡顿的问题。

本申请另一方面还提供一种消息阻塞检测装置，图4是本申请提供的消息阻塞检测装置的一种实施例的结构示意图，如图4所示，所示装置400可以包括：

期望开始时间设置模块410，可以用于当处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间；

实际开始时间获取模块420，可以用于获取所述下一个消息的实际开始处理时间；

第一计算模块430，可以用于计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差；

第一检测模块440，可以用于检测所述时间差是否大于预设阻塞时间阈值；

第一阻塞位置确定模块450，可以用于当所述第一检测模块440检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述当前消息的处理阶段所述消息队列发生阻塞。

在另一个实施例中，所述装置400还可以包括：

第一比较模块，可以用于在所述第一计算模块430计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差之前，比较所述下一个消息的期望开始处理时间与实际开始处理时间的大小，当所述实际开始处理时间大于所述期望开始处理时间时，所述第一计算模块430计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差。

在另一个实施例中，所述装置400还可以包括：

第一阻塞信息获取模块，可以用于获取所述第一计算模块计算得到的所述消息队列中的消息的时间差，对所述消息队列中消息所对应的时间差进行统计分析处理，得到所述消息队列的阻塞信息。

在另一个实施例中，所述装置400还可以包括：

第一执行时间获取模块，可以用于获取所述消息队列发生阻塞所对应的消息的执行时间；

第一判断模块，可以用于判断所述执行时间是否大于预设执行时间阈值

第一阻塞确定模块，可以用于当所述第一判断模块判断出所述执行时间大于所述预设执行时间阈值时，确定大于所述预设执行时间阈值的执行时间所对应的消息的执行导致消息队列发生阻塞。

在另一个实施例中，所述装置400还可以包括：

第二阻塞确定模块，用于当所述第一判断模块判断出所述执行时间小于等于所述预设执行时间阈值时，确定小于等于所述预设执行时间阈值的执行时间所对应的消息的处理阶段发生的线程之间的资源抢夺导致所述消息队列发生阻塞。

本申请还提供一种消息阻塞检测装置另一种实施例，图5是本申请提供的消息阻塞检测装置的另一种实施例的结构示意图，如图5所示，所示装置500可以包括：

期望结束时间设置模块510，可以用于当处理完成消息队列中的一个消息时，设置所述消息的下一个消息的期望结束处理时间；

实际结束时间获取模块520，可以用于获取所述下一个消息的实际开始处理时间；

第二计算模块530，可以用于计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差；

第二检测模块540，可以用于检测所述时间差是否大于预设阻塞时间阈值；

第二阻塞位置确定模块550，可以用于当所述第二检测模块540检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述下一个消息的处理阶段所述消息队列发生阻塞。

在另一个实施例中，所述装置500还可以包括：

第四检测模块，可以用于在所述第二计算模块530计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差之前，比较所述下一个消息的期望开始处理时间与实际开始处理时间的大小，当所述实际开始处理时间大于所述期望开始处理时间时，所述第二计算模块530可以计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差。

在另一个实施例中，所述装置500还可以包括：

第二阻塞信息获取模块，可以用于获取所述第二计算模块计算得到的所述消息队列中的消息所对应的时间差，对所述消息队列中消息所对应的时间差进行统计分析处理，得到所述消息队列的阻塞信息。

在另一个实施例中，所述装置500还可以包括：

第二执行时间获取模块，可以用于获取所述消息队列发生阻塞所对应的消息的执行时间；

第二判断模块，可以用于判断所述执行时间是否大于预设执行时间阈值；

第三阻塞确定模块，可以用于当所述第二判断模块判断出所述执行时间大于所述预设执行时间阈值时，确定大于所述预设执行时间阈值的执行时间所对应的消息的执行导致消息队列发生阻塞。

在另一个实施例中，所述装置500还可以包括：

第四阻塞确定模块，可以用于当所述第二判断模块判断出所述执行时间小于等于所述预设执行时间阈值时，确定小于等于所述预设执行时间阈值的执行时间所对应的消息的处理阶段发生的线程之间的资源抢夺导致所述消息队列发生阻塞。

本申请另一方面还提供一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时可以实现以下步骤：

当处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间；

获取所述下一个消息的实际开始处理时间；

计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差；

检测所述时间差是否大于预设阻塞时间阈值；

当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述当前消息的处理阶段所述消息队列发生阻塞。

本申请另一方面还提供一种计算机存储介质的另一种实施例，该计算机存储介质上存储有计算机程序，该程序被处理器执行时可以实现以下步骤：

当处理完成消息队列中的一个消息时，设置所述消息的下一个消息的期望结束处理时间；

获取所述下一个消息的实际开始处理时间；

计算所述下一个消息的期望结束处理时间与实际结束执行时间的时间差；

检测所述时间差是否大于预设阻塞时间阈值；

当检测到所述时间差大于所述预设阻塞时间阈值时，确定在所述下一个消息的处理阶段所述消息队列发生阻塞。

由此可见，本申请一种消息阻塞检测方法、装置或计算机存储介质的实施例通过处理消息队列中的当前消息时，设置所述当前消息的下一个消息的期望开始处理时间，在获取消息实际开始处理时间之后，计算所述下一个消息的期望开始处理时间与实际开始处理时间的时间差，接着，通过检测消息队列中消息的期望开始处理时间与实际开始处理时间的时间差是否大于预设阻塞时间阈值的方式，确定在时间差大于预设阻塞时间阈值对应的当前消息的处理阶段所述消息队列发生阻塞。与现有技术相比，利用本申请提供的技术方案可以准确定位出因消息处理时间过长、线程之间的资源抢夺等造成消息队列发生阻塞的消息位置，进而可以解决电子设备上应用卡顿的问题。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice，pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、装置或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。