CN108776624A - 确定终端卡顿原因的方法、装置及存储介质 - Google Patents

Abstract

本公开是关于一种确定终端卡顿原因的方法、装置及存储介质，其中，确定终端卡顿原因的方法包括：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据历史线程的记录确定导致终端出现卡顿的原因，本公开通过预先保存预设时间段内的终端的历史线程的记录，在终端出现卡顿时，利用历史线程的记录能够确定出导致终端卡顿的原因，无需在终端出现卡顿之后再去提取并分析终端操作系统的内核信息，提高了确定终端卡顿原因的效率。

Description

确定终端卡顿原因的方法、装置及存储介质

技术领域

本公开涉及计算机应用技术领域，尤其涉及确定终端卡顿原因的方法、装置及存储介质。

背景技术

目前，移动终端的性能在不断提高，但在移动终端的使用过程中，还会出现卡顿的问题，为解决这个问题，需高效获知导致终端卡顿的原因。

发明内容

为克服相关技术中存在的问题，本公开提供一种确定终端卡顿原因的方法、装置及存储介质。

根据本公开的第一个方面，提供了一种确定终端卡顿原因的方法，包括：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

根据本公开的第二个方面，提供了一种确定终端卡顿原因的装置，包括：获取模块，用于在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；确定模块，用于根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

根据本公开的第三个方面，提供了一种确定终端卡顿原因的装置，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

根据本公开的第四个方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由处理器执行时，使得处理器能够执行根据本公开第一个方面所述的确定终端卡顿原因的方法。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开的实施例提供的确定终端卡顿原因的方法，通过预先保存预设时间段内的终端的历史线程的记录，在终端出现卡顿时，利用历史线程的记录能够确定出导致终端卡顿的原因，无需在终端出现卡顿之后再去提取并分析终端操作系统的内核信息，提高了确定终端卡顿原因的效率。

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

附图说明

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

图1是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图。

图2是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图。

图3是保存分配内存耗时超过第一时长的第一线程的记录的示意图。

图4是保存调度耗时超过第二时长的第二线程的记录的示意图。

图5是保存导致CPU降频和/或锁核的第三线程的记录的示意图。

图6是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图。

图7是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图。

图8是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图。

图9是根据一示例性实施例示出的终端卡顿的原因的示意图。

图10是根据一示例性实施例示出的确定终端卡顿原因的装置的框图。

图11是根据一示例性实施例示出的确定终端卡顿原因的装置的框图。

图12是根据一示例性实施例示出的确定终端卡顿原因的装置的框图。

图13是根据一示例性实施例示出的确定终端卡顿原因的装置的框图。

具体实施方式

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

图1是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图，如图1所示，该方法包括：

步骤101：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；

在步骤101中，可根据终端当前的丢帧率来确定终端是否出现卡顿。

步骤102：根据历史线程的记录确定导致终端出现卡顿的原因。

本实施例提供的确定终端卡顿原因的方法，通过预先保存预设时间段内的终端的历史线程的记录，在终端出现卡顿时，利用历史线程的记录能够确定出导致终端卡顿的原因，无需在终端出现卡顿之后再去提取并分析终端操作系统的内核信息，提高了确定终端卡顿原因的效率。

图2是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图，如图2所示，该方法在图1所示的方法的基础上，还可包括步骤201：保存终端运行过程中产生的以下至少一种线程的记录：

分配内存耗时超过第一时长的第一线程，其中，该第一线程可包括App对内存的占用，例如，swap，kernel slab以及native对内存的占用；调度耗时超过第二时长的第二线程，该第二进程例如可包括，后台死循环以及后台编辑的线程，通过统计，该类线程所导致的终端卡顿的现象大概占终端所有卡顿现象的1％；导致CPU降频和/或锁核的第三线程；以及占用binder线程的资源超过第三时长的第四线程。由于在终端运行过程中被记录的这些线程在一定概率上可能为异常线程，这些线程与终端卡顿的原因存在较大的关联性，故在终端出现卡顿时，可直接利用这些历史线程的记录来确定终端卡顿的原因，无需在终端出现卡顿后再提取并分析终端操作系统的内核信息，降低了确定卡顿原因操作的复杂度。其中，第一时长、第二时长、第三时长可根据需要设置，本公开对此不作限制。

需要说明的是，步骤201可在终端运行过程中实时执行，或周期性执行，图2中仅示出了该步骤在步骤101以及102之前执行的一种情况。

图3是保存分配内存耗时超过第一时长的第一线程的记录的示意图，在图3中，第一时长以100us为例，第一线程以slow path为例，可以通过设置参数record_threshold_us来筛选并记录分配内存耗时超过第一时长的线程。

