一种分析应用程序卡顿的方法和装置与流程

本发明涉及计算机技术领域，尤其涉及一种分析应用程序卡顿的方法和装置。

背景技术：

通常在应用程序运行的过程中，对硬件计算能力的需求是不断变化的，如果处理某一帧显示所需资源的时长超出了预设的标准时长(以标准帧率为每秒60帧为例，则每一帧预设的标准时长为16毫秒)则会出现卡顿的问题。因此，在开发应用程序的过程中，需要对应用程序界面的显示性能进行分析，保证界面运行维持在一定的帧率标准之上，从而为用户提供流畅的使用体验。

现有技术采用人工方式分析应用程序界面卡顿的原因，通常采用一些追踪程序追踪并录制一段时间内对应用程序的人工操作，人工对录制结果进行分析从而找到超时帧，并进一步确定超时帧出现的原因。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：追踪程序只能以流文件形式记录应用程序运行过程中执行的方法，记录的结果难以辨识，并且需要逐条排查存在问题的方法，不但效率较低还耗费了大量的人力资源。尤其是对于版本更新较为频繁的应用程序，每次发版前都需要对各界面进行人工分析，工作量过于庞大。

技术实现要素：

有鉴于此，本发明实施例提供一种分析应用程序卡顿的方法和装置，能够自动化地分析应用程序卡顿的原因，从而提高分析系效率并降低人力成本。

为实现上述目的，根据本发明实施例的一个方面，提供了一种分析应用程序卡顿的方法，包括：

根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构；

从所述流文件数据中获取与所述任务名称对应的时间戳；

根据所述帧结构和所述时间戳生成帧数据；

根据所述帧数据查找超时帧，根据所述超时帧的状态确定卡顿原因。

可选的，根据所述帧结构和所述时间戳生成帧数据的步骤包括：

根据与各所述任务名称对应的起始时间戳和终止时间戳，确定帧结构中各任务的起始时间和终止时间；

以所述帧结构中主任务的起始时间作为所述帧的起始时间；

判断所述帧结构是否包含显示任务；

若不包含，则以所述帧结构的主任务的终止时间作为帧的终止时间；若包含，则以所述显示任务的终止时间作为帧的终止时间；

生成包含所述帧的帧结构、所述帧的起始时间和终止时间以及所述帧中各任务的起始时间和终止时间的帧数据。

可选的，所述方法还包括：

在根据记录有应用程序运行过程的流文件数据中的任务名称以及与所述任务名称对应的起始标记和终止标记构建帧结构的步骤前，

使用自动化脚本模拟应用程序运行过程，以及将应用程序运行过程记录为流文件数据。

可选的，根据所述超时帧的状态确定卡顿原因的步骤包括：

预先设置超时帧状态与卡顿原因的关联关系；

根据所述关联关系确定与所述帧数据中的超时帧对应的卡顿原因。

可选的，所述流文件数据为使用systrace工具记录的html文件。

为实现上述目的，根据本发明实施例的另一个方面，提供了一种分析应用程序卡顿的装置，包括：

帧结构模块，用于根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构；

时间戳模块，用于从所述流文件数据中获取与所述任务名称对应的时间戳；

帧数据模块，用于根据所述帧结构和所述时间戳生成帧数据；

卡顿分析模块，用于根据所述帧数据查找超时帧，根据所述超时帧的状态确定卡顿原因。

可选的，所述帧数据模块还用于：

根据与各所述任务名称对应的起始时间戳和终止时间戳，确定帧结构中各任务的起始时间和终止时间；

以所述帧结构中主任务的起始时间作为所述帧的起始时间；

判断所述帧结构是否包含显示任务；

若不包含，则以所述帧结构的主任务的终止时间作为帧的终止时间；若包含，则以所述显示任务的终止时间作为帧的终止时间；

生成包含所述帧的帧结构、所述帧的起始时间和终止时间以及所述帧中各任务的起始时间和终止时间的帧数据。

可选的，所述装置还包括：

流文件记录模块，用于使用自动化脚本模拟应用程序运行过程，以及将应用程序运行过程记录为流文件数据。

