CN116701035A - 卡顿原因的确定方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种卡顿原因的确定方法、装置及电子设备，属于数据处理技术领域。该方法包括：获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

Description

卡顿原因的确定方法、装置及电子设备

技术领域

本申请属于数据处理技术领域，具体涉及一种卡顿原因的确定方法、装置及电子设备。

背景技术

目前，大数据平台收集了大量埋点数据、日志数据以及试用用户使用场景异常时采集的追踪trace数据。大数据人员可以根据埋点数据获得某些项目某项指标的趋势以及预警；性能代表人员可以根据日志和trace数据分析到卡顿或者异常的原因。然而面对服务器上海量的数据，需要大量性能代表人员分析处理。而现有的分析方式是通过人力在后台下载卡顿trace，解压转化trace，找到问题trace用浏览器打开分析。从上述的分析trace的过程可以看到，每个步骤都是非常耗时并且重复的，卡顿原因分析的效率低。

发明内容

本申请实施例的目的是提供一种卡顿原因的确定方法、装置及电子设备，能够解决现有技术分析卡顿原因效率低的问题。

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

第一方面，本申请实施例提供了一种卡顿原因的确定方法，包括：

获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；

根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；

根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

第二方面，本申请实施例提供了一种卡顿原因的确定装置，包括：

第一获取模块，用于获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；

第二获取模块，用于根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；

第一确定模块，用于根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；

第二确定模块，用于根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。

第五方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法。

第六方面，本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如第一方面所述的方法。

在本申请实施例中，通过获取埋点数据，该埋点数据用于表征电子设备发生卡顿时采集的卡顿数据，并根据埋点数据中的trace日志链接，获取与追踪trace日志链接对应的第一，根据第一trace文件，确定与第一trace文件对应的第一线程上的异常帧，并根据异常帧在中央处理器上的运行状态，确定异常帧的卡顿原因。即在需要分析卡顿原因时，自动获取埋点数据，并自动根据埋点数据中的trace日志链接下载第一trace文件，在批量处理卡顿异常确定卡顿原因时，能够准确定位到对应的trace文件数据，并通过分析trace文件数据精准确定卡顿的异常帧，实现自动分析trace文件确定卡顿点；再根据异常帧在中央处理器上的不同运行状态确定异常帧的具体卡顿原因，整个流程自动化分析卡顿原因，提高了卡顿原因分析效率。

附图说明

图1是本申请实施例提供的数据分析系统框架示意图；

图2是本申请实施例提供的卡顿原因的确定方法的流程示意图之一；

图3是本申请实施例提供的表格示意图；

图4是本申请实施例提供的卡顿原因的确定方法的流程示意图之二；

图5是本申请实施例提供的一种卡顿原因的确定装置的结构示意图；

图6是本申请实施例提供的一种电子设备的结构框图；

图7是本申请实施例提供的另一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的卡顿原因的确定方法进行详细地说明。

本申请实施例提供了一种卡顿原因的确定方法，可以应用于数据分析系统，该数据分析系统框架如图1所示。该数据分析系统包括两类模块，一类是公共模块，一类是场景适配模块。其中，公共模块是数据分析系统提供的基础能力，是各个独立的模块，可以单独提供接口软件包文件格式jar包单独适配；场景适配模块是数据分析系统基于现有项目适配自动分析各类场景的模块，一方面在项目开发中通过试用大数据分析识别各个场景卡顿原因，另一方面分析流程可以供其他开发者参考。

具体的，公共模块具体包括如下模块：

配置管理模块ConfigManager:主要承接整个功能的配置工作，对外包含访问接口的配置、解析工具的配置，对内包含各类开关的配置、分析场景配置等。

表格管理模块ExcelManager:主要读入/写出excel表格，提供接口访问excel表格内容，用于埋点数据内容的分析。

报告故障ReportBug:主要对自动分析完成的场景，自动提bug到bug系统，并且生成bug list列表供相关人员跟进问题。

日志下载程序模块LogDownloader:主要管控批量下载/处理日志功能。

压缩工具模块ZipUtils:提供解压/压缩日志报功能。

追踪转换模块TraceConverter:主要接收trace转化工具，封装转化指令，提供接口转化指定trace文件。

日志管理模块LogManager:包含日志工具LogUtils和追踪工具TraceUtils，主要针对所有日志包的处理，并且提供接口供开发适配者获取想要的信息。

场景适配模块主要对现有项目中发现的问题进行适配自动识别，一方面已适配的场景可以用于持续观察优化是否已经生效，另一方面后续项目可以自动识别此类卡顿原因。具体包括如下模块：

分析模块Analyzer:主要串联所有公共模块流程，读excel→下载日志压缩包→解压压缩包→转化trace→删除压缩包→找问题trace→分析问题trace→回写分析结果到excel→上报bug→删除所有日志文件。

场景管理模块SceneManeger：各个场景分析的父类，主要串联场景分析流程：读trace→找分析进程→找待分析的时间区间/标签→找异常帧的刷新时间→遍历已适配的原因→打印可能的所有原因→回写结果到内存excel→释放内存。其中，各个场景是项目开发过程中经常被投诉所总结出来的场景。

评价模块Judger:针对一次异常解析出来的多个原因进行评分，该评分可以供分析人员权衡哪个原因是主要卡顿原因。该评分的产生需要大量项目数据人工分析之后，给多原因进行评分分级，经过大量数据迭代之后，最后评分高的原因会逐步筛选出来，成为主要异常原因。

如图2所示，上述卡顿原因的确定方法，具体可以包括如下步骤：

步骤201，获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据。

具体的，用户在使用电子设备时，如果电子设备发生卡顿，则采集卡顿数据上报至服务器，得到埋点数据。在需要进行卡顿分析的情况下，通过取数模板从服务器获取埋点数据，并通过ExcelManager模块将埋点数据生成excel表格，如图3所示，excel表格中一行就是一个卡顿异常。解析excel表格得到trace日志链接、分辨率、网络类型、平均温度、最高温度、开始电量、结束电量、充电模式等。如果有重复的trace日志链接，则将重复的trace日志链接进行合并，如果有无效的trace日志链接或者空链接，则将无效的trace日志链接或者空链接剔除。

步骤202，根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件。

具体的，根据trace日志链接，通过LogDownloader模块、ZipUtils模块、TraceConverter模块自动获取对应的第一trace文件，该第一trace文件即为待分析的trace文件。

其中，第一trace文件即系统追踪system trace文件，记录系统中所有进程调用关系的文件，主要用于性能问题分析。第一trace文件可以在卡顿的时候采集，具体是否每次卡顿都采集，需要根据采集的指令什么时候调用决定。第一trace文件中可以分析出卡顿时，系统方法的调用关系。

步骤203，根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧。

具体的，根据第一trace文件获取对应的异常线程，即第一线程，并进一步确定该第一线程上的异常帧，即确定第一线程上的卡顿点为异常帧卡顿。

步骤204，根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

具体的，在确定异常帧之后，解析异常帧在中央处理器(Central ProcessingUnit，CPU)上的运行状态，并根据该异常帧在CPU上的运行状态，判断异常帧的卡顿原因，即确定异常帧的卡顿原因。

需要说明的是，CPU运行状态包括：

运行中running状态：某任务在某个CPU核上运行的状态；

磁盘读写block io状态：任务运行到某个时刻，等待将依赖资源读入内存的状态；

不可中断睡眠uninterrupt sleep状态：该线程和另外线程在争抢锁，导致的阻塞状态；

可运行runnable状态：该任务等待被调度到CPU上运行的状态；

休眠sleep状态：该线程任务依赖其他线程任务，在等待其他线程任务执行结束的状态。

在本申请上述实施例中，通过获取埋点数据，该埋点数据用于表征电子设备发生卡顿时采集的卡顿数据，并根据埋点数据中的trace日志链接，获取与追踪trace日志链接对应的第一trace文件，根据第一trace文件，确定与第一trace文件对应的第一线程上的异常帧，并根据异常帧在中央处理器上的运行状态，确定异常帧的卡顿原因。即在需要分析卡顿原因时，自动获取埋点数据，并自动根据埋点数据中的trace日志链接下载第一trace文件，在批量处理卡顿异常确定卡顿原因时，能够准确定位到对应的trace文件数据，并通过分析trace文件数据精准确定卡顿的异常帧，实现自动分析trace文件确定卡顿点；再根据异常帧在中央处理器上的不同运行状态确定异常帧的具体卡顿原因，整个流程自动化分析卡顿原因，提高了卡顿原因分析效率。

作为一可选的实施例，所述步骤202根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件，具体包括：

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的trace日志压缩包；

对所述trace日志压缩包进行解压，得到解压文件；

将所述解压文件中的第二trace文件进行格式转换，得到所述第一trace文件。

具体的，根据trace日志链接，通过LogDownloader模块下载对应的trace日志压缩包，并将trace日志压缩包保存在预定的目录中。通过ZipUtils模块解压trace日志压缩包得到解压文件，并将解压文件保存在软件容器Map中。判断Map中解压文件对应的文件夹中是否有第二trace文件，如果没有第二trace文件，则通过ZipUtils模块删除该解压文件以及对应的trace日志压缩包，以节省磁盘空间。

如果有第二trace文件，则判断第二trace文件的文件大小是否小于预设值(如：5M)；如果第二trace文件的文件大小小于预设值，则通过ZipUtils模块删除该解压文件以及对应的trace日志压缩包，以节省磁盘空间。如果第二trace文件的文件大小大于或等于预设值，则通过TraceConverter模块调用计算机编程语言Python转化脚本将第二trace文件转化成待分析的第一trace文件(如：.html后缀的文件)，此文件即为待分析卡顿原因的文件。

其中，trace日志压缩包是电子设备上报到服务器的所有日志信息，包括但不限于：各类日志(后称log)、分析工具systrac、系统属性设置、应用列表，进程信息等。各类日志文件可以分析代码逻辑异常；第一trace文件可以分析是否是性能问题。

可以理解的是，为了节省磁盘空间，可以通过ZipUtils模块删除该解压文件对应的trace日志压缩包，保存解压文件。

需要说明的是，Map是一种软件容器，用于保存键值对，让键和值形成映射关系

作为一可选的实施例，所述步骤203根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧，具体包括：

根据所述第一trace文件的标签tag名或者包名，获取与所述标签tag名或者包名对应场景的第一时间区间；

解析所述第一时间区间内的所有帧，确定所述第一时间区间内的异常帧，所述异常帧为所述第一时间区间内的所有帧中耗时最长的帧。

具体的，根据第一trace文件的标签tag名或者包名，在第一trace文件中获取如下基础信息：解析起始时间、解析结束时间、进程ID(Process Id，PID),trace文件对应的线程ID(Thread Id，TID)、线程名等，上述基础信息可用于检索其他线程的基础信息。并且，根据第一trace文件的标签tag名或者包名，获取与标签tag名或者包名对应场景的第一时间区间，并通过SceneManeger模块自动选择对应的解析器解析不同的场景的第一时间区间的所有帧，得到每一帧的运行时间和运行状态。通过每一帧的运行时间和运行状态判断异常帧。进一步的，在第一时间区间内的所有帧中运行时间最长(即耗时最长)的帧为异常帧。

例如：应用启动场景，解析绑定应用程序BindApplication tag的运行状态，活动开始ActivityStart tag的运行状态，活动恢复ActivityResume tag的运行状态；如果是进入/退出动效场景，解析进入应用程序窗口openApp_window或者退出应用窗口closeApp_window时间区间内的所有帧的运行状态。

其中，tag表示性能数据采集和systrace文件中标签，用来记录一段代码运行过程状态的标签。一个tag可以反应用户执行某个操作的耗时情况，也可以反应一个方法执行的耗时情况。

需要说明的是，在第一trace文件有tag名的情况下，优先通过tag名获取第一时间区间。在第一trace文件没有tag名的情况下，通过包名获取第一时间区间。

作为一可选的实施例，所述步骤204根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因，具体包括：

在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿；

在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿；

其中，所述第一状态为休眠sleep状态耗时最长的状态；所述第二状态为运行中running状态耗时最长的状态、可运行runnable状态耗时最长的状态、不可中断睡眠uninterrupt sleep状态耗时最长的状态和磁盘读写block io状态耗时最长的状态中的至少一者。

具体的，在确定异常帧之后，解析该异常帧的CPU上的运行状态，通过异常帧在CPU上的运行状态判断卡顿原因。如果异常帧在CPU上的运行状态中sleep状态耗时最长，则表示该异常帧是依赖的其他线程卡顿导致的卡顿。如果异常帧在CPU上的运行状态中running状态耗时最长或者runnable状态耗时最长或者uninterrupt sleep状态耗时最长或者磁盘读写block io状态耗时最长的情况下，表示异常帧是由于自身卡顿导致的卡顿。

作为一可选的实施例，上述在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿的步骤之后，所述方法还包括：

沿着依赖链遍历其他线程，获取所述其他线程中的目标帧在所述中央处理器的运行状态；其中，所述依赖链是根据线程之间的依赖关系组成的线程依赖链；所述目标帧为所述其他线程中处于第二时间区间内的帧，所述第二时间区间为所述异常帧在所述第一线程中所处的时间区间；

若第二线程上的目标帧在所述中央处理器的运行状态为所述第二状态，则确定所述异常帧的卡顿原因为所述第二线程卡顿；其中，所述第二线程为所述其他线程中的至少一个线程。

具体的，如果异常帧是依赖的其他线程卡顿导致的卡顿，就需要沿着依赖链遍历其他线程，获取其他线程中的目标帧在CPU的运行状态。依赖链向前遍历搜索，直到唤醒wakeUP的线程ID为0为止，或者遍历到预置关注依赖链末端为止。如果在遍历过程中，其他线程中的第二线程的目标帧在CPU的运行状态为第二状态，则可以确定异常帧的卡顿时由于第二线程卡顿导致的。因为整份trace依赖链特别多，涉及的线程也特别多，为了解析效率，遍历预置关注依赖链，或者只遍历项目中经常出问题的线程就可以发现最终卡顿点，可以大大提高遍历效率。其中，所述目标帧为其他线程中处于第二时间区间内的帧，所述第二时间区间为所述异常帧在所述第一线程中所处的时间区间。

