CN109165114A - 应用程序无响应的处理方法、装置、存储介质及智能终端 - Google Patents

Abstract

本申请实施例公开了一种应用程序无响应的处理方法、装置、存储介质及智能终端。该方法包括监测应用程序的广播处理过程；在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。通过采用本申请实施例的技术方案，在广播ANR问题发生时，对消息队列中的目标广播消息进行收集，以供程序开发人员获知应用程序的广播处理情况，便于定位应用程序的广播ANR问题，为优化应用程序的代码提供依据。

Description

应用程序无响应的处理方法、装置、存储介质及智能终端

技术领域

本申请实施例涉及电子设备技术，尤其涉及一种应用程序无响应的处理方法、装置、存储介质及智能终端。

背景技术

随着智能终端的广泛普及，安装在终端上的应用程序(APP)所实现的功能越来越完善，从而，为用户的工作和生活提供了诸多便利。用户对应用程序运行流畅性的要求也越来越高。

以安卓(Android)系统为例，如果应用程序在一段时间内反应不够灵敏，则该系统会向用户显示一个对话框，该对话框被称为应用程序无响应(Application NotResponding，简称为ANR)对话框。APP通常会因为代码质量问题导致ANR，但是Android系统提供的ANR报错机制存在缺陷，当终端上的APP发生ANR时，研发人员无法获知ANR发生的具体情况、更无法根据ANR相关信息进行代码优化。

发明内容

本申请实施例提供一种应用程序无响应的处理方法、装置、存储介质及智能终端，可以优化相关技术中的应用程序无响应方案。

第一方面，本申请实施例提供了一种应用程序无响应的处理方法，包括：

监测应用程序的广播处理过程；

在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；

在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

第二方面，本申请实施例还提供了一种应用程序无响应的处理装置，该装置包括：

广播监测模块，用于监测应用程序的广播处理过程；

状态获取模块，用于在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；

消息获取模块，用于在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

第三方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如本申请实施例所述的应用程序无响应的处理方法。

第四方面，本申请实施例提供了一种智能终端，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，所述处理器执行所述计算机程序时实现如本申请实施例所述的应用程序无响应的处理方法。

本申请实施例提供一种应用程序无响应的处理方案，采用监测应用程序的广播处理过程的方式，在检测到该广播处理过程中出现应用程序无响应问题时，获取该应用程序的广播状态；在该广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，实现记录ANR发生时的广播处理情况。通过采用本申请实施例的技术方案，在ANR问题发生时，对消息队列中未处理的目标广播信息进行收集，以供程序开发人员获知应用程序的广播处理情况，从而便于定位应用程序的广播ANR问题，为优化应用程序的代码提供依据。

附图说明

图1为本申请实施例提供的一种应用程序无响应的处理方法的流程图；

图2为本申请实施例提供的另一种应用程序无响应的处理方法的流程图；

图3为本申请实施例提供的又一种应用程序无响应的处理方法的流程图；

图4为本申请实施例提供的一种应用程序无响应的处理装置的结构示意图；

图5为本申请实施例提供的一种智能终端的结构示意图；

图6为本申请实施例提供的一种智能手机的结构框图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

图1为本申请实施例提供的一种应用程序无响应的处理方法的流程图，本实施例可适用于智能终端上安装的应用程序调用预设的发送广播接口发送广播的情况，该方法可以由应用程序无响应的处理装置来执行，其中，该装置可由软件和/或硬件实现，一般可集成在智能终端中。该方法包括：

步骤110、监测应用程序的广播处理过程。

其中，广播机制是实现跨进程通信的技术。例如，在安卓系统中，广播可以是不同APP之间发送消息的一种手段。广播处理过程可以包括：系统通过binder方式把广播消息由系统进程发送给应用进程(即APP进程)。APP进程把接收到的广播消息发送至主线程的消息队列进行存储。等待入队时间在该广播消息之前的广播消息处理完成后，APP主线程由该消息队列中取出该广播消息进行处理。当该广播消息处理完成后，APP进程通过调用发送广播接口发送广播处理完成通知至系统进程，以反馈给系统知道该广播消息已经处理完成。其中，主线程可以是用户界面对应的线程，该线程在安卓系统运行的时候就被创建，用于负责UI界面的显示、更新和控件交互等。

基于上述广播处理过程，在检测到APP未接收到广播消息时，应用进程设置该APP的广播状态为等待状态，即可以定义广播状态是IN_IDLE状态，其取值为0。即若检测到广播状态为IN_IDLE或广播状态的取值为0，均可以确定当前APP还没有接收到广播消息，进而确定广播状态为等待状态。当系统进程通过binder方式将广播消息发送给APP进程后，APP在成功接收到广播消息时，应用进程设置该APP的广播状态为入队状态，表示广播消息开始进入APP主线程的消息队列。可以定义入队状态下的广播状态是IN_ENQUEUEING状态，其取值为1。APP进程检测APP主线程是否由消息队列中取出广播消息。在APP的主线程开始由消息队列中取出该广播消息进行处理时，APP进程设置广播状态为正在处理状态，表示该广播消息开始被处理。可以定义正在处理状态下的广播状态是IN_HANDLING状态，其取值为2。在APP处理完该广播消息时，APP进程设置该APP的广播状态为处理完成状态。可以定义处理完成状态下的广播状态是IN_FINISHING状态，其取值为3。在处理完一条广播消息后，APP进程会调用发送广播接口将广播处理完成通知传输回系统进程，在发送广播处理完成通知之后，应用进程将所述应用程序的广播状态重置为等待状态。

示例性的，对广播处理过程进行分解，得到等待广播消息过程和广播消息入队过程，其中，若广播状态为入队状态，则根据应用程序主线程对广播的处理情况，广播状态又可以细分为广播消息处理子过程和广播消息处理完成子过程等。针对各个过程或子过程对广播状态进行命名，并赋予不同的取值。例如，广播状态包括等待状态、入队状态、正在处理状态及处理完成状态。

示例性的，系统进程监测应用程序的广播处理过程可以是按照设定的周期值周期性的检测该广播处理过程中是否出现应用程序无响应问题。其中，应用程序无响应(即ANR)问题是当操作在一段时间内无法被系统处理时，系统层面会弹出ANR对话框，以提示出现ANR问题。导致ANR问题的原因可能是在主线程(UI线程)里面做了太多的阻塞耗时操作等。需要说明的是，当系统开始发送一条广播消息给APP时，记录开始时间，然后基于该开始时间进行计时，当计时的时间值达到预先设置的等待时间时，若该广播消息还没有在APP中处理完成，则系统判定APP已经出现ANR问题。

步骤120、在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态。

以安卓系统为例，预设的发送广播接口可以是安卓系统中原生的发送广播接口，用于供应用程序调用以发送广播消息。若要获取应用程序的广播状态，则需要借助新设置的接口。即在系统中添加一个接口，由系统端系统进程调用该接口，获取应用进程设置的广播状态。需要说明的是，该接口与安卓系统中原生的发送广播接口不同。运行于应用端的系统程序(例如应用进程)基于应用程序基于广播的处理过程设置广播状态，运行于系统端的系统程序(例如系统进程)通过调用该接口获取上述广播状态。

可选的，系统进程判断该广播状态是否为入队状态。可以通过该广播状态的取值确定是否为入队状态，即获取广播状态的取值，若该取值为1，则确定该广播状态为入队状态。还可以通过该广播状态的名称判断广播状态是否为入队状态，即获取广播状态的名称，若该名称为IN_ENQUEUEING，则确定该广播状态为入队状态。

步骤130、在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息。