可选的，所述卡顿分析模块还用于：

预先设置超时帧状态与卡顿原因的关联关系；以及根据所述关联关系确定与所述帧数据中的超时帧对应的卡顿原因。

可选的，所述流文件数据为使用systrace工具记录的html文件。

为实现上述目的，根据本发明实施例的再一个方面，提供了一种分析应用程序卡顿的电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器至少实现：

根据记录有应用程序运行过程的流文件数据生成帧数据；

查找所述帧数据中的超时帧，根据所述超时帧的状态确定卡顿原因。

为实现上述目的，根据本发明实施例的又一个方面，提供一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时至少实现：

根据记录有应用程序运行过程的流文件数据生成帧数据；

查找所述帧数据中的超时帧，根据所述超时帧的状态确定卡顿原因。

上述发明中的一个实施例具有如下优点或有益效果：因为采用将记录有应用程序运行过程的流文件数据恢复为帧数据，以及根据帧数据查找超时帧并根据其状态确定卡顿原因的技术手段，以自动化的过程实现了对应用程序运行过程的分析，所以克服了现有技术人工分析耗时费力的技术问题，进而达到了提高卡顿分析效率并节约人力成本的技术效果。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的分析应用程序卡顿的方法的主要步骤的示意图；

图2是根据本发明另一实施例的分析应用程序卡顿的方法的主要步骤的示意图；

图3是根据本发明另一实施例的分析应用程序卡顿的方法中帧结构的示意图；

图4是根据本发明实施例的分析应用程序卡顿的装置的主要模块的示意图；

图5是本发明实施例可以应用于其中的示例性系统架构图；

图6是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的分析应用程序卡顿的方法的主要步骤的示意图。

如图1所示，本发明实施例提供了一种分析应用程序卡顿的方法，包括：

s10，根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构。通过使用一些工具，可以将应用程序的运行过程记录为流文件数据；流文件也叫流式文件，是指有逻辑意义但无逻辑结构的连续数据的组合，虽然可以根据流文件数据辨识每一帧里系统所执行的任务，但是由于流文件数据没有逻辑结构，处理时非常困难。

在流文件数据中，任务可以为线程或者方法，每一项任务都附有任务名称、起始标记、起始时间戳、终止标记和终止时间戳；由于采用流式存储形式，因此在流文件数据中任务的起始和终止都是顺序记录的，而无法清楚地展示任务结构。对于包含有子任务的任务而言，该任务与其子任务的起始标记、终止标记等相互嵌套，导致更加难以辨识。本步骤通过识别流文件数据中的任务名称、起始标记和终止标记，对帧结构进行重构，以还原帧与其任务的对应关系。

s11，从所述流文件数据中获取与所述任务名称对应的时间戳。流文件数据中的每一项任务包括两个时间戳，即起始时间戳和终止时间戳，分别用来标记该任务的起始时间和终止时间。

s12，根据所述帧结构和所述时间戳生成帧数据。步骤s10中得到的帧结构实现了对帧中各任务间层次关系的重构，本步骤进一步根据所述帧结构和步骤s11中获取到的时间戳，将各任务基于同一的时间轴进行排列，从而得到既包含各任务的层次关系，又包含时间逻辑的帧数据。在执行完毕步骤s12后，实现了将流文件数据转换为结构化的帧数据，一方面可以提高后续处理速度，另一方面在使用者需要查看特定帧时可以直接访问该帧对应的帧数据，也提高了数据的可读性。

s13，据所述帧数据查找超时帧，根据所述超时帧的状态确定卡顿原因。根据帧数据可以获取每一帧的状态，包括每一帧的处理耗时以及每一帧中所执行的各任务的处理耗时，通过对处理耗时的分析，可以找到超时帧中的超时任务，从而根据任务确认卡顿发生的原因。

