CN116610479A - 一种自动监测故障方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请涉及程序运维技术领域，提供了一种自动监测故障方法、装置、电子设备及可读存储介质。该方法包括：当消息队列收到目标任务，执行目标任务，并记录目标任务的执行信息；判断执行信息是否符合正常运行条件；若否，判定目标任务执行故障，将执行信息上传至云平台；在目标任务的执行程序中，每个函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；执行信息包括目标任务的开始时间、目标任务的结束时间、第一记录函数的记录信息和第二记录函数的记录信息。本申请实施例有效克服了概率性出现的故障难以复现的问题，有助于故障的精准定位。

Description

一种自动监测故障方法、装置、电子设备及可读存储介质

技术领域

本申请涉及程序运维技术领域，尤其涉及一种自动监测故障方法、装置、电子设备及可读存储介质。

背景技术

现今Android应用程序在运维时，难以精准定位故障和故障概率性出现的特点成为解决故障的难题。其中，精准定位故障要求在分析程序运行时真实函数调用关系和具体函数的执行耗时，概率性出现的故障难以复现，要求故障出现时系统能够及时记录资源使用情况。

当前能够对程序的运行情况进行记录并分析的方法，主要在应用程序的开发和测试时，通过第三方工具记录运行情况，再将第三方软件的记录文件上传至电脑中由特定软件对运行中的故障进行分析。但在运维阶段，技术人员无法使用第三方工具，当前现有的调试框架，均无法及时获取概率性出现的故障的信息，也很难做到故障的精准定位，导致故障难以解决。

因此，如何提供一种解决上述技术问题的方案是目前本领域技术人员需要解决的问题。

发明内容

有鉴于此，本申请实施例提供了一种自动监测故障方法、装置、电子设备及可读存储介质，以解决现有技术中调试框架无法为故障分析提供有效信息的问题。

本申请实施例的第一方面，提供了一种自动监测故障方法，包括：

当消息队列收到目标任务，执行目标任务，并记录目标任务的执行信息；

判断执行信息是否符合正常运行条件；

若否，判定目标任务执行故障，将执行信息上传至云平台；

在目标任务的执行程序中，每个初始函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个初始函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；

执行信息包括目标任务的开始时间、目标任务的结束时间、第一记录函数的记录信息和第二记录函数的记录信息。

本申请实施例的第二方面，提供了一种自动监测故障装置，包括：

记录模块，用于当消息队列收到目标任务，执行目标任务，并记录目标任务的执行信息；

判断模块，用于判断执行信息是否符合正常运行条件；

动作模块，用于当执行信息不符合正常运行条件，判定目标任务执行故障，将执行信息上传至云平台；

在目标任务的执行程序中，每个初始函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个初始函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；

执行信息包括目标任务的开始时间、目标任务的结束时间、第一记录函数的记录信息和第二记录函数的记录信息。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种可读存储介质，该可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果至少包括：本申请实施例通过在执行目标任务的过程中记录任务执行信息、在执行信息不符合正常运行条件时判定目标任务执行故障、将执行信息上传云平台的步骤，有效克服了概率性出现的故障难以复现的问题，及时将发生故障的执行信息上传到云平台，有助于故障的精准定位和后续处理，提高了故障处理的效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本申请实施例的一种应用场景的场景示意图；

图2是本申请实施例提供的一种自动监测故障方法的流程示意图；

图3是本申请实施例提供的一种具体的自动监测故障方法的流程示意图；

图4是本申请实施例提供的一种自动监测故障装置的结构示意图；

图5是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

下面将结合附图详细说明根据本申请实施例的一种自动监测故障方法、装置、电子设备及可读存储介质。

图1是本申请实施例的应用场景的场景示意图。该应用场景可以包括终端设备101、102和103、服务器104以及网络105。

终端设备101、102和103可以是硬件，也可以是软件。当终端设备101、102和103为硬件时，其可以是具有显示屏且支持与服务器104通信的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等；当终端设备101、102和103为软件时，其可以安装在如上所述的电子设备中。终端设备101、102和103可以实现为多个软件或软件模块，也可以实现为单个软件或软件模块，本申请实施例对此不作限制。进一步地，终端设备101、102和103上可以安装有各种应用，例如数据处理应用、即时通信工具、社交平台软件、搜索类应用、购物类应用等。

服务器104可以是提供各种服务的服务器，例如，对与其建立通信连接的终端设备发送的请求进行接收的后台服务器，该后台服务器可以对终端设备发送的请求进行接收和分析等处理，并生成处理结果。服务器104可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者还可以是一个云计算服务中心，本申请实施例对此不作限制。

需要说明的是，服务器104可以是硬件，也可以是软件。当服务器104为硬件时，其可以是为终端设备101、102和103提供各种服务的各种电子设备。当服务器104为软件时，其可以是为终端设备101、102和103提供各种服务的多个软件或软件模块，也可以是为终端设备101、102和103提供各种服务的单个软件或软件模块，本申请实施例对此不作限制。

网络105可以是采用同轴电缆、双绞线和光纤连接的有线网络，也可以是无需布线就能实现各种通信设备互联的无线网络，例如，蓝牙(Bluetooth)、近场通信(Near FieldCommunication，NFC)、红外(Infrared)等，本申请实施例对此不作限制。

需要说明的是，终端设备101、102和103、服务器104以及网络105的具体类型、数量和组合可以根据应用场景的实际需求进行调整，本申请实施例对此不作限制。

图2是本申请实施例提供的一种自动监测故障方法的流程示意图。图2的自动监测故障方法可以由图1的终端设备执行。如图2所示，该自动监测故障方法包括：

S201：当消息队列收到目标任务，执行目标任务，并记录目标任务的执行信息；

S202：判断执行信息是否符合正常运行条件；

S203：若否，判定目标任务执行故障，将执行信息上传至云平台；

在目标任务的执行程序中，每个初始函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个初始函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；

执行信息包括目标任务的开始时间、目标任务的结束时间、第一记录函数的记录信息和第二记录函数的记录信息。

执行目标任务，意味着读取目标任务的执行程序并运行，传统方案的执行程序中包括实现目标任务所需的多个初始函数，运行执行程序的过程中各初始函数将被调用。本申请实施例在原本的执行程序的基础上，在每个初始函数的端点处增设了第一记录函数和第二记录函数，即在初始函数的函数入口标识符后设置第一记录函数，在初始函数的函数出口标识符前设置第二记录函数，每个初始函数执行前都会先执行第一记录函数，每个初始函数结束前都会执行第二记录函数。第一记录函数和第二记录函数均用于记录自身调用时刻，考虑到第一记录函数和第二记录函数的位置，第一记录函数的记录信息也就是对应的初始函数的开始执行时刻，第二记录函数的记录信息也就是对应的初始函数的结束执行时刻。

消息队列中每个任务的执行过程通常存在一个是否正常运行的判定标准，本实施例中执行信息包括目标任务的开始时间、结束时间、第一记录函数的记录信息和第二记录函数的记录信息，这些信息均属于时间信息，因此利用执行信息分析目标任务的执行过程是否正常时，判定标准以时间为判断参量，正常运行条件对应特定的时间范围，一旦超出该时间范围，则认为目标任务执行故障。对于频繁执行的目标任务，或初始函数较多较复杂的目标任务，如果直接利用执行信息计算每个初始函数的执行耗时再观察是否超出初始函数的正常耗时范围，将耗费较多资源。况且发生初始函数的执行耗时超出正常耗时范围的情况并不多见，如果每次都以初始函数作为判断对象，其判断动作所占用的资源将造成较大浪费。

为了降低资源占用，可选择通过目标任务的整体完成情况进行宏观判断，因此在一些具体的实施例中，步骤S202判断执行信息是否符合正常运行条件的过程，包括：根据开始时间和结束时间，计算目标任务的执行耗时；判断执行耗时是否超出预设耗时区间；若是，判定执行信息不符合正常运行条件；若否，判定执行信息符合正常运行条件。这种方式能够在资源占用较少的情况下，快速且准确地确定目标任务是否发生执行故障。

除了直接通过目标任务的执行耗时判断执行信息是否符合正常运行条件外，还可以从所有初始函数中挑选部分重点初始函数作为判断对象，利用第一记录函数和第二记录函数的记录信息确定重点函数对象的函数执行耗时，然后判断函数执行耗时是否超出预设函数耗时区间。

此时正常运行条件与函数执行耗时超出预设函数耗时区间的重点函数对象相关，可根据多方面因素来设置，例如根据每个重点初始函数的重要性、目标任务的整体完成情况的权重占比，对每个函数执行耗时的判断结果、目标任务的执行耗时结果进行打分，最后根据总分是否处于正常分值区间来判断是否符合正常运行条件；也可以设置每个函数执行耗时的判断结果、目标任务的执行耗时结果与正常运行条件的逻辑关系，例如一旦目标任务的执行耗时超出预设耗时区间，则直接判定执行信息不符合正常运行条件；若执行耗时未超出预设耗时区间，再判断每个重点初始函数的函数执行耗时是否超出对应的预设函数耗时区间，如果超出预设函数耗时区间的重点初始函数的个数超出预设个数，则判定执行信息不符合正常运行条件；还可以在目标任务的执行耗时为首要判断条件的前提下，对重点初始函数再分级，如正常运行条件中允许超出预设函数耗时区间的A级重点初始函数、B级重点初始函数的预设个数不同，对象分类手法上，对初始函数再分级与上一权重占比的思路类似，但是逻辑关系上再分级的判断处理速度更快，不要求必须遍历所有执行信息，可更快地获得判断结果，计算量明显更小。此处关于重点初始函数的权重、预设个数、预设函数耗时区间、预设耗时区间，均可根据用户需求或故障敏感度要求进行设置。