需要说明的是，应用进程包括应用程序主线程和至少一个应用程序从线程。应用程序主线程的消息队列中存储仅能由应用程序主线程处理的广播消息。对于消息队列中的广播消息，若广播消息处理完成，则将该处理完的广播消息由消息队列中移除，因此，消息队列中的广播消息是未处理完成的广播消息。

其中，目标广播消息可以是消息队列中包含的全部广播消息，即获取消息队列中所有未处理的广播消息，从而可以明确的显示消息队列中的消息情况，方便定位APP中广播ANR问题。此外，目标广播消息还可以是消息队列中最新入队的当前广播消息。需要说明的是，当前广播消息可能位于消息队列的头部、尾部或中部，本申请实施例不作具体限定。另外，目标广播消息还可以包括当前广播消息和入队时间在当前广播消息之前的参考广播消息。其中，参考广播消息可以包括消息队列中正在处理的广播和未被处理的广播。

示例性的，在广播状态的取值为1时，系统进程获取应用程序主线程对应的消息队列，获取该消息队列中包含的全部广播消息，作为目标广播消息，采用日志的形式存储该目标广播消息。可选的，存储有目标广播消息的日志可以被周期性的或定时的上传至应用程序的服务器，以便于在广播消息卡在消息队列中没有处理而导致APP发生广播ANR时，程序开发人员基于该日志内记载的目标广播消息的情况，明确的看到广播消息属于未处理消息中，从而定位广播ANR问题。

本实施例的技术方案，采用监测应用程序的广播处理过程的方式，在检测到该广播处理过程中出现应用程序无响应问题时，获取该应用程序的广播状态；在该广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息。通过本申请实施例的技术方案，在ANR发生时，对消息队列中未处理的广播信息进行收集，以供程序开发人员获知应用程序的广播处理情况，从而便于定位应用程序的广播ANR问题，为优化应用程序的代码提供依据。

图2为本申请实施例提供的另一种应用程序无响应的处理方法的流程图，如图2所示，该方法包括：

步骤201、设置所述应用程序的广播状态为等待状态。

示例性的，若系统进程没有发送广播消息至应用进程，则应用进程设置该应用程序的广播状态为等待状态。将广播状态的名称设置为IN_IDLE，取值设置为0。

步骤202、判断是否接收到系统通过binder方式发送的广播消息，若是，则执行步骤203，否则执行步骤201。

示例性的，若系统进程通过binder方式发送广播消息至应用进程，则判断是否接收到应用进程返回的接收成功通知。若在预设时间内接收到接收成功通知，则确定该应用程序成功接收到广播消息。

步骤203、确定所述应用程序的广播状态为入队状态。

应用进程将广播状态的名称设置为IN_ENQUEUEING，取值设置为1。

步骤204、判断所述应用程序的主线程是否由所述消息队列中获取所述广播消息，若是，则执行步骤205，否则执行步骤204。

应用进程判断应用程序的主线程是否由消息队列中获取广播消息。

步骤205、确定所述应用程序的广播状态为正在处理状态。

在应用程序的主线程由消息队列中获取广播消息时，应用进程将广播状态设置为正在处理状态。

步骤206、判断所述应用程序是否处理完所述广播消息，若是，则执行步骤207，否则，返回执行步骤205。

应用进程判断该广播消息是否处理完成。例如，是否检测到广播消息的结束符，若是，则确定该广播消息已处理完成。

步骤207、确定所述应用程序的广播状态为处理完成状态，将所述应用程序的广播状态重置为等待状态。

在该广播消息已处理完成时，应用进程将广播状态设置为处理完成状态。应用进程调用发送广播接口将广播处理完成通知传输回系统，应用进程将所述应用程序的广播状态重置为等待状态，以返回执行步骤202。

步骤208、监测应用程序的广播处理过程，判断是否出现ANR问题，若是，则执行步骤209，否则执行步骤201。