从上面所述可以看出，根据本实施例提供的分析应用程序卡顿的方法，因为采用将记录有应用程序运行过程的流文件数据恢复为帧数据，以及根据帧数据查找超时帧并根据其状态确定卡顿原因的技术手段，以自动化的过程实现了对应用程序运行过程的分析，所以克服了现有技术人工分析耗时费力的技术问题，进而达到了提高卡顿分析效率并节约人力成本的技术效果。

在一些可选的实施例中，s12，根据所述帧结构和所述时间戳生成帧数据的步骤包括：

根据与各所述任务名称对应的起始时间戳和终止时间戳，确定帧结构中各任务的起始时间和终止时间。

以所述帧结构中主任务的起始时间作为所述帧的起始时间；判断所述帧结构是否包含显示任务；若不包含，则以所述帧结构的主任务的终止时间作为帧的终止时间；若包含，则以所述显示任务的终止时间作为帧的终止时间。主任务是指帧结构中的主要任务，通常为帧结构中第一个开始的任务；显示任务是指与硬件的显示设备交互实现最终的图像显示功能的任务，当帧结构中存在显示任务时，主任务在执行到一定阶段后会将处理好的相关数据传递给显示任务，有显示任务最终实现显示功能，因此显示任务的终止时间会落后于主任务的终止时间，此时应当以显示任务的终止时间作为整个帧的终止时间。

生成包含所述帧的帧结构、所述帧的起始时间和终止时间以及所述帧中各任务的起始时间和终止时间的帧数据。帧数据的一种较佳的时间方式是基于同一时间轴，将各任务按照其层次关系和起始、终止时间进行排放，从而可以使开发者清楚地了解一帧中各任务的执行顺序。

需要说明的是，流文件数据中的时间戳所标记的时间是操作系统时间，为了更加直观地体现各任务在单次卡顿分析中的时间节点，可以对时间戳进行预处理，即将第一个任务的起始时间戳设置为0时刻，并在保持时间差的前提下转换其他时间戳的数值，以使全部任务分布在以0时刻为起始时刻的毫秒级时间轴上。在一些可选的实施方式中，还可以根据各任务的起始时间戳和终止时间戳计算该任务的耗时，以便于执行后续步骤对超时帧的查找。

从上面所述可以看出，本实施例的方法可以将顺序记录的流文件数据还原为结构化的帧数据，不但便于查找超时帧，还可以提高数据的可读性。

可选的，所述方法还包括：

在s10，根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构的步骤前，

使用自动化脚本模拟应用程序运行过程，以及将应用程序运行过程记录为流文件数据。自动化脚本是指预先配置好的、包含操作指令并可自动运行的脚本文件，自动化脚本可以自动按照一定顺序执行操作指令，从而模拟人工对应用程序的操作。可选的，自动化脚本包含的操作指令应当是直接作用于应用程序所运行的硬件设备上的输入输出设备的指令，而不是直接作用于应用程序的指令，以提高模拟运行过程的真实度。例如对于运行于移动终端的应用程序，操作指令应当是例如模拟触控屏的触控信号；对于运行于台式计算机上的应用程序，操作指令应当是例如模拟键盘的输入信号或者鼠标的点击信号。

在一些可选的实施例中，s20中，根据所述超时帧的状态确定卡顿原因的步骤包括：

预先设置超时帧状态与卡顿原因的关联关系，根据所述关联关系确定与所述帧数据中的超时帧对应的卡顿原因。

根据超时帧表现出的状态并结合技术经验，可以超时帧状态与卡顿原因之间的联系；将这些状态与对应的卡顿原因的关联关系进行保存，即可自动化地确定卡顿原因。超时帧状态包括多个方面，例如，多个帧连续超时，且每一帧中均出现了同一个超时任务；又如，超时帧中出现了特定的超时任务等。

为了使本发明的技术方案更加清楚，下面通过一个具体的实施例对本发明的技术方案进行进一步说明。

图2是根据本发明另一实施例的分析应用程序卡顿的方法的主要步骤的示意图；图3是根据本发明另一实施例的分析应用程序卡顿的方法中帧结构的示意图。

如图2所示，本实施例根据本发明提供的上述方法，提出一种基于android系统的智能设备的卡顿测试方法，主要包括以下步骤：