当判定执行信息不符合正常运行条件，执行步骤S203，将执行信息上传云平台，技术人员可通过云平台查看执行信息并对故障进行定位、分析和处理，除了上传云平台，执行步骤S203的程序处可支持外部接口扩展，扩展内容不作限制。

当判定执行信息符合正常运行条件，判定目标任务执行正常，此时执行信息不需要上传云平台，如果信息价值较低，可以被删除或覆盖，则判断执行信息是否符合正常运行条件之后，还包括：若是，清除执行信息。但如果存在一定的信息价值，也可暂存或上传至云平台，具体处理方式根据用户设置进行。

本申请实施例可应用于任何目标任务的执行过程中来检测目标任务是否发生执行故障，目标任务的执行环境通常为Android应用程序框架，目标任务可以是偶发低频次的目标任务，也可以是重复高频次的目标任务，例如UI绘制任务。Android应用程序框架下，UI(User Interface，用户界面)按照一定的频率进行刷新，具体可按照垂直同步机制刷新，具体可按16ms的间隔刷新，也称为一帧，每次刷新都会执行若干绘制指令将UI元素的位置、大小、样式等信息传递给GPU进行解析执行，如果每次刷新所要执行的绘制指令都能在16ms内执行完成，可视为流畅，反之则视为卡顿，也即掉帧。这些绘制指令的集合被视为UI绘制任务，每执行一次UI绘制任务，则完成一次刷新操作，如果UI绘制任务的执行耗时超出16ms，可判定执行信息不符合正常运行条件，UI任务执行故障，该场景中预设耗时区间为(0，16ms)。根据本申请实施例的方法对高频次的目标任务的执行进行持续监测，可及时发现执行故障并将执行信息上传云平台，有效克服了原本概率性出现的故障难以复现、难以定位的问题。

本申请实施例通过在执行目标任务的过程中记录任务执行信息、在执行信息不符合正常运行条件时判定目标任务执行故障、将执行信息上传云平台的步骤，有效克服了概率性出现的故障难以复现的问题，及时将发生故障的执行信息上传到云平台，有助于故障的精准定位和后续处理，提高了故障处理的效率。

本发明实施例公开了一种具体的自动监测故障方法，相对与上一实施例，本实施例对技术方案做了进一步的说明和优化。

Android应用程序框架提供了choreographer组件，该组件支持每一帧UI绘制任务开始前进行监听，可利用该组件来实现本申请实施例的方法。

因此当消息队列收到目标任务，执行目标任务，并记录目标任务的执行信息的过程，包括：当消息队列收到目标任务，通过choreographer组件记录目标任务的开始时间，执行目标任务；通过消息队列的监听任务监听目标任务的结束状态，并记录目标任务执行结束时的结束时间。

Choreographer组件记录开始时间前，需要首先遍历回调函数(callback函数)，因为应用绘制是连续的，所以消息队列中第一条会是上一次执行目标任务时插入的预设回调函数，所有预设回调函数会首先被执行。

因此当消息队列收到目标任务，通过choreographer组件记录目标任务的开始时间，执行目标任务的过程，包括：

当消息队列收到目标任务，执行预设回调函数，然后记录目标任务的开始时间，执行目标任务；预设回调函数为上次执行目标任务时插入choreographer组件的回调函数队列头部的回调函数。

相应的通过消息队列的监听任务监听目标任务的结束状态，并记录目标任务执行结束时的结束时间之后，还包括：在choreographer组件的回调函数队列头部插入预设回调函数。该动作为下一次绘制备用，以此形成每一帧的连续绘制耗时监听。预设回调函数的插入和执行利用了java动态hook技术，实现了对Android系统中choreographer组件的绘制监控，准确有效确定了每次UI绘制任务的执行耗时。

根据以上描述，可得到图3所示的一种具体的自动监测故障方法的流程示意图。图3的自动监测故障方法可以由图1的终端设备执行。如图3所示，该自动监测故障方法包括：

