CN111338713A - 一种应用卡顿的处理方法、装置、设备及存储介质 - Google Patents
一种应用卡顿的处理方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN111338713A CN111338713A CN202010084730.XA CN202010084730A CN111338713A CN 111338713 A CN111338713 A CN 111338713A CN 202010084730 A CN202010084730 A CN 202010084730A CN 111338713 A CN111338713 A CN 111338713A
- Authority
- CN
- China
- Prior art keywords
- thread
- application
- data
- stuck
- determining
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
Abstract
本发明实施例公开了一种应用卡顿的处理方法、装置、设备及存储介质。该方法通过确定应用在运行过程中所开启的线程；基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点；记录所述应用在所述时间点的应用数据；将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡顿的更新数据，解决因应用检测卡顿不够灵敏所导致的不利于及时发现卡顿的问题，实现提高发现卡顿的及时性，便于服务器生成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流畅性。
Description
技术领域
本发明实施例涉及计算机软件的技术，尤其涉及一种应用卡顿的处理方法、装置、设备 及存储介质。
背景技术
在安卓(Android)上，如果应用程序有一段时间响应不够灵敏，系统会向用户显示一个 对话框，这个对话框称作应用程序无响应(Application Not Responding，ANR)对话框。进 一步的，用户可以选择“等待”而让程序继续运行，也可以选择“强制关闭”。
一般的，在应用程序中不能出现ANR，而让用户每次都要处理这个ANR对话框，这容易造成应用程序的运行流畅度受到影响。
另外，在默认情况下，在Android中，活动(Activity)的最长执行时间是5秒，广播接 收者(Broadcast Receiver)的最长执行时间则是10秒。即应用程序的Activity超过5秒，或 者Broadcast Receiver超过10秒响应不够灵敏，系统会显示一个ANR对话框。也就是说，从 应用程序发生卡顿到卡顿被发现的时间过长，不利于应用程序的卡顿现象的及时发现。
发明内容
本发明提供一种应用卡顿的处理方法、装置、设备及存储介质，以实现提高发现卡顿的 及时性，便于服务器生成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流畅性。
第一方面，本发明实施例提供了一种应用卡顿的处理方法，该方法包括：
确定应用在运行过程中所开启的线程；
基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点；
记录所述应用在所述时间点的应用数据；
将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所 述卡顿的更新数据。
进一步的，所述线程包括主线程，所述基于执行所述线程所产生的线程数据，确定所述 应用发生卡顿的时间点，包括：
执行所述主线程；
获取包括所述主线程的线程状态的线程数据；
当确定所述主线程频繁处于同一线程状态时，确定所述主线程造成所述应用发生卡顿；
将所述主线程频繁处于同一线程状态的时间，确定为所述应用发生卡顿的时间点。
进一步的，所述获取包括所述主线程的线程状态的线程数据，包括：
获取所述主线程的线程控制块；
从所述线程控制块中读取所述主线程的线程状态，作为线程数据之一。
进一步的，所述确定所述主线程频繁处于同一线程状态，包括：
统计在预设周期内，所述主线程处于一线程状态的次数；
当所述次数超过预置频次时，确定所述主线程频繁处于一线程状态。
进一步的，所述确定所述主线程频繁处于同一线程状态，包括:
以预置的时间段为统计周期；
确定每一统计周期中，所述主线程的线程状态；
确定所述主线程连续处于同一线程状态的、所述统计周期的个数；
当所述个数超过预设个数时，确定所述主线程频繁处于一线程状态。
进一步的，所述线程包括子线程，所述基于执行所述线程所产生的线程数据，确定所述 应用发生卡顿的时间点，包括：
切换至执行子线程；
获取包括所述子线程对硬件资源的占用率的线程数据；
将所述占用率超过预设范围的子线程，确定为造成所述应用发生卡顿的目标线程；
将所述目标线程的执行时间，确定为所述应用发生卡顿的时间点。
进一步的，所述线程包括主线程和子线程，所述记录所述应用在所述时间点的应用数据， 包括：
将在所述时间点，所述应用所处的业务场景、所述主线程的执行栈、所述子线程的线程 信息，记录成所述应用数据。
进一步的，所述将所述应用数据发送至服务器，包括：
获取用于排除应用卡顿的白名单；
将所述应用数据与所述白名单进行匹配；
取消对与所述白名单匹配成功的应用数据的发送。
进一步的，在将所述应用数据发送至服务器之后，还包括：
接收服务器所发送的所述更新数据；
基于所述更新数据更新所述应用，以修复所述卡顿。
第二方面，本发明实施例还提供了一种应用卡顿的处理方法，其特征在于，包括：
接收客户端发送的应用数据，所述客户端包括应用在运行过程中所开启的线程，所述应 用数据为所述客户端所记录的、所述应用在设定的时间点的数据，设定的所述时间点为所述 客户端基于执行所述线程所产生的线程数据所确定的、所述应用发生卡顿的时间；
分析所述应用数据，以生成用于修复所述卡顿的更新数据。
进一步的，所述分析所述应用数据，以生成用于修复所述卡顿的更新数据，包括:
对至少一个客户端所发送的所述应用数据进行针对预置维度的归类；
对所述归类得到的、每一预置维度的应用数据进行分析，得到所述应用卡顿的原因；
基于所述原因生成用于修复所述卡顿的更新数据。
进一步的，在所述分析所述应用数据，以生成用于修复所述卡顿的更新数据之后，还包 括：
将所述更新数据发送至所述客户端，所述客户端用于基于所述更新数据更新所述应用， 以修复所述卡顿。
第三方面，本发明实施例还提供了一种应用卡顿的处理装置，该装置包括：
线程确定模块，用于确定应用在运行过程中所开启的线程；
卡顿确定模块，用于基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时 间点；
应用数据记录模块，用于记录所述应用在所述时间点的应用数据；
应用数据发送模块，用于将所述应用数据发送至服务器，所述服务器用于分析所述应用 数据，以生成用于修复所述卡顿的更新数据。
第四方面，本发明实施例还提供了一种应用卡顿的处理装置，该装置包括：
应用数据接收模块，用于接收客户端发送的应用数据，所述客户端包括应用在运行过程 中所开启的线程，所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数据， 设定的所述时间点为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应用发 生卡顿的时间；
应用数据分析模块，用于分析所述应用数据，以生成用于修复所述卡顿的更新数据。
第五方面，本发明实施例还提供了一种设备，该设备包括：存储器以及一个或多个处理 器；
所述存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现 如第一方面中任一所述的应用卡顿的处理方法，或第二方面中任一所述的应用卡顿的处理方 法。
第六方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，其特征在于， 所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面中任一所述的应用卡 顿的处理方法，或第二方面中任一所述的应用卡顿的处理方法。
本发明实施例通过确定应用在运行过程中所开启的线程；基于执行所述线程所产生的线 程数据，确定所述应用发生卡顿的时间点；记录所述应用在所述时间点的应用数据；将所述 应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡顿的更 新数据，解决因应用检测卡顿不够灵敏所导致的不利于及时发现卡顿的问题，实现提高发现 卡顿的及时性，便于服务器生成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流 畅性。
附图说明
图1为本发明实施例一提供的一种应用卡顿的处理方法的流程图；
图2为本发明实施例二提供的一种应用卡顿的处理方法的流程图；
图3为本发明实施例三提供的一种应用卡顿的处理方法的流程图；
图4为本发明实施例四提供的一种应用卡顿的处理方法的流程图；
图5为本发明实施例五提供的一种应用卡顿的处理装置的结构示意图；
图6为本发明实施例六提供的一种应用卡顿的处理装置的结构示意图；
图7为本发明实施例七提供的一种应用卡顿的处理设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具 体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述， 附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种应用卡顿的处理方法的流程图，本实施例可适用于检 测应用卡顿的情况，该方法可以由应用卡顿的处理设备来执行。该设备可以是电脑、服务器、 移动终端等。本实施例中，以该应用卡顿的处理设备为移动终端为例进行说明。其中，该移 动终端中可以安装有用于执行应用卡顿的处理方法的客户端。需要说明的是，该客户端可以 包括运行界面、或者运行在系统后台中。
参照图1，该方法具体包括如下步骤：
S110、确定应用在运行过程中所开启的线程。
一般的，移动终端中配置有操作系统，该操作系统可以是安卓系统、ios系统、Linux 系统等。应用是运行在该操作系统中的程序，也是该应用卡顿的处理方法的检测对象。示例 性的，该应用可以是直播平台提供的客户端，可以通过该客户端观看主播用户上传至该直播 平台的直播内容。
一般的，程序并不能单独执行，只有将程序加载到内存中，操作系统为其分配资源后才 能够运行，这种运行的程序称之为进程。也就是说，进程是在操作系统上执行的一个程序。 进一步的，线程(Thread)是操作系统能够进行运算调度的最小单位。线程被包含在进程之 中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中 可以并发多个线程，每条线程并行执行不同的任务。
进一步的，线程可以包括主线程和子线程。一般的，当一个程序启动时，就有一个进程 被操作系统创建，与此同时一个线程也立刻运行，该线程通常叫做程序的主线程(Main Thread)，因为它是程序开始时就执行的。如果需要再创建线程，那么创建的线程就是这个 主线程的子线程。每个进程至少都有一个主线程，是产生其他子线程的线程。
也就是说，应用的运行过程是流畅或者卡顿，可以通过开启的线程的执行情况来确定。 需要注意的是，使用线程来确定应用的卡顿情况，比使用ANR的检测方式具有更高的灵敏度， 可以在弹出ANR对话框之前，就确定卡顿情况的存在。
S120、基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点。
本实施例中，在线程的开启和执行过程中，可以产生线程数据。由于线程是动态概念， 该线程数据可以用于描述线程的动态特性。该动态特性可以包括用于描述线程的运行状态是 顺畅或者卡顿，进一步可以确定应用的运行状态是顺畅或者卡顿。
本实施例中，通过举例说明的方式，分别针对主线程和子线程两种情况，对如何基于线 程数据确定应用发生卡顿进行说明。
1、针对主线程
本实施例中，步骤S120可以进一步细化为包括如下步骤S121-S124：
S121、执行主线程。
本实施例中，在应用启动时，就有一个进程被操作系统创建，与此同时，主线程立刻被 执行。
S122、获取包括主线程的线程状态的线程数据。
本实施例中，线程数据可以包括线程状态。如，可以在主线程的执行过程中，获取主线 程的线程状态，作为主线程的线程数据。
其中，线程状态可以包括如下的几种：
①初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。
②运行(RUNNABLE)：线程中将就绪(ready)和运行中(running)两种状态笼统的称为 “运行”。
线程对象在创建后，当其他线程(比如主线程)调用了该线程对象的start()方法时，该 线程对象进入RUNNABLE的线程状态。该状态的线程位于可运行线程池中，等待被线程调度 选中，获取中央处理器(Central Processing Unit，CPU)的使用权，此时处于就绪状态 (ready)。就绪状态的线程在获得CPU时间片后变为运行中状态(running)。
③阻塞(BLOCKED)：表示线程阻塞于锁。
④等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作(通知或中 断)。
⑤超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。
⑥终止(TERMINATED)：表示该线程已经执行完毕。
进一步的，可以通过获取主线程的线程控制块(Thread Control Block，TCB)；从线 程控制块中读取主线程的线程状态，作为线程数据之一。
其中，TCB包括以下信息：
(1)线程状态。
(2)当线程不运行时，被保存的现场资源。
(3)一组执行堆栈。
(4)存放每个线程的局部变量主存区。
(5)访问同一个进程中的主存和其它资源。该其他资源可以是用于指示被执行指令序 列的程序计数器、保留局部变量、少数状态参数和返回地址等的一组寄存器和堆栈。
S123、当确定该主线程频繁处于同一线程状态时，确定该主线程造成该应用发生卡顿。
本实施例中，主线程的线程状态可以作为一种描述线程的动态特性的线程数据，可以用 于通过如下方式来确定主线程是否频繁处于同一线程状态。
1)第一种方式：
在一实施例中，可以通过统计在预设周期内，该主线程处于一线程状态的次数；当该次 数超过预置频次时，确定该主线程频繁处于一线程状态。如设置预设周期为10分钟，预置 频次为2次，则在10分钟内，主线程的线程状态依次为NEW、RUNNABLE、WAITING、WAITING、 BLOCKED、BLOCKED、BLOCKED，则主线程处于NEW线程状态的次数为1，处于NEW线程状态的 次数为1，处于NEW线程状态的次数为1，处于RUNNABLE线程状态的次数为1，处于WAITING 线程状态的次数为2，处于BLOCKED线程状态的次数为3，则可以确定主线程频繁处于BLOCKED 线程状态。
2)第二种方式：
在又一实施例中，可以通过以预置的时间段为统计周期；确定每一统计周期中，该主线 程的线程状态；确定该主线程连续处于同一线程状态的、该统计周期的个数；当该个数超过 预设个数时，确定该主线程频繁处于一线程状态。示例性的，设置预设次数为2次，在连续 的多个统计周期(如1分钟)中，主线程的线程状态依次为NEW、RUNNABLE、WAITING、WAITING、 BLOCKED、BLOCKED、BLOCKED，则主线程连续处于BLOCKED线程状态的次数为3次，超过了2 次，则确定主线程频繁处于BLOCKED线程状态。
S124、将该主线程频繁处于同一线程状态的时间，确定为该应用发生卡顿的时间点。
在步骤S124中，可以将该主线程频繁处于同一线程状态的起始时间，确定为该应用发 生卡顿的时间点；还可以将该主线程频繁处于同一线程状态的终止时间，确定为该应用发生 卡顿的时间点；还可以将该起始时间和终止时间之间的任一时间，确定为该应用发生卡顿的 时间点。
2、针对子线程
本实施例中，步骤S120还可以进一步细化为包括如下步骤S125-S128：
S125、切换至执行子线程。
本实施例中，可以其他线程，如主线程或其他子线程切换至执行目标子线程。该切换的 过程，可以通过在其他线程，如主线程或其他子线程中调用该目标子线程的start()方法。
S126、获取包括该子线程对硬件资源的占用率的线程数据。
本实施例中，硬件资源可以是CPU、运行内存、存储空间等。可以通过查看进程状态的 命令，如ps(Process status)等，显示子线程对硬件资源的占用率的线程数据。进一步的， 在安卓系统中，可以使用adb shell ps命令，执行该查看进程状态的命令。
S127、将该占用率超过预设范围的子线程，确定为造成该应用发生卡顿的目标线程。
一般的，当子线程对硬件资源的占用率超过预设范围时，容易造成应用发生卡顿。本实 施例中，可以将预设范围设置为占用硬件资源的50％。
S128、将该目标线程的执行时间，确定为该应用发生卡顿的时间点。
在步骤S128中，还可以将该目标线程对硬件资源占有率超过预设范围的期间中的任一 时间，确定为应用发生卡顿的时间点。
进一步的，步骤S121-124与步骤S125-128可以并行或者串行执行。当针对主线程和子 线程中出现至少一个的线程数据满足应用卡顿特征时，均可以确定应用发生卡顿。
该应用卡顿的特征，可以是如主线程频繁处于一线程状态，又如子线程对硬件资源的占 用率超过预设范围。
S130、记录所述应用在所述时间点的应用数据。
本实施例中，应用数据是应用运行过程中所产生的数据，在该时间点的应用数据，可以 用于分析得到应用卡顿的原因，从而对该卡顿进行针对性的修复。
在一实施例中，应用数据可以包括主线程或者子线程的调用栈中的栈数据。
一般的，每个线程在启动时，都对应配置有调用栈。其中，调用栈(Call stack)又称 为执行栈(execution stack)、控制栈(control stack)、运行时栈(run-time stack)与机器栈(machine stack)等，是计算机科学中存储有关正在运行的子程序的消息的栈。
其中，栈数据为调用栈中存放的数据。具体的，调用栈的主要功能是存放返回地址。除 此之外，调用栈还用于存放。
本地变量：子程序的变量可以存入调用栈，这样可以达到不同子程序间变量分离开的作 用。
参数传递：如果寄存器不足以容纳子程序的参数，可以在调用栈上存入参数。
环境传递：有些语言(如Pascal与Ada)支持“多层子程序”，即子程序中可以利用主程序的本地变量。这些变量可以通过调用栈传入子程序。
进一步的，还可以从线程的调用栈中确定线程的线程名称。
基于线程或者子线程的调用栈中的栈数据或线程名称，可以方便的对导应用数据进行分 析，以确定导致致应用发生卡顿的原因，并对该应用数据所对应的线程进行修复。
S140、将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于 修复所述卡顿的更新数据。
本实施例中，服务器可以接收从多个客户端发送的应用数据，进一步的，对该应用数据 的集合进行统计分析，从而确定导致致应用发生卡顿的原因，并对该应用数据所对应的线程 进行修复。
本实施例的技术方案，通过确定应用在运行过程中所开启的线程；基于执行所述线程所 产生的线程数据，确定所述应用发生卡顿的时间点；记录所述应用在所述时间点的应用数据； 将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡 顿的更新数据，区别于使用ANR的检测方式的延迟性，通过基于线程数据及时确定卡顿的 时间点，并基于该时间点的应用数据确定用于解决卡顿问题的更新数据，解决因应用检测卡 顿不够灵敏所导致的不利于及时发现卡顿的问题，实现提高发现卡顿的及时性，便于服务器 生成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流畅性。
实施例二
图2为本发明实施例二提供的一种应用卡顿的处理方法的流程图。
本实施例在上述实施例的基础上进一步细化，具体的，至少包括：从服务器接收用于修 复应用卡顿问题的更新数据、增加多种类型的应用数据等的说明。
参照图2，该方法具体包括如下的步骤：
S210、确定应用在运行过程中所开启的线程。
需要注意的是，使用线程来确定应用的卡顿情况，比使用ANR的检测方式具有更高的灵 敏度，可以在弹出ANR对话框之前，就确定卡顿情况的存在。
S220、基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点。
本实施例中，线程包括主线程和子线程，当针对主线程和子线程中出现至少一个的线程 数据，满足应用卡顿特征时，均可以确定应用发生卡顿。
该应用卡顿的特征，如主线程频繁处于一线程状态，又如子线程对硬件资源的占用率超 过预设范围。
S230、记录所述应用在所述时间点的应用数据。
本实施例中，应用数据是应用运行过程中所产生的数据，在该时间点的应用数据，可以 用于分析得到应用卡顿的原因，从而对该卡顿进行针对性的修复。
在一实施例中，可以将在该时间点，该应用所处的业务场景、该主线程的执行栈、该子 线程的线程信息，记录成该应用数据。
(1)业务场景
业务场景可以是应用执行的、与业务相关的场景，可以包括用户操作，如进出应用中的 某个页面，又如，点击某个按钮；还可以包括应用正运行的业务，如直播、游戏等；还可以 包括应用在运行某一业务的后台操作，如拉流、推流、数据缓存、页面渲染等。该应用场景 可以通过查看应用的运行日子进行获取；也可以通过在客户端中设置可用于检测应用的业务 场景的功能模块。
(2)主线程的执行栈
主线程的执行栈，又称调用栈，执行栈的栈数据主要用于存放返回地址。除此之外，执 行栈还用于存放：
本地变量：子程序的变量可以存入调用栈，这样可以达到不同子程序间变量分离开的作 用。
参数传递：如果寄存器不足以容纳子程序的参数，可以在调用栈上存入参数。
环境传递：有些语言(如Pascal与Ada)支持“多层子程序”，即子程序中可以利用主程序的本地变量。这些变量可以通过调用栈传入子程序。
本实施例中，可以通过主线程的执行栈确定是主线程运行到哪个节点，应用发生了卡顿。 进而，开发人员可以对该节点进行针对性的修复。
(3)子线程的线程信息
同样的，也可以从子线程的执行栈中确定子线程的线程信息，如包括线程名称、线程状 态、所执行的方法函数等。当然，线程状态也可以从线程的TCB中获取。进一步的，该子线 程的线程信息，可以用于分析造成应用卡顿的源头，如哪个子线程，子线程中的哪个方法函 数等。进一步的，可以有针对性的对子线程或子线程的具体的方法函数进行优化和修复，节 省了修复的时间，及时保证应用运行的流畅性。
在又一实施例中，还可以获取在该时间点的系统日志，如在Android系统中，可以通过 android.utils.Log的命令打印系统日志。应用是运行在操作系统中的。那么，在系统运行 错误的情况下，也有可能导致原本正常的应用受到系统的影响，而造成卡顿。当然，也有可 能是系统与应用之间不兼容导致的。为此，本实施例中对系统日志进行记录，可以排除因系 统所造成的应用卡顿现象。
S240、将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于 修复所述卡顿的更新数据。
本实施例中，更新数据可以是应用的更新版本或者补丁，应用可以基于该更新数据进行 更新。
进一步的，在服务器一端中，服务器可以对至少一个客户端所发送的该应用数据进行针 对预置维度的归类；对该归类得到的、每一预置维度的应用数据进行分析，得到该应用卡顿 的原因；基于该原因生成用于修复该卡顿的更新数据。其中，该预置的维度可以包括上述的 应用所处的业务场景、该主线程的执行栈、该子线程的线程信息、系统日志等。
本实施例中，在将应用数据发送至服务器时，还可以先获取用于排除应用卡顿的白名单； 将该应用数据与该白名单进行匹配；取消对与该白名单匹配成功的应用数据的发送。具体的， 如在某些业务场景，如游戏、页面渲染等容易造成应用的卡顿，但并非应用本身的问题，可 以忽略该时间点的应用卡顿。通过上述的设置，可以对应用数据进行提前的过滤，降低服务 器的处理压力，也减少分析所述应用数据所花费的成本。
进一步的，该白名单可以是集成在客户端中，也可以由服务器发送至客户端进行更新。 该白名单的生成，可以是在对应用数据进行分析时生成，如在确定某些业务场景是容易导致 应用卡顿，但并非应用本身的问题，可以将该业务场景添加到报名单中。
S250、接收服务器所发送的所述更新数据。
本实施例中，客户端可以定时向服务器发送更新请求，以从服务器接收更新数据；也可 以是，服务器在生成更新数据时，向客户端发送更新的通知，以提醒客户端从服务器下载该 更新数据。
S260、基于所述更新数据更新所述应用，以修复所述卡顿。
本实施例中，当更新数据为应用的更新版本时或者补丁时，客户端可以使用该更新数据 对原始的应用进行覆盖安装，得到修复了卡顿问题的新应用。
本实施例的技术方案，通过确定应用在运行过程中所开启的线程；基于执行所述线程所 产生的线程数据，确定所述应用发生卡顿的时间点；记录所述应用在所述时间点的应用数据； 将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡 顿的更新数据；接收服务器所发送的所述更新数据；基于所述更新数据更新所述应用，以修 复所述卡顿，区别于使用ANR的检测方式的延迟性，通过基于线程数据及时确定卡顿的时 间点，并基于该时间点的应用数据确定用于解决卡顿问题的更新数据，解决因应用检测卡顿 不够灵敏所导致的不利于及时发现卡顿的问题，实现提高发现卡顿的及时性，便于服务器生 成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流畅性。进一步的，通过使用白 名单对应用数据进行提前的过滤，可以降低服务器的处理压力，也减少分析所述应用数据所 花费的成本。
实施例三
图3为本发明实施例三提供的一种应用卡顿的处理方法的流程图。本实施例以应用卡顿 的处理设备为服务器进行详细说明，该服务器可以是独立服务器或集群服务器。
参照图3，该方法具体包括如下步骤：
S310、接收客户端发送的应用数据，所述客户端包括应用在运行过程中所开启的线程， 所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数据，设定的所述时间点 为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应用发生卡顿的时间。
本实施例中，应用数据是应用运行过程中所产生的数据，在该时间点的应用数据，可以 用于分析得到应用卡顿的原因，从而对该卡顿进行针对性的修复。
在一实施例中，应用数据可以包括主线程或者子线程的调用栈中的栈数据。
进一步的，还可以从线程的调用栈中确定线程的线程名称。
基于线程或者子线程的调用栈中的栈数据或线程名称，可以方便的对导应用数据进行分 析，以确定导致致应用发生卡顿的原因，并对该应用数据所对应的线程进行修复。
在又一实施例中，可以将在该时间点，该应用所处的业务场景、该主线程的执行栈、该 子线程的线程信息，记录成该应用数据。
(1)业务场景
业务场景可以是应用执行的、与业务相关的场景，可以包括用户操作，如进出应用中的 某个页面，又如，点击某个按钮；还可以包括应用正运行的业务，如直播、游戏等；还可以 包括应用在运行某一业务的后台操作，如拉流、推流、数据缓存、页面渲染等。
(2)主线程的执行栈
主线程的执行栈，又称调用栈，执行栈的栈数据主要用于存放返回地址。除此之外，执 行栈还用于存放：本地变量、参数传递和环境传递等。
本实施例中，可以通过主线程的执行栈确定是主线程运行到哪个节点，应用发生了卡顿。 进而，开发人员可以对该节点进行针对性的修复。
(3)子线程的线程信息
同样的，也可以从子线程的执行栈中确定子线程的线程信息，如包括线程名称、线程状 态、所执行的方法函数等。当然，线程状态也可以从线程的TCB中获取。进一步的，该子线 程的线程信息，可以用于分析造成应用卡顿的源头，如哪个子线程，子线程中的哪个方法函 数等。进一步的，可以有针对性的对子线程或子线程的具体的方法函数进行优化和修复，节 省了修复的时间，及时保证应用运行的流畅性。
在又一实施例中，应用数据还可以包括操作系统的系统日志，如在Android系统中，可 以通过android.utils.Log的命令打印系统日志。应用是运行在操作系统中的。那么，在系 统运行错误的情况下，也有可能导致原本正常的应用受到系统的影响，而造成卡顿。当然， 也有可能是系统与应用之间不兼容导致的。为此，本实施例中对系统日志进行记录，可以排 除因系统所造成的应用卡顿现象。
S320、分析所述应用数据，以生成用于修复所述卡顿的更新数据。
本实施例中，可以通过对至少一个客户端所发送的所述应用数据进行针对预置维度的归 类；对所述归类得到的、每一预置维度的应用数据进行分析，得到所述应用卡顿的原因；基 于所述原因生成用于修复所述卡顿的更新数据。
具体的，在对应用数据进行分析的过程中，可以根据每一预置维度的应用数据所出现的 频次超过预置次数，来确定该预置维度为造成应用卡顿的主要原因之一。进一步的，还可以 在对应用数据进行分析时生成白名单，用于在客户端中将获取的该应用数据与该白名单进行 匹配；取消对与该白名单匹配成功的应用数据的发送。具体的，该白名单中用于存储排除应 用卡顿的应用数据。如在某些业务场景，如游戏、页面渲染等容易造成应用的卡顿，但并非 应用本身的问题，可以忽略该时间点的应用卡顿。通过上述的设置，可以对应用数据进行提 前的过滤，降低服务器的处理压力，也减少分析所述应用数据所花费的成本。
本实施例的技术方案，通过接收客户端发送的应用数据，所述客户端包括应用在运行过 程中所开启的线程，所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数据， 设定的所述时间点为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应用发 生卡顿的时间；分析所述应用数据，以生成用于修复所述卡顿的更新数据，区别于使用ANR 的检测方式的延迟性，通过基于线程数据及时确定卡顿的时间点，并基于该时间点的应用数 据确定用于解决卡顿问题的更新数据，可以在弹出ANR对话框之前，就确定卡顿情况的存在， 解决因应用检测卡顿不够灵敏所导致的不利于及时发现卡顿的问题，实现提高发现卡顿的及 时性，便于服务器生成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流畅性。
在上述实施例的基础上，还可以将所述更新数据发送至所述客户端，所述客户端用于基 于所述更新数据更新所述应用，以修复所述卡顿。
本实施例中，服务器可以接收客户端定时发送的更新请求，以将更新数据发送至客户端； 也可以是，服务器在生成更新数据时，向客户端发送更新的通知，以提醒客户端从服务器下 载该更新数据。
实施例四
图4为本发明实施例四提供的一种应用卡顿的处理方法的流程图，本实施例以前述实施 例为基础，进一步增加客户端与服务器之间的交互操作，该方法具体包括如下步骤：
S410、客户端确定应用在运行过程中所开启的线程。
本实施例中，线程可以包括主线程和子线程。一般的，当一个程序启动时，就有一个进 程被操作系统创建，与此同时一个线程也立刻运行，该线程通常叫做程序的主线程(Main Thread)，因为它是程序开始时就执行的。也就是说，应用的运行过程是流畅或者卡顿，可 以通过开启的线程的执行情况来确定。
需要注意的是，使用线程来确定应用的卡顿情况，比使用ANR的检测方式具有更高的灵 敏度，可以在弹出ANR对话框之前，就确定卡顿情况的存在。
S420、客户端基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点。
本实施例中，在线程的开启和执行过程中，可以产生线程数据。由于线程是动态概念， 该线程数据可以用于描述线程的动态特性。该动态特性可以包括用于描述线程的运行状态是 顺畅或者卡顿，进一步可以确定应用的运行状态是顺畅或者卡顿。
本实施例中，通过举例说明的方式，分别针对主线程和子线程两种情况，对如何基于线 程数据确定应用发生卡顿进行说明。
针对主线程，可以通过执行主线程；获取包括主线程的线程状态的线程数据；当确定该 主线程频繁处于同一线程状态时，确定该主线程造成该应用发生卡顿。
针对子线程，可以通过切换至执行子线程；获取包括该子线程对硬件资源的占用率的线 程数据；将该占用率超过预设范围的子线程，确定为造成该应用发生卡顿的目标线程；将该 目标线程的执行时间，确定为该应用发生卡顿的时间点。
进一步的，当针对主线程和子线程中出现至少一个的线程数据满足应用卡顿特征时，均 可以确定应用发生卡顿。该应用卡顿的特征，可以是如主线程频繁处于一线程状态，又如子 线程对硬件资源的占用率超过预设范围。
S430、客户端记录所述应用在所述时间点的应用数据。
本实施例中，应用数据是应用运行过程中所产生的数据，在该时间点的应用数据，可以 用于分析得到应用卡顿的原因，从而对该卡顿进行针对性的修复。
在一实施例中，应用数据可以包括主线程或者子线程的调用栈中的栈数据。
进一步的，还可以从线程的调用栈中确定线程的线程名称。
基于线程或者子线程的调用栈中的栈数据或线程名称，可以方便的对导应用数据进行分 析，以确定导致致应用发生卡顿的原因，并对该应用数据所对应的线程进行修复。
在又一实施例中，可以将在该时间点，该应用所处的业务场景、该主线程的执行栈、该 子线程的线程信息，记录成该应用数据。
(1)业务场景
业务场景可以是应用执行的、与业务相关的场景，可以包括用户操作，如进出应用中的 某个页面，又如，点击某个按钮；还可以包括应用正运行的业务，如直播、游戏等；还可以 包括应用在运行某一业务的后台操作，如拉流、推流、数据缓存、页面渲染等。
(2)主线程的执行栈
主线程的执行栈，又称调用栈，执行栈的栈数据主要用于存放返回地址。除此之外，执 行栈还用于存放：本地变量、参数传递和环境传递等。
本实施例中，可以通过主线程的执行栈确定是主线程运行到哪个节点，应用发生了卡顿。 进而，开发人员可以对该节点进行针对性的修复。
(3)子线程的线程信息
同样的，也可以从子线程的执行栈中确定子线程的线程信息，如包括线程名称、线程状 态、所执行的方法函数等。当然，线程状态也可以从线程的TCB中获取。进一步的，该子线 程的线程信息，可以用于分析造成应用卡顿的源头，如哪个子线程，子线程中的哪个方法函 数等。进一步的，可以有针对性的对子线程或子线程的具体的方法函数进行优化和修复，节 省了修复的时间，及时保证应用运行的流畅性。
在又一实施例中，应用数据还可以包括操作系统的系统日志，如在Android系统中，可 以通过android.utils.Log的命令打印系统日志。应用是运行在操作系统中的。那么，在系 统运行错误的情况下，也有可能导致原本正常的应用受到系统的影响，而造成卡顿。当然， 也有可能是系统与应用之间不兼容导致的。为此，本实施例中对系统日志进行记录，可以排 除因系统所造成的应用卡顿现象。
S440、客户端将所述应用数据发送至服务器。
S450、服务器接收客户端发送的应用数据。
S460、服务器分析所述应用数据，以生成用于修复所述卡顿的更新数据。
本实施例中，在服务器一端中，服务器可以对至少一个客户端所发送的该应用数据进行 针对预置维度的归类；对该归类得到的、每一预置维度的应用数据进行分析，得到该应用卡 顿的原因；基于该原因生成用于修复该卡顿的更新数据。其中，该预置的维度可以包括上述 的应用所处的业务场景、该主线程的执行栈、该子线程的线程信息、系统日志等。
具体的，在对应用数据进行分析的过程中，可以根据每一预置维度的应用数据所出现的 频次超过预置次数，来确定该预置维度为造成应用卡顿的主要原因之一。进一步的，还可以 在对应用数据进行分析时生成白名单，用于在客户端中将获取的该应用数据与该白名单进行 匹配；取消对与该白名单匹配成功的应用数据的发送。具体的，该白名单中用于存储排除应 用卡顿的应用数据。如在某些业务场景，如游戏、页面渲染等容易造成应用的卡顿，但并非 应用本身的问题，可以忽略该时间点的应用卡顿。通过上述的设置，可以对应用数据进行提 前的过滤，降低服务器的处理压力，也减少分析所述应用数据所花费的成本。
S470、服务器将所述更新数据发送至所述客户端。
本实施例中，服务器可以接收客户端定时发送的更新请求，以将更新数据发送至客户端； 也可以是，服务器在生成更新数据时，向客户端发送更新的通知，以提醒客户端从服务器下 载该更新数据。
S480、客户端接收服务器所发送的所述更新数据。
S490、客户端基于所述更新数据更新所述应用，以修复所述卡顿。
本实施例中，当更新数据为应用的更新版本时或者补丁时，客户端可以使用该更新数据 对原始的应用进行覆盖安装，得到修复了卡顿问题的新应用。
实施例五
图5为本发明实施例五提供的一种应用卡顿的处理装置的结构示意图。
参照图5，该装置具体包括如下结构：线程确定模块510、卡顿确定模块520、应用数据 记录模块530和应用数据发送模块540。
线程确定模块510，用于确定应用在运行过程中所开启的线程。
卡顿确定模块520，用于基于执行所述线程所产生的线程数据，确定所述应用发生卡顿 的时间点。
应用数据记录模块530，用于记录所述应用在所述时间点的应用数据。
应用数据发送模块540，用于将所述应用数据发送至服务器，所述服务器用于分析所述 应用数据，以生成用于修复所述卡顿的更新数据。
本实施例的技术方案，确定应用在运行过程中所开启的线程；基于执行所述线程所产生 的线程数据，确定所述应用发生卡顿的时间点；记录所述应用在所述时间点的应用数据；将 所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡顿 的更新数据，区别于使用ANR的检测方式的延迟性，通过基于线程数据及时确定卡顿的时 间点，并基于该时间点的应用数据确定用于解决卡顿问题的更新数据，解决因应用检测卡顿 不够灵敏所导致的不利于及时发现卡顿的问题，实现提高发现卡顿的及时性，便于服务器生 成修复卡顿的更新数据，及时修复卡顿，以保证应用运行的流畅性。
在上述技术方案的基础上，所述线程包括主线程，所述卡顿确定模块520，包括：
主线程执行单元，用于执行所述主线程。
第一线程数据获取单元，用于获取包括所述主线程的线程状态的线程数据。
卡顿确定单元，用于当确定所述主线程频繁处于同一线程状态时，确定所述主线程造成 所述应用发生卡顿。
第一时间点确定单元，用于将所述主线程频繁处于同一线程状态的时间，确定为所述应 用发生卡顿的时间点。
在上述技术方案的基础上，所述第一线程数据获取单元，具体用于：线程控制块获取所 述主线程的线程控制块；从所述线程控制块中读取所述主线程的线程状态，作为线程数据之 一。
在一实施例中，所述第一卡顿确定单元，具体用于：统计在预设周期内，所述主线程处 于一线程状态的次数；当所述次数超过预置频次时，确定所述主线程频繁处于一线程状态。
在又一实施例中，所述第一卡顿确定单元，具体用于：以预置的时间段为统计周期；确 定每一统计周期中，所述主线程的线程状态；确定所述主线程连续处于同一线程状态的、所 述统计周期的个数；当所述个数超过预设个数时，确定所述主线程频繁处于一线程状态。
在上述技术方案的基础上，所述线程包括子线程，所述卡顿确定模块520，包括：
子线程执行单元，用于切换至执行子线程。
第二线程数据获取单元，用于获取包括所述子线程对硬件资源的占用率的线程数据。
目标线程确定单元，用于将所述占用率超过预设范围的子线程，确定为造成所述应用发 生卡顿的目标线程。
第二时间点确定单元，用于将所述目标线程的执行时间，确定为所述应用发生卡顿的时 间点。
在上述技术方案的基础上，所述线程包括主线程和子线程，所述应用数据记录模块530， 包括：
应用数据记录单元，用于将在所述时间点，所述应用所处的业务场景、所述主线程的执 行栈、所述子线程的线程信息，记录成所述应用数据。
在上述技术方案的基础上，所述应用数据发送模块540，包括：
白名单获取单元，用于获取用于排除应用卡顿的白名单。
匹配单元，用于将所述应用数据与所述白名单进行匹配。
取消发送单元，用于取消对与所述白名单匹配成功的应用数据的发送。
在上述技术方案的基础上，所述装置还包括：
更新接收模块，用于在将所述应用数据发送至服务器之后，接收服务器所发送的所述更 新数据。
更新模块，用于基于所述更新数据更新所述应用，以修复所述卡顿。
上述产品可执行本发明任意实施例所提供的方法，具备执行方法相应的功能模块和有益 效果。
实施例六
图6为本发明实施例六提供的一种应用卡顿的处理装置的结构示意图。
参照图6，该装置具体包括如下结构：应用数据接收模块610和应用数据分析模块620。
应用数据接收模块610，用于接收客户端发送的应用数据，所述客户端包括应用在运行 过程中所开启的线程，所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数 据，设定的所述时间点为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应 用发生卡顿的时间。
应用数据分析模块620，用于分析所述应用数据，以生成用于修复所述卡顿的更新数据。
本实施例的技术方案，通过接收客户端发送的应用数据，所述客户端包括应用在运行过 程中所开启的线程，所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数据， 设定的所述时间点为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应用发 生卡顿的时间；分析所述应用数据，以生成用于修复所述卡顿的更新数据，区别于使用ANR 的检测方式的延迟性，通过基于线程数据及时确定卡顿的时间点，并基于该时间点的应用数 据确定用于解决卡顿问题的更新数据，解决因应用检测卡顿不够灵敏所导致的不利于及时发 现卡顿的问题，实现提高发现卡顿的及时性，便于服务器生成修复卡顿的更新数据，及时修 复卡顿，以保证应用运行的流畅性。
在上述技术方案的基础上，所述应用数据分析模块620，包括:
归类单元，用于对至少一个客户端所发送的所述应用数据进行针对预置维度的归类。
卡顿原因确定单元，用于对所述归类得到的、每一预置维度的应用数据进行分析，得到 所述应用卡顿的原因。
更新数据生成单元，用于基于所述原因生成用于修复所述卡顿的更新数据。
在上述技术方案的基础上，所述装置，还包括：
更新数据发送模块，用于在所述分析所述应用数据，以生成用于修复所述卡顿的更新数 据之后，将所述更新数据发送至所述客户端，所述客户端用于基于所述更新数据更新所述应 用，以修复所述卡顿。
实施例七
图7为本发明实施例七提供的一种应用卡顿的处理设备的结构示意图。如图7所示，该 应用卡顿的处理设备包括：处理器70、存储器71、输入装置72以及输出装置73。该应用卡 顿的处理设备中处理器70的数量可以是一个或者多个，图7中以一个处理器70为例。该应 用卡顿的处理设备中存储器71的数量可以是一个或者多个，图7中以一个存储器71为例。 该应用卡顿的处理设备的处理器70、存储器71、输入装置72以及输出装置73可以通过总 线或者其他方式连接，图7中以通过总线连接为例。该应用卡顿的处理设备可以是电脑、服 务器、移动终端等。
存储器71作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以 及模块，如本发明任意实施例所述的应用卡顿的处理方法对应的程序指令/模块(例如，应 用卡顿的处理装置中的线程确定模块510、卡顿确定模块520、应用数据记录模块530和应 用数据发送模块540；又例如，应用卡顿的处理装置中的应用数据接收模块610和应用数据 分析模块620)。存储器71可主要包括存储程序区和存储数据区，其中，存储程序区可存储 操作系统、至少一个功能所需的应用程序；存储数据区可存储根据设备的使用所创建的数据 等。此外，存储器71可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至 少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器71 可进一步包括相对于处理器70远程设置的存储器，这些远程存储器可以通过网络连接至设 备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置72可用于接收输入的数字或者字符信息，以及产生与应用卡顿的处理设备的 观众用户设置以及功能控制有关的键信号输入，还可以是用于获取图像的摄像头以及获取音 频数据的拾音设备。输出装置73可以包括扬声器等音频设备。需要说明的是，输入装置72 和输出装置73的具体组成可以根据实际情况设定。
处理器70通过运行存储在存储器71中的软件程序、指令以及模块，从而执行设备的各 种功能应用以及数据处理，即实现上述的应用卡顿的处理方法。
实施例八
本发明实施例八还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令 在由计算机处理器执行时用于执行一种应用卡顿的处理方法。
在一实施例中，该方法包括：
确定应用在运行过程中所开启的线程；
基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点；
记录所述应用在所述时间点的应用数据；
将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所 述卡顿的更新数据。
在又一实施例中，该方法包括：
接收客户端发送的应用数据，所述客户端包括应用在运行过程中所开启的线程，所述应 用数据为所述客户端所记录的、所述应用在设定的时间点的数据，设定的所述时间点为所述 客户端基于执行所述线程所产生的线程数据所确定的、所述应用发生卡顿的时间；
分析所述应用数据，以生成用于修复所述卡顿的更新数据。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行 指令不限于如上所述的应用卡顿的处理方法操作,还可以执行本发明任意实施例所提供的应 用卡顿的处理方法中的相关操作，且具备相应的功能和有益效果。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助 软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施 方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以 软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机 的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory, RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是机器 人，个人计算机，服务器，或者网络设备等)执行本发明任意实施例所述的应用卡顿的处理 方法。
值得注意的是，上述应用卡顿的处理装置中，所包括的各个单元和模块只是按照功能逻 辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单 元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施 方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件 来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术 中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻 辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门 阵列(FPGA)等。
在本说明书的描述中，参考术语“在一实施例中”、“在又一实施例中”、“示例性的”或“在具体的实施例中”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述 不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任 何的一个或多个实施例或示例中以合适的方式结合。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发 明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调 整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详 细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括 更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。
Claims (16)
1.一种应用卡顿的处理方法，其特征在于，包括：
确定应用在运行过程中所开启的线程；
基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点；
记录所述应用在所述时间点的应用数据；
将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡顿的更新数据。
2.根据权利要求1所述的方法，其特征在于，所述线程包括主线程，所述基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点，包括：
执行所述主线程；
获取包括所述主线程的线程状态的线程数据；
当确定所述主线程频繁处于同一线程状态时，确定所述主线程造成所述应用发生卡顿；
将所述主线程频繁处于同一线程状态的时间，确定为所述应用发生卡顿的时间点。
3.根据权利要求2所述的方法，其特征在于，所述获取包括所述主线程的线程状态的线程数据，包括：
获取所述主线程的线程控制块；
从所述线程控制块中读取所述主线程的线程状态，作为线程数据之一。
4.根据权利要求2所述的方法，其特征在于，所述确定所述主线程频繁处于同一线程状态，包括：
统计在预设周期内，所述主线程处于一线程状态的次数；
当所述次数超过预置频次时，确定所述主线程频繁处于一线程状态。
5.根据权利要求2所述的方法，其特征在于，所述确定所述主线程频繁处于同一线程状态，包括:
以预置的时间段为统计周期；
确定每一统计周期中，所述主线程的线程状态；
确定所述主线程连续处于同一线程状态的、所述统计周期的个数；
当所述个数超过预设个数时，确定所述主线程频繁处于一线程状态。
6.根据权利要求1所述的方法，其特征在于，所述线程包括子线程，所述基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点，包括：
切换至执行子线程；
获取包括所述子线程对硬件资源的占用率的线程数据；
将所述占用率超过预设范围的子线程，确定为造成所述应用发生卡顿的目标线程；
将所述目标线程的执行时间，确定为所述应用发生卡顿的时间点。
7.根据权利要求1所述的方法，其特征在于，所述线程包括主线程和子线程，所述记录所述应用在所述时间点的应用数据，包括：
将在所述时间点，所述应用所处的业务场景、所述主线程的执行栈、所述子线程的线程信息，记录成所述应用数据。
8.根据权利要求1-7任一所述的方法，其特征在于，所述将所述应用数据发送至服务器，包括：
获取用于排除应用卡顿的白名单；
将所述应用数据与所述白名单进行匹配；
取消对与所述白名单匹配成功的应用数据的发送。
9.根据权利要求8所述的方法，其特征在于，在将所述应用数据发送至服务器之后，还包括：
接收服务器所发送的所述更新数据；
基于所述更新数据更新所述应用，以修复所述卡顿。
10.一种应用卡顿的处理方法，其特征在于，包括：
接收客户端发送的应用数据，所述客户端包括应用在运行过程中所开启的线程，所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数据，设定的所述时间点为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应用发生卡顿的时间；
分析所述应用数据，以生成用于修复所述卡顿的更新数据。
11.根据权利要求10所述的方法，其特征在于，所述分析所述应用数据，以生成用于修复所述卡顿的更新数据，包括:
对至少一个客户端所发送的所述应用数据进行针对预置维度的归类；
对所述归类得到的、每一预置维度的应用数据进行分析，得到所述应用卡顿的原因；
基于所述原因生成用于修复所述卡顿的更新数据。
12.根据权利要求10所述的方法，其特征在于，在所述分析所述应用数据，以生成用于修复所述卡顿的更新数据之后，还包括：
将所述更新数据发送至所述客户端，所述客户端用于基于所述更新数据更新所述应用，以修复所述卡顿。
13.一种应用卡顿的处理装置，其特征在于，包括：
线程确定模块，用于确定应用在运行过程中所开启的线程；
卡顿确定模块，用于基于执行所述线程所产生的线程数据，确定所述应用发生卡顿的时间点；
应用数据记录模块，用于记录所述应用在所述时间点的应用数据；
应用数据发送模块，用于将所述应用数据发送至服务器，所述服务器用于分析所述应用数据，以生成用于修复所述卡顿的更新数据。
14.一种应用卡顿的处理装置，其特征在于，包括：
应用数据接收模块，用于接收客户端发送的应用数据，所述客户端包括应用在运行过程中所开启的线程，所述应用数据为所述客户端所记录的、所述应用在设定的时间点的数据，设定的所述时间点为所述客户端基于执行所述线程所产生的线程数据所确定的、所述应用发生卡顿的时间；
应用数据分析模块，用于分析所述应用数据，以生成用于修复所述卡顿的更新数据。
15.一种设备，其特征在于，包括：存储器以及一个或多个处理器；
所述存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-9中任一所述的应用卡顿的处理方法，或权利要求10-12中任一所述的应用卡顿的处理方法。
16.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-9中任一所述的应用卡顿的处理方法，或权利要求10-12中任一所述的应用卡顿的处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010084730.XA CN111338713A (zh) | 2020-02-10 | 2020-02-10 | 一种应用卡顿的处理方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010084730.XA CN111338713A (zh) | 2020-02-10 | 2020-02-10 | 一种应用卡顿的处理方法、装置、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111338713A true CN111338713A (zh) | 2020-06-26 |
Family
ID=71182640
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010084730.XA Pending CN111338713A (zh) | 2020-02-10 | 2020-02-10 | 一种应用卡顿的处理方法、装置、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111338713A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113626244A (zh) * | 2021-08-26 | 2021-11-09 | 广州市百果园网络科技有限公司 | Anr异常数据的收集方法、显示方法、装置及设备 |
| CN116347488A (zh) * | 2023-02-21 | 2023-06-27 | 荣耀终端有限公司 | 网络卡顿的处理方法、设备以及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106919488A (zh) * | 2016-07-21 | 2017-07-04 | 阿里巴巴集团控股有限公司 | 应用程序的响应状态的确定方法及装置 |
| CN107390670A (zh) * | 2017-06-27 | 2017-11-24 | 深圳市爱培科技术股份有限公司 | Android系统资源控制方法、存储介质及智能终端 |
| US20190065279A1 (en) * | 2017-08-31 | 2019-02-28 | TidalScale, Inc. | Entanglement of pages and guest threads |
| CN109840177A (zh) * | 2017-11-24 | 2019-06-04 | 腾讯科技（深圳）有限公司 | 一种卡顿的处理方法及相关设备 |
| CN110413641A (zh) * | 2019-07-15 | 2019-11-05 | 苏州浪潮智能科技有限公司 | 一种数据库卡顿处理方法与装置 |
-
2020
- 2020-02-10 CN CN202010084730.XA patent/CN111338713A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106919488A (zh) * | 2016-07-21 | 2017-07-04 | 阿里巴巴集团控股有限公司 | 应用程序的响应状态的确定方法及装置 |
| CN107390670A (zh) * | 2017-06-27 | 2017-11-24 | 深圳市爱培科技术股份有限公司 | Android系统资源控制方法、存储介质及智能终端 |
| US20190065279A1 (en) * | 2017-08-31 | 2019-02-28 | TidalScale, Inc. | Entanglement of pages and guest threads |
| CN109840177A (zh) * | 2017-11-24 | 2019-06-04 | 腾讯科技（深圳）有限公司 | 一种卡顿的处理方法及相关设备 |
| CN110413641A (zh) * | 2019-07-15 | 2019-11-05 | 苏州浪潮智能科技有限公司 | 一种数据库卡顿处理方法与装置 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113626244A (zh) * | 2021-08-26 | 2021-11-09 | 广州市百果园网络科技有限公司 | Anr异常数据的收集方法、显示方法、装置及设备 |
| CN116347488A (zh) * | 2023-02-21 | 2023-06-27 | 荣耀终端有限公司 | 网络卡顿的处理方法、设备以及存储介质 |
| CN116347488B (zh) * | 2023-02-21 | 2023-10-20 | 荣耀终端有限公司 | 网络卡顿的处理方法、设备以及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107832100B (zh) | 一种apk插件的加载方法及其终端 | |
| EP3799390A1 (en) | Preemptive scheduling based resource sharing use method, system and | |
| CN110737534A (zh) | 任务的处理方法、装置和服务器 | |
| CN107025135B (zh) | Docker容器内应用进程管理方法、装置和介质 | |
| WO2017049912A1 (zh) | 一种jslee容器的业务处理方法及系统 | |
| WO2021189257A1 (zh) | 恶意进程的检测方法、装置、电子设备及存储介质 | |
| CN111338713A (zh) | 一种应用卡顿的处理方法、装置、设备及存储介质 | |
| KR20130108613A (ko) | 프로세스 간 통신을 위한 방법, 장치 및 컴퓨터 기록 매체 | |
| WO2019168715A1 (en) | Event to serverless function workflow instance mapping mechanism | |
| WO2017219872A1 (zh) | 机顶盒的升级、换台方法及系统 | |
| WO2019117767A1 (en) | Method, function manager and arrangement for handling function calls | |
| CN109271268B (zh) | 一种基于dpdk的智能容错方法 | |
| CN112559565A (zh) | 一种异常检测方法、系统及装置 | |
| CN112766470B (zh) | 特征数据处理方法、指令序列生成方法、装置及设备 | |
| CN111831408A (zh) | 异步任务处理方法、装置、电子设备及介质 | |
| CN109005465B (zh) | 弹幕消息分发方法、装置、设备及存储介质 | |
| US9244736B2 (en) | Thinning operating systems | |
| CN113285857B (zh) | 一种面向物联网异构物体的微服务匹配方法 | |
| US20220405104A1 (en) | Cross platform and platform agnostic accelerator remoting service | |
| CN112580092B (zh) | 一种敏感文件识别方法及装置 | |
| CN115438020A (zh) | 一种数据库资源调度方法、装置、设备及介质 | |
| CN114201293A (zh) | Kafka中间件集群参数的修改方法、装置以及存储介质 | |
| CN115082911A (zh) | 一种视频分析方法、装置及视频处理设备 | |
| CN112162626A (zh) | 一种应用程序处理方法及装置 | |
| CN113778726A (zh) | 一种错误信息处理方法、装置、服务器和存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |