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

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

Method, device and storage medium for determining terminal Catton cause

The present disclosure is about a method, device and storage medium for determining the cause of terminal karton, in which methods for determining the cause of terminal Karton include: acquiring records of historical threads stored in a predetermined period of time when the terminal appears karton; determining the cause of terminal Karton according to the records of historical threads; By pre-storing the records of the historical threads of the terminal in the preset time period, when the terminal has a Katon, the cause of the terminal's Katon can be determined by using the records of the historical threads. It is not necessary to extract and analyze the kernel information of the terminal operating system after the terminal has a Katon, thus improving the determination of the terminal's Katon. Cause efficiency.

【技术实现步骤摘要】
确定终端卡顿原因的方法、装置及存储介质
本公开涉及计算机应用
，尤其涉及确定终端卡顿原因的方法、装置及存储介质。
技术介绍
目前，移动终端的性能在不断提高，但在移动终端的使用过程中，还会出现卡顿的问题，为解决这个问题，需高效获知导致终端卡顿的原因。
技术实现思路
为克服相关技术中存在的问题，本公开提供一种确定终端卡顿原因的方法、装置及存储介质。根据本公开的第一个方面，提供了一种确定终端卡顿原因的方法，包括：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据所述历史线程的记录确定导致所述终端出现卡顿的原因。根据本公开的第二个方面，提供了一种确定终端卡顿原因的装置，包括：获取模块，用于在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；确定模块，用于根据所述历史线程的记录确定导致所述终端出现卡顿的原因。根据本公开的第三个方面，提供了一种确定终端卡顿原因的装置，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据所述历史线程的记录确定导致所述终端出现卡顿的原因。根据本公开的第四个方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由处理器执行时，使得处理器能够执行根据本公开第一个方面所述的确定终端卡顿原因的方法。本公开的实施例提供的技术方案可以包括以下有益效果：本公开的实施例提供的确定终端卡顿原因的方法，通过预先保存预设时间段内的终端的历史线程的记录，在终端出现卡顿时，利用历史线程的记录能够确定出导致终端卡顿的原因，无需在终端出现卡顿之后再去提取并分析终端操作系统的内核信息，提高了确定终端卡顿原因的效率。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。附图说明此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。图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，kernelslab以及native对内存的占用；调度耗时超过第二时长的第二线程，该第二进程例如可包括，后台死循环以及后台编辑的线程，通过统计，该类线程所导致的终端卡顿的现象大概占终端所有卡顿现象的1％；导致CPU降频和/或锁核的第三线程；以及占用binder线程的资源超过第三时长的第四线程。由于在终端运行过程中被记录的这些线程在一定概率上可能为异常线程，这些线程与终端卡顿的原因存在较大的关联性，故在终端出现卡顿时，可直接利用这些历史线程的记录来确定终端卡顿的原因，无需在终端出现卡顿后再提取并分析终端操作系统的内核信息，降低了确定卡顿原因操作的复杂度。其中，第一时长、第二时长、第三时长可根据需要设置，本公开对此不作限制。需要说明的是，步骤201可在终端运行过程中实时执行，或周期性执行，图2中仅示出了该步骤在步骤101以及102之前执行的一种情况。图3是保存分配内存耗时超过第一时长的第一线程的记录的示意图，在图3中，第一时长以100us为例，第一线程以slowpath为例，可以通过设置参数record_threshold_us来筛选并记录分配内存耗时超过第一时长的线程。图4是保存调度耗时超过第二时长的第二线程的记录的示意图，在图4中，第二时长以2ms为例，第二线程可包括可运行状态的线程以及不间断睡眠状态的线程，其中，不间断睡眠状态的线程例如I/O(输入/输出)线程，或lockcontention(锁争用)线程，可通过echopid2，pid2...>pids，来设置需记录的线程，通过参数filter_block/filter_preempt/filter_wait来筛选超过第二时长的记录。图5是保存导致CPU降频和/或锁核的第三线程的记录的示意图，在图5中，该记录中还包括了导致CPU降频运行的负载的ID，如图5中倒数第三列所示的5、4…6。图6是根据一示例性实施例示出的一种确定终端卡顿原因的方法的流程图，如图6所示，在该方法中，上述步骤101可由步骤601来实现，在步骤601中，获取预先保存的预设时间段内的历史线程的记录包括：获取由Ktrace预先保存的终端在预设时间段内运行所产生历史线程的记录。例如，Ktrace可包括memKtrace模块，该模块用于存储终端运行过程中产生的分配内存耗时超过第一时长的第一线程的记录，cpuschedKtrace模块，该模块用于存储终端运行过程中产生的调度耗时超过第二时长的第二线程的记录，cpufreqKtrace模块，该模块用于存储终端运行过程中产生的导致CPU降频和/或锁核的第三线程，binderKtrace模块，该模块用于存储终端运行过程中产生的占用binder线程的资源超过第三时长的第四线程，借助Ktrace对内核层面的状态跟踪机制，预先保存终端运行过程中产生的历史线程的记录，在终端发生卡顿时，可直接获取预先保存的历史线程的记录，无需再提前打开本文档来自技高网...

【技术保护点】
1.一种确定终端卡顿原因的方法，其特征在于，包括：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据所述历史线程的记录确定导致所述终端出现卡顿的原因。

【技术特征摘要】
1.一种确定终端卡顿原因的方法，其特征在于，包括：在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；根据所述历史线程的记录确定导致所述终端出现卡顿的原因。2.根据权利要求1所述的方法，其特征在于，所述方法还包括：保存所述终端运行过程中产生的以下至少一种线程的记录：分配内存耗时超过第一时长的第一线程，调度耗时超过第二时长的第二线程，导致中央处理器CPU降频和/或锁核的第三线程，以及占用binder线程的资源超过第三时长的第四线程。3.根据权利要求1所述的方法，其特征在于，所述获取预先保存的预设时间段内的历史线程的记录，包括：获取由Ktrace预先保存的所述终端在所述预设时间段内运行所产生历史线程的记录。4.根据权利要求2所述的方法，其特征在于，所述根据所述历史线程的记录确定导致所述终端出现卡顿的原因，包括以下至少一种方式：在根据所述历史线程的记录中的第一线程，确定存在内存回收频率大于预设频率的历史线程时，确定导致所述终端出现卡顿的原因包括线程内存回收频繁或终端内存不足；在根据所述历史线程的记录中的第二线程，确定存在抢占CPU时间的时长超过第四时长的历史线程时，确定导致所述终端出现卡顿的原因包括线程抢占CPU的时间过长；在根据所述历史线程的记录中的第三线程，确定存在导致CPU降频和/或锁核运行次数超过第一预设次数的负载时，确定导致所述终端出现卡顿的原因包括线程中的CPU负载导致降频和/或锁核；在根据所述历史线程的记录中的第四线程，确定存在占用binder线程的资源的时长超过第五时长历史线程时，确定导致所述终端出现卡顿的原因包括线程占用binder线程的资源的时间过长。5.根据权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：在根据所述历史线程的记录确定导致所述终端出现卡顿的原因之后，显示导致所述终端出现卡顿的原因和/或所述原因对应的所述历史线程的记录。6.一种确定终端卡顿原因的装置，其特征在于，包括：获取模块，用于在终端出现卡顿时，获取预先保存的预设时间段内的历史线程的记录；确定模块，用于根据所述历史线程的记录确定导致所述终端出现卡顿的...

【专利技术属性】
技术研发人员：刘才，顾云建，
申请(专利权)人：北京小米移动软件有限公司，
类型：发明
国别省市：北京,11