一种卡顿异常监测方法、装置、终端设备及介质与流程

1.本公开涉及终端领域，尤其涉及一种卡顿异常监测方法、装置、终端设备及介质。


背景技术：

2.随着技术发展，终端设备的使用范围越来越广泛。基于终端设备的操作系统(比如安卓)，终端设备能够支持多种应用程序。在终端设备的使用过程中，由于安装的应用程序越来越多，在使用过程中会发生卡顿现象。相关技术中缺乏有效发现并解决终端设备卡顿问题的方法。


技术实现要素：

3.为克服相关技术中存在的问题，本公开提供一种卡顿异常监测方法、装置、终端设备及介质。
4.根据本公开实施例的第一方面，提供一种卡顿异常监测方法，应用于终端设备，包括：
5.监测终端设备运行期间的时间信息；
6.根据所述时间信息，确定终端设备运行期间是否出现卡顿异常；
7.当出现卡顿异常时，存储所述卡顿异常对应的异常日志信息，所述异常日志信息包括卡顿异常位置及卡顿异常时间。
8.可选地，所述监测终端设备运行期间的时间信息，包括：
9.监测应用程序运行期间的时间信息、监测进程间通信的时间信息、监测系统服务进程的时间信息和/或系统运行的时间信息。
10.可选地，所述卡顿异常位置包括应用进程、进程间通信、系统服务进程和/或系统中的异常位置。
11.可选地，所述根据所述时间，确定终端设备运行期间是否出现卡顿异常，包括：
12.根据所述时间信息和与其对应的预设卡顿阈值，确定终端设备运行期间是否出现卡顿异常。
13.可选地，所述根据所述时间信息和与其对应的预设卡顿阈值，确定终端设备运行期间是否出现卡顿异常，包括：
14.判断所述时间信息是否超过所述预设卡顿阈值；
15.若所述时间信息超过所述预设卡顿阈值，确定终端设备运行期间出现卡顿异常。
16.可选地，所述方法还包括：
17.接收异常日志请求信息；
18.输出所述异常日志信息至外接设备，和/或，显示所述异常日志信息于终端设备。
19.根据本公开实施例的第二方面，提供一种卡顿异常监测装置，应用于终端设备，包括：
20.监测模块，用于监测终端设备运行期间的时间信息；
21.确定模块，用于根据所述时间信息，确定终端设备运行期间是否出现卡顿异常；
22.存储模块，用于当出现卡顿异常时，存储所述卡顿异常对应的异常日志信息，所述异常日志信息包括卡顿异常位置及卡顿异常时间。
23.可选地，所述监测模块，具体用于：
24.监测应用程序运行期间的时间信息、监测进程间通信的时间信息、监测系统服务进程的时间信息和/或系统运行的时间信息。
25.可选地，所述卡顿异常位置包括应用进程、进程间通信、系统服务进程和/或系统中的异常位置。
26.可选地，所述确定模块具体用于：
27.根据所述时间信息和与其对应的预设卡顿阈值，确定终端设备运行期间是否出现卡顿异常。
28.可选地，所述确定模块包括：
29.判断子模块，用于判断所述时间信息是否超过所述预设卡顿阈值；
30.确定子模块，用于若所述时间信息超过所述预设卡顿阈值，确定终端设备运行期间出现卡顿异常。
31.可选地，所述装置还包括：
32.接收模块，用于接收异常日志请求信息；
33.输出模块，用于输出所述异常日志信息至外接设备，和/或，显示所述异常日志信息于终端设备。
34.根据本公开实施例的第三方面，提供了一种终端设备，包括：
35.处理器；
36.用于存储处理器的可执行指令的存储器；
37.其中，所述处理器被配置为执行如上任一项所述的卡顿异常监测方法。
38.根据本公开实施例的第四方面，提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由智能设备的处理器执行时，使得终端设备能够执行如上任一项所述的卡顿异常监测方法。
39.本公开的实施例提供的技术方案可以包括以下有益效果：使用本公开的方法，能够实时监测终端设备在运行过程中是否发生卡顿，并且在卡顿发生时，能够及时存储异常日志信息，以使用户或开发人员根据异常日志信息方便快捷的获知卡顿发生的原因。
40.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
41.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
42.图1是根据一示例性实施例示出的方法的流程图。
43.图2是根据一示例性实施例示出的方法的流程图。
44.图3是根据一示例性实施例示出的方法的流程图。
45.图4是根据一示例性实施例示出的方法的流程图。
46.图5是根据一示例性实施例示出的方法的流程图。
47.图6是根据一示例性实施例示出的方法的监测框图。
48.图7是根据一示例性实施例示出的时间节点示意图。
49.图8是根据一示例性实施例示出的装置的框图。
50.图9是根据一示例性实施例示出的装置的框图。
51.图10是根据一示例性实施例示出的装置的框图。
52.图11是根据一示例性实施例示出的终端设备的框图。
具体实施方式
53.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
54.随着技术发展，终端设备的使用范围越来越广泛。基于终端设备的操作系统(比如安卓)，终端设备能够支持多种应用程序。
55.终端设备一般包括处理器、存储器和显示屏，以实现终端设备系统的运行或应用程序的运行。其中，处理器通过运行或执行存储在存储器内的指令、程序、代码集或指令集，以及调用存储在存储器内的数据，执行智能设备的各种功能和处理数据。比如，处理器可集成中央处理器(centralprocessing unit，cpu)、图像处理器(graphics processing unit，gpu)和调制解调器等中的一种或几种。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。存储器可用于存储指令、程序、代码、代码集或指令集。比如，存储器的存储程序区可存储用于实现操作系统的指令、用于执行至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现控制方法的指令等。
56.以操作系统为安卓系统的智能设备为例，存储器中存储有linux内核层、系统运行库层、应用框架层和应用层。其中，linux内核层为智能设备的各种硬件提供了底层的驱动，如显示驱动、音频驱动等。系统运行库层通过一些c/c 库来为android系统提供了主要的特性支持，如opengl/es库提供了3d绘图的支持。应用框架层提供了构建应用程序时可能用到的各种api，比如构建如下程序：窗口管理、视图管理等。应用层中运行有至少一个应用程序，这些应用程序可以是操作系统自带的，比如短信程序；也可以是第三方开发者所开发的应用程序，比如微信程序、qq程序等。
57.在终端设备的使用过程中，由于安装的应用程序越来越多，在使用过程中会发生卡顿现象。相关技术中缺乏有效发现并解决终端设备卡顿问题的方法。
58.为保证终端设备的质量会进行开发测试，但在开发测试过程中仅能解决终端设备一部分卡顿问题，而在使用过程中，由于终端设备使用场景的多样化、操作习惯的多样化，卡顿现象是时有发生的，而卡顿现象的原因也不尽相同。
59.相关技术中，在解决终端设备卡顿性能问题的过程中，往往采用systrace(系统调用跟踪提供器)工具，但该工具使用难度较大，需开发人员二次分析才能获知异常原因。或者仅根据android系统的原生bugreport日志系统进行性能分析，但bugreport分析所需专
业性强，分析过程繁琐复杂。
60.为解决上述技术问题，本公开提出了一种卡顿异常监测方法，应用于终端设备，包括：监测终端设备运行期间的时间信息；根据时间信息，确定终端设备运行期间是否出现卡顿异常；当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。使用本公开的方法，能够实时监测终端设备在运行过程中是否发生卡顿，并且在卡顿发生时，能够及时存储异常日志信息，以使使用者根据异常日志信息方便快捷的获知卡顿发生的原因。
61.在一个示例性的实施例中，本实施例的方法，应用于终端设备，其中，终端设备比如可以是手机、平板电脑、笔记本电脑和电子书等便携式电子设备。终端设备可以是操作系统为安卓(android)系统的终端设备，也可以是操作系统是ios系统的终端设备。
62.以操作系统为安卓(android)系统的终端设备为例，本实施例在终端设备的bugreport中集成有miturbo模块，miturbo模块能够实时监控终端设备运行期间的日志信息。并且本公开中miturbo采用日志增强技术优化了miturbo日志信息的日志打印的位置、日志打印的内容以及日志打印的数量，使得通过miturbo日志增强技术获得的日志信息中包含的信息更丰富，比如本实施例中日志信息中包含事件的运行时间及运行情况，当卡顿异常发生时，miturbo可监测到异常日志信息，通过miturbo监控的异常日志信息即可得知卡顿异常发生的位置及原因。
63.如图1所示，本实施例的方法包括如下步骤：
64.s110、监测终端设备运行期间的应用程序运行的时间信息。
65.s120、根据时间信息，确定终端设备运行期间是否出现卡顿异常。
66.s130、当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。
67.在步骤s110中，miturbo能够监测终端设备的应用程序在运行过程中的日志信息，即获取app运行层面的日志信息。参照图6所示，miturbo在应用程序运行过程中的日志信息是基于looper的消息实时监控获得的，监测的日志信息可以包括：主线程消息耗时监控日志、callback监控日志及耗时统计日志(running时间、runnable时间及sleep时间)。
68.其中，android系统中looper负责管理线程的消息队列和消息循环，一个线程可以存在一个消息队列和一个消息循环(looper)。android的主线程一般负责界面的更新操作(通过loop.getmainlooper()可以获得当前进程的主线程的looper对象)，对主线程消息进行监控，能够发现进程中的耗时信息。比如在使用消息机制进行ui(用户界面)更新过程中，更新ui的线程(比如activity是一个运行于主线程中的ui线程)具有looper，在其loop方法中不断调取message(消息)，可监测各消息的执行时间。此外，android系统每隔一定时间(如16ms)发出vsync(垂直同步)信号，通知界面进行重绘、渲染。在此过程中，涉及callback(回调)监控，监控获得的日志信息包括两次回调的时间周期，通过两次回调的时间周期是否超时可判断此过程是否发生卡顿。可以理解的，通过耗时统计日志可以获知某一事件的running(运行)时间、runnable(运行状态)时间及sleep(限期等待状态)时间。
69.本步骤中，应用程序运行期间的时间信息比如可以是应用程序中某一事件的实际运行时间，比如应用程序中某一个事件开始运行的时间信息为t1，该事件结束运行的时间信息为t2，则该事件的实际运行时间
△
t，
△
t为该事件在应用程序运行期间的时间信息。
70.在步骤s120中，应用程序中任一事件具有其对应的预设运行时间或预设运行时间范围，当应用程序中各事件以各自对应的预设运行时间运行或在预设运行时间范围内运行，则认为该事件是正常运行的、不存在卡顿异常。当事件的实际运行时间大于预设运行时间或预设运行时间范围，认为该事件存在卡顿，此时卡顿异常的位置即为在应用进程中的该事件。
71.本步骤中，根据实际运行时间信息和与其对应的预设卡顿阈值，确定终端设备运行期间是否出现卡顿异常。
72.在一个示例中，预设卡顿阈值是指应用程序中任一事件对应的预设运行时间，应用程序运行过程中，实时判断各事件的时间信息是否超过对应的预设卡顿阈值；若时间信息超过预设卡顿阈值，确定终端设备运行期间出现卡顿异常。
73.在另一个示例中，预设卡顿阈值是指应用程序中任一事件对应的预设运行时间范围，应用程序运行过程中，实时判断各事件的时间信息是否超过对应的预设卡顿阈值(超过预设运行时间范围的上限)；若时间信息超过预设卡顿阈值，确定终端设备运行期间出现卡顿异常。
74.在步骤s130中，当出现卡顿异常时，存储miturbo日志信息中的应用程序对应的异常日志信息，异常日志信息中包括卡顿发生的位置(比如具体卡顿事件)及卡顿异常时间(比如卡顿事件延迟的时间)。比如，ui(用户界面)更新不及时，用户感知到卡顿，通过miturbo监控的日志信息可以监测到：应用程序app的主线程有耗时消息，导致ui更新不及时，同时日志消息中包含主线程的耗时消息，并输出耗时统计。
75.在一个示例中，miturbo监测到如下主线程doframelate异常日志信息：
76.01-21 12:07:01.255 21147 21147w looper:slow looper:doframe is 321ms late because of 12msg,msg 1took 90ms(cputime＝6ms late＝50ms h＝com.android.systemui.statusbar.commandqueue$h w＝655360),msg 10took 217ms(cputime＝4ms late＝110ms h＝com.android.systemui.statusbar.commandqueue$h w＝589824)
77.由本示例的日志消息可知，应用主线程繁忙，某一帧的绘制延迟时间为321ms(doframe is 321ms late)，绘制过程中执行了12个消息message(because of 12msg)，并可知各消息的执行耗时(比如msg 1took 90ms：第1个消息耗时90ms)。其中，最耗时的消息是掉帧(会引起卡顿)的最主要原因。由此，通过日志消息即可直接获知掉帧(卡顿)的原因。
78.在另一个示例中，miturbo监测到有如下activity late异常日志信息：
79.01-21 12:07:49.169 7619 7619w looper:slow looper:
80.activity com.android.quicksearchbox/.searchactivity is 633ms late(process＝ 54ms cputime＝ 8ms clienttransaction{lifecyclerequest＝android.app.servertransaction
81..pauseactivityitem})because of 33msg,
82.msg 1took 543ms(cputime＝157ms late＝1ms h＝android.os.handler c＝com.android.quicksearchbox.searchactivity$a),
83.msg 7took 82ms
84.(cputime＝3ms late＝650ms h＝android.view.choreographer$framehandler c＝android.view.choreographer$framedisplayeventreceiver),
85.msg 22took 72ms
86.(cputime＝5ms late＝585ms h＝com.miui.org.chromium.base.systemmessagehandler w＝1)
87.由本示例的日志消息可知，应用主线程繁忙，以及导致activity lifecycle回调慢的耗时message信息。比如：com.android.quicksearchbox的searchactivity的onpause(pauseactivityitem)回调延迟了633ms；在导致回调延迟的总时长(633ms)中，looper执行了33个消息(because of 33msg)，第1个消息、第7个消息及第22个消息这三个耗时消息是导致activity回调延迟的主要原因。其中，第1个消息执行耗时543ms，cpu running time(cpu运行时间)占157ms，handler＝android.os.handler callback＝com.android.quicksearchbox.searchactivity$a；第7个消息执行耗时82ms，第22个消息执行耗时72ms。
88.在另一个示例中，miturbo监测到有如下异常日志信息：
89.02-22 08:19:33.764 10231 30213 30213w looper:slow looper main:long msg:seq＝103338plan＝08:18:56.765late＝1ms wall＝36996ms running＝4ms runnable＝4ms h＝android.view.choreographer$framehandlerc＝android.view.choreographer$framedisplayeventreceiver
90.由本示例的日志消息可知，应用主线程繁忙，原因包括长消息的延迟(1ms)，并可知消息的running时间(4ms)及runnable时间(4ms)。
91.在一个示例性的实施例中，如图2所示，本实施例方法包括如下步骤：
92.s210、监测终端设备运行期间的系统运行的时间信息。
93.s220、根据时间信息，确定终端设备运行期间是否出现卡顿异常。
94.s230、当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。
95.在步骤s210中，miturbo能够监测终端设备的系统运行中的日志信息，即监测系统层面的日志信息，本实施例中系统运行监控是指对核心系统模块的监控。参照图6所示，miturbo在核心系统模块的监控日志信息中，监测的日志信息可以包括：surfaceflinger vsync上报异常监控、surfaceflinger合成图像监控及input分发流程监控。其中，surfaceflinger能够接收surface(界面)作为输入，根据透明度、大小、位置等参数，计算出每个surface在最终合成图像中的位置。通过对核心系统模块的监控，比如sf的显示监控、input输入事件的全链路监控，确定卡顿异常位置是否在系统模块的运行中。
96.步骤s220确定系统运行的时间信息是否出现卡顿异常的步骤，可参照步骤s120，此处不再赘述。
97.在步骤s230中，当出现卡顿异常时，存储miturbo日志信息中的系统运行中的异常日志信息，异常日志信息中包括卡顿异常位置(比如具体卡顿事件)及原因(比如卡顿事件延迟的时间)。
98.在一个示例中，日志信息可以包括input分发流程监控日志。一次用户输入事件的传递过程可以简化为：硬件、kernel(核心系统模块)、system_server(系统服务模块)、app(应用程序)。根据传递过程定义如图7所示的四个时间节点(t1、t2、t3及t4)，t1表示inputreader从/dev/input/xxx读出事件的时间，t2表示inputdispatcher向app发送事件的时间，t3表示app主线程开始处理输入事件的时间，t4表示app主线程处理输入事件结束
的时间。其中，system_server(系统服务模块)的耗时时间为
①
(t2-t1)，应用程序处理前的耗时为
②
(t3-t1)，应用程序处理耗时为
③
(t4-t3)。
99.比如，miturbo监测到有如下异常日志信息：
100.03-26 18:25:06.590 1306 1773w inputtransport:slow input:372ms so far,channel'3908d6b navigationbar(server)'publisher～publishmotionevent:seq＝3004,deviceid＝6,source＝0x1002,action＝0x2,actionbutton＝0x00000000,
101.flags＝0x0,edgeflags＝0x0,metastate＝0x0,buttonstate＝0x0,xoffset＝0.000000,yoffset＝-2210.000000,
102.xprecision＝1.000000,yprecision＝1.000000,downtime＝28011572008000,eventtime＝28011595886000,pointercount＝1
103.由上述日志消息可知，在向app发送事件中input超时(inputtransport:slow input)，且此时是在system_server的耗时时段(t2-t1)或应用程序处理前的耗时时段(t3-t1)。由日志信息可知超时的原因为system_server的inputdispatcher线程处理超时。本示例中input事件没有及时处理的原因是系统问题。
104.再比如，miturbo监测到有如下异常日志信息：
105.03-22 11:04:07.692 7001 7001w inputeventreceiver:app input:dispatching inputevent took 114ms in main thread！
106.由上述日志消息可知，在app运行中input超时，即本示例日志信息是在应用程序处理耗时时段(t4-t3)，超时原因为应用主线程超时(took 114ms in main thread)。本示例中input事件没有及时处理的原因是app问题。
107.通过上述示例可知，在input分发流程监控日志日志信息中，可以输出input超时原因，并区分input事件没有及时处理的原因是系统问题还是app问题。
108.在另一个示例中，日志信息还可以包括surfaceflinger合成图像监控日志。surfaceflinger合成图像的监控日志信息能够精准定位硬件合成导致的卡顿。比如，miturbo监测到有如下异常日志信息：
109.12-20 18:34:40.653 16190 16190w surfaceflinger:slow operation:98ms so far,now at docomposition completed.
110.由本示例的日志消息可知，sf运行慢，sf合成超时。
111.在surfaceflinger合成图像监控中，某一事件的耗时检查比如可以是在事件开始时打点记录起始时刻，在事件完成后记录结束时刻，从而检查该事件的耗时。比如本示例中，在开始进行frame refresh的时候打点，再分别在prepareframe、docomposition、postcomposition结束时刻检查耗时。
112.在另一个示例中，日志信息还可以包括surfaceflinger vsync上报异常监控日志，比如miturbo监测到有如下异常日志信息：
113.02-07 16:59:53.289 26972 26999w surfaceflinger:slow vsync-app on display(19261116564980353),last period is 22ms
114.由本示例的日志消息可知，surfaceflinger在进行vsync(垂直同步信号)上报app进行显示时异常。
115.在一个示例性的实施例中，如图3所示，本实施例方法包括如下步骤：
116.s310、监测终端设备运行期间系统服务进程的时间信息。
117.s320、根据时间信息，确定终端设备运行期间是否出现卡顿异常。
118.s330、当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。
119.在步骤s310中，miturbo能够监测终端设备运行期间系统服务进程(systemserver)的日志信息，本实施例监测的仍然是系统层面的日志信息。参照图6所示，miturbo在系统服务进程的监控日志信息中，监测的日志信息可以包括ams(activitymanagerservice)监控、wms(windowmanagerservice)监控及pms(packagemanagerservice)监控。其中，ams、wms以及pms等都是运行在systemserver这个进程中的线程，ams用于管理应用程序的activity，wms用于管理各个窗口的隐藏或显示等，pms用于来管理跟踪应用程序的apk、安装、解析及控制权限等。
120.步骤s320确定系统服务进程的时间信息是否出现卡顿异常的步骤，可参照步骤s120，此处不再赘述。
121.步骤s330中，当出现卡顿异常，miturbo会存储监控的系统服务进程中的异常日志信息，异常信息日志中会包括系统服务进程中的卡顿异常位置(比如具体卡顿事件)及原因(比如卡顿事件延迟的时间)。
122.在一个示例性的实施例中，如图4所示，本实施例方法包括如下步骤：
123.s410、监测终端设备运行期间的进程间通信的时间信息。
124.s420、根据时间信息，确定终端设备运行期间是否出现卡顿异常。
125.s430、当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。
126.在步骤s410中，miturbo能够监测终端设备运行期间进程间通信机制(ipc机制)的日志信息，android系统的终端设备应用进程间的ipc机制通常采用binder通信方式。
127.步骤s420确定进程间通信的时间信息是否出现卡顿异常的步骤，可参照步骤s120，此处不再赘述。
128.在步骤s430中，当出现卡顿异常，miturbo会将监控的进程间通信机制中的异常日志信息输出，异常信息日志中会包括binder通信的卡顿异常位置(比如具体卡顿事件)及原因(比如卡顿事件延迟的时间)。
129.在一个示例性的实施例中，如图5所示，本实施例方法包括如下步骤：
130.s510、监测终端设备运行期间的时间信息。
131.s520、根据时间信息，确定终端设备运行期间是否出现卡顿异常。
132.s530、当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。
133.s540、接收异常日志请求信息。
134.s550、输出异常日志信息至外接设备，和/或，显示异常日志信息于终端设备。
135.其中，步骤s510中，终端设备运行期间的时间信息可以包括应用程序运行期间的时间信息、进程间通信的时间信息、系统服务进程的时间信息和/或系统运行的时间信息，即可以同时监测图1至图4对应的实施例中涉及的时间信息。
136.步骤s520确定时间信息是否出现卡顿异常的步骤，可参照步骤s120，此处不再赘
述。
137.在步骤s530中，根据监测的日志信息，卡顿异常发生的位置可能是应用进程、进程间通信、系统服务进程和/或系统，具体可参照图1至图4对应的实施例。
138.在步骤s540中，异常日志请求信息可以是由用户发出的，也可以是由手机的厂商、app开发人员或系统开发人员等发出的。
139.在步骤s550中，本实施例的miturbo实时监测终端设备运行期间的日志信息，但只需在卡顿异常发生时，存储(可采用缓存方式)异常日志信息即可。在接收到异常日志请求信息后，miturbo可将异常日志信息输出异常日志信息至外接设备，和/或，显示异常日志信息于终端设备。在异常日志输出后，miturbo存储的异常日志信息可及时删除。
140.比如，当请求信息是开发人员发出的，异常日志信息可以输出至开发人员的计算机设备，便于开发人员针对异常原因改进终端设备的性能。再比如，当请求信息是用户发出的，异常日志信息可以直接在终端设备上显示，便于用户查看。本实施例中的异常日志信息包含卡顿异常原因及结果，因此即使是普通用户也能方便获知异常原因，便于针对异常原因采取相应处理措施，以提升终端设备的性能。本实施例中，终端设备的miturbo中可存储厂商经验，在发生卡顿异常后，用户可以通过问题反馈应用反馈问题给开发者，集成有miturbo的bugreport系统会自动生成改进方案并通知终端设备的相应进程。
141.综合上述实施例，本公开中的方法，能够在终端设备使用过程中发生卡顿时，根据miturbo日志增强方式监测的日志信息，自动确认是app的问题还是系统问题，并存储或打印输出相关的异常日志信息。使得用户或开发人员可以迅速定位卡顿异常原因，并根据原因给出合适的解决方案，极大的提高了分析问题的效率。对比相关技术中的systrace工具，本公开的方法具备非实时(卡顿异常发生时才进行日志输出或存储)、自动化分析(日志信息包含卡顿异常的原因)等特性，是一种更便捷的性能分析技术。
142.在一个示例性的实施例中，本公开提出了一种卡顿异常监测装置，如图8所示，应用于终端设备，包括：监测模块110、确定模块120及存储模块130。在实施过程中，监测模块110用于监测终端设备运行期间的时间信息。确定模块120用于根据时间信息，确定终端设备运行期间是否出现卡顿异常。存储模块130用于当出现卡顿异常时，存储卡顿异常对应的异常日志信息，异常日志信息包括卡顿异常位置及卡顿异常时间。当监测模块110用于监测应用程序运行期间的时间信息，本实施例中的装置用于实现如图1所示的方法。当监测模块110用于监测系统运行的时间信息，本实施例中的装置用于实现如图2所示的方法。当监测模块110用于监测系统服务进程的时间信息，本实施例中的装置用于实现如图3所示的方法。当监测模块110用于监测进程间通信的时间信息，本实施例中的装置用于实现如图4所示的方法。其中，卡顿异常位置可以包括在应用进程、进程间通信、系统服务进程和/或系统中的异常位置(发生卡顿的事件)。
143.在一个示例性的实施例中，参照图9，本实施例的装置包括：监测模块110、确定模块120及存储模块130，确定模块120包括判断子模块1201及确定子模块1202。在实施过程中，确定模块具体用于根据时间信息和与其对应的预设卡顿阈值，确定终端设备运行期间是否出现卡顿异常。其中，判断子模块1201用于判断时间信息是否超过预设卡顿阈值。确定子模块1202用于若时间信息超过预设卡顿阈值，确定终端设备运行期间出现卡顿异常。
144.在一个示例性的实施例中，参照图10，本实施例的装置包括：监测模块110、确定模
块120、存储模块130、接收模块140及输出模块150，本实施例中的装置用于实现如图5所示的方法。在实施过程中，接收模块140用于接收异常日志请求信息。输出模块150用于输出异常日志信息至外接设备，和/或，显示异常日志信息于终端设备。
145.如图11所示是一种终端设备的框图。本公开还提供了一种终端设备，例如，设备500可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。
146.设备500可以包括以下一个或多个组件：处理组件502，存储器504，电力组件506，多媒体组件508，音频组件510，输入/输出(i/o)的接口512，传感器组件514，以及通信组件516。
147.处理组件502通常控制设备500的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件502可以包括一个或多个处理器520来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件502可以包括一个或多个模块，便于处理组件502和其他组件之间的交互。例如，处理组件502可以包括多媒体模块，以方便多媒体组件508和处理组件502之间的交互。
148.存储器504被配置为存储各种类型的数据以支持在设备500的操作。这些数据的示例包括用于在设备500上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
149.电力组件506为设备500的各种组件提供电力。电力组件506可以包括电源管理系统，一个或多个电源，及其他与为装置500生成、管理和分配电力相关联的组件。
150.多媒体组件508包括在设备500和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件508包括一个前置摄像头和/或后置摄像头。当设备500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。
151.音频组件510被配置为输出和/或输入音频信号。例如，音频组件510包括一个麦克风(mic)，当设备500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件516发送。在一些实施例中，音频组件510还包括一个扬声器，用于输出音频信号。
152.i/o接口512为处理组件502和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
153.传感器组件514包括一个或多个传感器，用于为设备500提供各个方面的状态评估。例如，传感器组件514可以检测到设备500的打开/关闭状态，组件的相对定位，例如组件
为设备500的显示器和小键盘，传感器组件514还可以检测设备500或设备500一个组件的位置改变，用户与设备500接触的存在或不存在，设备500方位或加速/减速和装置500的温度变化。传感器组件514可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件514还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件514还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。
154.通信组件516被配置为便于设备500和其他设备之间有线或无线方式的通信。设备500可以接入基于通信标准的无线网络，如wifi，2g或3g，或它们的组合。在一个示例性实施例中，通信组件516经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件516还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
155.在示例性实施例中，设备500可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的方法。
156.本公开另一个示例性实施例中提供的一种非临时性计算机可读存储介质，例如包括指令的存储器504，上述指令可由设备500的处理器520执行以完成上述方法。例如，计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。当存储介质中的指令由电子设备的处理器执行时，使得终端设备能够执行上述的方法。
157.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本技术旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。
158.应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。