S301：当消息队列收到目标任务，执行预设回调函数，然后记录目标任务的开始时间，执行目标任务；

S302：通过消息队列的监听任务监听目标任务的结束状态，并记录目标任务执行结束时的结束时间；

S303：在choreographer组件的回调函数队列头部插入预设回调函数；

S304：判断执行信息是否符合正常运行条件；若否，执行S305，若是，执行S306；

S305：判定目标任务执行故障，将执行信息上传至云平台；

S306：判定目标任务执行正常，清除执行信息。

根据垂直同步机制，消息队列收到目标任务有垂直同步信号触发，即当垂直同步信号进入应用进程，Android系统会自动向消息队列插入一条目标任务。

这里仅出现了目标任务的开始时间和结束时间，但由于目标任务的执行程序中设有第一记录函数和第二记录函数，在目标任务的执行过程中还将获得所有第一记录函数的记录信息和第二记录函数的记录信息，所有的执行信息可生成日志以便上传云平台。

本发明实施例公开了一种具体的自动监测故障方法，相对与上一实施例，本实施例对技术方案做了进一步的说明和优化。

传统方案的执行程序中包括实现目标任务所需的多个初始函数，运行执行程序的过程中各初始函数将被调用。本申请实施例在原本的执行程序的基础上，在每个初始函数的端点处增设了第一记录函数和第二记录函数，即在初始函数的函数入口标识符后设置第一记录函数，在初始函数的函数出口标识符前设置第二记录函数，具体的，第一记录函数和第二记录函数在编译执行程序时设置于执行程序的字节码文件中，可在执行程序的编译阶段对执行程序的原字节码文件进行修改，原字节码文件包含编译后的多个初始函数，对原字节码文件中每个初始函数的函数入口标识符后和函数出口标识符前分别增加第一记录函数和第二记录函数生成本实施例中的字节码文件，用于执行目标任务。该修改环境为Android Studio工程中，修改工具可选择ASM工具，这是一套开源的修改工具，可以对每个字节码文件进行字节码级别的内容修改。可在执行程序的编译阶段对执行程序的原字节码文件进行修改的动作，可通过预设编译插件来实现。具体的，在Android Studio工程中通过Transform API(Application Programming Interface，应用程序编程接口)调用预设编译插件，预设编译插件利用ASM工具实现以下动作：对原字节码文件中每个初始函数的函数入口标识符后和函数出口标识符前分别增加第一记录函数和第二记录函数生成本实施例中的字节码文件，用于执行目标任务。

每个初始函数对应一个第一记录函数和一个第二记录函数，为确保数据不发生混淆，可遍历原字节码文件的初始函数，对每个初始函数标记唯一的函数ID，后续第一记录函数、第二记录函数的数据记录都联系该函数ID建立对应关系。第一记录函数的记录信息和第二记录函数的记录信息都是自身被调用的时刻，可记录在调用记录缓存队列buffer中，具体的记录信息的数据结构可根据实际情况进行设置，此处不作限制。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图4是本申请实施例提供的一种自动监测故障装置的示意图。如图4所示，该自动监测故障装置包括：

记录模块401，用于当消息队列收到目标任务，执行目标任务，并记录目标任务的执行信息；

判断模块402，用于判断执行信息是否符合正常运行条件；

动作模块403，用于当执行信息不符合正常运行条件，判定目标任务执行故障，将执行信息上传至云平台；

在目标任务的执行程序中，每个初始函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个初始函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；

执行信息包括目标任务的开始时间、目标任务的结束时间、第一记录函数的记录信息和第二记录函数的记录信息。

本申请实施例通过在执行目标任务的过程中记录任务执行信息、在执行信息不符合正常运行条件时判定目标任务执行故障、将执行信息上传云平台的步骤，有效克服了概率性出现的故障难以复现的问题，及时将发生故障的执行信息上传到云平台，有助于故障的精准定位和后续处理，提高了故障处理的效率。

在一些具体的实施例中，记录模块401具体用于：

当消息队列收到目标任务，通过choreographer组件记录目标任务的开始时间，执行目标任务；

通过消息队列的监听任务监听目标任务的结束状态，并记录目标任务执行结束时的结束时间。

在一些具体的实施例中，当消息队列收到目标任务，通过choreographer组件记录目标任务的开始时间，执行目标任务的过程，包括：

当消息队列收到目标任务，执行预设回调函数，然后记录目标任务的开始时间，执行目标任务；预设回调函数为上次执行目标任务时插入choreographer组件的回调函数队列头部的回调函数，

相应的，通过消息队列的监听任务监听目标任务的结束状态，并记录目标任务执行结束时的结束时间之后，还包括：

