一种卡顿检测方法及装置和电子设备与流程

文档序号:15399537发布日期:2018-09-11 17:09阅读:151来源:国知局

本申请涉及移动终端技术,尤其涉及一种卡顿检测方法及装置、电子设备和计算机可读存储介质。



背景技术:

随着移动终端技术的快速发展,各种移动终端已非常普及,并且,功能日益强大。安装在智能手机、平板电脑以及一些新兴的智能设备中的应用程序在功能、设计和服务范围上日新月异,用户每天花费在这些智能设备上的时间越来越多,对于应用程序的用户体验要求也越来越高。如果开发者无法为用户提供体验更好的应用程序,用户流失在所难免。例如,某个应用程序的用户界面(userinterface,简称为ui)发生卡顿,即应用程序没有及时响应,发生页面延迟、出现丢帧的现象,或者点击无响应,则会大大影响用户使用该应用程序的体验。

相关技术中,通过检测页面加载和销毁的时间来检测是否存在卡顿,但是该检测方式所耗费的时间较长。



技术实现要素:

有鉴于此,本申请提供一种卡顿检测方法及装置、电子设备和计算机可读存储介质。

具体地,本申请是通过如下技术方案实现的:

根据本公开实施例的第一方面,提供一种卡顿检测方法,所述方法包括:

基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔;

若所述ui卡顿时间间隔大于预设阈值,则确定所述当前应用程序存在ui卡顿。

在一实施例中,所述方法还包括:

在所述确定所述当前应用程序存在ui卡顿之后,获取当前系统信息,并对所述当前系统信息进行过滤;

向服务端发送过滤后的系统信息,以用于所述服务端根据所述过滤后的系统信息确定卡顿原因。

在一实施例中,所述基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔,包括:

基于所述回调句柄获取第一垂直同步信号,并记录获取到所述第一垂直同步信号时的第一时刻;

基于所述回调句柄获取第二垂直同步信号,并记录获取到所述第二垂直同步信号时的第二时刻;

计算出所述第一时刻和所述第二时刻之间的时间间隔;

将所述时间间隔确定为所述当前应用程序的ui卡顿时间间隔。

在一实施例中,所述获取当前系统信息,包括:

展示dump当前应用程序ui线程调用的堆栈信息。

在一实施例中,所述对所述当前系统信息进行过滤,包括:

去掉所述当前应用程序ui线程调用的方法执行路径,以过滤掉与确定所述当前应用程序是否存在ui卡顿无关的系统信息。

在一实施例中,所述当前系统信息包括当前终端的内存信息、中央处理单元cpu信息和显卡信息中的至少一项。

根据本公开实施例的第二方面,提供一种卡顿检测装置,所述装置包括:

获取模块,用于基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔;

确定模块,用于若所述获取模块获取的所述ui卡顿时间间隔大于预设阈值,则确定所述当前应用程序存在ui卡顿。

在一实施例中,所述装置还包括:

获取过滤模块,用于在所述确定模块确定所述当前应用程序存在ui卡顿之后,获取当前系统信息,并对所述当前系统信息进行过滤;

发送模块,用于向服务端发送所述获取过滤模块过滤后的系统信息,以用于所述服务端根据所述过滤后的系统信息确定卡顿原因。

在一实施例中,所述获取模块包括:

第一获取记录子模块,用于基于所述回调句柄获取第一垂直同步信号,并记录获取到所述第一垂直同步信号时的第一时刻;

第二获取记录子模块,用于基于所述回调句柄获取第二垂直同步信号,并记录获取到所述第二垂直同步信号时的第二时刻;

计算子模块,用于计算出所述第一获取记录子模块记录的所述第一时刻和所述第二获取记录子模块记录的所述第二时刻之间的时间间隔;

确定子模块,用于将所述计算子模块计算出的所述时间间隔确定为所述当前应用程序的ui卡顿时间间隔。

在一实施例中,所述获取过滤模块,具体用于:

展示dump当前应用程序ui线程调用的堆栈信息。

在一实施例中,所述获取过滤模块,具体用于:

去掉所述当前应用程序ui线程调用的方法执行路径,以过滤掉与确定所述当前应用程序是否存在ui卡顿无关的系统信息。

在一实施例中,所述当前系统信息包括当前终端的内存信息、中央处理单元cpu信息和显卡信息中的至少一项。

根据本公开实施例的第三方面,提供一种计算机可读存储介质,所述存储介质存储有计算机程序,所述计算机程序用于执行上述卡顿检测方法。