图4是保存调度耗时超过第二时长的第二线程的记录的示意图，在图4中，第二时长以2ms为例，第二线程可包括可运行状态的线程以及不间断睡眠状态的线程，其中，不间断睡眠状态的线程例如I/O(输入/输出)线程，或lock contention(锁争用)线程，可通过echo pid2，pid2...>pids，来设置需记录的线程，通过参数filter_block/filter_preempt/filter_wait来筛选超过第二时长的记录。

图5是保存导致CPU降频和/或锁核的第三线程的记录的示意图，在图5中，该记录中还包括了导致CPU降频运行的负载的ID，如图5中倒数第三列所示的5、4…6。

图6是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图，如图6所示，在该方法中，上述步骤101可由步骤601来实现，在步骤601中，获取预先保存的预设时间段内的历史线程的记录包括：获取由Ktrace预先保存的终端在预设时间段内运行所产生历史线程的记录。例如，Ktrace可包括mem Ktrace模块，该模块用于存储终端运行过程中产生的分配内存耗时超过第一时长的第一线程的记录，cpu sched Ktrace模块，该模块用于存储终端运行过程中产生的调度耗时超过第二时长的第二线程的记录，cpu freq Ktrace模块，该模块用于存储终端运行过程中产生的导致CPU降频和/或锁核的第三线程，binderKtrace模块，该模块用于存储终端运行过程中产生的占用binder线程的资源超过第三时长的第四线程，借助Ktrace对内核层面的状态跟踪机制，预先保存终端运行过程中产生的历史线程的记录，在终端发生卡顿时，可直接获取预先保存的历史线程的记录，无需再提前打开trace，避免了由于打开trace导致printk log被冲掉的问题。

图7是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图，如图7所示，在该方法中，上述步骤102中根据历史线程的记录确定导致终端出现卡顿的原因可由以下至少一个步骤来实现：

步骤701：在根据预设时间段内的历史线程的记录中的第一线程，确定存在内存回收频率大于预设频率的历史线程时，确定导致终端出现卡顿的原因包括线程内存回收频繁或终端内存不足；步骤702：在根据预设时间段内的历史线程的记录中的第二线程，确定存在抢占CPU时间的时长超过第四时长的历史线程时，确定导致终端出现卡顿的原因包括线程抢占CPU的时间过长；步骤703：在根据预设时间段内的历史线程的记录中的第三线程，确定存在导致CPU降频和/或锁核运行次数超过第一预设次数的负载时，确定导致终端出现卡顿的原因包括线程中的CPU负载导致降频和/或锁核；步骤704：在根据据预设时间段内的历史线程的记录中的第四线程，确定存在占用binder线程的资源的时长超过第五时长历史线程时，确定导致终端出现卡顿的原因包括线程占用binder线程的资源的时间过长。其中，预设频率、第四时长、第五时长、第一预设次数可根据需要设置，本公开对此不做限制。本实施例中，可以选择执行步骤701、步骤702、步骤703以及步骤704中的至少一个步骤来执行，且步骤701、步骤702、步骤703以及步骤704之间不存在先后执行顺序，图7中仅示出了执行步骤701-704，且步骤701至704顺序执行的一种情况。

在上述步骤701中，可根据预设时间段内保存的所有第一线程的记录中记录的内存分配耗时，计算这些线程的内存回收频率，其中，内存分配耗时可包括分配内存操作的耗时以及回收内存操作的耗时，线程的内存回收频率可由线程对应的回收内存操作的总耗时除以统计时间得出，此处的统计时间可为上述预设时间段，在通过计算确定第一线程中存在内存回收频率大于预设频率的历史线程时，确定导致终端出现卡顿的原因包括线程内存回收频繁或终端内存不足。

在上述步骤702中，可根据预设时间段内保存的所有第二线程的记录中的抢占CPU时间(例如线程处于可运行状态或不间断睡眠状态的时间)，计算线程在预设时间段内抢占CPU总时长，在通过计算确定第二线程中存在抢占CPU总时长超过第四时长的历史线程时，确定导致终端出现卡顿的原因包括线程抢占CPU时间过长。

在上述步骤703中，可根据预设时间段内保存的所有第三线程的记录中导致CPU降频、导致CPU锁核，以及导致CPU降频且锁核的历史线程中的负载，计算在预设时间段内导致CPU降频和/或锁核运行次数，在通过计算确定第三线程的记录中存在导致CPU降频、锁核以及降频且锁核运行次数超过第一预设次数的负载时，确定导致终端出现卡顿的原因包括线程中的CPU负载导致降频和/或锁核。

