CN111443957B - 针对应用卡顿的处理方法、装置和电子设备 - Google Patents

Abstract

本申请实施例提供一种针对应用卡顿的处理方法、装置和电子设备。方法包括：判断应用主线程的事件处理队列中的新加入事件是否需要被优先响应；当所述新加入事件需要被优先响应时，判断所述新加入事件在所述事件处理队列中的等待时间是否超过预设时间阈值；当超过时，收回所述应用主线程的代码执行权；重新排列所述事件处理队列，包括，将所述新加入事件排在重排后的事件处理队列的第一位；恢复所述应用主线程的代码执行权，令所述应用主线程执行重排后的事件处理队列。根据本申请一实施例的方法，通过重排应用主线程的事件处理队列，优先执行需要优先响应的事件，避免由于事件处理时间过长而导致用户产生等待感，从而大大提高了用户体验。

Description

针对应用卡顿的处理方法、装置和电子设备

技术领域

本申请涉及智能终端技术领域，特别涉及一种针对应用卡顿的处理方法、装置和电子设备。

背景技术

在计算机应用场景中，为了使用计算机硬件设备实现各种不同的应用功能，技术人员开发了众多具备各种应用功能的应用软件。随着计算机硬件技术的不断发展，计算机终端在人类的日常生产生活中的应用范围不断扩大，应用软件的种类也不断增长。

在实际应用场景中，在硬件设备上安装有操作系统(例如，安卓(Android)系统)，在操作系统中加载有应用软件，应用软件运行在操作系统的系统框架下。由于计算机硬件处理性能不足、和/或计算机硬件错误、和/或系统框架设计缺陷、和/或软件设计缺陷、和/或输入数据错误等因素的存在，在使用应用软件的过程中，会出现应用软件运行卡顿的情况(例如，应用无响应(Application Not Responding，ANR))，大大影响了用户使用应用软件的用户体验。

发明内容

本申请提供了一种针对应用卡顿的处理方法、装置和电子设备，本申请还提供一种计算机可读存储介质，以提供一种在应用软件外部的数据处理方式，降低应用卡顿对用户造成的操作影响，提高应用软件使用的用户体验。

本申请实施例采用下述技术方案：

第一方面，本申请提供了一种针对应用卡顿的处理方法，包括：

监控应用主线程的事件处理队列，判断事件处理队列中的新加入事件是否需要被优先响应；具体的，需要被优先响应的事件包括但不限于会向用户反馈信息的事件；例如，在根据本申请一实施例的应用场景中，将响应被迟滞后会导致用户产生等待感的事件均定义为需要优先响应；例如，会向用户反馈信息的预定时处理事件和/或周期处理事件；

当新加入事件需要被优先响应时，计算新加入事件在事件处理队列中的等待时间，判断等待时间是否超过预设时间阈值；预设时间阈值的大小可以在具体实现时根据装置性能和/实现需求等自行设定，本实施例对预设时间阈值的大小不作限定，举例来说，根据用户的感知习惯设置预设时间阈值，以用户不会明显有等待感的事件长度为预设时间阈值，例如，将预设时间阈值设定为1秒；

当等待时间超过预设时间阈值时，收回应用主线程的代码执行权；

在应用主线程的代码执行权被收回后，重新排列事件处理队列，包括：

前移新加入事件的排位，，将新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，阻塞事件为事件处理队列被重排前，排在第一位且被主线程执行的事件；即，相较于重排前的事件处理队列，在重排后的事件处理队列中，阻塞事件被移除或阻塞事件的排位被后移；在重新排列事件处理队列的过程中，对阻塞事件是采用排位后移方案还是移除方案，是由具体实现时根据装置性能和/实现需求等决定的；本实施例对重新排列事件处理队列的过程中针对阻塞事件所采用的方案不做明确限定；举例来说，根据阻塞事件的具体内容来确定针对阻塞事件所采用的方案，例如，当阻塞事件为针对用户的关键信息反馈和/或阻塞事件被一个或多个后续事件依赖时，在重新排列事件处理队列的过程中后移阻塞事件的排位；当阻塞事件为独立非关键事件(例如，自动检索升级文件)时，在重新排列事件处理队列的过程中移除阻塞事件，待后续重置阻塞事件的输入参数后再重新发起阻塞事件；

在事件处理队列被重排完毕后，恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

根据上述第一方面的方法流程，当新加入应用主线程的事件处理队列的事件为需要被优先响应(例如，会向用户反馈信息的事件(消息))时，在当前处理的事件(消息)对新加入的事件产生可被感知的迟滞之前就进行事件处理顺序调整，暂停当前事件的处理，优先处理新加入的事件，从而尽可能的确保及时的向用户反馈信息，这样，会使得用户感觉应用始终在正常运行，使得用户感觉应用对用户的信息回馈并没有受到任何干扰，从而避免用户产生等待感，进而提高用户体验。根据本申请一实施例的方法，通过重排应用主线程的事件处理队列，优先执行需要优先响应的事件，避免由于事件处理时间过长而导致用户产生等待感，从而大大提高了用户体验。

一种可能的实现方式中，判断事件处理队列中的新加入事件是否需要被优先响应，包括：

判断新加入事件是否为用户输入事件；

当新加入事件为用户输入事件时，判定新加入事件需要被优先响应。

在本实现方式中，通过将用户输入事件定义为需要被优先响应的事件，细化了优先响应事件的判定条件，从而使得优先响应事件的判定更为简单易行，降低了方案的实施难度。一种可能的实现方式中，监控应用主线程的事件处理队列，包括：

构建监控子线程；

使用监控子线程监控应用主线程的事件处理队列。

在本实现方式中，通过构建子线程来实现监控操作，可以避免监控操作影响到主线程的正常运行，从而大大提高系统运行的稳定性。

一种可能的实现方式中，判断事件处理队列中的新加入事件是否需要被优先响应之前，还包括：

判断新加入事件是否依赖其他事件；

当新加入事件不依赖其他事件时，进一步判断事件处理队列中的新加入事件是否需要被优先响应；当新加入事件依赖其他事件时，则判定事件处理队列中的新加入事件不需要被优先响应。

在本实现方式中，进行优先响应判定时加入了依赖关系的参考，可以避免由事件处理顺序与依赖关系不匹配而导致的事件处理错误，从而大大提高了系统运行的稳定性，增强了本方案的实用性以及可行性。

一种可能的实现方式中，收回应用主线程的代码执行权，包括，向应用主线程发中断消息，在应用主线程响应中断消息的过程中，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。具体的，修改安卓运行时的虚拟机的中断发送流程，把中断直接重定向到安卓应用框架层的消息分配函数，安卓系统侧来控制接下来的执行代码。即发送应用代码导致的主线程阻塞时，通过中断，强制收回线程的代码执行权，交给系统侧重新分配。

在本实现方式中，由于中断响应是软件系统中常见的响应设置，因此，通过中断方式来回收主线程的代码执行权不需要进行额外的响应配置，可以大大简化回收主线程的代码执行权的执行步骤，减少实现主线程的代码执行权回收所需要录入的代码量，降低主线程的代码执行权回收步骤的实现难度。

一种可能的实现方式中，重新排列事件处理队列的过程还包括：在重新排列事件处理队列的过程中，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变。即，在重排后的事件处理队列中，除阻塞事件以及新加入事件以外的其他事件相互间的排序与重拍前是一致的。这样就可以确保除阻塞事件以及新加入事件以外的其他事件相互间存在依赖关系时，事件处理队列的重排不会影响到事件的顺利处理。

一种可能的实现方式中，后移阻塞事件的排位，包括：

判断是否存在依赖阻塞事件的事件；

当存在依赖阻塞事件的事件时，在重排后的事件处理队列中，将阻塞事件排在依赖该阻塞事件的事件之前；

当不存在依赖阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的末尾。