在choreographer组件的回调函数队列头部插入预设回调函数。

在一些具体的实施例中，判断模块402具体用于：

根据开始时间和结束时间，计算目标任务的执行耗时；

判断执行耗时是否超出预设耗时区间；

若是，判定执行信息不符合正常运行条件；

若否，判定执行信息符合正常运行条件。

在一些具体的实施例中，第一记录函数和第二记录函数在编译执行程序时设置于执行程序的字节码文件中。

在一些具体的实施例中，动作模块403判断执行信息是否符合正常运行条件之后，还包括：

若是，清除执行信息。

在一些具体的实施例中，目标任务为UI绘制任务。

图5是本申请实施例提供的电子设备5的示意图。如图5所示，该实施例的电子设备5包括：处理器501、存储器502以及存储在该存储器502中并且可在处理器501上运行的计算机程序503。处理器501执行计算机程序503时实现上述各个方法实施例中的步骤。或者，处理器501执行计算机程序503时实现上述各装置实施例中各模块/单元的功能。

电子设备5可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备5可以包括但不仅限于处理器501和存储器502。本领域技术人员可以理解，图5仅仅是电子设备5的示例，并不构成对电子设备5的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器501可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器502可以是电子设备5的内部存储单元，例如，电子设备5的硬盘或内存。存储器502也可以是电子设备5的外部存储设备，例如，电子设备5上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器502还可以既包括电子设备5的内部存储单元也包括外部存储设备。存储器502用于存储计算机程序以及电子设备所需的其它程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。可读存储介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，可读存储介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，可读存储介质不包括电载波信号和电信信号。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种自动监测故障方法，其特征在于，包括：

当消息队列收到目标任务，执行所述目标任务，并记录所述目标任务的执行信息；

判断所述执行信息是否符合正常运行条件；

若否，判定所述目标任务执行故障，将所述执行信息上传至云平台；

在所述目标任务的执行程序中，每个初始函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个所述初始函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；

所述执行信息包括所述目标任务的开始时间、所述目标任务的结束时间、所述第一记录函数的记录信息和所述第二记录函数的记录信息。

2.根据权利要求1所述的方法，其特征在于，所述目标任务为UI绘制任务。

3.根据权利要求2所述的方法，其特征在于，当消息队列收到目标任务，执行所述目标任务，并记录所述目标任务的执行信息的过程，包括：

当消息队列收到目标任务，通过choreographer组件记录所述目标任务的开始时间，执行所述目标任务；

通过所述消息队列的监听任务监听所述目标任务的结束状态，并记录所述目标任务执行结束时的结束时间。

4.根据权利要求3所述的方法，其特征在于，当消息队列收到目标任务，通过choreographer组件记录所述目标任务的开始时间，执行所述目标任务的过程，包括：

当消息队列收到目标任务，执行预设回调函数，然后记录所述目标任务的开始时间，执行所述目标任务；所述预设回调函数为上次执行所述目标任务时插入choreographer组件的回调函数队列头部的回调函数；

相应的，通过所述消息队列的监听任务监听所述目标任务的结束状态，并记录所述目标任务执行结束时的结束时间之后，还包括：

在所述choreographer组件的回调函数队列头部插入所述预设回调函数。

5.根据权利要求1所述的方法，其特征在于，判断所述执行信息是否符合正常运行条件的过程，包括：

根据所述开始时间和所述结束时间，计算所述目标任务的执行耗时；

判断所述执行耗时是否超出预设耗时区间；

若是，判定所述执行信息不符合正常运行条件；

若否，判定所述执行信息符合所述正常运行条件。

6.根据权利要求1所述的方法，其特征在于，判断所述执行信息是否符合正常运行条件之后，还包括：

若是，清除所述执行信息。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述第一记录函数和所述第二记录函数在编译所述执行程序时设置于所述执行程序的字节码文件中。

8.一种自动监测故障装置，其特征在于，包括：

记录模块，用于当消息队列收到目标任务，执行所述目标任务，并记录所述目标任务的执行信息；

判断模块，用于判断所述执行信息是否符合正常运行条件；

动作模块，用于当所述执行信息不符合所述正常运行条件，判定所述目标任务执行故障，将所述执行信息上传至云平台；

在所述目标任务的执行程序中，每个初始函数的函数入口标识符后均设有一个记录自身调用时刻的第一记录函数，每个所述初始函数的函数出口标识符前均设有一个记录自身调用时刻的第二记录函数；

所述执行信息包括所述目标任务的开始时间、所述目标任务的结束时间、所述第一记录函数的记录信息和所述第二记录函数的记录信息。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述方法的步骤。

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