在上述步骤704中，可根据预设时间段内保存的所有第四线程的记录中占用binder线程的资源的时长，计算各历史线程占用binder线程的资源总时长，在通过计算确定第四线程中包括占用binder线程的资源总时长超过第五时长的历史线程时，确定导致终端出现卡顿的原因包括线程占用binder线程的资源的时间过长。

通过步骤701至704，可确定出导致终端卡顿的系统层面的原因以及导致终端卡顿的历史进程，从而为解决终端卡顿问题提供了参考。

图8是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图，如图8所示，该方法在图1所示的方法的基础上还可包括步骤801：在根据历史线程的记录确定导致终端出现卡顿的原因之后，显示导致终端出现卡顿的原因和/或原因对应的历史线程的记录。或者本实施例的方法还可以在图6或图7所示的方法的基础上包括步骤801。在显示导致终端卡顿的原因或历史线程后，使得导致终端卡顿的原因及历史线程能够直观的被呈现，便于用户/开发者基于这些信息采取相应措施以解决或缓解终端的卡顿。

图9是根据一示例性实施例示出的终端卡顿的原因的示意图，导致终端卡顿的原因可基于上述确定终端卡顿的方法确定出，在该图9中，频繁的内存回收为上述内存回收率大于预设频率的示例情况，该原因可基于上述第一线程的记录确定得出，在根据第一线程的记录确定出终端的内存回收频繁后，可以查看第一线程的记录中占用内存较多的线程以及Kernel的unreclaim slab，以进一步找出导致终端卡顿的主要线程；频繁的I/O或lockcontention为线程抢占CPU时间过长的示例情况，该原因可基于上述第二线程的记录确定得出；CPU限频和/或锁核运行，可包括在有限频和/或锁核的情况下线程处于运行状态或可运行状态的时间过长，该原因可基于上述第三线程的记录确定得出，在确定出该原因后，可以确定出导致CPU发热，引起降频和/或锁核的线程，例如，可确定导致CPU降频和/或锁核运行次数超过第一预设次数的历史线程为导致CPU发热的线程；CPU饥饿为线程抢占CPU时间过长的另一个示例，可包括无限频以及锁核现象的同时线程处于可运行状态的时间过长，该原因可基于上述第二线程的记录确定得出，在确定CPU饥饿时，可以确定出大量抢占CPU时间的进程，例如抢占CPU时间的时长超过第四时长的历史线程；binder的主线程处于睡眠的时间过长以及biner的渲染线程Render Thread binder处于睡眠状态的时间过长为binder线程的资源被占用时间过长的示例情况，binder的主线程处于睡眠的时间过长的原因可包括binder call资源被抢占，如service频繁启动的情况以及biner的渲染线程Render Thread binder处于睡眠状态的时间过长，该原因可由上述第四线程的记录确定得出，在确定出binder call线程的资源被抢占后，可确定出频繁占用binder call线程的资源的线程，例如占用binder线程的资源的时长超过第五时长的历史线程。

图10是根据一示例性实施例示出的一种确定终端卡顿原因的装置的框图，如图10所示，该装置100包括：

获取模块101，用于在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；

确定模块102，用于根据历史线程的记录确定导致终端出现卡顿的原因。

图11是根据一示例性实施例示出的确定终端卡顿的装置的框图，如图11所示，该装置110在装置100的基础上，还可包括：保存模块111，该模块用于保存终端运行过程中产生的以下至少一种线程的记录：分配内存耗时超过第一时长的第一线程，调度耗时超过第二时长的第二线程，导致中央处理器CPU降频和/或锁核的第三线程，以及占用binder线程的资源超过第三时长的第四线程。

在一种可实现方式中，获取模块可用于：获取由Ktrace预先保存的终端在预设时间段内运行所产生历史线程的记录。

在一种可实现方式中，确定模块可用于通过以下至少一种方式确定导致终端出现卡顿的原因：在根据历史线程的记录中的第一线程，确定存在内存回收频率大于预设频率的历史线程时，确定导致终端出现卡顿的原因包括线程内存回收频繁或终端内存不足；在根据历史线程的记录中的第二线程，确定存在抢占中央处理器CPU时间的时长超过第四时长的历史线程时，确定导致终端出现卡顿的原因包括线程抢占CPU的时间过长；在根据历史线程的记录中的第三线程，确定存在导致CPU降频和/或锁核运行次数超过第一预设次数的负载时，确定导致终端出现卡顿的原因包括线程中的CPU负载导致降频和/或锁核；在根据历史线程的记录中的第四线程，确定存在占用binder线程的资源的时长超过第五时长历史线程时，确定导致终端出现卡顿的原因包括线程占用binder线程的资源的时间过长。