在本实现方式中，在重新排列事件处理队列的过程中加入了阻塞事件与其他事件间依赖关系的参考，从而避免了由事件处理顺序与依赖关系不匹配而导致的事件处理错误，大大提高系统运行的稳定性，增强了本方案的实用性以及可行性。

一种可能的实现方式中，后移阻塞事件的排位，包括：将阻塞事件排在重排后的事件处理队列的第二位。在本实现方式中，当阻塞事件排在重排后的事件处理队列的第二位时，不需要考虑事件处理队列中是否存在依赖阻塞事件的事件，因此也就取消了事件处理队列重排过程中的依赖判断步骤，从而大大降低数据处理量。

一种可能的实现方式中，移除阻塞事件，包括：

判断阻塞事件导致的重新排列事件处理队列的次数是否大于预设次数阈值；预设次数阈值的大小可以在具体实现时根据装置性能和/实现需求等自行设定，本实施例对预设次数阈值的大小不作限定，举例来说，将预设次数阈值设定为3次；

当重新排列事件处理队列的次数大于预设次数阈值时，从事件处理队列中移除阻塞事件；或者，当重新排列事件处理队列的次数大于预设次数阈值时，从事件处理队列中移除阻塞事件并输出提示信息，提示用户阻塞事件已被移除；或者，当重新排列事件处理队列的次数大于预设次数阈值时，输出提示信息，由用户决定是否要从事件处理队列中移除阻塞事件。

在本实现方式中，在初期延后阻塞事件的处理(将事件处理队列中阻塞事件的排位后移)，为阻塞事件保留处理机会，从而避免某些处理耗时较长的事件被无限制的强行关闭；当阻塞事件多次导致事件处理队列重排(此时阻塞事件很有可能是一个无法顺利处理的事件)时，放弃处理阻塞事件(将阻塞事件从事件处理队列中移除)，从而避免陷入不断延后阻塞事件的处理的死循环中。

第二方面，本申请一实施例提出了一种针对应用卡顿的处理装置，包括：

事件监控模块，其用于监控应用主线程的事件处理队列，判断事件处理队列中的新加入事件是否需要被优先响应；

等待时间判断模块，其用于当新加入事件需要被优先响应时，计算新加入事件在事件处理队列中的等待时间，判断等待时间是否超过预设时间阈值；

执行权收回模块，其用于当等待时间超过预设时间阈值时，收回应用主线程的代码执行权；

队列重排模块，其用于在应用主线程的代码执行权被收回后，重新排列事件处理队列，包括：

前移新加入事件的排位，将新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，阻塞事件为事件处理队列被重排前，排在第一位且被主线程执行的事件；

执行权恢复模块，其用于在事件处理队列被重排完毕后，恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

使用上述第二方面的处理装置，可以实现对应用主线程的事件处理队列的监控并在合适的时机进行事件处理队列重排，从而使得应用主线程优先执行需要优先响应的事件，避免由于事件处理时间过长而导致用户产生等待感，进而大大提高了用户体验。

一种可能的实现方式中，事件监控模块包括：

优先响应判定单元，其用于判断新加入事件是否为用户输入事件，当新加入事件为用户输入事件时，判定新加入事件需要被优先响应。

一种可能的实现方式中，事件监控模块包括：

监控单元，其用于构建监控子线程，使用监控子线程监控应用主线程的事件处理队列。

一种可能的实现方式中，事件监控模块包括：

第一依赖关系判定单元，其用于判断新加入事件是否依赖其他事件；

优先响应判定单元，其用于当新加入事件不依赖其他事件时，判断事件处理队列中的新加入事件是否需要被优先响应。

一种可能的实现方式中，执行权收回模块包括：

中断单元，其用于向应用主线程发中断消息，在应用主线程响应中断消息的过程中，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。

一种可能的实现方式中，队列重排模块还用于在重新排列事件处理队列的过程中，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变。

一种可能的实现方式中，队列重排模块包括：

第二依赖关系判定单元，其用于判断是否存在依赖阻塞事件的事件；

移位单元，其用于当存在依赖阻塞事件的事件时，在重排后的事件处理队列中，将阻塞事件排在依赖该阻塞事件的事件之前。

一种可能的实现方式中，移位单元还用于：

当不存在依赖阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的末尾。

一种可能的实现方式中，队列重排模块包括：

移位单元，其用于将阻塞事件排在重排后的事件处理队列的第二位。

一种可能的实现方式中，队列重排模块包括：

重排次数判定单元，其用于判断阻塞事件导致的重新排列事件处理队列的次数是否大于预设次数阈值；

移位单元，其用于当重新排列事件处理队列的次数大于预设次数阈值时，移除阻塞事件和/或输出提示信息。

第三方面，本申请一实施例提出了一种电子设备，电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行如下步骤：

监控应用主线程的事件处理队列，判断事件处理队列中的新加入事件是否需要被优先响应；

当新加入事件需要被优先响应时，计算新加入事件在事件处理队列中的等待时间，判断等待时间是否超过预设时间阈值；

当等待时间超过预设时间阈值时，收回应用主线程的代码执行权；

在应用主线程的代码执行权被收回后，重新排列事件处理队列，包括：

前移新加入事件的排位，将新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，阻塞事件为所述事件处理队列被重排前，排在第一位且被主线程执行的事件；

在事件处理队列被重排完毕后，恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

一种可能的实现方式中，指令被设备执行时，使得设备执行判断事件处理队列中的新加入事件是否需要被优先响应的步骤，包括：

判断新加入事件是否为用户输入事件；

当新加入事件为用户输入事件时，判定新加入事件需要被优先响应。

一种可能的实现方式中，指令被设备执行时，使得设备执行监控应用主线程的事件处理队列的步骤，包括：

构建监控子线程；

使用监控子线程监控应用主线程的事件处理队列。

一种可能的实现方式中，指令被设备执行时，使得设备执行判断事件处理队列中的新加入事件是否需要被优先响应的步骤之前，还包括：

判断新加入事件是否依赖其他事件；

当新加入事件不依赖其他事件时，判断事件处理队列中的新加入事件是否需要被优先响应。

一种可能的实现方式中，指令被设备执行时，使得设备执行收回应用主线程的代码执行权的步骤，包括，向应用主线程发中断消息，在应用主线程响应中断消息的过程中，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。

一种可能的实现方式中，指令被设备执行时，使得设备执行重新排列事件处理队列的步骤中，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变。

一种可能的实现方式中，指令被设备执行时，使得设备执行后移阻塞事件的排位的步骤，包括：

判断是否存在依赖阻塞事件的事件；

当存在依赖阻塞事件的事件时，在重排后的事件处理队列中，将阻塞事件排在依赖该阻塞事件的事件之前。

一种可能的实现方式中，指令被设备执行时，使得设备执行判断是否存在依赖阻塞事件的事件的步骤之后，还包括：

当不存在依赖阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的末尾。

一种可能的实现方式中，指令被设备执行时，使得设备执行后移阻塞事件的排位的步骤，包括：将阻塞事件排在重排后的事件处理队列的第二位。

一种可能的实现方式中，指令被设备执行时，使得设备执行移除阻塞事件的步骤，包括：

判断阻塞事件导致的重新排列事件处理队列的次数是否大于预设次数阈值；

当重新排列事件处理队列的次数大于预设次数阈值时，移除阻塞事件和/或输出提示信息。

第四方面，本申请一实施例提出了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例的方法。

附图说明

图1所示为根据本申请针对应用卡顿的处理方法一实施例的流程图；

图2所示为根据本申请针对应用卡顿的处理方法一应用场景的线程结构示意图；

图3所示为根据本申请针对应用卡顿的处理方法一实施例的部分流程图；

图4所示为根据本申请针对应用卡顿的处理方法一实施例的部分流程图；

图5所示为根据本申请针对应用卡顿的处理方法一实施例的流程图；

图6所示为根据本申请针对应用卡顿的处理装置一实施例的结构图；

图7所示为根据本申请针对应用卡顿的处理装置一实施例的结构图；

图8为根据本申请电子设备一实施例的设备结构示意图；

图9为根据本申请一实施例的电子设备的软件结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。

针对应用卡顿的问题，本申请一实施例提出了一种针对应用卡顿的处理方法。为了提出本申请实施例的方法，发明人首先分析应用卡顿出现的应用场景。在实际应用场景中，在硬件设备上安装有操作系统(例如，安卓(Android)系统)，在操作系统中加载有运行在操作系统的系统框架下的应用软件。导致应用软件运行卡顿的主要原因包括计算机硬件处理性能无法满足应用需求、和/或计算机硬件错误、和/或系统框架设计缺陷、和/或软件设计缺陷、和/或输入数据错误等因素，如果要从根本上解决应用卡顿的问题，就需要实际分析应用卡顿的原因，并有针对性的解决导致应用卡顿的因素。由于应用种类架构的多种多样，不同的系统框架设计、硬件环境之间的区别也多种多样，这就导致分析应用卡顿原因存在很大的实现难度。

进一步的，针对计算机硬件处理性能无法满足应用需求的场景，一种可行的方案是应用主进程(UI-Thread)线程减负。此方案需要对软件代码进行优化调整，具体实现方式依赖应用开发者的能力和意愿，从系统框架角度没有可靠的管控方案。并且，实际情况是应用的业务都在增加，对资源的需求是越来越大的。某些特殊场景，甚至超过了系统资源的供给量。

进一步的，针对计算机硬件处理性能无法满足应用需求的场景，一种可行的方案是提高系统资源供给(例如，对前台应用使用大核高频处理器、在进行应用数据处理时提高处理器频率、对应用的输入输出操作进行接口优先供给)。但是，应用资源的需求不能量化，就不能精细化的供给。系统侧也不能一直高水平的资源供给，会导致高功耗问题。随机突发高负载必然导致处理不及时。并且，一些任务，在特殊环境或者场景下才会特别耗时，资源供给无法解决。

基于上述分析，在本申请一实施例中，从提高用户体验的角度入手，并不是通过消除导致应用卡顿的因素来解决应用卡顿，而是通过降低应用卡顿对用户操作的影响来提升用户的操作感观，提升用户体验。

具体的，在实际应用场景中，在一般的应用卡顿状态中，卡顿是由当前正在处理的事件，或者说，正在处理的应用消息(Message，msg)，的处理时间过长(或者处理进程停滞)而造成的。在应用处理当前正在处理的事件的过程中，在事件处理完毕前是无法向用户反馈信息的。因此，应用卡顿的外在表现主要为应用反馈信息的延时拉长、应用暂停信息反馈、应用对输入操作不生成对应的信息反馈(应用无响应)等。

应用卡顿对用户操作的操作感观影响主要体现在会使用户明显感觉到当前应用陷入迟滞状态、进行操作后长时间没有信息回应、应用好似停止了运行。也就是说，令用户产生了明显的等待感。如果能够确保用户不会产生等待的感觉，就能够大大提高用户体验。

为了确保用户不会产生等待的感觉，可行的方案是确保应用能够始终及时的向用户反馈信息。具体的，一种可行的方案是监控应用的UI-Thread，当出现应用卡顿时，由系统框架弹出提示信息，提示用户对应用执行管理操作；和/或，由系统框架提示应用，其自身处理进程发生卡顿，需要解决。例如，在针对ANR的一种解决方案中，当应用的UI-Thread中，因为繁忙导致输入消息(InputMsg)没有及时处理(例如，输出消息处理等待时间>5S)时，系统会弹出“应用无响应”。与此同时，系统会向应用发送中断信息，指示应用处理当前的ANR或提示用户处理ANR。例如，给用户提示当前应用ANR，向用户确认是否关闭/重启当前应用。

然而，上述方案虽然在出现应用卡顿时可以对用户进行消息反馈，避免应用卡顿时间过长，或是应用陷入无限期的ANR。但是，基于上述方案，在向用户反馈信息时，应用卡顿的情况已经发生并且已能够被用户感知，其并不能有效缓解应用卡顿对用户体验的负面影响。进一步的，基于上述方案，在发生应用卡顿时，系统只是提醒应用进行针对卡顿的处理，其具体的处理方式依赖应用开发者对应用逻辑架构的具体设置。例如，给阻塞(wait/sleep)的线程发中断，系统只会给wiat或者sleep的代码所在的函数，发一个中断异常(InterruptExption)。接下来怎么执行，依赖应用开发者的想法。由于在很多应用架构中，应用开发者并没有设置完善的应用卡顿解决方案(例如，只是简单的设置了利用应用重启的方式解决卡顿)，因此，基于上述方案，应用卡顿对用户体验所带来的负面影响并未改善，并未实现对用户操作体验的提升。

基于上述分析，本申请中，当新加入应用主线程的事件处理队列的事件为需要被优先响应(例如，会向用户反馈信息的事件(消息))时，在当前处理的事件(消息)对新加入的事件产生可被感知的迟滞之前就进行事件处理顺序调整，暂停当前事件的处理，优先处理新加入的事件，从而尽可能的确保及时的向用户反馈信息，避免用户产生等待的感觉，从而提高用户体验。

进一步的，考虑到在出现应用卡顿时，当前处理的事件(排在当前事件处理队列第一位的事件)即是造成应用卡顿的直接原因。因此，在本申请一实施例中，在需要优先处理新加入的事件的场景中，当应用卡顿时，当前处理的事件(排在当前事件处理队列第一位的事件)即为阻塞事件，在优先处理新加入的事件的同时延后对阻塞事件的处理或者取消对阻塞事件的处理。进一步的，在取消对阻塞事件的处理后，还可以根据实际应用场景需求重新发起阻塞事件或是重置阻塞事件的输入参数后再发起阻塞事件。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1所示为根据本申请针对应用卡顿的处理方法一实施例的流程图。在本申请一实施例中，如图1所示，针对应用卡顿的处理方法包括：

步骤110，监控应用主线程的事件处理队列；

步骤111，判断事件处理队列中的新加入事件是否需要被优先响应；

当新加入事件不需要被优先响应时，跳转回步骤110继续监控；

步骤120，当新加入事件需要被优先响应时，计算新加入事件在事件处理队列中的等待时间；

步骤121，判断等待时间是否超过预设时间阈值；当等待时间未超过预设时间阈值时，跳转回步骤110继续监控；

步骤130，当等待时间超过预设时间阈值时，收回应用主线程的代码执行权；

步骤140，当应用主线程的代码执行权被收回后，重新排列事件处理队列；

步骤150，恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

进一步的，事件处理队列中当前正在处理的事件即为导致等待时间超过预设时间阈值的事件。在等待时间超过预设时间阈值时，事件处理队列中正在进行处理的事件为排在第一位的事件，因此，在事件处理队列被重排前，事件处理队列中排在第一位的事件即为阻塞事件。即，阻塞事件为事件处理队列被重排前，排在第一位且被主线程执行的事件。

具体的，在步骤140中，为了确保新加入事件被优先响应，将新加入事件排在重排后的事件处理队列的第一位；并且，将事件处理队列中的阻塞事件移除或后移阻塞事件的排位。根据图1所示的方法流程，可以通过重排应用主线程的事件处理队列，优先执行需要优先响应的事件，从而避免由于事件处理时间过长而导致用户产生等待感，进而大大提高了用户体验。

进一步的，在具体实施过程中，图1所示的各个步骤可以包含多种不同的实现方式。技术人员可以根据实际应用需求采用适合的实现方式。

具体的，在步骤110的一种实现方式中，通过构建独立于应用主线程的子线程来实现对应用主线程的事件处理队列进行监控。具体的，在步骤110的一种实现方式中，步骤110包括：构建监控子线程；使用构建的监控子线程监控应用主线程的事件处理队列。通过构建子线程来实现监控操作，可以避免监控操作影响到主线程的正常运行，从而大大提高系统运行的稳定性。

具体的，在实际应用场景中，当某一事件会向用户反馈信息时，该事件的处理被迟滞后就会直接导致向用户反馈信息的行为被迟滞，这就很容易令用户产生等待感。因此，在步骤111的一种实现方式中，步骤111的判定逻辑为，需要被优先响应的事件包括但不限于会向用户反馈信息的事件。例如，在根据本申请一实施例的应用场景中，将响应被迟滞后会导致用户产生等待感的事件(例如，会向用户反馈信息的预定时处理事件和/或周期处理事件)设置为需要优先响应。这样，会使得用户感觉应用始终在正常运行，使得用户感觉应用对用户的信息回馈并没有受到任何干扰，从而避免用户产生等待感。进一步的，在实际应用场景中，当用户执行了输入操作时，如果输入操作没有得到及时响应，那么用户很容易产生等待感，从而降低用户体验。因此，在步骤111的另一种实现方式中，步骤111的判定逻辑为，将用户输入操作对应的用户输入事件(InputMsg)设置为需要被优先响应的事件。具体的，在步骤111的一种实现方式中，在步骤111中：判断新加入事件是否为用户输入事件；当新加入事件为用户输入事件时，判定新加入事件需要被优先响应。在本实现方式中，通过将用户输入事件设置为需要被优先响应的事件，细化了优先响应事件的判定条件，从而使得优先响应事件的判定更为简单易行，降低了方案的实施难度。

以一具体的应用场景为例，图2所示为根据本申请针对应用卡顿的处理方法一应用场景的线程结构示意图。在本申请一实施例中，如图2所示，线程200为应用主线程(UI-Thread)，虚线框201为线程200当前需要执行的事件处理队列，事件处理队列201按照事件21、事件22、事件23的顺序排列。线程210为独立于线程200的监控子线程(Probe Thread)，其用于监控线程200的事件处理队列201。

在主线程运行过程中，新的事件会不断地加入事件处理队列201，最新加入的事件会排在事件处理队列201的末尾。例如，新的事件24被加入事件处理队列201，其排在事件23之后，新加入事件24后，事件处理队列201中的事件排序为事件21、事件22、事件23、事件24。

当线程210监控到新的事件(事件24)加入到事件处理队列201中时，判断事件24是否为用户输入事件(InputMsg)，如果事件24为用户输入事件(InputMsg)，则事件24需要被优先响应。

当事件24为用户输入事件(InputMsg)时，计算事件24在事件处理队列201中的等待时间；判断等待时间是否超过预设时间阈值；当前正在处理的事件处理队列201中第一位的事件21一直没有处理完毕从而导致等待时间超过预设时间阈值时，即说明当前正在处理的事件处理队列201中第一位的事件21为阻塞事件。此时收回应用主线程200的代码执行权。

当应用主线程200的代码执行权被收回后，将事件处理队列201重排为事件处理队列202。事件处理队列202中，将事件24(优先响应事件)排在第一位，将事件21(阻塞事件)后移。

事件处理队列201重排结束后，恢复应用主线程200的代码执行权，令应用主线程200执行事件处理队列202。进一步的，在实际应用场景中，某些事件的处理是需要依赖其他事件的(例如，某些事件执行时需要将其他事件的输出量作为自身的输入量)，也就是说，在一个事件所依赖的事件处理完毕之前，该事件是无法被顺利处理的。基于此，在步骤111的一种实现方式中，需要确定处理新加入事件是否需要依赖其他事件，以此来避免后续新加入事件排到其所依赖的事件之前处理而导致事件处理异常的情况的发生。在进行优先响应判定时加入了依赖关系的参考，可以避免由事件处理顺序以依赖关系不匹配而导致的事件处理错误，从而大大提高系统运行的稳定性，增强本方案的实用性以及可行性。

具体的，图3所示为根据本申请针对应用卡顿的处理方法一实施例的部分流程图。在步骤111的一种实现方式中，步骤111可以包括如图3所示的步骤301～303。执行如下步骤以实现图1所示实施例的步骤110、111以及120：

步骤300，监控应用主线程的事件处理队列；

步骤301，判断事件处理队列中是否存在新加入事件；

当不存在新加入事件时，返回步骤300继续监控；

步骤302，当存在新加入事件时，判断新加入事件是否依赖事件处理队列中的一个或多个其他事件；

当新加入事件依赖事件处理队列中的一个或多个其他事件时，判定新加入事件不需要优先响应，返回步骤300继续监控；

步骤303，当新加入事件不依赖事件处理队列中的其他事件时，判断新加入事件是否为用户输入事件；

当新加入事件不为用户输入事件时，判定新加入事件不需要优先响应，返回步骤300继续监控；

当新加入事件为用户输入事件时，执行步骤310，判定新加入事件需要优先响应，开始计算新加入事件的等待时间。

具体的，在步骤302的一种实现方式中，当新加入事件的运行需要引入事件处理队列中的某个事件的输出，或者，事件处理队列中的某个事件的输出变化会对新加入事件的运行产生影响时，判定新加入事件依赖该事件。

具体的，在步骤302的一种实现方式中，遍历执行新加入事件所需的所有输入量，当执行新加入事件所需的输入量中的某个输入量为事件处理队列中的某个事件的输出量时，判定新加入事件依赖该事件。进一步的，遍历新加入事件运行时所依托的运行环境参数变量，当事件处理队列中的某个事件的运行结果会影响到新加入事件运行时所依托的运行环境参数变量时，判定新加入事件依赖该事件。

例如，事件处理队列中存在事件A，事件A的运行结果是对屏幕截图并保存截图文件为图片A，新加入事件为向指定目标用户发送图片A。新加入事件运行时必须调用事件A的运行结果(图片A)，因此可以判定新加入事件依赖事件A。

进一步的，在本申请一实施例中，图1所示实施例中步骤121所采用的预设时间阈值的大小可以在具体实现时根据装置性能和/实现需求等自行设定，本实施例对预设时间阈值的大小不作限定，举例来说，根据用户的感知习惯设置预设时间阈值，以用户不会明显有等待感的事件长度为预设时间阈值。例如，将预设时间阈值设定为1秒。

进一步的，在本申请一实施例中，在具体实现图1所示实施例步骤140的过程中，重新排列事件处理队列时，对阻塞事件是采用后移方案还是移除方案，是由具体实现时根据装置性能和/实现需求等决定的。本实施例对重新排列事件处理队列的过程中针对阻塞事件所采用的方案不做明确限定。举例来说，根据阻塞事件的具体内容来确定针对阻塞事件所采用的方案，例如，当阻塞事件为针对用户的关键信息反馈和/或阻塞事件被一个或多个后续事件依赖时，在重新排列事件处理队列的过程中后移阻塞事件；当阻塞事件为独立非关键事件(例如，自动检索升级文件)时，在重新排列事件处理队列的过程中移除阻塞事件，待后续重置阻塞事件的输入参数后再重新发起阻塞事件。

进一步的，为确保重排后的事件处理队列中的事件可以顺利的被处理，在步骤140的一种实现方式中，重新排列事件处理队列时，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变。即，在重排后的事件处理队列中，除阻塞事件以及新加入事件以外的其他事件相互间的排序与重排前是一致的。这样就可以确保除阻塞事件以及新加入事件以外的其他事件相互间存在依赖关系时，事件处理队列的重排不会影响到事件的顺利处理。

进一步的，为确保重排后的事件处理队列中的事件可以顺利的被处理，在步骤140的一种实现方式中，重新排列事件处理队列时，采用后移阻塞事件的排位的方案，并且，根据阻塞事件与其他事件间的依赖关系来确定后移阻塞事件的具体实施细节。

具体的，在步骤140的一种实现方式中，在后移阻塞事件的排位的过程中：

判断是否存在依赖阻塞事件的事件；

当存在依赖阻塞事件的事件时，在重排后的事件处理队列中，将阻塞事件排在依赖该阻塞事件的事件之前；

当不存在依赖所述阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的末尾。

进一步，为简化事件处理队列重排操作，在步骤140的一种实现方式中，在后移阻塞事件的排位的过程中，将阻塞事件排在重排后的事件处理队列的第二位。例如，如图2所示，将事件处理队列201重排为事件处理队列202。将新加入事件24排在第一位，将阻塞事件21排在第二位，无论事件22、事件23是否依赖阻塞事件21，事件处理队列202都可以顺利处理。依照步骤140的上述实现方式，将阻塞事件排在重排后的事件处理队列的第二位，不需要考虑事件处理队列中是否存在依赖阻塞事件的事件，因此也就取消了步骤140中的依赖判断步骤，从而大大降低数据处理量。

进一步的，在步骤140的一种实现方式中，将后移阻塞事件的排位以及移除阻塞事件的方案结合。具体的，在初期延后阻塞事件的处理(将事件处理队列中阻塞事件的排位后移)，为阻塞事件保留处理机会，从而避免某些处理耗时较长的事件被无限制的强行关闭；当阻塞事件多次导致事件处理队列重排(此时阻塞事件很有可能是一个无法顺利处理的事件)时，放弃处理阻塞事件(将阻塞事件从事件处理队列中移除)，从而避免陷入不断延后阻塞事件的处理的死循环中。

具体的，在步骤140的一种实现方式中，记录同一阻塞事件导致的事件处理队列重排的次数，在移除阻塞事件或后移阻塞事件的排位的过程中：

判断阻塞事件导致的重新排列事件处理队列的次数是否大于预设次数阈值；

当重新排列事件处理队列的次数大于预设次数阈值时，从事件处理队列中移除阻塞事件和/或输出提示信息；例如，当重新排列事件处理队列的次数大于预设次数阈值时，从事件处理队列中移除阻塞事件；或者，当重新排列事件处理队列的次数大于预设次数阈值时，从事件处理队列中移除阻塞事件并输出提示信息，提示用户阻塞事件已被移除；或者，当重新排列事件处理队列的次数大于预设次数阈值时，输出提示信息，由用户决定是否要从事件处理队列中移除阻塞事件；

当重排次数小于或等于预设次数阈值时，后移阻塞事件在事件处理队列中的排位。

具体的，在本申请一实施例中，在上述步骤140的实现方式中，进行重排次数判定所采用的预设次数阈值的大小可以在具体实现时根据装置性能和/实现需求等自行设定，本实施例对预设次数阈值的大小不作限定，举例来说，将预设次数阈值设定为3次。

具体的，图4所示为根据本申请针对应用卡顿的处理方法一实施例的部分流程图。在步骤140的一种实现方式中，如图4所示，步骤140包括：

步骤441，将新加入事件排在重排后的事件处理队列的第一位；

步骤442，判断事件处理队列中是否存在依赖阻塞事件的事件；

步骤443，如果存在，将阻塞事件排在重排后的事件处理队列的第二位；

步骤444，如果不存在，判断阻塞事件导致的重新排列事件处理队列的次数是否大于3；

步骤445，如果阻塞事件导致的重新排列事件处理队列的次数小于等于3，将阻塞事件排在重排后的事件处理队列的末位；

步骤446，如果阻塞事件导致的重新排列事件处理队列的次数大于3，将阻塞事件从事件处理队列移除；

步骤447，输出提示信息，通知用户阻塞事件已被移除。

进一步的，在步骤140的一种实现方式中，基于中断响应实现对主线程的代码执行权的收回。具体的，在收回应用主线程的代码执行权的过程中，向应用主线程发中断消息，通过应用主线程中断消息的响应，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。由于中断响应是软件系统中常见的响应设置。因此通过中断方式来回收主线程的代码执行权不需要进行额外的响应配置，可以大大简化回收主线程的代码执行权的执行步骤，减少实现步骤140所需要录入的代码量，降低步骤140的实现难度。

具体的，以Android系统应用场景为例，在一实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层(Application Framework)，安卓运行时(Android runtime，ART)和系统库，以及内核层。

应用程序层可以包括一系列应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

在根据本申请一实施例的应用场景中，修改安卓运行时(Android runtime，ART)的虚拟机的中断发送流程，把中断直接重定向到安卓应用框架层(ApplicationFramework，App FWK)的消息分配函数(loop)，安卓系统侧来控制接下来的执行代码。即在实现步骤130时，通过中断，强制收回线程的代码执行权，交给系统侧重新分配。

具体的，在本申请一实施例中，单独启动一个监控线程(Probe线程)，监控应用主线程(UI-Thread)的输入事件(InputMsg)处理。如果应用主线程里面的输入事件处理被延迟(超过1S)，则给应用主线程发中断(Interrupt)。应用主线程(UI-Thread)响应中断的时候，在ART虚拟机中断处理流程中，修改调用栈，让程序计数器指针(Program Counter，以下简称PC)(程序计数器用于存放下一条将要执行的指令地址)跳转到安卓应用框架层消息控制的地方(loop函数)。基于loop函数实现对应用主线程的事件处理队列的重排。重排完成后，中断结束，恢复应用主线程的代码执行权。

根据本申请一实施例的方法，在系统侧实现针对应用主线程的事件监控、代码执行权收回/恢复以及事件处理队列的重排，在不更改应用自身的逻辑框架的基础上，就实现了针对应用卡顿的处理，在不增加开发者工作量、复杂化应用逻辑架构的前提下大大提高了应用的用户体验。并且，根据本申请一实施例的方法，由于不需要开发者更改应用的逻辑框架，因此操作简单，具有很高的实用价值。

具体的，图5所示为根据本申请针对应用卡顿的处理方法一实施例的流程图。在本申请一实施例中，如图5所示，针对应用卡顿的处理方法包括：

步骤500，启动监控子线程；

步骤501，使用监控子线程监控应用主线程；

步骤510，判断应用主线程的事件处理队列中是否新加入了用户输入事件；

如果没有，返回步骤501；

如果事件处理队列中新加入了用户输入事件，执行步骤520，计算用户输入事件的处理等待时间；

步骤521，判断用户输入事件的处理等待时间是否超过1秒；

如果用户输入事件的处理等待时间小于等于1秒，执行步骤522，判断用户输入事件是否被处理；

如果用户输入事件被处理，返回步骤501；

如果用户输入事件未被处理，返回步骤520；

如果用户输入事件的处理等待时间大于1秒，执行步骤530，向应用主线程发中断，通过应用主线程的中断响应，收回应用主线程的代码执行权，将代码执行权交予系统侧重新分配；

步骤540，当应用主线程响应中断时，代码执行定向到系统框架的loop函数，基于loop函数重排应用主线程的事件处理队列；

步骤550，事件处理队列重排完毕后，恢复应用主线程的代码执行权。

可以理解的是，上述实施例中的部分或全部步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。

进一步的，基于本申请实施例所提出的方法，在本申请一实施例中还提出了一种针对应用卡顿的处理装置。具体的，图6所示为根据本申请针对应用卡顿的处理装置一实施例的结构图。在本申请一实施例中，如图6所示，针对应用卡顿的处理装置600包括：

事件监控模块610，其用于监控应用主线程的事件处理队列，判断事件处理队列中的新加入事件是否需要被优先响应；

等待时间判断模块620，其用于当新加入事件需要被优先响应时，计算新加入事件在事件处理队列中的等待时间，判断等待时间是否超过预设时间阈值；

执行权收回模块630，其用于当等待时间超过预设时间阈值时，收回应用主线程的代码执行权；

队列重排模块640，其用于当应用主线程的代码执行权被收回后，重新排列事件处理队列，包括：

前移新加入事件的排位，将新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，阻塞事件为事件处理队列被重排前，排在第一位且被主线程执行的事件；

执行权恢复模块650，其用于在队列重排模块640完成事件处理队列的重排后，恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

使用图6所示的处理装置，可以实现对应用主线程的事件处理队列的监控并在合适的时机进行事件处理队列重排，从而使得应用主线程优先执行需要优先响应的事件，避免由于事件处理时间过长而导致用户产生等待感，进而大大提高了用户体验。

图6所示的本申请一实施例提供的装置可用于执行本申请图1所示实施例的方法实施例的技术方案，其实现原理和技术效果可以进一步参考方法实施例中的相关描述。

进一步的，在本申请一实施例中，事件监控模块610包括：

优先响应判定单元，其用于判断新加入事件是否为用户输入事件，当新加入事件为用户输入事件时，判定新加入事件需要被优先响应。

进一步的，在本申请一实施例中，事件监控模块610包括：

监控单元，其用于构建监控子线程，使用监控子线程监控应用主线程的事件处理队列。

进一步的，在本申请一实施例中，事件监控模块610包括：

第一依赖关系判定单元，其用于判断新加入事件是否依赖其他事件；

优先响应判定单元，其用于当新加入事件不依赖其他事件时，判断事件处理队列中的新加入事件是否需要被优先响应。

进一步的，在本申请一实施例中，执行权收回模块630包括：

中断单元，其用于向应用主线程发中断消息，在应用主线程响应中断消息的过程中，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。

进一步的，在本申请一实施例中，队列重排模块640还用于在重新排列事件处理队列的过程中，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变。

进一步的，在本申请一实施例中，队列重排模块640包括：

第二依赖关系判定单元，其用于判断是否存在依赖阻塞事件的事件；

移位单元，其用于当存在依赖阻塞事件的事件时，在重排后的事件处理队列中，将阻塞事件排在依赖该阻塞事件的事件之前。

进一步的，在本申请一实施例中，队列重排模块640中的移位单元还用于：

当不存在依赖阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的末尾。

进一步的，在本申请一实施例中，队列重排模块640包括：

移位单元，其用于将阻塞事件排在重排后的事件处理队列的第二位。

进一步的，在本申请一实施例中，队列重排模块640包括：

重排次数判定单元，其用于判断阻塞事件导致的事件处理队列的重排次数是否大于预设次数阈值；

移位单元，其用于当重排次数大于预设次数阈值时，移除阻塞事件和/或输出提示信息。

具体的，图7所示为根据本申请针对应用卡顿的处理装置一实施例的结构图。在本申请一实施例中，如图7所示，针对应用卡顿的处理装置700包括事件监控模块710、等待时间判断模块720、执行权收回模块730、队列重排模块740以及执行权恢复模块750。

事件监控模块710包括监控单元711、依赖关系判定单元712、优先响应判定单元713。监控单元711用于构建监控子线程，使用监控子线程监控应用主线程的事件处理队列。当监控单元711监控到有事件新加入到事件处理队列中时，依赖关系判定单元712判断新加入事件是否依赖事件处理队列中的其他事件。当新加入事件不依赖事件处理队列中的其他事件时，优先响应判定单元713判断新加入事件是否为用户输入事件。当新加入事件为用户输入事件时，新加入事件需要被优先响应。

当新加入事件需要被优先响应时，等待时间判断模块720计算新加入事件在事件处理队列中的等待时间，判断等待时间是否超过1秒；

执行权收回模块730包括中断单元731。中断单元731用于在等待时间超过1秒时，通过系统框架向应用主线程发中断消息，在应用主线程响应中断消息的过程中，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。

队列重排模块740包括依赖关系判定单元741、重排次数判定单元742以及移位单元743。依赖关系判定单元741用于在应用主线程的代码执行权被收回后，判断是否存在依赖阻塞事件的事件。重排次数判定单元742用于当不存在依赖阻塞事件的事件时，判断阻塞事件导致的事件处理队列的重排次数是否大于3次。

移位单元743用于在应用主线程的代码执行权被收回后，重排事件处理队列，其中：

将新加入事件排在重排后的事件处理队列的第一位，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变；

当存在依赖阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的第二位；

当不存在依赖阻塞事件的事件、并且阻塞事件导致的事件处理队列的重排次数小于或者等于3次时，将阻塞事件排在重排后的事件处理队列的末尾；

当不存在依赖阻塞事件的事件、并且阻塞事件导致的事件处理队列的重排次数大于3次时，从事件处理队列中移除阻塞事件和/或输出提示信息。

执行权恢复模块750用于在移位单元743完成事件处理队列重排后恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

进一步的，在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(FieldProgrammable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字装置“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera HardwareDescription Language)、Confluence、CUPL(Cornell University ProgrammingLanguage)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

进一步的，在当前的技术应用场景中，电子设备的控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、MicrochipPIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

因此，在本申请实施例的描述中，为了描述的方便，描述装置时以功能分为各种模块/单元分别描述，各个模块/单元的划分仅仅是一种逻辑功能的划分，在实施本申请实施例时可以把各模块/单元的功能在同一个或多个软件和/或硬件中实现。

具体的，本申请实施例所提出的装置在实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块以软件通过处理元件调用的形式实现，部分模块通过硬件的形式实现。例如，检测模块可以为单独设立的处理元件，也可以集成在电子设备的某一个芯片中实现。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，ASIC)，或，一个或多个微处理器(Digital Singnal Processor，DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，FPGA)等。再如，这些模块可以集成在一起，以片上装置(System-On-a-Chip，SOC)的形式实现。

本申请一实施例还提出了一种电子设备，电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行如下步骤：

监控应用主线程的事件处理队列，判断事件处理队列中的新加入事件是否需要被优先响应；

当新加入事件需要被优先响应时，计算新加入事件在事件处理队列中的等待时间，判断等待时间是否超过预设时间阈值；

当等待时间超过预设时间阈值时，收回应用主线程的代码执行权；

在应用主线程的代码执行权被收回后，重新排列事件处理队列，包括：

前移新加入事件的排位，将新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，阻塞事件为所述事件处理队列被重排前，排在第一位且被主线程执行的事件；

在事件处理队列被重排完毕后，恢复应用主线程的代码执行权，令应用主线程执行重排后的事件处理队列。

一种可能的实现方式中，指令被设备执行时，使得设备执行判断事件处理队列中的新加入事件是否需要被优先响应的步骤，包括：

判断新加入事件是否为用户输入事件；

当新加入事件为用户输入事件时，判定新加入事件需要被优先响应。

一种可能的实现方式中，指令被设备执行时，使得设备执行监控应用主线程的事件处理队列的步骤，包括：

构建监控子线程；

使用监控子线程监控应用主线程的事件处理队列。

一种可能的实现方式中，指令被设备执行时，使得设备执行判断事件处理队列中的新加入事件是否需要被优先响应的步骤之前，还包括：

判断新加入事件是否依赖其他事件；

当新加入事件不依赖其他事件时，判断事件处理队列中的新加入事件是否需要被优先响应。

一种可能的实现方式中，指令被设备执行时，使得设备执行收回应用主线程的代码执行权的步骤，包括，向应用主线程发中断消息，在应用主线程响应中断消息的过程中，收回应用主线程的代码执行权，将代码执行权交予系统框架重新分配。

一种可能的实现方式中，指令被设备执行时，使得设备执行重新排列事件处理队列的步骤中，保持除阻塞事件以及新加入事件以外的其他事件相互间的排序不变。

一种可能的实现方式中，指令被设备执行时，使得设备执行后移阻塞事件的排位的步骤，包括：

判断是否存在依赖阻塞事件的事件；