需要说明的是，依赖链也是线索链，每个应用编译好之后，调用关系就是固定的，任务在某个线程名上运行就是相对固定的。如果基于任务来寻找卡顿原因，每个应用的逻辑很难统一掌控，并且如果以模拟人工看trace的思路(基于线程唤醒关系找卡顿点)来自动找卡顿点，可能会出现依赖链上没有卡顿点的情况，是前面几帧处理超时了，导致后面帧堆积导致的卡顿情况。因此，依赖链是基于线程关系检索的，应用场景运行的线程是固定的，只要某个线程上出现卡顿点就记录下来，然后根据固定的线程依赖关系，依赖靠前的先出现卡顿，就是根本卡顿原因。例如：依赖链是线程3依赖线程2，线程2依赖线程1，如果线程1是异常帧所在的第一线程，在分析卡顿原因时，如果是其他线程导致的卡顿，则分析是否为线程2导致的卡顿，如果确定是线程2导致的卡顿，则确定卡顿原因为线程2卡顿。另外，还可以在分析完线程2之后，再分析线程3是否卡顿，如果线程3也发生卡顿，则认为是线程2和线程3导致的卡顿，线程2是主要卡顿原因。

如图4所示，下面通过一具体流程对上述步骤进行说明：

步骤401：根据trace文件(即待分析的第一trace文件)tag名或者包名获取基础信息。具体的，根据第一trace文件tag名或者包名，在第一trace文件中获取第一线程的基础信息；

步骤402：解析对应场景的第一时间区间的所有帧。具体的，根据第一trace文件的标签tag名或者包名，获取与标签tag名或者包名对应场景的第一时间区间，并通过SceneManeger模块自动选择对应的解析器解析第一时间区间的所有帧，得到每一帧的运行时间和运行状态。

步骤403：确定异常帧，并解析异常帧在CPU上运行状态。具体的，通过每一帧的运行时间和运行状态确定异常帧，并解析异常帧在CPU上的运行状态。

步骤404：判断是否是当前线程卡顿。具体的，通过异常帧在CPU上的运行状态，判断是否因为当前线程卡顿导致异常帧卡顿；如果是，进入步骤407；如果否，进入步骤405。

步骤405：解析其他线程上的运行状态。具体的，如果异常帧在CPU上的运行状态为sleep状态耗时最长的状态，则表示该异常帧是依赖的其他线程卡顿导致的卡顿，沿着依赖链遍历其他线程在异常帧所处的第二时间区间的CPU的运行状态。

步骤406：判断依赖链是否结束。在沿着依赖链遍历的过程中，判断当前遍历的其他线程是否为依赖链的最后一个线程，如果是，则结束流程；如果否，则进入步骤404继续判断是否为当前线程卡顿导致异常帧卡顿。

步骤407：根据CPU运行状态确定具体卡顿原因。在确定具体卡顿原因之后，结束流程。

作为一可选的实施例，上述在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿步骤之后，所述方法还包括：

在所述第二状态为所述运行中running状态耗时最长的状态的情况下，根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因。

具体的，如果卡顿原因是由于第一线程卡顿、且异常帧在CPU上的运行状态中running状态耗时最长，需要通过埋点数据生成的表格中的技术参数，确定第一线程的卡顿原因，确定是否因为自身原因运行久导致的卡顿。例如：桌面进程在CPU7上处于running状态最长，然后可以在结合log中解析在加载哪些组件，桌面模块相关人员可以很方便得知这些组件是否可以做预加载等策略。

如果卡顿原因是由于第一线程卡顿、且异常帧在CPU上的运行状态中runnable状态耗时最长，则需要确定是否是优先级调度问题，通过获取该任务的优先级，判断是否符合预期优先级，如果符合预期优先级，则确定卡顿原因是由于同一优先级的任务较多导致。如果不符合预期优先级，则确定卡顿原因是任务没有得到调度。例如：桌面主线程的一帧运行状态是sleep状态耗时最长，说明此处是依赖其他线程导致的卡顿。根据依赖链可知：桌面主线程依赖线程2，线程2依赖线程3，现成3依赖线程4。如果线程4的运行状态是runnable状态，说明没有得到CPU调度，因此此例问题就属于调度问题，需要调整renderthread的优先级。

如果卡顿原因是由于第一线程卡顿、且异常帧在CPU上的运行状态中uninterruptsleep状态耗时最长，则确定卡顿原因是由于第一线程和其他线程互相争抢锁，第一线程在等锁。例如：桌面主线程长时间没有绘制帧，且运行状态是sleep状态，因此是依赖其他线程导致的卡顿。根据依赖链，主线程依赖线程2，线程2运行状态是uninterrupt sleep状态，说明该线程和其他线程抢锁所致，因此需要模块确认具体为什么抢锁。

如果卡顿原因是由于第一线程卡顿、且异常帧在CPU上的运行状态中block io状态耗时最长，则表示部分内存被回收了，软件正在读磁盘的依赖资源到内存中，需要进一步获取block io的原因(如：A函数卡顿)。例如：桌面主线程处于sleep状态，说明在依赖其他线程任务运行。根据依赖线索链所知：桌面主线程依赖线程2，线程2依赖线程3，如果线程3CPU运行状态是block io，说明最终卡顿原因是线程3的block io，进一步分析是由于什么函数导致卡顿。作为一可选的实施例，上述根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因的步骤，具体可以包括：