图12是根据一示例性实施例示出的确定终端卡顿原因的装置的框图，如图12所示，该装置120在上述装置100的基础上还可包括：显示模块121，该模块用于在根据历史线程的记录确定导致终端出现卡顿的原因之后，显示导致终端出现卡顿的原因和/或原因对应的历史线程的记录。

图13是根据一示例性实施例示出的一种确定终端卡顿原因的装置800的框图。例如，装置800可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图8，装置800可以包括以下一个或多个组件：处理组件802，存储器804，电源组件806，多媒体组件808，音频组件810，输入/输出(I/O)的接口812，传感器组件814，以及通信组件816。

处理组件802通常控制装置800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在装置800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件806为装置800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电力相关联的组件。

多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当装置800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当装置800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。

I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到装置800的打开/关闭状态，组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1932，上述指令可由装置1900的处理组件1922执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

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

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (12)

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

在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；

根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

保存所述终端运行过程中产生的以下至少一种线程的记录：

分配内存耗时超过第一时长的第一线程，调度耗时超过第二时长的第二线程，导致中央处理器CPU降频和/或锁核的第三线程，以及占用binder线程的资源超过第三时长的第四线程。

3.根据权利要求1所述的方法，其特征在于，所述获取预先保存的预设时间段内的历史线程的记录，包括：

获取由Ktrace预先保存的所述终端在所述预设时间段内运行所产生历史线程的记录。

4.根据权利要求2所述的方法，其特征在于，所述根据所述历史线程的记录确定导致所述终端出现卡顿的原因，包括以下至少一种方式：

在根据所述历史线程的记录中的第一线程，确定存在内存回收频率大于预设频率的历史线程时，确定导致所述终端出现卡顿的原因包括线程内存回收频繁或终端内存不足；

在根据所述历史线程的记录中的第二线程，确定存在抢占CPU时间的时长超过第四时长的历史线程时，确定导致所述终端出现卡顿的原因包括线程抢占CPU的时间过长；

在根据所述历史线程的记录中的第三线程，确定存在导致CPU降频和/或锁核运行次数超过第一预设次数的负载时，确定导致所述终端出现卡顿的原因包括线程中的CPU负载导致降频和/或锁核；

在根据所述历史线程的记录中的第四线程，确定存在占用binder线程的资源的时长超过第五时长历史线程时，确定导致所述终端出现卡顿的原因包括线程占用binder线程的资源的时间过长。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：

在根据所述历史线程的记录确定导致所述终端出现卡顿的原因之后，显示导致所述终端出现卡顿的原因和/或所述原因对应的所述历史线程的记录。

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

获取模块，用于在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；

确定模块，用于根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

保存模块，用于保存所述终端运行过程中产生的以下至少一种线程的记录：

分配内存耗时超过第一时长的第一线程，调度耗时超过第二时长的第二线程，导致中央处理器CPU降频和/或锁核的第三线程，以及占用binder线程的资源超过第三时长的第四线程。

8.根据权利要求6所述的装置，其特征在于，所述获取模块用于：

获取由Ktrace预先保存的所述终端在所述预设时间段内运行所产生历史线程的记录。

9.根据权利要求7所述的装置，其特征在于，所述确定模块用于通过以下至少一种方式确定导致所述终端出现卡顿的原因：

在根据所述历史线程的记录中的第一线程，确定存在内存回收频率大于预设频率的历史线程时，确定导致所述终端出现卡顿的原因包括线程内存回收频繁或终端内存不足；

在根据所述历史线程的记录中的第二线程，确定存在抢占CPU时间的时长超过第四时长的历史线程时，确定导致所述终端出现卡顿的原因包括线程抢占CPU的时间过长；

在根据所述历史线程的记录中的第三线程，确定存在导致CPU降频和/或锁核运行次数超过第一预设次数的负载时，确定导致所述终端出现卡顿的原因包括线程中的CPU负载导致降频和/或锁核；

在根据所述历史线程的记录中的第四线程，确定存在占用binder线程的资源的时长超过第五时长历史线程时，确定导致所述终端出现卡顿的原因包括线程占用binder线程的资源的时间过长。

10.根据权利要求6至9任一项所述的装置，其特征在于，所述装置还包括：

显示模块，用于在根据所述历史线程的记录确定导致所述终端出现卡顿的原因之后，显示导致所述终端出现卡顿的原因和/或所述原因对应的所述历史线程的记录。

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

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；

根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

12.一种非临时性计算机可读存储介质，当所述存储介质中的指令由处理器执行时，使得处理器能够执行根据权利要求1至5任意一项所述的方法。