s20，使用自动化脚本模拟app待测试界面的运行过程，以及将应用程序运行过程记录为html文件。在本实施例中，应用程序具体为基于安卓系统运行的app，应用程序的运行过程具体为app的待测试界面的运行过程。程序卡顿最直观的体现在界面切换或变化的过程，例如在滑动界面中的列表时为了渲染新的显示内容导致的卡顿，或者在点击了界面中的某个插件时触发了显示特效后的卡顿等。本实施例使用自动化脚本模拟app待测试界面的运行过程，例如对于使用在具备触摸屏的移动设备的app，所述自动化脚本的作用是向处理器发送触控信号，模拟人工的触控行为。

所述html文件是使用systrace工具生成的流式文件，在文件体的<scriptclass＝“trace-data”type＝“application/text”>……</script>中记录着所有app界面操作过程中记录的数据，例如包括如下数据：

(1)taskname-25917(25917)[000]...1699252.417026:tracing_mark_write:b|25917|choreographer#doframe

(2)taskname-25917(25917)[000]...1699252.417046:tracing_mark_write:b|25917|input

(3)taskname-25917(25917)[000]...1699252.417094:tracing_mark_write:e

(4)taskname-25917(25917)[000]...1699252.417108:tracing_mark_write:e

以上述(1)的数据为例，“taskname”是指此次测试的名称，如果是应用的主线程，就用这个应用的包名；还可能是应用的其它线程，例如renderthread线程；

第一个括号外的“25917”表示线程的id；第二个括号内的“(25917)”，表示线程所属进程的id，如果是进程的主线程，那么进程id和线程id一样；第三个“25917”是进程的id，同第二个；例如某进程有一个renderthread的子线程，则记录可能为：renderthread-26308(25917)[001]...1699250.872633:tracing_mark_write:b|25917|tessellatepath，表示这个应用的进程(id为25917)中有个renderthread子线程(id为26308)；

“...1”表示cpu的编号，从0开始，如果为8核的cpu，则取0到7；

“choreographer#doframe”为关键字，即前面实施例中所称的任务名称，主要表示app中使用的方法；

“b”为起始标记，表示此项记录是方法的开始时刻记录，而(3)和(4)中的“e”为终止标记，表示此项记录是方法的结束时刻记录；

“699252.417026”为时间戳，直接记录的是系统时间，后续步骤中会换算为本次检测的从0时刻开始的相对时间；位于“b”后的时间戳为起始时间戳，位于“e”后的时间戳为终止时间戳；

从(1)-(4)可以看出，html文件中顺序记录了各方法的开始和结束，存在着嵌套结构，因此难以直接阅读。以(1)-(4)为例，即包含了两个方法，且“input”方法从属于“choreographer#doframe”方法。

s21，解析原始的记录以得到帧数据的信息。帧数据的信息包括任务名称线程id，时间戳等信息；如果是帧数据的记录，则帧数据的信息还包括帧的始末标记(b，e)，进程id，方法等。在html文件中，除了帧数据相关的记录外，还包含了其他类型数据的记录，本步骤从html文件中选取了与帧数据相关的记录以便于重构帧数据，并且排除了与卡顿无关的数据以便于阅读。

s22，根据帧数据的信息重构帧数据。待测试界面对应的帧数据以”choreographer#doframe”或者”performtraversals”关键字开始，中间嵌套大量的方法操作。在某些机型上，帧数据开始可能还有”deliverinputevent”，”obtainview”，”setuplistitem”等关键字的数据。如果存在renderthread，render线程的数据开始标记为”drawframe”。如果帧数据有开始的标记b，但是没有结束标记e，则认为这是个不完整的帧，不参与后续超时帧的分析。