在判定所述埋点数据中的技术参数正常的情况下，将所述述埋点数据中的异常时间数据进行拼接，得到第一时间戳；

根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件；

根据所述目标文件，确定所述第一线程的卡顿原因。

具体的，获取表格中的技术参数，例如：游戏类埋点数据表格中的技术参数可以包括：网络延迟统计、温度统计、帧率分布、最低电量、是否充电，使用wifi或者流量上网、CPU能力值等，并判断技术参数是否异常，如果技术参数均正常，则将表格中的异常时间数据进行拼接，得到拼接后的第一时间戳，例如：异常时间数据为2023年02月20日22:32:15，拼接后的第一时间戳为：2023_0220_223215。通过trace日志链接得到的解压文件中包含有多个日志文件，通过解压文件以及第一时间戳，可以找到对应的目标文件，并遍历目标文件里面的内容，再根据第一进程的基本信息，可以遍历该第一进程在第三时间区间加载了哪些资源，也可以遍历属性文件中的数据是否项目差异配置异常等，由此确定第一线程的卡顿原因。

其中，第三时间区间为：包含第二时间区间在内、且大于第二时间区间的时间区间。例如：取出第二时间区间前10s至后5s所有mainlog日志、属性值日志、内核kernal日志等，从日志信息中可以找到程序某个环节在CPU上运行时间长的原因，例如：启动在加载哪些资源、绘制在加载哪些视图view对象等。

如果技术参数异常，则表示卡顿原因是由于系统策略限制，进一步的需要根据技术参数配置指标确定卡顿的具体原因。例如：最低电量指标为5％，表格中的最低电量为4％，由于4％小于5％，则受到了最低电量的策略限制，卡顿原因是由于受到最低电量限制导致的。

其中，第一时间戳用于获取目标文件，应用包名用于锁定发生问题的应用，找到第一进程ID，以便解析对应的第一trace文件。

下面通过游戏表格数据进行举例分析：

如图3所示，表格的每一行代表用户一局游戏的所有游戏状态(此处省略了部分数据)，如果上报了一条，说明在此局游戏中出现过卡顿，可以通过这个excel表格大致分析用户遇到卡顿的原因。例如：画质、CPU能力、进程是否被杀、最高温度、平均温度等。这些埋点数据可以初步判断是否因为策略限制导致卡顿，比如：温度高可能温升限频、超低电量可能关核等。

第一trace文件中渲染线程两帧没有绘制，是因为running时间久，需要从log中遍历日志文件。通过日志文件可以具体分析卡顿原因。

作为一可选的实施例，上述根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件的步骤，具体可以包括：

根据所述追踪trace日志链接，获取日志文件，并判断所述日志文件是否为依赖时间戳的日志文件；

在所述日志文件为不依赖时间戳的日志文件的情况下，确定所述日志文件为所述目标文件。

在所述日志文件为依赖时间戳的日志文件的情况下，根据所述第一时间戳和所述日志文件中的每一个子文件包含的第二时间戳，确定所述日志文件中的目标文件；其中，所述目标文件是所述日志文件中的其中一个子文件，且所述子文件包含的第二时间戳在所述第一时间戳之前、且所述子文件包含的第二时间戳最接近所述第一时间戳。

具体的，根据trace日志链接下载trace日志压缩包，解压得到解压文件，从解压文件中获取日志文件，并判断该日志文件是否为依赖时间戳的日志文件。如果该日志文件是不依赖时间戳的日志文件，则将该日志文件作为目标文件。

如果该日志文件是依赖时间戳的日志文件，则获取该日志文件中每一个子文件，每一个子文件的文件名中包括第二时间戳，通过第一时间戳和第二时间戳，能够从多个子文件中确定出目标文件，该目标文件是第二时间戳在第一时间戳之前的多个子文件中，最接近第一时间戳的子文件。例如：第一时间戳为2023_0309_140739，各类日志文件中的子文件名类似main_log_1333__2023_0309_140508格式，即第二时间戳为2023_0309_140508。如果日志文件中有2023_0309_140508、2023_0309_140658、2023_0309_140730的子文件，则2023_0309_140730的子文件为目标文件。

需要说明的是，Main log、kernal log等一段时间保存一份文件的就是依赖时间戳的文件；属性文件、ps文件(即进程信息文件)、事件日志eventlog文件等一个日志压缩包只保存一份的日志文件是不依赖时间戳的文件。

综上所述，首先自动抓取试用用户对应场景的埋点数据，并进一步获取trace日志压缩包，通过解压、格式转换得到第一trace文件；然后自动分析第一trace文件卡顿最终依赖到哪个线程或者tag上，然后解析出日志文件的各类技术参数，通过各类技术参数指标和日志文件，锁定卡顿原因，整个流程自动化分析卡顿原因，降低了人力分析的错误率，不仅提高了卡顿原因分析的准确度和概率，还提高了卡顿分析效率。