按照设定周期检测应用程序的广播处理过程，检测是否出现广播ANR问题。需要说明的是，由于在未出现ANR问题的情况下，上述步骤201～207为循环执行过程，可知，步骤208并不限于在执行完步骤207才执行，即步骤208可能与前述7个步骤的执行过程并行执行。

步骤209、获取所述应用程序的广播状态。

在广播发生ANR问题时，系统进程调用预先添加的接口由应用进程获取该应用程序的广播状态。

步骤210、判断所述广播状态是否为入队状态，若是，则执行步骤211，否则执行步骤214。

系统进程判断广播状态是否为入队状态。

步骤211、获取所述应用程序的主线程对应的消息队列。

若是入队状态，则系统进程获取该应用程序的主线程对应的消息队列。

步骤212、根据广播参数查询所述消息队列，确定最新入队的当前广播消息。

需要说明的是，广播参数包括广播的发送者、广播接收者，广播发送时间、广播入队时间等等。在所述广播状态为入队状态时，基于广播参数中的广播入队时间可以确定最新入对的广播消息。

系统进程根据该广播参数查询消息队列，确定最新入队的当前广播消息。

步骤213、基于所述当前广播消息确定目标广播消息，采用日志的形式存储所述目标广播消息。

将该最新入队的广播消息作为目标广播消息，系统进程打印该目标广播消息，并采用日志的形式存储该目标广播消息，得到关于该广播ANR的log文件。

步骤214、采用日志形式存储应用程序发生广播ANR问题。

在检测到出现应用程序无响应问题时，若获取到的该应用程序的广播状态不是入队状态，则系统进程采用日志形式存储应用程序发生广播ANR问题。

本实施例的技术方案，采用监测应用程序的广播处理过程的方式，在检测到该广播处理过程中出现应用程序无响应问题时，获取该应用程序的广播状态；在该广播状态为入队状态时，获取应用程序主线程的消息队列中最新入队的广播消息，记为当前广播消息；将该当前广播消息作为目标广播消息，采用日志的形式存储该目标广播消息。采用上述技术方案，由于仅打印了当前广播消息，减小了系统开销，为研发人员优化应用程序提供依据。

图3为本申请实施例提供的又一种应用程序无响应的处理方法的流程图，如图3所示，该方法包括：

步骤301、设置所述应用程序的广播状态为等待状态。

步骤302、判断是否接收到系统通过binder方式发送的广播消息，若是，则执行步骤303，否则执行步骤301。

步骤303、确定所述应用程序的广播状态为入队状态。

步骤304、判断所述应用程序的主线程是否由所述消息队列中获取所述广播消息，若是，则执行步骤305，否则执行步骤306。

步骤305、确定所述应用程序的广播状态为正在处理状态。

步骤306、判断所述应用程序是否处理完所述广播消息，若是，则执行步骤307，否则，返回执行步骤305。

步骤307、确定所述应用程序的广播状态为处理完成状态，将所述应用程序的广播状态重置为等待状态。

步骤308、监测应用程序的广播处理过程，判断是否出现ANR问题，若是，则执行步骤309，否则执行步骤301。

由于在未出现ANR问题的情况下，上述步骤301～307为循环执行过程，可知，步骤308并不限于在执行完步骤307才执行，即步骤308可能与前述7个步骤的执行过程并行执行。

步骤309、获取所述应用程序的广播状态。

步骤310、判断所述广播状态是否为入队状态，若是，则执行步骤311，否则执行步骤315。

步骤311、取所述应用程序的主线程对应的消息队列。

步骤312、根据广播参数查询所述消息队列，确定最新入队的当前广播消息。

步骤313、获取所述消息队列中入队时间在所述当前广播消息之前的参考广播消息。

由于广播参数包括广播入队时间，基于该广播入队时间对消息队列中的广播消息进行排序，根据排序结果，将入队时间在当前广播消息之前的广播消息作为参考广播消息。

