CN106708563A - 一种应用程序无响应处理方法及终端 - Google Patents

Abstract

本发明公开了一种应用程序无响应处理方法及终端，通过在应用程序启动时为就为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程；在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程，使待执行任务在任务执行线程中进行任务处理；并在应用程序退出时，结束用户交互线程及任务执行线程。这样在任务执行线程中完成应用程序的一个待执行任务执行后，不会对任务执行线程销毁，而是可以继续用于执行应用程序的其他待执行任务，避免了任务执行线程的频繁创建，减少了系统开销，降低了程序复杂度，减少了维护成本。

Description

一种应用程序无响应处理方法及终端

技术领域

本发明涉及应用程序处理领域，更具体地说，涉及一种应用程序无响应处理方法及终端。

背景技术

随着智能终端的快速发展，安装在终端上的应用程序所实现的功能越来越完善，相应的，这些应用程序本身的结构也越来越复杂，因此运行起来也更加耗费系统资源，这就导致终端经常会出现应用程序无响应(Application Not Responding，简称ANR)的情况。

当前，在系统框架中设置有一种ANR机制，当某一应用程序的执行任务在一定时间内没有响应，将弹出提示框，指引用户结束该任务或继续等待。然而一个流畅的合理的应用程序中不应出现ANR提示框，让用户每次都要处理这个ANR提示框。为了避免这种情况出现，系统会新建一个任务执行线程去执行较为复杂、耗时较长的任务，在完成一个较为复杂、耗时较长的任务后，系统会销毁执行该任务的任务执行线程。但是这样会导致线程频繁地被创建和销毁，增加系统开销和程序复杂度，从而增加开发和维护成本。

发明内容

本发明要解决的技术问题在于:当前系统框架中设置的ANR机制中，系统会频繁地创建和销毁任务执行线程，导致系统开销和程序复杂度增大，并增加系统开发和维护成本。针对该技术问题，提供一种应用程序无响应处理方法及终端。

为解决上述技术问题，本发明提供一种程序无响应处理方法，所述程序无响应处理方法包括：

在应用程序启动时为所述应用程序创建用户交互线程，并为所述用户交互线程创建任务执行线程；

在所述用户交互线程中，将收到的待执行任务打包成任务消息发给所述任务执行线程；

在所述任务执行线程中，对接收到的任务消息中的待执行任务进行任务处理；

在所述应用程序退出时，结束所述用户交互线程及任务执行线程。

进一步地，在所述用户交互线程中，将收到的待执行任务打包成任务消息发给所述任务执行线程之前，还包括：

判断执行所述待执行任务所需的时间是否大于等于预设时间阈值，如否，则在所述用户交互线程中对该待执行任务进行处理；否则，对所述的待执行任务打包成任务消息发给所述任务执行线程；

所述预设时间阈值大于等于应用程序无响应时间阈值。

进一步地，将收到的待执行任务打包成任务消息发给所述任务执行线程包括：

判断所述待执行任务是否包含执行体，如是，从所述待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给所述任务执行线程；

否则，直接从所述待执行任务中获取任务标识以及待执行数据打包成任务消息发给所述任务执行线程。

进一步地，在所述任务执行线程中对所述待执行任务进行任务处理包括：

从所述任务消息中提取任务标识以及待执行数据，并判断所述任务消息中是否包含执行体，如是，生成所述执行体对所述待执行数据进行执行；否则，根据所述任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对所述待执行数据进行执行。

进一步地，所述应用程序无响应处理方法还包括：

在所述任务执行线程中对所述待执行任务进行任务处理后，将得到的任务执行结果存储于任务结果数据池中，并向所述用户交互线程反馈至少包含任务标识的任务处理完成消息；

在所述用户交互线程中，根据所述任务处理完成消息中的任务标识从所述任务结果数据池中提取对应的任务处理结果。

进一步地，本发明提供了一种终端，所述终端包括：

线程创建模块，用于在应用程序启动时为所述应用程序创建用户交互线程，并为所述用户交互线程创建任务执行线程；

用户交互主控模块，用于在所述用户交互线程中，将收到的待执行任务打包成任务消息发给所述任务执行线程；

执行主控模块，用于在所述任务执行线程中，对接收到的任务消息中的待执行任务进行任务处理；