当存在依赖阻塞事件的事件时，在重排后的事件处理队列中，将阻塞事件排在依赖该阻塞事件的事件之前。

一种可能的实现方式中，指令被设备执行时，使得设备执行判断是否存在依赖阻塞事件的事件的步骤之后，还包括：

当不存在依赖阻塞事件的事件时，将阻塞事件排在重排后的事件处理队列的末尾。

一种可能的实现方式中，指令被设备执行时，使得设备执行后移阻塞事件的排位的步骤，包括：将阻塞事件排在重排后的事件处理队列的第二位。

一种可能的实现方式中，指令被设备执行时，使得设备执行移除阻塞事件的步骤，包括：

判断阻塞事件导致的重新排列事件处理队列的次数是否大于预设次数阈值；

当重新排列事件处理队列的次数大于预设次数阈值时，移除阻塞事件和/或输出提示信息。

本申请实施例阐明的电子设备、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，例如可以为台式电脑、笔记本电脑、平板电脑、手机、个人数字助理、媒体播放器、导航设备、游戏控制台、可穿戴设备或者这些设备中的任何设备的组合。具体的，在本申请一实施例中，上述电子设备可以为是终端设备，例如，移动终端(手机、平板电脑、笔记本电脑)、本地终端(个人/工业电脑)、云端服务器等设备；也可以是内置于上述终端设备的电路设备。

进一步的，在本申请一实施例中，电子设备的处理器可以是片上装置SOC，该处理器中可以包括中央处理器(Central Processing Unit，CPU)、DSP、微控制器、应用处理器(Application Processor，AP)、图形处理器(Graphics Processing Unit，GPU)、嵌入式神经网络处理器(Neural-network Process Units，NPU)、图像信号处理器(Image SignalProcessing，ISP)、调制解调处理器、视频编解码器、基带处理器、脉冲宽度调制(Pulsewidth modulation，PWM)控制器，还可以进一步包括其他类型的处理器。

进一步的，在本申请一实施例中，处理器还可包括必要的硬件加速器或逻辑处理硬件电路，如ASIC，或一个或多个用于控制本申请技术方案程序执行的集成电路等。此外，处理器可以具有操作一个或多个软件程序的功能，软件程序可以存储在存储介质中。

进一步的，在本申请一实施例中，电子设备的存储器包括永久性和非永久性、可移动和非可移动的可以由任何方法或技术来实现信息存储的计算机可读介质。存储器的计算机可读介质存储的信息可以是计算机可读指令、数据结构、程序的模块或其他数据。

用于构造存储器的计算机可读介质例子包括但不限于：只读存储器(Read-OnlyMemory，ROM)、可存储静态信息和指令的其它类型的静态存储设备、随机存取存储器(Random Access Memory，RAM)、电可擦可编程只读存储器(Electrically ErasableProgrammable Read-Only Memory，EEPROM)、相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、快闪记忆体或其他内存技术的记忆体、只读光盘(Compact Disc Read-Only Memory，CD-ROM)、数字多功能光盘(DVD)或其他光学存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质等各种可以存储程序代码的、可以被计算设备访问的介质。

进一步的，在本申请一实施例中，处理器可以和存储器可以合成一个处理装置，更常见的是彼此独立的部件，处理器用于执行存储器中存储的程序代码来实现本申请实施例方法。具体实现时，该存储器也可以集成在处理器中，或者，独立于处理器。