步骤314、将所述当前广播消息和参考广播消息作为目标广播消息，采用日志的形式存储所述目标广播消息。

步骤315、采用日志形式存储应用程序发生广播ANR问题。

本实施例的技术方案，采用监测应用程序的广播处理过程的方式，在检测到该广播处理过程中出现应用程序无响应问题时，获取该应用程序的广播状态；在该广播状态为入队状态时，获取应用程序主线程的消息队列中最新入队的广播消息，记为当前广播消息；获取消息队列中入队时间在该当前广播消息之前的参考广播消息；将该当前广播消息和参考广播消息作为目标广播消息，采用日志的形式存储该目标广播消息。采用上述技术方案，对当前广播消息及入队时间在该当前广播消息之前的参考广播消息进行打印，实现在出现ANR问题时，打印消息队列中部分广播消息，减小了系统开销。

图4为本申请实施例提供的一种应用程序无响应的处理装置的结构示意图。该装置可由软件和/或硬件实现，一般集成在智能终端中，可通过执行一种应用程序无响应的处理方法收集广播ANR发生时的消息处理情况，为应用程序研发人员提供代码优化依据。如图4所示，该装置包括：

广播监测模块410，用于监测应用程序的广播处理过程；

状态获取模块420，用于在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；

消息获取模块430，用于在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

本申请实施例提供一种应用程序无响应的处理装置，通过监测应用程序的广播处理过程，在检测到该广播处理过程中出现应用程序无响应问题时，获取该应用程序的广播状态，在该广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息的方式，实现在广播ANR问题发生时，对消息队列中的目标广播消息进行收集，以供程序开发人员获知应用程序的广播处理情况，便于定位应用程序的广播ANR问题，为优化应用程序的代码提供依据

可选的，还包括：

状态设置模块，用于在监测应用程序的广播处理过程之前，判断应用程序是否接收到系统发送的广播消息；

在未接收到广播消息时，设置所述应用程序的广播状态为等待状态；

在接收到广播消息时，设置所述应用程序的广播状态为入队状态。

可选的，状态设置模块还用于：

若所述广播状态为入队状态，则判断所述应用程序的主线程是否由所述消息队列中获取所述广播消息；

若是，则设置所述应用程序的广播状态为正在处理状态；

否则，判断所述应用程序是否处理完所述广播消息；

若是，则设置所述应用程序的广播状态为处理完成状态。

可选的，状态设置模块还用于：

在设置所述应用程序的广播状态为处理完成状态之后，发送广播处理完成通知至所述系统，将所述应用程序的广播状态重置为等待状态。例如，若所述应用程序的广播状态为处理完成状态，则应用进程调用发送广播接口发送广播处理完成通知至系统进程，应用进程将所述应用程序的广播状态重置为等待状态。

可选的，消息获取模块430具体用于：

若所述广播状态为入队状态，则获取所述应用程序的主线程对应的消息队列；

获取所述消息队列中包含的全部广播消息，作为目标广播消息，采用日志的形式存储所述目标广播消息。

可选的，消息获取模块430还具体用于：

若所述广播状态为入队状态，则获取所述应用程序的主线程对应的消息队列；

根据广播参数查询所述消息队列，确定最新入队的当前广播消息；

基于所述当前广播消息确定目标广播消息，采用日志的形式存储所述目标广播消息。

可选的，消息获取模块430包括：

参考广播获取子模块，用于在根据广播参数查询所述消息队列，确定最新入队的当前广播消息之后，获取所述消息队列中入队时间在所述当前广播消息之前的参考广播消息；

以及，基于所述当前广播消息确定目标广播消息，包括：

将所述当前广播消息和参考广播消息作为目标广播消息。

本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行应用程序无响应的方法，该方法包括：

监测应用程序的广播处理过程；

在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；

在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