s23，把目标app的帧数据和renderthread帧数据(如果存在)根据时间的关联合并成完整的帧数据。在合并完成后，还可选地为每一帧、每个方法添加起始时间戳和终止时间戳。一个最复杂的完整的帧通常的结构如图3所示，图3中示意内容为方法或者线程名称，表示此方法执行的跨度，例如主线程绘制一帧都在choreographer.doframe方法(android5.0及以上版本)或performtraversals方法中完成，例如deliverinputevent处理用户操作行为的方法；obtainview和setuplistitem用来获取和设置列表信息；animation用来处理动画；travelsal中包含测量，布局和展示。可以根据各帧和各方法的启示时间戳和终止时间戳绘制例如图3所示的帧数据结构示意图，通过图形方式标识各方法的时间顺序，以便于阅读。

继续参考图3所示，在一帧的处理过程中，可能包含了多个并行的线程，在app主线程处理到draw阶段后，会把结果交给renderthread方，后者再参与与系统的显示模块交互。当renderthread处理完成之后表示这帧数据结束了，所以帧起始时间戳即为app主线程的起始时间戳，帧终止时间戳即为renderthread线程的终止时间戳(当帧不包含renderthread线程时，帧终止时间戳为app主线程的终止时间戳)，完整的帧长度可以根据app主线程中帧起始时间和renderthread的结束时间计算出来。

s24，根据帧数据执行卡顿分析。根据android界面设计要求，界面流畅的标准是帧率达到60帧，据此计算，每个帧的时长不能超过16ms。在卡顿分析中，可以适当放宽要求，app主线程时长大于20ms，renderthread线程时长大于20ms，或者整个完整帧的长度大于30ms，则认为超时帧。

在发现了超时帧数据后，需要分析超时帧产生的原因。需要查找超限帧包含的方法，分析这些方法占用的时长，判断产生的原因。在确定超时帧数据的状态与卡顿原因的关系之后，可以建立二者之间的关联，并采用自动方法进行匹配以实现自动化的卡顿分析。根据经验，android界面中一般的卡顿的情形和对应的原因如下：

(1)choreographer#doframe/performtraversals超长(>20ms)，且非连续出现，它的方法包含了超长的obtainview/setuplistitem(>8ms)，表明在listview获取新的数据时createview/measure耗时，需要做优化；

(2)每一帧performtraversals包含measure操作且超长帧连续出现，表明在滑动操作过程中onscroll的代码中添加了导致重新刷新的代码；

(3)目标app或renderthread的数据中drawdisplaylist方法超时(>12ms)，表明布局中存在导致opengl绘制超时的操作，如setalpha等；

(4)出现大帧数据时，在超时的方法中找到gc相关的字段，表明是频繁的内存分配释放，导致在操作过程中出现了gc致使界面暂停，需要对局部变量的分配进行优化。

下面通过一个例子对本实施例方法的具体使用进行说明，例如对于如下html文件中的部分数据：

app.package.name-25917(25917)[003]...1699253.574979:tracing_mark_write:b|25917|animation

app.package.name-25917(25917)[003]...1699253.576824:tracing_mark_write:b|25917|obtainview

app.package.name-25917(25917)[004]...1699253.586487:tracing_mark_write:e

app.package.name-25917(25917)[004]...1699253.587492:tracing_mark_write:b|25917|setuplistitem

app.package.name-25917(25917)[003]...1699253.591303:tracing_mark_write:e

app.package.name-25917(25917)[003]...1699253.591366:tracing_mark_write:e

根据本实施例的方法对某app进行卡顿分析后，输出结果为：

检测到超时帧：起始时间3278.179ms，帧长30.762ms，

其中方法animation方法耗时16.387ms，

animation的子方法obtainview耗时9.663ms，

animation的子方法setuplistitem耗时3.811ms，

obtainview消耗时间过长，请检查listview类的oncreateview方法中是否有耗时操作。

图4是根据本发明实施例的分析应用程序卡顿的装置的主要模块的示意图。

如图所示，根据本发明实施例的另一个方面，提供了一种分析应用程序卡顿的装置400，包括：

帧结构模块401，用于根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构；

时间戳模块402，用于从所述流文件数据中获取与所述任务名称对应的时间戳；

帧数据模块403，用于根据所述帧结构和所述时间戳生成帧数据；

卡顿分析模块404，用于根据所述帧数据查找超时帧，根据所述超时帧的状态确定卡顿原因。