根据本公开实施例的第四方面,提供一种电子设备,包括处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述卡顿检测方法。

本申请实施例,由于基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔,使得终端在根据该ui卡顿时间间隔确定所述当前应用程序是否存在ui卡顿所耗费的时间更短。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。

图1是本申请一示例性实施例示出的一种卡顿检测方法的流程图;

图2是本申请一示例性实施例示出的获取当前应用程序的ui卡顿时间间隔的流程图;

图3是本申请一示例性实施例示出的另一种卡顿检测方法的流程图;

图4是本申请一示例性实施例示出的一种卡顿检测装置所在电子设备的一种硬件结构图;

图5是本申请一示例性实施例示出的一种卡顿检测装置的框图;

图6是本申请一示例性实施例示出的另一种卡顿检测装置的框图;

图7是本申请一示例性实施例示出的另一种卡顿检测装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请一示例性实施例示出的一种卡顿检测方法的流程图,该实施例从终端侧进行描述,如图1所示,卡顿检测方法包括:

步骤s101,基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔。

其中,回调句柄是指当前操作系统对于应用开发者的事件通知。例如,显示器硬件需要刷新应用界面时,会通过信号通知到操作系统,操作系统将该信号以回调的形式传递给开发者。

为了检测当前应用程序是否存在ui卡顿问题,该实施例中,可以基于当前应用程序ui线程的回调句柄获取两个垂直同步信号之间的时间间隔,并基于该时间间隔获取当前应用程序的ui卡顿时间间隔。

其中,当前应用程序所采用的操作系统可以为安卓(android)系统,垂直同步信号是指触发ui线程对ui进行渲染的信号,其来自硬件层,而回调句柄来自操作系统层,终端可借助回调句柄来获取两个垂直同步信号之间的时间间隔。

例如,如图2所示,获取当前应用程序的ui卡顿时间间隔可以包括以下步骤:

步骤s201,基于回调句柄获取第一垂直同步信号,并记录获取到第一垂直同步信号时的第一时刻。

其中,可以基于回调句柄获取第一垂直同步信号,并记录获取到第一垂直同步信号时的第一时刻。

步骤s202,基于回调句柄获取第二垂直同步信号,并记录获取到第二垂直同步信号时的第二时刻。

同样地,可以基于回调句柄获取第二垂直同步信号,并记录获取到第二垂直同步信号时的第二时刻。

步骤s203,计算出第一时刻和第二时刻之间的时间间隔。

步骤s204,将时间间隔确定为当前应用程序的ui卡顿时间间隔。

在该实施例中,可以将计算出的第一时刻和第二时刻之间的时间间隔作为当前应用程序的ui卡顿时间间隔。

上述基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔的方式简单,且获取的ui卡顿时间间隔更准确。

步骤s102,若ui卡顿时间间隔大于预设阈值,则确定当前应用程序存在ui卡顿。

其中,预设阈值可以根据需要设置,例如可以为100毫秒(ms)、500ms等。

在该实施例中,任意一次检测到的ui卡顿时间间隔大于预设阈值,则可以确定当前应用程序存在ui卡顿。

上述实施例,由于基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔,使得终端在根据该ui卡顿时间间隔确定当前应用程序是否存在ui卡顿所耗费的时间更短。

图3是本申请一示例性实施例示出的另一种卡顿检测方法的流程图,如图3所示,在步骤s102之后,该方法还可以包括:

步骤s103,获取当前系统信息,并对当前系统信息进行过滤。

其中,当前系统信息可以包括但不局限于当前终端的内存信息、中央处理单元(cpu)信息和显卡信息中的至少一项。

其中,可以通过展示(dump)当前应用程序ui线程调用的堆栈信息来达到获取当前系统信息的目的。

由于当前系统信息中存在一些无用信息即存在与确定当前应用程序是否存在ui卡顿无关的系统信息,因此,对当前系统信息进行过滤,例如去掉当前应用程序ui线程调用的方法执行路径。

具体地,可以通过关键字对当前系统信息进行过滤,例如不上报包含关键字“xxxx”的系统信息。

可选地,也可以通过系统标记对当前系统信息进行过滤,例如,过滤到系统标记是“xxx”的系统信息。

可选地,还可以通过标记级别对当前系统信息进行过滤,例如,可以将系统信息分为a、b、c和d四个级别,将b、c和d级别的系统信息过滤掉。

由此可见,该实施例可以通过多种方式过滤当前系统信息,实现手段灵活多样。