存储介质——任何的各种类型的存储器设备或存储设备。术语“存储介质”旨在包括：安装介质，例如CD-ROM、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如DRAM、DDR RAM、SRAM、EDO RAM，兰巴斯(Rambus)RAM等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的第一计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到第一计算机系统。第二计算机系统可以提供程序指令给第一计算机用于执行。术语“存储介质”可以包括可以驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的应用程序无响应的操作，还可以执行本申请任意实施例所提供的应用程序无响应的方法中的相关操作。

本申请实施例提供了一种智能终端，该智能终端内具有Android、iOS、windowsphone及windows mobile等操作系统，该智能终端中可集成本申请实施例提供的应用程序无响应的装置。其中，智能终端可以为智能手机、PAD(平板电脑)、掌上游戏机、智能家电及智能穿戴设备等。图5为本申请实施例提供的一种智能终端的结构示意图。如图5所示，该智能终端包括存储器510及处理器520。所述存储器510，用于存储计算机程序、广播状态及消息队列等；所述处理器520读取并执行所述存储器510中存储的计算机程序。所述处理器520在执行所述计算机程序时实现以下步骤：监测应用程序的广播处理过程；在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

上述示例中列举的存储器及处理器均为智能终端的部分元器件，所述智能终端还可以包括其它元器件。以智能手机为例，说明上述智能终端可能的结构。图6为本申请实施例提供的一种智能手机的结构框图。如图6所示，该智能手机可以包括：存储器601、中央处理器(Central Processing Unit，CPU)602(又称处理器，以下简称CPU)、外设接口603、RF(Radio Frequency，射频)电路605、音频电路606、扬声器611、触摸屏612、电源管理芯片608、输入/输出(I/O)子系统609、其他输入/控制设备610以及外部端口604，这些部件通过一个或多个通信总线或信号线607来通信。

应该理解的是，图示智能手机600仅仅是智能终端的一个范例，并且智能手机600可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

下面就本实施例提供的集成有应用程序无响应的装置的智能手机进行详细的描述。

存储器601，所述存储器601可以被CPU602、外设接口603等访问，所述存储器601可以包括高速随机存取存储器，还可以包括非易失性存储器，例如一个或多个磁盘存储器件、闪存器件、或其他易失性固态存储器件。在存储器601中存储计算机程序，还可以存储预设文件及预设白名单等。

外设接口603，所述外设接口603可以将设备的输入和输出外设连接到CPU602和存储器601。

I/O子系统609，所述I/O子系统609可以将设备上的输入输出外设，例如触摸屏612和其他输入/控制设备610，连接到外设接口603。I/O子系统609可以包括显示控制器6091和用于控制其他输入/控制设备610的一个或多个输入控制器6092。其中，一个或多个输入控制器6092从其他输入/控制设备610接收电信号或者向其他输入/控制设备610发送电信号，其他输入/控制设备610可以包括物理按钮(按压按钮、摇臂按钮等)、拨号盘、滑动开关、操纵杆、点击滚轮。值得说明的是，输入控制器6092可以与以下任一个连接：键盘、红外端口、USB接口以及诸如鼠标的指示设备。

触摸屏612，所述触摸屏612是用户终端与用户之间的输入接口和输出接口，将可视输出显示给用户，可视输出可以包括图形、文本、图标、视频等。

I/O子系统609中的显示控制器6091从触摸屏612接收电信号或者向触摸屏612发送电信号。触摸屏612检测触摸屏上的接触，显示控制器6091将检测到的接触转换为与显示在触摸屏612上的用户界面对象的交互，即实现人机交互，显示在触摸屏612上的用户界面对象可以是运行游戏的图标、联网到相应网络的图标等。值得说明的是，设备还可以包括光鼠，光鼠是不显示可视输出的触摸敏感表面，或者是由触摸屏形成的触摸敏感表面的延伸。