在一些可选的实施例中，所述帧数据模块403还用于：

根据与各所述任务名称对应的起始时间戳和终止时间戳，确定帧结构中各任务的起始时间和终止时间；

以所述帧结构中主任务的起始时间作为所述帧的起始时间；

判断所述帧结构是否包含显示任务；

若不包含，则以所述帧结构的主任务的终止时间作为帧的终止时间；若包含，则以所述显示任务的终止时间作为帧的终止时间；

生成包含所述帧的帧结构、所述帧的起始时间和终止时间以及所述帧中各任务的起始时间和终止时间的帧数据。

在一些可选的实施例中，所述装置400还包括：

流文件记录模块405，用于使用自动化脚本模拟应用程序运行过程，以及将应用程序运行过程记录为流文件数据。

在一些可选的实施例中，所述卡顿分析模块404还用于：

预先设置超时帧状态与卡顿原因的关联关系；以及根据所述关联关系确定与所述帧数据中的超时帧对应的卡顿原因。

在一些可选的实施例中，所述流文件数据为使用systrace工具记录的html文件。

从上面所述可以看出，根据本实施例提供的分析应用程序卡顿的装置，因为采用将记录有应用程序运行过程的流文件数据恢复为帧数据，以及根据帧数据查找超时帧并根据其状态确定卡顿原因的技术手段，以自动化的过程实现了对应用程序运行过程的分析，所以克服了现有技术人工分析耗时费力的技术问题，进而达到了提高卡顿分析效率并节约人力成本的技术效果。

图5示出了可以应用本发明实施例的分析应用程序卡顿的方法或分析应用程序卡顿的装置的示例性系统架构500。

如图5所示，系统架构500可以包括终端设备501、502、503，网络504和服务器505。网络504用以在终端设备501、502、503和服务器505之间提供通信链路的介质。网络504可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备501、502、503通过网络504与服务器505交互，以接收或发送消息等。终端设备501、502、503上可以安装有各种待测试的应用程序，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备501、502、503可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器505可以是提供各种服务的服务器，例如对用户利用终端设备501、502、503运行的待测试应用程序的运行过程进行记录和分析的运算服务器。运算服务器可以对接收到的记录数据进行重构、分析等处理，并输出处理结果。

需要说明的是，本发明实施例所提供的分析应用程序卡顿的方法一般由服务器505执行，相应地，分析应用程序卡顿的装置一般设置于服务器505中。

应该理解，图5中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

根据本发明的实施例，本发明还提供了一种电子设备和一种可读存储介质。

图6是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

下面参考图6，其示出了适于用来实现本发明实施例的终端设备的计算机系统500的结构示意图。图6示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图6所示，计算机系统600包括中央处理单元(cpu)601，其可以根据存储在只读存储器(rom)602中的程序或者从存储部分608加载到随机访问存储器(ram)603中的程序而执行各种适当的动作和处理。在ram603中，还存储有系统600操作所需的各种程序和数据。cpu601、rom602以及ram603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。

以下部件连接至i/o接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本发明的实施例，上文主要步骤的示意图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行主要步骤的示意图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(cpu)601执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括帧结构模块、时间戳模块、帧数据模块和卡顿分析模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，帧结构模块还可以被描述为“用于根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

根据记录有应用程序运行过程的流文件数据中的任务名称，以及与所述任务名称对应的起始标记和终止标记构建帧结构；

从所述流文件数据中获取与所述任务名称对应的时间戳；

根据所述帧结构和所述时间戳生成帧数据；

根据所述帧数据查找超时帧，根据所述超时帧的状态确定卡顿原因。

根据本发明实施例的技术方案，因为采用将记录有应用程序运行过程的流文件数据恢复为帧数据，以及根据帧数据查找超时帧并根据其状态确定卡顿原因的技术手段，以自动化的过程实现了对应用程序运行过程的分析，所以克服了现有技术人工分析耗时费力的技术问题，进而达到了提高卡顿分析效率并节约人力成本的技术效果。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。