例如,假设获取的当前系统信息为当前应用程序ui线程调用的堆内存占用信息、栈空间占用信息和当前应用程序ui线程调用的方法执行路径,由于当前应用程序ui线程调用的方法执行路径与确定当前应用程序是否存在ui卡顿无关,所以可以过滤掉当前应用程序ui线程调用的方法执行路径。

步骤s104,向服务端发送过滤后的系统信息,以用于服务端根据过滤后的系统信息确定卡顿原因。

终端在过滤掉无用的系统信息后,向服务端发送过滤后的系统信息,服务端在接收到过滤后的系统信息后,可以根据过滤后的系统信息确定卡顿原因。

另外,终端也可以直接将未过滤的系统信息发送到服务器,由服务器对系统信息进行过滤,并根据过滤后的系统信息确定卡顿原因。

可选地,终端也可以不用将每次检测到的系统信息都进行上传,例如,可以每日将检测到的系统信息进行上传,或者每达到若干卡顿次数则将检测到的系统信息上传一次,或者每若干时间段将检测到的系统信息上传一次。

可选地,终端可以在本地,根据卡顿时间,对卡顿情况进行优先级标注,即终端可以根据优先级确定上传时间,或者,用于服务器优先处理或者分析卡顿原因。

可选地,终端也可以在本地,根据卡顿时的系统信息,对卡段情况进行初步分类并进行标注,便于后续服务器统计或分析卡顿原因。

由此可见,本实施例可以通过方式确定卡顿原因,实现手段灵活多样。

上述实施例,通过对获取的当前系统信息进行过滤,并向服务端发送过滤后的系统信息,使得服务端根据过滤后的系统信息确定卡顿原因,从而为后续解决当前应用程序的ui卡顿问题提供了条件。

与前述应用程序的ui检测方法的实施例相对应,本申请还提供了应用程序的ui检测装置的实施例。

本申请卡顿检测装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。如图4所示,为本申请卡顿检测装置400所在电子设备的一种硬件结构图,该电子设备包括处理器410、存储器420及存储在存储器420上并可在处理器410上运行的计算机程序,该处理器410执行该计算机程序时实现上述卡顿检测方法。除了图4所示的处理器410及存储器420之外,实施例中装置所在的电子设备通常根据卡顿检测的实际功能,还可以包括其他硬件,对此不再赘述。

图5是本申请一示例性实施例示出的一种卡顿检测装置的框图,如图5所示,该装置包括:获取模块51和确定模块52。

获取模块51用于基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔。

其中,回调句柄是指当前操作系统对于应用开发者的事件通知。例如,显示器硬件需要刷新应用界面时,会通过信号通知到操作系统,操作系统将该信号以回调的形式传递给开发者。为了检测当前应用程序是否存在ui卡顿问题,该实施例中,可以基于当前应用程序ui线程的回调句柄获取两个垂直同步信号之间的时间间隔,并基于该时间间隔获取当前应用程序的ui卡顿时间间隔。

其中,当前应用程序所采用的操作系统可以为安卓(android)系统,垂直同步信号是指触发ui线程对ui进行渲染的信号,其来自硬件层,而回调句柄来自操作系统层,终端可借助回调句柄来获取两个垂直同步信号之间的时间间隔。

确定模块52用于若获取模块51获取的ui卡顿时间间隔大于预设阈值,则确定当前应用程序存在ui卡顿。

其中,预设阈值可以根据需要设置,例如可以为100毫秒(ms)、500ms等。

在该实施例中,任意一次检测到的ui卡顿时间间隔大于预设阈值,则可以确定当前应用程序存在ui卡顿。

上述实施例,由于基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔,使得终端在根据该ui卡顿时间间隔确定当前应用程序是否存在ui卡顿所耗费的时间更短。

图6是根据一示例性实施例示出的另一种卡顿检测装置的框图,如图6所示,在上述图5所示实施例的基础上,该装置还可以包括:获取过滤模块53和发送模块54。

获取过滤模块53用于在确定模块52确定当前应用程序存在ui卡顿之后,获取当前系统信息,并对当前系统信息进行过滤。

其中,当前系统信息可以包括但不局限于当前终端的内存信息、中央处理单元(cpu)信息和显卡信息中的至少一项。

其中,获取过滤模块53可以具体用于:通过展示(dump)当前应用程序ui线程调用的堆栈信息来达到获取当前系统信息的目的。

由于当前系统信息中存在一些无用信息即存在与确定当前应用程序是否存在ui卡顿无关的系统信息,因此,对当前系统信息进行过滤,例如去掉当前应用程序ui线程调用的方法执行路径。

具体地,可以通过关键字对当前系统信息进行过滤,例如不上报包含关键字“xxxx”的系统信息。

可选地,也可以通过系统标记对当前系统信息进行过滤,例如,过滤到系统标记是“xxx”的系统信息。

可选地,还可以通过标记级别对当前系统信息进行过滤,例如,可以将系统信息分为a、b、c和d四个级别,将b、c和d级别的系统信息过滤掉。由此可见,该实施例可以通过多种方式过滤当前系统信息,实现手段灵活多样。

例如,假设获取的当前系统信息为当前应用程序ui线程调用的堆内存占用信息、栈空间占用信息以及当前应用程序ui线程调用的方法执行路径,由于当前应用程序ui线程调用的方法执行路径与确定当前应用程序是否存在ui卡顿无关,所以可以过滤掉当前应用程序ui线程调用的方法执行路径。

发送模块54用于向服务端发送获取过滤模块53过滤后的系统信息,以用于服务端根据过滤后的系统信息确定卡顿原因。

其中,发送模块54可以向服务端发送过滤后的系统信息,服务端在接收到过滤后的系统信息后,可以根据过滤后的系统信息确定卡顿原因。

另外,发送模块54也可以直接将未过滤的系统信息发送到服务器,由服务器对系统信息进行过滤,并根据过滤后的系统信息确定卡顿原因。

可选地,发送模块54也可以不用将每次检测到的系统信息都进行上传,例如,可以每日将检测到的系统信息进行上传,或者每达到若干卡顿次数则将检测到的系统信息上传一次,或者每若干时间段将检测到的系统信息上传一次。

可选地,终端可以在本地,根据卡顿时间,对卡顿情况进行优先级标注,即终端可以根据优先级确定上传时间,或者,用于服务器优先处理或者分析卡顿原因。

可选地,终端也可以在本地,根据卡顿时的系统信息,对卡段情况进行初步分类并进行标注,便于后续服务器统计或分析卡顿原因。

由此可见,本实施例可以通过方式确定卡顿原因,实现手段灵活多样。

上述实施例,通过对获取的当前系统信息进行过滤,并向服务端发送过滤后的系统信息,使得服务端根据过滤后的系统信息确定卡顿原因,从而为后续解决当前应用程序的ui卡顿问题提供了条件。

图7是根据一示例性实施例示出的另一种卡顿检测装置的框图,如图7所示,在上述图5所示实施例的基础上,获取模块51可以包括:第一获取记录子模块511、第二获取记录子模块512、计算子模块513和确定子模块514。

第一获取记录子模块511用于基于所述回调句柄获取第一垂直同步信号,并记录获取到所述第一垂直同步信号时的第一时刻。

其中,第一获取记录子模块511可以基于回调句柄获取第一垂直同步信号,并记录获取到第一垂直同步信号时的第一时刻。

第二获取记录子模块512用于基于所述回调句柄获取第二垂直同步信号,并记录获取到所述第二垂直同步信号时的第二时刻。

其中,第二获取记录子模块512可以基于回调句柄获取第二垂直同步信号,并记录获取到第二垂直同步信号时的第二时刻。

计算子模块513用于计算出所述第一获取记录子模块511记录的所述第一时刻和所述第二获取记录子模块512记录的所述第二时刻之间的时间间隔。

确定子模块514用于将所述计算子模块513计算出的所述时间间隔确定为所述当前应用程序的ui卡顿时间间隔。

在该实施例中,可以将计算出的第一时刻和第二时刻之间的时间间隔作为当前应用程序的ui卡顿时间间隔。

上述基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔的方式简单,且获取的ui卡顿时间间隔更准确。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。

在示例性实施例中,还提供了一种计算机可读存储介质,该存储介质存储有计算机程序,该计算机程序用于执行上述卡顿检测方法,其中,该卡顿检测方法包括:

基于当前应用程序ui线程的回调句柄,获取当前应用程序的ui卡顿时间间隔;

若ui卡顿时间间隔大于预设阈值,则确定当前应用程序存在ui卡顿。

上述计算机可读存储介质可以是只读存储器(rom)、随机存取存储器(ram)、光盘只读存储器(cd-rom)、磁带、软盘和光数据存储设备等。

对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由权利要求指出。

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

以上仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1