RF电路605，主要用于建立手机与无线网络(即网络侧)的通信，实现手机与无线网络的数据接收和发送。例如收发短信息、电子邮件等。具体地，RF电路605接收并发送RF信号，RF信号也称为电磁信号，RF电路605将电信号转换为电磁信号或将电磁信号转换为电信号，并且通过该电磁信号与通信网络以及其他设备进行通信。RF电路605可以包括用于执行这些功能的已知电路，其包括但不限于天线系统、RF收发机、一个或多个放大器、调谐器、一个或多个振荡器、数字信号处理器、CODEC(COder-DECoder，编译码器)芯片组、用户标识模块(Subscriber Identity Module，SIM)等等。

音频电路606，主要用于从外设接口603接收音频数据，将该音频数据转换为电信号，并且将该电信号发送给扬声器611。

扬声器611，用于将手机通过RF电路605从无线网络接收的语音信号，还原为声音并向用户播放该声音。

电源管理芯片608，用于为CPU602、I/O子系统及外设接口所连接的硬件进行供电及电源管理。

本申请实施例提供的智能终端，可以在广播ANR问题发生时，对消息队列中的目标广播消息进行收集，以供程序开发人员获知应用程序的广播处理情况，便于定位应用程序的广播ANR问题，为优化应用程序的代码提供依据。

上述实施例中提供的应用程序无响应的装置、存储介质及智能终端可执行本申请任意实施例所提供的应用程序无响应的方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的应用程序无响应的方法。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。

Claims (10)

1.一种应用程序无响应的处理方法，其特征在于，包括：

监测应用程序的广播处理过程；

在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；

在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

2.根据权利要求1所述的方法，其特征在于，在监测应用程序的广播处理过程之前，还包括：

判断应用程序是否接收到系统发送的广播消息；

在未接收到广播消息时，设置所述应用程序的广播状态为等待状态；

在接收到广播消息时，设置所述应用程序的广播状态为入队状态。

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

若所述广播状态为入队状态，则判断所述应用程序的主线程是否由所述消息队列中获取所述广播消息；

若是，则设置所述应用程序的广播状态为正在处理状态；

否则，判断所述应用程序是否处理完所述广播消息；

若是，则设置所述应用程序的广播状态为处理完成状态。

4.根据权利要求3所述的方法，其特征在于，在设置所述应用程序的广播状态为处理完成状态之后，还包括：

发送广播处理完成通知至所述系统，将所述应用程序的广播状态重置为等待状态。

5.根据权利要求1至4中任一项所述的方法，其特征在于，在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，包括：

若所述广播状态为入队状态，则获取所述应用程序的主线程对应的消息队列；

获取所述消息队列中包含的全部广播消息，作为目标广播消息，采用日志的形式存储所述目标广播消息。

6.根据权利要求1至4中任一项所述的方法，其特征在于，在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，包括：

若所述广播状态为入队状态，则获取所述应用程序的主线程对应的消息队列；

根据广播参数查询所述消息队列，确定最新入队的当前广播消息；

基于所述当前广播消息确定目标广播消息，采用日志的形式存储所述目标广播消息。

7.根据权利要求6所述的方法，其特征在于，在根据广播参数查询所述消息队列，确定最新入队的当前广播消息之后，还包括：

获取所述消息队列中入队时间在所述当前广播消息之前的参考广播消息；

以及，基于所述当前广播消息确定目标广播消息，包括：

将所述当前广播消息和参考广播消息作为目标广播消息。

8.一种应用程序无响应的处理装置，其特征在于，包括：

广播监测模块，用于监测应用程序的广播处理过程；

状态获取模块，用于在所述广播处理过程中出现应用程序无响应问题时，获取所述应用程序的广播状态；

消息获取模块，用于在所述广播状态为入队状态时，获取应用程序主线程的消息队列中包含的目标广播消息，其中，所述目标广播消息用于表示所述应用程序的广播处理情况。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的应用程序无响应的处理方法。

10.一种智能终端，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的应用程序无响应的处理方法。