具体的，图8为根据本申请电子设备一实施例的设备结构示意图。在本申请一实施例中，如图8所示，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(Universal Serial Bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(Subscriber Identification Module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，图8所示实施例的结构并不构成对本申请所提出的电子设备的具体限定。在本申请另一些实施例中，根据本申请实施例的电子设备可以包括比图8所示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

具体的，在本申请一实施例中，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括AP、调制解调处理器、GPU、ISP、控制器、视频编解码器、DSP、基带处理器、和/或、NPU等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。处理器110中的控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(Inter-Integrated Circuit，I2C)接口，集成电路内置音频(Inter-Integrated CircuitSound，I2S)接口，脉冲编码调制(Pulse Code Modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(Mobile Industry Processor Interface，MIPI)，通用输入输出(General-PurposeInput/Output，GPIO)接口，用户标识模块(Subscriber Identity Module，SIM)接口，和/或USB接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(Serial Data Line，SDA)和一根串行时钟线(Serail Clock Line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K，充电器，闪光灯，摄像头193等。

I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。

PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。I2S接口和PCM接口都可以用于音频通信。

UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的功能。

MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。MIPI接口包括摄像头串行接口(Camera Srial Interface，CSI)，显示屏串行接口(DisplaySerial Interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现电子设备100的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现电子设备100的显示功能。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

USB接口130是符合USB标准规范的接口。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(Low Noise Amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(WirelessLocal Area Networks，WLAN)(如无线保真(Wireless Fidelity，Wi-Fi)网络)，蓝牙(Bluetooth，BT)，全球导航卫星系统(Global Navigation Satellite System，GNSS)，调频(Frequency Modulation，FM)，近距离无线通信技术(Near Field Communication，NFC)，红外技术(Infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。无线通信技术可以包括全球移动通讯系统(Global System For Mobile Communications，GSM)，通用分组无线服务(General Packet Radio Service，GPRS)，码分多址接入(CodeDivision Multiple Access，CDMA)，宽带码分多址(Wideband Code Division MultipleAccess，WCDMA)，时分码分多址(Time-Division Code Division Multiple Access，TD-SCDMA)，长期演进(Long Term Evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。GNSS可以包括全球卫星定位系统(Global Positioning System，GPS)，全球导航卫星系统(Global Navigation Satellite System，GLONASS)，北斗卫星导航系统(BeidouNavigation Satellite System，BDS)，准天顶卫星系统(Quasi-Zenith SatelliteSystem，QZSS)和/或星基增强系统(Satellite Based Augmentation Systems，SBAS)。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(Liquid Crystal Display，LCD)，有机发光二极管(Organic Light-EmittingDiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(Active-MatrixOrganic Light Emitting Diode的，AMOLED)，柔性发光二极管(Flex Llight-EmittingDiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(Quantum Dot LightEmitting Diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及DSP等实现拍摄功能。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件把光信号转换成电信号，之后将电信号传递给ISP。

ISP用于处理摄像头193反馈的数据，将感光元件发送的电信号转换成数字图像信号。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

DSP用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(Moving Picture Experts Group，MPEG)1，MPEG2，MPEG3，MPEG4等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(Universal Flash Storage，UFS)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备100的各种功能应用以及数据处理。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。

陀螺仪传感器180B可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定电子设备100围绕三个轴(即，x，y和z轴)的角速度。陀螺仪传感器180B可以用于拍摄防抖。

气压传感器180C用于测量气压。

磁传感器180D包括霍尔传感器。电子设备100可以利用磁传感器180D检测翻盖皮套的开合。

加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。当电子设备100静止时可检测出重力的大小及方向。还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

距离传感器180F，用于测量距离。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。电子设备100通过发光二极管向外发射红外光。电子设备100使用光电二极管检测来自附近物体的红外反射光。

环境光传感器180L用于感知环境光亮度。

指纹传感器180H用于采集指纹。

温度传感器180J用于检测温度。

触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

骨传导传感器180M可以获取振动信号。在一些实施例中，骨传导传感器180M可以获取人体声部振动骨块的振动信号。骨传导传感器180M也可以接触人体脉搏，接收血压跳动信号。

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以从SIM卡接口195插入或拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。电子设备100通过SIM卡和网络交互，实现通话以及数据通信等功能。

应理解，图8所示的电子设备100能够实现本申请实施例提供的方法的各个过程。电子设备100中的各个模块的操作和/或功能，分别为了实现上述方法实施例中的相应流程。具体可参见本申请实施例方法实施例中的描述，为避免重复，此处适当省略详细描述。

电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层(Application Framework)，安卓运行时(Android runtime，ART)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。图9为根据本申请一实施例的电子设备的软件结构框图。如图9所示，应用程序层可以包括一系列应用程序包，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图9所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

下面结合捕获拍照场景，示例性说明电子设备100软件以及硬件的工作流程。

当触摸传感器180K接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别该输入事件所对应的控件。以该触摸操作是触摸单击操作，该单击操作所对应的控件为相机应用图标的控件为例，相机应用调用应用框架层的接口，启动相机应用，进而通过调用内核层启动摄像头驱动，通过摄像头193捕获静态图像或视频。

本领域内的技术人员应明白，本申请实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。

在本申请所提供的几个实施例中，任一功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。

具体的，本申请一实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的方法。

本申请一实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的方法。

本申请中的实施例描述是参照根据本申请实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示单独存在A、同时存在A和B、单独存在B的情况。其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a，b，c，a和b，a和c，b和c或a和b和c，其中a，b，c可以是单个，也可以是多个。

本申请实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以意识到，本申请实施例中描述的各单元及算法步骤，能够以电子硬件、计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上，仅为本申请实施例的具体实施方式，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。本申请的保护范围应以权利要求的保护范围为准。

Claims (22)

1.一种针对应用卡顿的处理方法，其特征在于，包括：

监控应用主线程的事件处理队列，判断所述事件处理队列中的新加入事件是否需要被优先响应；

当所述新加入事件需要被优先响应时，计算所述新加入事件在所述事件处理队列中的等待时间，判断所述等待时间是否超过预设时间阈值；

当所述等待时间超过所述预设时间阈值时，收回所述应用主线程的代码执行权；

在所述应用主线程的代码执行权被收回后，重新排列所述事件处理队列，包括：

前移所述新加入事件的排位，将所述新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，所述阻塞事件为所述事件处理队列被重排前，排在第一位且被主线程执行的事件；

在所述事件处理队列被重排完毕后，恢复所述应用主线程的代码执行权，令所述应用主线程执行所述重排后的事件处理队列。

2.根据权利要求1所述的方法，其特征在于，所述判断所述事件处理队列中的新加入事件是否需要被优先响应，包括：

判断所述新加入事件是否为用户输入事件；

当所述新加入事件为用户输入事件时，判定所述新加入事件需要被优先响应。

3.根据权利要求1所述的方法，其特征在于，所述监控应用主线程的事件处理队列，包括：

构建监控子线程；

使用所述监控子线程监控所述应用主线程的事件处理队列。

4.根据权利要求1所述的方法，其特征在于，所述判断所述事件处理队列中的新加入事件是否需要被优先响应之前，还包括：

判断所述新加入事件是否依赖其他事件；

当所述新加入事件不依赖其他事件时，判断所述事件处理队列中的新加入事件是否需要被优先响应。

5.根据权利要求1所述的方法，其特征在于，所述收回所述应用主线程的代码执行权，包括：

向所述应用主线程发中断消息，在所述应用主线程响应所述中断消息的过程中，收回所述应用主线程的代码执行权，将所述代码执行权交予系统框架重新分配。

6.根据权利要求1所述的方法，其特征在于，所述重新排列所述事件处理队列，还包括：

在所述重新排列所述事件处理队列的过程中，保持除所述阻塞事件以及所述新加入事件以外的其他事件相互间的排序不变。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述后移阻塞事件的排位，包括：

判断是否存在依赖所述阻塞事件的事件；

当存在依赖所述阻塞事件的事件时，在所述重排后的事件处理队列中，将所述阻塞事件排在依赖所述阻塞事件的事件之前。

8.根据权利要求7所述的方法，其特征在于，所述判断是否存在依赖所述阻塞事件的事件之后，还包括：

当不存在依赖所述阻塞事件的事件时，将所述阻塞事件排在所述重排后的事件处理队列的末尾。

9.根据权利要求1所述的方法，其特征在于，所述后移阻塞事件的排位，包括：将所述阻塞事件排在所述重排后的事件处理队列的第二位。

10.根据权利要求1所述的方法，其特征在于，所述移除阻塞事件，包括：

判断所述阻塞事件导致的重新排列所述事件处理队列的次数是否大于预设次数阈值；

当所述重新排列所述事件处理队列的次数大于预设次数阈值时，移除所述阻塞事件和/或输出提示信息。

11.一种针对应用卡顿的处理装置，其特征在于，包括：

事件监控模块，其用于监控应用主线程的事件处理队列，判断所述事件处理队列中的新加入事件是否需要被优先响应；

等待时间判断模块，其用于当所述新加入事件需要被优先响应时，计算所述新加入事件在所述事件处理队列中的等待时间，判断所述等待时间是否超过预设时间阈值；

执行权收回模块，其用于当所述等待时间超过所述预设时间阈值时，收回所述应用主线程的代码执行权；

队列重排模块，其用于在所述应用主线程的代码执行权被收回后，重新排列所述事件处理队列，包括：

前移所述新加入事件的排位，将所述新加入事件排在重排后的事件处理队列的第一位；

移除阻塞事件或后移阻塞事件的排位，其中，所述阻塞事件为所述事件处理队列被重排前，排在第一位且被主线程执行的事件；

执行权恢复模块，其用于在所述事件处理队列被重排完毕后，恢复所述应用主线程的代码执行权，令所述应用主线程执行重排后的事件处理队列。

12.根据权利要求11所述的装置，其特征在于，所述事件监控模块包括：

优先响应判定单元，其用于判断所述新加入事件是否为用户输入事件，当所述新加入事件为用户输入事件时，判定所述新加入事件需要被优先响应。

13.根据权利要求11所述的装置，其特征在于，所述事件监控模块包括：

监控单元，其用于构建监控子线程，使用所述监控子线程监控所述应用主线程的事件处理队列。

14.根据权利要求11所述的装置，其特征在于，所述事件监控模块包括：

第一依赖关系判定单元，其用于判断所述新加入事件是否依赖其他事件；

优先响应判定单元，其用于当所述新加入事件不依赖其他事件时，判断所述事件处理队列中的新加入事件是否需要被优先响应。

15.根据权利要求11所述的装置，其特征在于，所述执行权收回模块包括：

中断单元，其用于向所述应用主线程发中断消息，在所述应用主线程响应所述中断消息的过程中，收回所述应用主线程的代码执行权，将所述代码执行权交予系统框架重新分配。

16.根据权利要求11所述的装置，其特征在于，所述队列重排模块还用于在重新排列所述事件处理队列的过程中，保持除所述阻塞事件以及所述新加入事件以外的其他事件相互间的排序不变。

17.根据权利要求11-16中任一项所述的装置，其特征在于，所述队列重排模块包括：

第二依赖关系判定单元，其用于判断是否存在依赖所述阻塞事件的事件；

移位单元，其用于当存在依赖所述阻塞事件的事件时，在所述重排后的事件处理队列中，将所述阻塞事件排在依赖所述阻塞事件的事件之前。

18.根据权利要求17所述的装置，其特征在于，所述移位单元还用于：

当不存在依赖所述阻塞事件的事件时，将所述阻塞事件排在所述重排后的事件处理队列的末尾。

19.根据权利要求11所述的装置，其特征在于，所述队列重排模块包括：

移位单元，其用于将所述阻塞事件排在所述重排后的事件处理队列的第二位。

20.根据权利要求11所述的装置，其特征在于，所述队列重排模块包括：

重排次数判定单元，其用于判断所述阻塞事件导致的重新排列所述事件处理队列的次数是否大于预设次数阈值；

移位单元，其用于当所述重新排列所述事件处理队列的次数大于预设次数阈值时，移除所述阻塞事件和/或输出提示信息。

21.一种电子设备，其特征在于，所述电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述电子设备执行如权利要求1-10中任一项所述的方法步骤。

22.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1-10任一项所述的方法。

Images