线程结束模块，用于在所述应用程序退出时，结束所述用户交互线程及任务执行线程。

进一步地，所述用户交互主控模块用于在所述用户交互线程中创建任务队列、用户交互消息管理器以及用户交互消息处理器；

所述任务队列用于存储待执行任务；

所述用户交互消息管理器用于判断执行所述任务队列中的待执行任务所需消耗的时间是否大于等于预设时间阈值，如否，将所述待执行任务发给所述用户交互消息处理器进行处理；否则，对所述的待执行任务打包成任务消息发给所述任务执行线程；

所述预设时间阈值大于等于应用程序无响应时间阈值。

进一步地，所述用户交互消息管理器用于判断所述待执行任务是否包含执行体，如是，从所述待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给所述任务执行线程，否则，直接从所述待执行任务中获取任务标识以及待执行数据打包成任务消息发给所述任务执行线程。

进一步地，所述执行主控模块用于在所述任务执行线程创建待执行消息队列以及执行消息处理器；

所述待执行消息队列用于存储接收到的任务消息，并下发给所述执行消息处理器；

所述执行消息处理器用于从接收到的任务消息中提取任务标识以及待执行数据，并判断所述任务消息中是否包含执行体，如是，生成所述执行体对所述待执行数据进行执行；否则，根据所述任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对所述待执行数据进行执行。

进一步地，所述执行主控模块还用于在所述任务执行线程创建执行消息管理器；

所述执行消息处理器还用于在对所述待执行任务进行任务处理后，将得到的任务执行结果存储于任务结果数据池中，并通过所述执行消息管理器向所述用户交互线程反馈至少包含任务标识的任务处理完成消息；

所述用户交互主控模块还用于在所述用户交互线程中创建用于存储任务处理完成消息的用户交互消息队列；

所述用户交互消息处理器还用于根据所述任务处理完成消息中的任务标识从所述任务结果数据池中提取对应的任务处理结果。

有益效果

本发明提供的应用程序无响应处理方法及终端，通过在应用程序启动时为就为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程；在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程，使待执行任务在任务执行线程中进行任务处理；并在应用程序退出时，结束用户交互线程及任务执行线程。这样在任务执行线程中完成应用程序的一个待执行任务执行后，不会对任务执行线程销毁，而是可以继续用于执行应用程序的其他待执行任务，避免了任务执行线程的频繁创建，减少了系统开销，降低了程序复杂度，减少了维护成本。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图；

图2为本发明第一实施例提供的应用程序无响应处理方法流程示意图；

图3为本发明第一实施例提供的对待执行任务的判断处理流程示意图；

图4为本发明第一实施例提供的将收到的待执行任务打包成任务消息发给任务执行线程具体流程示意图；

图5为本发明第一实施例提供的对待执行任务进行任务处理的具体流程；

图6为本发明第二实施例提供的用户交互线程与任务执行线程之间的处理流程示意图；

图7为本发明第三实施例提供的一种终端结构示意图；

图8为本发明第三实施例提供的一种用户交互线程结构示意图；

图9为本发明第三实施例提供的一种任务执行线程结构示意图；

图10为本发明第四实施例提供的终端结构框架图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

移动终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是移动终端，然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图。

移动终端100可以包括无线通信单元110、A/V(音频/视频)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的移动终端，但是应理解的是，并不要求实施所有示出的组件，可以替代地实施更多或更少的组件，将在下面详细描述移动终端的元件。

无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统或网络之间的无线电通信。A/V输入单元120用于接收音频或视频信号。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。

感测单元140检测移动终端100的当前状态，(例如，移动终端100的打开或关闭状态)、移动终端100的位置、用户对于移动终端100的接触(即，触摸输入)的有无、移动终端100的取向、移动终端100的加速或减速移动和方向等等，并且生成用于控制移动终端100的操作的命令或信号。例如，当移动终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制移动终端的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，己经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。

以下通过具体实施例进行详细说明。

第一实施例

为减少系统开销，降低维护成本，本实施例提供了一种应用程序无响应处理方法，参照图2，图2为本发明第一实施例提供的应用程序无响应处理方法流程示意图，包括：

S201:在应用程序启动时为该应用程序创建用户交互线程；

S202:为该用户交互线程创建任务执行线程；

S203:在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程；

S204:在任务执行线程中，对接收到的任务消息中的待执行任务进行任务处理；

S205:判断该应用程序是否退出，若是，转至S206；否则，转至S203。

S206:结束用户交互线程及任务执行线程。

本实施例中，为用户交互线程创建的任务执行线程可以是一个，此时当任务执行线程中的前一个待执行任务进行任务处理完毕之后，在任务执行线程中才会处理下一个从用户交互线程中发送来的待执行任务。为用户交互线程创建的任务执行线程也可以是多个，此时可以在多个任务执行线程中并行执行待执行任务，值得注意的是，在每一个任务执行线程中，只有在处理完毕前一个待执行任务之后，才会处理下一个用户交互线程发送来的待执行任务。例如，系统为用户交互线程创建了2个任务执行线程，则在同一时刻可以同时进行2个待执行任务的任务处理，在每一个任务执行线程中分别处理一个待执行任务。

应当理解的是，任务执行线程可以在同一时段内接收多个任务消息，此时在任务执行线程中，可以根据接收到任务消息的先后顺序依次对任务消息中的待执行任务进行任务处理；任务执行线程也可以一次只接收一个任务消息，当前一个接收到的任务消息中的待执行任务在任务执行线程中进行任务处理完毕之后，再接收下一个任务消息。

本实施例中可以预先设置时间阈值，在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程之前，可以根据预设时间阈值对待执行任务进行判断，从而决定是否发送至任务执行线程中进行处理，在用户交互线程中的具体判断处理过程参照图3所示，包括：

S301:判断执行待执行任务所需的时间是否大于等于预设时间阈值，如否，转至S302；否则，进行S303的操作。

S302:在用户交互线程中对该待执行任务进行处理。

S303:将待执行任务打包成任务消息发给任务执行线程。

值得注意的是，本实施例中预设时间阈值应当大于等于应用程序无响应时间阈值。应用程序无响应时间阈值可以是根据执行应用程序某一待执行任务的最长执行时间来确定的，也可以是根据经验值来进行设置。例如，我们知道，在默认情况下，在android(安卓)中Activity的最长执行时间是5秒，Broadcast Receiver(广播接收器)的最长执行时间则是10秒，故而可以设置应用程序无响应时间阈值为5秒或10秒，则相应的设置预设时间阈值大于等于5秒或者10秒。

具体的，例如，以预设时间阈值为5秒为例，在用户交互线程创建后，接收到第一个待执行任务A，判断出执行待执行任务A的所需时间小于5秒，则在用户交互线程中直接对待执行任务A进行任务处理；用户交互线程在接收到第一个待执行任务A之后，又接收到一个待执行任务B，判断出执行待执行任务B的所需时间大于5秒，则在用户交互线程中，将待执行任务B打包成任务消息发到任务执行线程中进行任务处理。

又例如，在将待执行任务B打包成任务消息发到任务执行线程中之后，用户交互线程又收到一个待执行任务C，判断出执行待执行任务C的所需时间也大于5秒，若系统创建的任务执行线程只有一个，且此时任务执行线程中仍在处理待执行任务B，则在用户交互线程中，可以等待任务执行线程中待执行任务B处理完毕之后，再将待执行任务C打包成任务消息发到该任务执行线程中进行任务处理；若系统创建的任务执行线程有多个，则在用户交互线程中，可以将待执行任务C打包成任务消息发到其余空闲的任务执行线程中进行任务处理。

本实施例中，待执行任务至少包含任务标识和待执行数据，同时还可以包含有执行体。应当理解的是执行体用于在用户交互线程或任务执行线程中处理数据。

本实施例中，步骤S203中将收到的待执行任务打包成任务消息发给任务执行线程具体流程参见图4，包括：

S401:判断待执行任务是否包含执行体，若是，转至S402，否则，转至S403；

S402:从待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给任务执行线程。

S403:直接从待执行任务中获取任务标识以及待执行数据打包成任务消息发给任务执行线程。

本实施例中，步骤S204在任务执行线程中对待执行任务进行任务处理的具体流程参见图5，包括：

S501:从任务消息中提取任务标识以及待执行数据；

S502:判断任务消息中是否包含执行体，若是，转至S503，否则，转至S504；

S503:生成执行体对待执行数据进行执行。

S504:根据任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对待执行数据进行执行。

应当理解的是，步骤S504中，预设的任务标识与预置执行体对应关系是预先在系统中设置好的，其对应关系可以是通过图表等形式进行存储。

具体的，在任务消息不存在执行体的情况下，根据任务标识与预设的任务标识进行匹配，当从任务消息中提取到的任务标识与某一预设的任务标识匹配时，根据预设的任务标识与预置执行体对应关系，提取对应的预置执行体作为该任务消息的执行体，对待执行数据进行执行。

本实施例中，可以在用户交互线程和任务执行线程之外设置任务结果数据池，用于存储各待执行任务的任务执行结果。

在任务执行线程中对待执行任务进行任务处理后，可以将得到的任务执行结果存储于任务结果数据池中，同时还可以向用户交互线程反馈至少包含任务标识的任务处理完成消息。

在用户交互线程中，在得到任务处理完成消息后，可以根据任务处理完成消息中的任务标识从任务结果数据池中提取对应的任务处理结果。

应当理解的是，在根据任务处理完成消息中的任务标识从任务结果数据池中提取出对应的任务处理结果后，可以将任务处理结果反馈到显示界面以告知用户，当然也可以不反馈。

本实施例提供的应用程序无响应处理方法，可以应用于如图1所示的终端上，前述各方法步骤具体可以通过图1中的控制器实现，任务结果数据池可以设置于图1中的存储器内，以存储任务处理结果。

本实施例提供的应用程序无响应处理方法，通过在应用程序启动时为就为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程；在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程，使待执行任务在任务执行线程中进行任务处理；并在应用程序退出时，结束用户交互线程及任务执行线程。这样在任务执行线程中完成应用程序的一个待执行任务执行后，不会对任务执行线程销毁，而是可以继续用于执行应用程序的其他待执行任务，避免了任务执行线程的频繁创建，减少了系统开销，降低了程序复杂度，减少了维护成本。

第二实施例

本实施例在第一实施例的基础上，以只具有一个任务执行线程的处理流程为例，对本发明提供的应用程序无响应处理方法作进一步示例说明。

本实施例中，在应用程序启动时，为该应用程序创建用户交互线程，并为该用户交互线程创建一个任务执行线程。之后，参照图6，图6为本发明第二实施例提供的用户交互线程与任务执行线程之间的处理流程示意图。

从图6中可见，待执行任务首先在用户交互线程中进行操作，包括：

S601：判断执行待执行任务所需的时间是否大于等于预设时间阈值，若否，转至S601，否则，转至S603；

S602:对该待执行任务进行处理。

S603:判断待执行任务是否包含执行体，若是，进行S604操作，否则，进行S605操作。

S604：从待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给任务执行线程。

S605:从待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给任务执行线程。

对于转至任务执行线程的待执行任务，在任务执行线程中的操作包括：

S606:从任务消息中提取任务标识以及待执行数据；

S607:判断任务消息中是否包含执行体，若是，转至S608，否则，转至S609；

S608:生成执行体对待执行数据进行执行；

S609:根据任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对待执行数据进行执行；

S610:将任务处理结果存入任务结果数据池中。

此时，在用户交互线程侧，会进行步骤S611：从任务结果数据池中提取出任务处理结果。

应当理解的是，在执行完步骤S611之后，会判断该应用程序是否退出，当应用程序退出后，相应的用户交互线程结束，同时可以发送结束消息给任务执行线程，任务执行线程根据结束消息释放线程中的数据信息，并结束线程。若应用程序未退出，则相应的用户交互线程会继续接收应用程序下发的待执行任务，并重复上述处理流程。

还应当理解的是，本实施例仅示例了存在一个任务执行线程的情况，当存在多个任务执行线程时，每一个任务执行线程与用户交互线程之间的处理流程均可参照上述示例流程进行。

本实施例提供的应用程序无响应处理方法，通过在应用程序启动时为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程；在用户交互线程中，将执行时间大于等于预设时间阈值的待执行任务打包成任务消息发给任务执行线程，使待执行任务在任务执行线程中进行任务处理；并将任务处理结果存储于任务结果数据池中，供用户交互线程侧提取，避免了在任务执行线程中完成应用程序的一个待执行任务执行后就对任务执行线程销毁的情况的出现，实现了任务执行线程的高利用率，避免了任务执行线程的频繁创建，减少了系统开销，降低了程序复杂度，减少了维护成本。

第三实施例

为避免现有终端在处理耗时较长的任务时，需要频繁创建和销毁任务执行线程，导致终端系统开销和程序复杂度大，维护成本高的问题，本实施例提供了一种新的终端，参照图7，图7为本发明第三实施例提供的一种终端结构示意图，包括：

线程创建模块71，用于在应用程序启动时为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程。

本实施例中，线程创建模块71为用户交互线程创建的任务执行线程可以是一个，也可以是多个。

用户交互主控模块72，用于在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程。

本实施例中，用户交互主控模块72可以在收到待执行任务后，即将收到的待执行任务打包成任务消息发给任务执行线程，即此时可以向一个任务执行线程发送多个任务消息，任务消息可以在任务执行线程中存留；也可以在判定任务执行线程空闲时，将收到的待执行任务打包成任务消息发给任务执行线程，即当一个任务执行线程中，正在处理待执行任务时，不向该任务执行线程发送任务消息，当一个任务执行线程未处理待执行任务时，再向其发送一个任务消息。

执行主控模块73，用于在任务执行线程中，对接收到的任务消息中的待执行任务进行任务处理。

本实施例中，当线程创建模块71为用户交互线程创建的任务执行线程为一个时，执行主控模块73在任务执行线程中的前一个待执行任务进行任务处理完毕之后，才会处理下一个用户交互主控模块72发送来的待执行任务。

当线程创建模块71为用户交互线程创建的任务执行线程为多个时，执行主控模块73可以在多个任务执行线程中并行执行用户交互主控模块72发送来的多个待执行任务。值得注意的是，执行主控模块73在每一个任务执行线程中，只有在处理完毕该任务执行线程中的前一个待执行任务之后，才会在该任务执行线程中处理下一个用户交互主控模块72发送来的待执行任务。

例如，线程创建模块71为用户交互线程创建了2个任务执行线程，用户交互主控模块72在同一时间段内向任务执行线程发送了2个包含待执行任务的任务消息，则执行主控模块73可以分别在2个任务执行线程中同时对2个待执行任务进行任务处理，当在其中一个任务执行线程中的待执行任务处理完毕之后，用户交互主控模块72再向任务执行线程中发送一个包含待执行任务的任务消息，执行主控模块73在该任务执行线程中对用户交互主控模块72新发送的任务消息中的待执行任务进行处理。

又例如，用户交互主控模块72在同一时间段内向任务执行线程发送4个包含待执行任务的任务消息，其中每个任务执行线程接收到2个任务消息，则执行主控模块73可以分别在2个任务执行线程中，同时对每个任务执行线程接收到的2个任务消息中的一个的待执行任务进行任务处理，在每个任务执行线程中处理完前一个待执行任务后，再继续处理每个任务执行线程中接收到的另一个任务消息。应当理解的是，本示例中，各任务执行线程之间可以存在任务调配机制，比如在一个任务执行线程中，用户交互主控模块72已完成了该任务执行线程接收到的两个待执行任务，而在另一个任务执行线程中，并未完成第一个待执行任务的处理，此时用户交互主控模块72可以将另一个任务执行线程中的剩余一个待执行任务调配至已完成所有待执行任务的任务执行线程中处理，从而进一步的提高各任务执行线程的利用率。

线程结束模块74，用于在应用程序退出时，结束用户交互线程及任务执行线程。

具体的，在应用程序退出时，线程结束模块74可以向用户交互线程和任务执行线程发送结束消息，用户交互线程和任务执行线程根据结束消息释放线程中的数据信息，并结束线程。

本实施例中，用户交互主控模块72还用于在用户交互线程中创建任务队列721、用户交互消息管理器722以及用户交互消息处理器723，参见图8，其中：

任务队列721用于存储待执行任务。

用户交互消息管理器722用于判断执行任务队列721中的待执行任务所需消耗的时间是否大于等于预设时间阈值，如否，将待执行任务发给用户交互消息处理器723进行处理；否则，将待执行任务打包成任务消息发给任务执行线程。

值得注意的是，本实施例中预设时间阈值应当大于等于应用程序无响应时间阈值。应用程序无响应时间阈值可以是根据执行应用程序某一待执行任务的最长执行时间来确定的，也可以是根据经验值来进行设置。例如，可以设置应用程序无响应时间阈值为5秒或10秒，则相应的设置预设时间阈值大于等于5秒或者10秒。

本实施例中，待执行任务至少包含任务标识和待执行数据，同时还可以包含有执行体。应当理解的是执行体用于在用户交互线程或任务执行线程中处理数据。

用户交互消息管理器722将待执行任务打包成任务消息发给任务执行线程具体包括：判断待执行任务是否包含执行体，如是，从待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给任务执行线程，否则，直接从待执行任务中获取任务标识以及待执行数据打包成任务消息发给任务执行线程。

本实施例中，本实施例中，执行主控模块73还用于在任务执行线程中创建待执行消息队列731以及执行消息处理器732，参见图9，其中：

待执行消息队列731用于存储接收到的任务消息，并下发给执行消息处理器732；

执行消息处理器732用于从接收到的任务消息中提取任务标识以及待执行数据，并判断任务消息中是否包含执行体，如是，生成执行体对待执行数据进行执行；否则，根据任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对待执行数据进行执行。

应当理解的是，预设的任务标识与预置执行体对应关系是预先设置好的，其对应关系可以是通过图表等形式存储在终端内。

具体的，在执行消息处理器732判断任务消息不存在执行体的情况下，执行消息处理器732根据任务标识与预设的任务标识进行匹配，当从任务消息中提取到的任务标识与某一预设的任务标识匹配时，再根据预设的任务标识与预置执行体对应关系，提取出对应的预置执行体作为该任务消息的执行体，对待执行数据进行执行。

本实施例提供的终端，其具体结构可以如图1所示，其中线程创建模块71、用户交互主控模块72、执行主控模块73以及线程结束模块74的具体功能可以由图1中的控制器实现，线程创建模块71、用户交互主控模块72、执行主控模块73以及线程结束模块74可以设置在图1中的控制器内。

本实施例提供的终端，在应用程序启动时通过线程创建模块为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程；并通过用户交互主控模块在用户交互线程中，将收到的待执行任务打包成任务消息发给任务执行线程，使执行主控模块在任务执行线程中对待执行任务进行任务处理；并通过线程结束模块，在应用程序退出时，结束用户交互线程及任务执行线程。这样在任务执行线程中完成应用程序的一个待执行任务执行后，终端不会对任务执行线程销毁，而是继续在任务执行线程中执行应用程序的其他待执行任务，避免了任务执行线程的频繁创建，减少了系统开销，降低了程序复杂度，减少了维护成本。

第四实施例

本实施例在第三实施例的基础上，以只具有一个任务执行线程的处理流程为例，对本发明的方案作进一步示例说明。

本实施例中，在应用程序启动时，线程创建模块71为该应用程序创建用户交互线程，并为该用户交互线程创建一个任务执行线程。之后，参照图10，图10为本发明第四实施例提供的终端结构框架图，值得注意的是：

终端还包括的任务结果数据池75，任务结果数据池75用于存储各待执行任务的任务执行结果。

在任务执行线程中，执行主控模块73除了创建有待执行消息队列731以及执行消息处理器732之外，还创建有执行消息管理器733，执行消息处理器733用于在对待执行任务进行任务处理后，将得到的任务执行结果存储于任务结果数据池75中，并通过执行消息管理器733向用户交互线程反馈至少包含任务标识的任务处理完成消息。

在用户交互线程中，用户交互主控模块72除了创建有任务队列721、用户交互消息管理器722以及用户交互消息处理器723之外，还创建有用户交互消息队列724，用户交互消息队列724用于存储任务处理完成消息。

同时，在用户交互线程中，用户交互消息处理器723还用于根据任务处理完成消息中的任务标识从任务结果数据池75中提取出对应的任务处理结果。

应当理解的是，用户交互消息处理器723可以从用户交互消息队列724中得到任务处理完成消息。具体的，用户交互消息队列724可以主动告知用户交互消息处理器723任务处理完成消息，用户交互消息队列724也可以不告知用户交互消息处理器723，用户交互消息处理器723主动去用户交互消息队列724查询。

因此，在线程创建模块71创建好用户交互线程和任务执行线程之后，终端处理过程如下：

S1：任务队列721存储来自应用程序的待执行任务。

S2：用户交互消息管理器722对执行任务队列721中的待执行任务所需消耗的时间进行判断；将所需消耗的时间大于等于预设时间阈值的待执行任务打包成任务消息发给待执行消息队列731。

应当理解的是，用户交互消息管理器722将所需消耗的时间小于预设时间阈值的待执行任务发给用户交互消息处理器723进行处理时，可以直接将待执行任务发给用户交互消息处理器723进行处理(例如图10所示)，也可以将待执行任务先发给用户交互消息队列724，再由用户交互消息处理器723从用户交互消息队列724得到。值得注意的是，将待执行任务先发给用户交互消息队列724后，用户交互消息队列724可以对接收到的信息进行判断，区分出接收到的是已处理的任务处理完成消息，还是未处理的待执行任务，以便于用户交互消息处理器723得到，其具体方式可以是用户交互消息队列724主动将未处理的待执行任务发给用户交互消息处理器723，也可以是用户交互消息处理器723主动从用户交互消息队列724中查询获取。

还应当注意的是，用户交互消息管理器722发送给待执行消息队列731的任务消息至少包含待执行任务的任务标识以及待执行数据，对于待执行任务中包含执行体的，还应在任务消息中包含待执行任务的执行体。

S3:待执行消息队列731接收并存储用户交互消息管理器722发送的任务消息，并下发给执行消息处理器732。

S4:执行消息处理器732根据任务消息中包含的任务标识、待执行数据、以及执行体(没有执行体的根据任务标识提取预设执行体)对待执行数据进行执行。

S5:执行消息管理器733将得到的任务执行结果存储于任务结果数据池75中，同时向用户交互消息队列724反馈任务处理完成消息。

S6:用户交互消息处理器723根据任务处理完成消息中的任务标识从任务结果数据池75中提取出对应的任务处理结果。

应当理解的是，用户交互消息处理器723在根据任务处理完成消息中的任务标识从任务结果数据池中提取出对应的任务处理结果后，可以将任务处理结果反馈到显示界面以告知用户，当然也可以不反馈。用户交互消息处理器723直接处理的待执行任务得到的任务处理结果也可以反馈到显示界面以告知用户或不反馈。

本实施例中，本实施例提供的终端，其具体结构可以如图1所示，其中任务队列721、用户交互消息管理器722、用户交互消息处理器723、用户交互消息队列724、待执行消息队列731、执行消息处理器732和执行消息管理器733的具体功能可以由图1中的控制器实现，任务队列721、用户交互消息管理器722、用户交互消息处理器723、用户交互消息队列724、待执行消息队列731、执行消息处理器732和执行消息管理器733可以设置在图1中的控制器内。任务结果数据池75可以设置于图1中的存储器内，以存储任务处理结果。

本实施例提供的终端，在应用程序启动时通过线程创建模块为该应用程序创建用户交互线程，并为该用户交互线程创建任务执行线程；在用户交互线程中，用户交互消息管理器将执行时间大于等于预设时间阈值的待执行任务打包成任务消息发给任务执行线程中的待执行消息队列，使待执行任务在任务执行线程中的执行消息处理器进行任务处理；并由执行消息管理器将任务处理结果存储于任务结果数据池中，供用户交互线程中的用户交互消息处理器提取，避免了现有终端在任务执行线程中完成应用程序的一个待执行任务执行后就对任务执行线程销毁的情况的出现，提高了任务执行线程的利用率，避免了任务执行线程被频繁创建，减少了终端系统的开销，降低了程序复杂度，减少了维护成本。

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

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims (10)

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

在应用程序启动时为所述应用程序创建用户交互线程，并为所述用户交互线程创建任务执行线程；

在所述用户交互线程中，将收到的待执行任务打包成任务消息发给所述任务执行线程；

在所述任务执行线程中，对接收到的任务消息中的待执行任务进行任务处理；

在所述应用程序退出时，结束所述用户交互线程及任务执行线程。