本申请实施例提供的卡顿原因的确定方法，执行主体可以为卡顿原因的确定装置。本申请实施例中以卡顿原因的确定装置执行卡顿原因的确定方法为例，说明本申请实施例提供的卡顿原因的确定装置。

如图5所示，本申请实施例还提供了一种卡顿原因的确定装置500，包括：

第一获取模块501，用于获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；

第二获取模块502，用于根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；

第一确定模块503，用于根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；

第二确定模块504，用于根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

在本申请上述实施例中，通过获取埋点数据，该埋点数据用于表征电子设备发生卡顿时采集的卡顿数据，并根据埋点数据中的trace日志链接，获取与追踪trace日志链接对应的第一trace文件，根据第一trace文件，确定与第一trace文件对应的第一线程上的异常帧，并根据异常帧在中央处理器上的运行状态，确定异常帧的卡顿原因。即在需要分析卡顿原因时，自动获取埋点数据，并自动根据埋点数据中的trace日志链接下载第一trace文件，在批量处理卡顿异常确定卡顿原因时，能够准确定位到对应的trace文件数据，并通过分析trace文件数据精准确定卡顿的异常帧，实现自动分析trace文件确定卡顿点；再根据异常帧在中央处理器上的不同运行状态确定异常帧的具体卡顿原因，整个流程自动化分析卡顿原因，提高了卡顿原因分析效率。

可选的，所述第二获取模块502，具体用于：

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的trace日志压缩包；

对所述trace日志压缩包进行解压，得到解压文件；

将所述解压文件中的第二trace文件进行格式转换，得到所述第一trace文件。

可选的，所述第一确定模块503，具体用于：

根据所述第一trace文件的标签tag名或者包名，获取与所述标签tag名或者包名对应场景的第一时间区间；

解析所述第一时间区间内的所有帧，确定所述第一时间区间内的异常帧，所述异常帧为所述第一时间区间内的所有帧中耗时最长的帧。

可选的，所述第二确定模块504，具体用于：

在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿；

在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿；

其中，所述第一状态为休眠sleep状态耗时最长的状态；所述第二状态为运行中running状态耗时最长的状态、可运行runnable状态耗时最长的状态、不可中断睡眠uninterrupt sleep状态耗时最长的状态和磁盘读写block io状态耗时最长的状态中的至少一者。

可选的，所述第二确定模块504在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿之后，所述第二确定模块还用于：

沿着依赖链遍历所述其他线程，获取所述其他线程中的目标帧在所述中央处理器的运行状态，其中，所述依赖链是根据线程之间的依赖关系组成的线程依赖链；所述目标帧为所述其他线程中处于第二时间区间内的帧，所述第二时间区间为所述异常帧在所述第一线程中所处的时间区间；

若第二线程上的目标帧在所述中央处理器的运行状态为所述第二状态，则确定所述异常帧的卡顿原因为所述第二线程卡顿；其中，所述第二线程为所述其他线程中的至少一个线程。

可选的，所述第二确定模块504在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿之后，所述第二确定模块504还用于：

在所述第二状态为所述运行中running状态耗时最长的状态的情况下，根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因。

可选的，所述第二确定模块504在根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因时，具体用于：

在判定所述埋点数据中的技术参数正常的情况下，将所述述埋点数据中的异常时间数据进行拼接，得到第一时间戳；

根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件；

根据所述目标文件，确定所述第一线程的卡顿原因。

可选的，所述第二确定模块504在根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件时，具体用于：

根据所述追踪trace日志链接，获取日志文件，并判断所述日志文件是否为依赖时间戳的日志文件；

在所述日志文件为不依赖时间戳的日志文件的情况下，确定所述日志文件为所述目标文件。

在所述日志文件为依赖时间戳的日志文件的情况下，根据所述第一时间戳和所述日志文件中的每一个子文件包含的第二时间戳，确定所述日志文件中的目标文件；其中，所述目标文件是所述日志文件中的其中一个子文件，且所述子文件包含的第二时间戳在所述第一时间戳之前、且所述子文件包含的第二时间戳最接近所述第一时间戳。

综上所述，首先自动抓取试用用户对应场景的埋点数据，并进一步获取trace日志压缩包，通过解压、格式转换得到第一trace文件；然后自动分析第一trace文件卡顿最终依赖到哪个线程或者tag上，然后解析出日志文件的各类技术参数，通过各类技术参数指标和日志文件，锁定卡顿原因，整个流程自动化分析卡顿原因，降低了人力分析的错误率，不仅提高了卡顿原因分析的准确度和概率，还提高了卡顿分析效率。