2.如权利要求1所述的应用程序无响应处理方法，其特征在于，

在所述用户交互线程中，将收到的待执行任务打包成任务消息发给所述任务执行线程之前，还包括：

判断执行所述待执行任务所需的时间是否大于等于预设时间阈值，如否，则在所述用户交互线程中对该待执行任务进行处理；否则，对所述的待执行任务打包成任务消息发给所述任务执行线程；

所述预设时间阈值大于等于应用程序无响应时间阈值。

3.如权利要求1或2所述的应用程序无响应处理方法，其特征在于，将收到的待执行任务打包成任务消息发给所述任务执行线程包括：

判断所述待执行任务是否包含执行体，如是，从所述待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给所述任务执行线程；

否则，直接从所述待执行任务中获取任务标识以及待执行数据打包成任务消息发给所述任务执行线程。

4.如权利要求3所述的应用程序无响应处理方法，其特征在于，在所述任务执行线程中对所述待执行任务进行任务处理包括：

从所述任务消息中提取任务标识以及待执行数据，并判断所述任务消息中是否包含执行体，如是，生成所述执行体对所述待执行数据进行执行；否则，根据所述任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对所述待执行数据进行执行。

5.如权利要求4所述的应用程序无响应处理方法，其特征在于，还包括：

在所述任务执行线程中对所述待执行任务进行任务处理后，将得到的任务执行结果存储于任务结果数据池中，并向所述用户交互线程反馈至少包含任务标识的任务处理完成消息；

在所述用户交互线程中，根据所述任务处理完成消息中的任务标识从所述任务结果数据池中提取对应的任务处理结果。

6.一种终端，其特征在于，包括：

线程创建模块，用于在应用程序启动时为所述应用程序创建用户交互线程，并为所述用户交互线程创建任务执行线程；

用户交互主控模块，用于在所述用户交互线程中，将收到的待执行任务打包成任务消息发给所述任务执行线程；

执行主控模块，用于在所述任务执行线程中，对接收到的任务消息中的待执行任务进行任务处理；

线程结束模块，用于在所述应用程序退出时，结束所述用户交互线程及任务执行线程。

7.如权利要求6所述的终端，其特征在于，

所述用户交互主控模块用于在所述用户交互线程中创建任务队列、用户交互消息管理器以及用户交互消息处理器；

所述任务队列用于存储待执行任务；

所述用户交互消息管理器用于判断执行所述任务队列中的待执行任务所需消耗的时间是否大于等于预设时间阈值，如否，将所述待执行任务发给所述用户交互消息处理器进行处理；否则，对所述的待执行任务打包成任务消息发给所述任务执行线程；

所述预设时间阈值大于等于应用程序无响应时间阈值。

8.如权利要求6或7所述的终端，其特征在于，

所述用户交互消息管理器用于判断所述待执行任务是否包含执行体，如是，从所述待执行任务中获取待执行体、任务标识以及待执行数据打包成任务消息发给所述任务执行线程，否则，直接从所述待执行任务中获取任务标识以及待执行数据打包成任务消息发给所述任务执行线程。

9.如权利要求8所述的终端，其特征在于，

所述执行主控模块用于在所述任务执行线程创建待执行消息队列以及执行消息处理器；

所述待执行消息队列用于存储接收到的任务消息，并下发给所述执行消息处理器；

所述执行消息处理器用于从接收到的任务消息中提取任务标识以及待执行数据，并判断所述任务消息中是否包含执行体，如是，生成所述执行体对所述待执行数据进行执行；否则，根据所述任务标识和预设的任务标识与预置执行体对应关系，提取对应的预置执行体对所述待执行数据进行执行。

10.如权利要求9所述的终端，其特征在于，

所述执行主控模块还用于在所述任务执行线程创建执行消息管理器；

所述执行消息处理器还用于在对所述待执行任务进行任务处理后，将得到的任务执行结果存储于任务结果数据池中，并通过所述执行消息管理器向所述用户交互线程反馈至少包含任务标识的任务处理完成消息；

所述用户交互主控模块还用于在所述用户交互线程中创建用于存储任务处理完成消息的用户交互消息队列；

所述用户交互消息处理器还用于根据所述任务处理完成消息中的任务标识从所述任务结果数据池中提取对应的任务处理结果。