本申请实施例中的卡顿原因的确定装置可以是电子设备，也可以是电子设备中的部件，例如集成电路或芯片。该电子设备可以是终端，也可以为除终端之外的其他设备。示例性的，电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、移动上网装置(Mobile Internet Device，MID)、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、机器人、可穿戴设备、超级移动个人计算机(ultra-mobilepersonal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，还可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的卡顿原因的确定装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的卡顿原因的确定装置能够实现图1至图4的方法实施例实现的各个过程，为避免重复，这里不再赘述。

可选地，如图6所示，本申请实施例还提供一种电子设备600，包括处理器601和存储器602，存储器602上存储有可在所述处理器601上运行的程序或指令，该程序或指令被处理器601执行时实现上述卡顿原因的确定方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

图7为实现本申请实施例的一种电子设备的硬件结构示意图。

该电子设备1000包括但不限于：射频单元1001、网络模块1002、音频输出单元1003、输入单元1004、传感器1005、显示单元1006、用户输入单元1007、接口单元1008、存储器1009、以及处理器1010等部件。

本领域技术人员可以理解，电子设备1000还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器1010逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图7中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

其中，所述处理器1010，用于获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；

根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；

根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

在本申请上述实施例中，通过获取埋点数据，该埋点数据用于表征电子设备发生卡顿时采集的卡顿数据，并根据埋点数据中的trace日志链接，获取与追踪trace日志链接对应的第一trace文件，根据第一trace文件，确定与第一trace文件对应的第一线程上的异常帧，并根据异常帧在中央处理器上的运行状态，确定异常帧的卡顿原因。即在需要分析卡顿原因时，自动获取埋点数据，并自动根据埋点数据中的trace日志链接下载第一trace文件，在批量处理卡顿异常确定卡顿原因时，能够准确定位到对应的trace文件数据，并通过分析trace文件数据精准确定卡顿的异常帧，实现自动分析trace文件确定卡顿点；再根据异常帧在中央处理器上的不同运行状态确定异常帧的具体卡顿原因，整个流程自动化分析卡顿原因，提高了卡顿原因分析效率。

可选的，所述处理器1010在根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件时，具体用于：

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的trace日志压缩包；

对所述trace日志压缩包进行解压，得到解压文件；

将所述解压文件中的第二trace文件进行格式转换，得到所述第一trace文件。

可选的，所述处理器1010在根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧时，具体用于：

根据所述第一trace文件的标签tag名或者包名，获取与所述标签tag名或者包名对应场景的第一时间区间；

解析所述第一时间区间内的所有帧，确定所述第一时间区间内的异常帧，所述异常帧为所述第一时间区间内的所有帧中耗时最长的帧。

可选的，所述处理器1010在根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因时，具体用于：

在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿；

在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿；

其中，所述第一状态为休眠sleep状态耗时最长的状态；所述第二状态为运行中running状态耗时最长的状态、可运行runnable状态耗时最长的状态、不可中断睡眠uninterrupt sleep状态耗时最长的状态和磁盘读写block io状态耗时最长的状态中的至少一者。

可选的，所述处理器1010在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿之后，还用于：

沿着依赖链遍历所述其他线程，获取所述其他线程中的目标帧在所述中央处理器的运行状态；其中，所述依赖链是根据线程之间的依赖关系组成的线程依赖链；所述目标帧为所述其他线程中处于第二时间区间内的帧，所述第二时间区间为所述异常帧在所述第一线程中所处的时间区间；

若第二线程上的目标帧在所述中央处理器的运行状态为所述第二状态，则确定所述异常帧的卡顿原因为所述第二线程卡顿；其中，所述第二线程为所述其他线程中的至少一个线程。

可选的，所述处理器1010在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿之后，还用于：

在所述第二状态为所述运行中running状态耗时最长的状态的情况下，根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因。

可选的，所述处理器1010在根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因时，具体用于：

在判定所述埋点数据中的技术参数正常的情况下，将所述述埋点数据中的异常时间数据进行拼接，得到第一时间戳；

根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件；

根据所述目标文件，确定所述第一线程的卡顿原因。

可选的，所述处理器1010在根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件时，具体用于：

根据所述追踪trace日志链接，获取日志文件，并判断所述日志文件是否为依赖时间戳的日志文件；

在所述日志文件为不依赖时间戳的日志文件的情况下，确定所述日志文件为所述目标文件。

在所述日志文件为依赖时间戳的日志文件的情况下，根据所述第一时间戳和所述日志文件中的每一个子文件包含的第二时间戳，确定所述日志文件中的目标文件；其中，所述目标文件是所述日志文件中的其中一个子文件，且所述子文件包含的第二时间戳在所述第一时间戳之前、且所述子文件包含的第二时间戳最接近所述第一时间戳。

综上所述，首先自动抓取试用用户对应场景的埋点数据，并进一步获取trace日志压缩包，通过解压、格式转换得到第一trace文件；然后自动分析第一trace文件卡顿最终依赖到哪个线程或者tag上，然后解析出日志文件的各类技术参数，通过各类技术参数指标和日志文件，锁定卡顿原因，整个流程自动化分析卡顿原因，降低了人力分析的错误率，不仅提高了卡顿原因分析的准确度和概率，还提高了卡顿分析效率。

应理解的是，本申请实施例中，输入单元1004可以包括图形处理器(GraphicsProcessing Unit，GPU)10041和麦克风10042，图形处理器10041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元1006可包括显示面板10061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板10061。用户输入单元1007包括触控面板10071以及其他输入设备10072中的至少一种。触控面板10071，也称为触摸屏。触控面板10071可包括触摸检测装置和触摸控制器两个部分。其他输入设备10072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

存储器1009可用于存储软件程序以及各种数据。存储器1009可主要包括存储程序或指令的第一存储区和存储数据的第二存储区，其中，第一存储区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器1009可以包括易失性存储器或非易失性存储器，或者，存储器1009可以包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请实施例中的存储器1009包括但不限于这些和任意其它适合类型的存储器。

处理器1010可包括一个或多个处理单元；可选的，处理器1010集成应用处理器和调制解调处理器，其中，应用处理器主要处理涉及操作系统、用户界面和应用程序等的操作，调制解调处理器主要处理无线通信信号，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器1010中。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述卡顿原因的确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器ROM、随机存取存储器RAM、磁碟或者光盘等。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述卡顿原因的确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如上述卡顿原因的确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种卡顿原因的确定方法，其特征在于，包括：

获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；

根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；

根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

2.根据权利要求1所述的方法，其特征在于，所述根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件，包括：

根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的trace日志压缩包；

对所述trace日志压缩包进行解压，得到解压文件；

将所述解压文件中的第二trace文件进行格式转换，得到所述第一trace文件。

3.根据权利要求1所述的方法，其特征在于，所述根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧，包括：

根据所述第一trace文件的标签tag名或者包名，获取与所述标签tag名或者包名对应场景的第一时间区间；

解析所述第一时间区间内的所有帧，确定所述第一时间区间内的异常帧，所述异常帧为所述第一时间区间内的所有帧中耗时最长的帧。

4.根据权利要求1所述的方法，其特征在于，所述根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因，包括：

在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿；

在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿；

其中，所述第一状态为休眠sleep状态耗时最长的状态；所述第二状态为运行中running状态耗时最长的状态、可运行runnable状态耗时最长的状态、不可中断睡眠uninterrupt sleep状态耗时最长的状态和磁盘读写block io状态耗时最长的状态中的至少一者。

5.根据权利要求4所述的方法，其特征在于，所述在所述异常帧在所述中央处理器上的运行状态为第一状态的情况下，确定所述异常帧的卡顿原因为所述第一线程所依赖的其他线程卡顿之后，所述方法还包括：

沿着依赖链遍历其他线程，获取所述其他线程中的目标帧在所述中央处理器的运行状态；其中，所述依赖链是根据线程之间的依赖关系组成的线程依赖链；所述目标帧为所述其他线程中处于第二时间区间内的帧，所述第二时间区间为所述异常帧在所述第一线程中所处的时间区间；

若第二线程上的目标帧在所述中央处理器的运行状态为所述第二状态，则确定所述异常帧的卡顿原因为所述第二线程卡顿；其中，所述第二线程为所述其他线程中的至少一个线程。

6.根据权利要求4所述的方法，其特征在于，所述在所述异常帧在所述中央处理器上的运行状态为第二状态的情况下，确定所述异常帧的卡顿原因为所述第一线程卡顿之后，所述方法还包括：

在所述第二状态为所述运行中running状态耗时最长的状态的情况下，根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因。

7.根据权利要求6所述的方法，其特征在于，所述根据所述埋点数据中的技术参数，确定所述第一线程的卡顿原因，包括：

在判定所述埋点数据中的技术参数正常的情况下，将所述述埋点数据中的异常时间数据进行拼接，得到第一时间戳；

根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件；

根据所述目标文件，确定所述第一线程的卡顿原因。

8.根据权利要求7所述的方法，其特征在于，所述根据所述追踪trace日志链接以及所述第一时间戳，获取目标文件，包括：

根据所述追踪trace日志链接，获取日志文件，并判断所述日志文件是否为依赖时间戳的日志文件；

在所述日志文件为不依赖时间戳的日志文件的情况下，确定所述日志文件为所述目标文件；

在所述日志文件为依赖时间戳的日志文件的情况下，根据所述第一时间戳和所述日志文件中的每一个子文件包含的第二时间戳，确定所述日志文件中的目标文件；其中，所述目标文件是所述日志文件中的其中一个子文件，且所述子文件包含的第二时间戳在所述第一时间戳之前、且所述子文件包含的第二时间戳最接近所述第一时间戳。

9.一种卡顿原因的确定装置，其特征在于，包括：

第一获取模块，用于获取埋点数据，所述埋点数据用于表征电子设备发生卡顿时采集的卡顿数据；

第二获取模块，用于根据所述埋点数据中的追踪trace日志链接，获取与所述追踪trace日志链接对应的第一trace文件；

第一确定模块，用于根据所述第一trace文件，确定与所述第一trace文件对应的第一线程上的异常帧；

第二确定模块，用于根据所述异常帧在中央处理器上的运行状态，确定所述异常帧的卡顿原因。

10.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1-8任一项所述的卡顿原因的确定方法的步骤。