应用运行状态监测方法、装置、终端及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种应用运行状态监测方法、装置、终端及存储介质。

背景技术

React Native是目前流行的跨平台移动应用开发框架之一，可以使用React(Web开发框架)和安卓(Android)或iOS的原生功能来构建混合移动应用。随着React Native被广泛使用，基于React Native开发的混合移动应用越来越多，人们对这些混合移动应用的体验要求不断提高，期望对应用的页面性能进一步的优化。这就需要一种方案能够监测混合移动应用的运行状态，定位混合移动应用页面卡顿的代码位置，以便于对造成混合移动应用页面卡顿的代码进行优化，从而提高混合移动应用的页面性能。

发明内容

本申请的多个方面提供一种应用运行状态监测方法、装置、终端及存储介质，用以监测混合移动应用的运行状态，定位引起混合移动应用页面卡顿的代码位置，以便于对造成混合移动应用页面卡顿的代码进行优化，从而提高混合移动应用的页面性能，提高用户使用体验。

本申请实施例提供一种应用运行状态监测方法，包括：在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时，混合移动应用包含多个用于响应页面请求的目标函数；以单线程方式，在定时器每次定时期间，依次执行被触发的目标函数，并利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息；在定时器每次被回调时，获取定时器每次的实际定时时长，若实际定时时长大于时长阈值，根据已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。

本申请实施例还提供一种应用运行状态监测装置，包括：启动模块，用于在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时，混合移动应用包含多个用于响应页面请求的目标函数；执行模块，用于以单线程方式，在定时器每次定时期间，依次执行被触发的目标函数，并利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息；获取模块，用于在定时器每次被回调时，获取定时器每次的实际定时时长，若实际定时时长大于时长阈值，根据已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；输出模块，用于输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。

本申请实施例还提供一种移动终端，包括：存储器和处理器；存储器用于存储混合移动应用对应的目标程序代码，处理器与存储器耦合，用于执行目标程序代码，以用于实现以上所述方法中的步骤；其中，目标程序代码是对混合移动应用对应的源程序代码进行编译得到的。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器能够实现以上所述的应用运行状态监测方法中的步骤。从而达到监测被触发的目标函数执行时长的目的。

本申请各实施例提供的技术方案，针对支持单线程运行的混合移动应用，为了监测其运行状态，实现了一种具有设定的时长阈值且具有循环定时功能的定时器，在启动混合移动应用时一并启动该定时器，在定时器每次定时期间，以单线程方式依次执行被触发的目标函数，同时利用预先在目标函数中插装的记录代码记录在定时器每次定时期间被执行的目标函数的标识信息及目标函数的执行时间，在定时器每次被回调时，结合定时器每次的实际定时时长，便可以得到在其实际定时时长大于设定的时长阈值的情况下，在该实际定时时长内执行的目标函数的标识信息，这些目标函数可能是导致混合移动应用的页面卡顿的函数，通过这些目标函数可以对混合移动应用的页面卡顿情况进行分析，以便于对导致混合移动应用的页面卡顿的目标函数进行优化，从而提高混合移动应用的页面性能及用户使用体验。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的应用运行状态监测方法的流程示意图；

图2为本申请一示例性实施例提供的应用运行状态监测装置的结构示意图；

图3为本申请一示例性实施例提供的移动终端的结构示意图。

具体实施方式

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

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

图1为本申请一示例性实施例提供的应用运行状态监测方法的流程示意图。如图1所示，该方法包括：

101、在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时，混合移动应用包含多个用于响应页面请求的目标函数；

102、以单线程方式，在定时器每次定时期间，依次执行被触发的目标函数，并利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息；

103、在定时器每次被回调时，获取定时器每次的实际定时时长，若实际定时时长大于时长阈值，根据已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；

104、输出在上述大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。

移动终端上可以运行混合移动应用，本申请实施例对移动终端的类型不作限定，例如，是智能手机、笔记本电脑或台式电脑等。对混合移动应用的类型也不作限定，例如，游戏类应用、金融类应用、房产类应用，房产类可以是租售房应用、看房应用等。混合移动应用是由跨平台移动应用开发框架开发的，申请实施例中，混合移动应用可以是基于ReactNative开发框架开发的，但不仅限于此。

在本实施例中，混合移动应用中包含实现各种功能的函数，这些函数包括系统函数和React Native开发框架开发的非系统函数。在这些非系统函数中，有一些函数是用于响应页面请求的，有一些函数是负责底层逻辑处理的，例如负责与服务端进行交互的函数。为便于区分，在本实施例中，将混合移动应用中包含的用于响应页面请求的函数称为目标函数。目标函数可以是一个或多个，这些目标函数都是开发人员基于React Native开发框架开发的，不属于系统函数。其中，混合移动应用在运行期间可向用户提供各种页面，例如首页面、登录页面以及各种具体业务页面等。这些页面上设置有一个或多个交互控件，用于供用户发起交互操作。其中，交互控件可以是任何能够响应用户触发操作并将用户触发操作转换为具体页面请求的控件形式，例如可以是视窗、文本框、按钮、下拉式菜单等。需要说明的是，页面的功能和类型不同，页面上设置的交互控件也会有所不同，本申请实施例对此不做限定。对用户来说，可以通过混合移动应用提供的任何页面上的任何交互控件向混合移动应用发起页面请求。也就是说，页面请求是混合移动应用在运行期间响应于用户对混合移动应用提供的各个页面上的交互控件的触发操作生成的。进一步，在混合移动应用运行期间还需要根据该页面请求，执行能够响应该页面请求的目标函数；最后，获取目标函数的执行结果或/或执行过程中产生的中间态数据，将执行结果和/或中间态数据作为该页面请求对应的响应数据输出给用户。可选地，为了便于描述和区分，将用户发起页面请求的页面记为第一页面，则该响应数据可以被直接作为第一页面上的嵌入式内容，直接显示在第一页面上；或者，该响应数据也可以以浮窗或浮层形式显示在第一页面上；或者，该响应数据也可以作为新的页面数据被显示在与第一页面关联的第二页面上，关于输出上述响应数据的方式本申请实施例不做限定。

在本实施例中，以混合移动应用是看房应用为例，看房应用具有一个或多个功能，每个功能对应一个目标函数，如房屋分类、查找等功能，相应的，在看房应用的页面上会显示有“分类”、“查找”等控件，在用户有需求时，可以触发“分类”、“查找”等控件，生成与“分类”、“查找”等控件对应的页面请求，混合移动应用可响应于与“分类”、“查找”等控件对应的页面请求，分别执行对应的目标函数，例如房屋分类函数、“查找函数”，并在相关页面上展示对房屋进行分类后的房屋列表信息或符合查找条件的房屋列表信息，以实现看房应用的“分类”、“查找”等功能。另外，需要说明的是，本实施例的混合移动应用支持单线程运行，即在混合应用运行过程中，同一时间只能有一个函数占用处理器资源，被处理器执行而处于运行状态，各函数按照顺序依次被执行。

在混合移动应用运行过程中，可能发生页面卡顿的现象。页面卡顿的现象是指页面请求的响应时间超过了设定的时长阈值，其中，页面请求的响应时间是指从用户触发页面请求开始到向用户输出响应数据的时间，该响应时间一旦超过了设定的时长阈值，就表示超出了用户可承受的等待时间，用户会有明显的卡顿感觉，也就是出现了的页面卡顿现象。在本实施例中，同一混合移动应用中各页面请求可以对应同一时长阈值。在本申请实施例中，该时长阈值可以反映从用户触发页面请求到向用户输出响应数据，用户所能承受的最大等待时间。关于该时长阈值可以通过测试方式来确定，具体地，可以让大量用户触发各种页面请求，并获取大量用户从触发各种页面请求到向用户返回响应数据时用户认为没有产生明显卡顿感觉的最大等待时间，根据大量用户所能承受的最大等待时间确定该时长阈值。例如，可以通过对大量用户所能承受的最大等待时间进行平均，将平均时间作为该时长阈值，或者也可以将所有最大等待时间中最大或最小的等待时间作为该时长阈值。另外，需要说明的是，该测试过程可以是专门针对本申请实施例提供的混合移动应用自身发起的测试，也就是说大量用户都是通过该混合移动应用提供的页面触发各种页面请求的，但并不限于此。例如，该测试过程也可以是针对多种支持人机交互的应用进行的，即不同用户可以通过不同应用提供的页面触发页面请求，进而根据获取到的大量用户所能承受的最大等待时间确定该时长阈值。例如，假设经过上述测试过程得到该时长阈值为1s，则用户触发页面上某个控件之后，等待了1s时间，页面依旧没有响应，或者页面依旧没有返回正确的页面数据，而是一直处于请求或等待状态，将这种现象称为页面卡顿现象。其中，引起页面卡顿现象的原因可能是混合移动应用中某些目标函数的开发不够合理，例如代码冗余度较大，导致运行超时，或者是，代码逻辑不够合理导致死循环等等。

因此，在混合移动应用的运行期间，需要监测混合移动应用中各目标函数的运行状态，定位引起混合移动应用页面卡顿的代码位置，以便于通过优化代码来改善混合移动应用的运行性能，解决页面卡顿的问题。

进一步，在本申请实施例中，为了能够监测混合移动应用中各目标函数的运行状态，改善页面卡顿问题，一方面，在混合移动应用开发过程中，参考看门狗程序，实现了一种定时器，该定时器会随着混合移动应用的启动而启动，用于按照上文提到的设定的时长阈值周期性循环定时。定时器的启动需要占用CPU资源，在定时器启动后的定时期间，定时器会被挂起，即会释放出CPU资源，CPU可以执行其它函数，这里的CPU资源是指运行该混合移动应用的移动终端的CPU资源。在定时器定时被挂起期间，如果混合移动应用提供的页面上的交互控件被用户触发(例如交互控件被点击、长按或双击等)，则CPU会响应于页面上交互控件的触发操作，生成与被触发的交互控件对应的页面请求，并执行该页面请求对应的目标函数，即CPU会执行该目标函数，直至目标函数运行完成，CPU资源才会被释放。

需要说明的是，如果定时器计时到达设定的时长阈值，但CPU资源未被释放，此时定时器会因为无法获得CPU资源而继续处于挂起状态，直至能够重新获得CPU资源才会被回调。然而，定时器在挂起期间会持续定时，这就有可能出现定时器的实际定时时长大于设定的时长阈值的情况；当定时器被回调时，可以执行与定时器绑定的一些函数或事件，当然，定时器也可以不绑定其它事件或函数，在本实施例中，当定时器被回调时，定时器会结束本轮定时任务并继续下一轮定时，从而实现循环定时；通过循环定时，可在混合移动应用运行期间持续监测被执行到的各目标函数中哪些目标函数在何时被执行会引起页面卡顿。需要说明的是，本实施例提供的混合移动应用状态监测方法的执行主体可以是运行该混合移动应用的移动终端，也可以是测试移动终端，还可以是混合移动应用的开发端等，即在得到混合移动应用之后，不论是在哪个阶段，凡是能够运行该混合移动应用的设备都可以采用本申请实施例提供的方法对混合移动应用的运行状态进行监测。

具体地，在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时。移动终端的CPU可以以单线程的方式依次执行混合移动应用包含的各函数，被依次执行的各函数包括定时器和目标函数。可选地，定时器可以属于混合移动应用中包含的一种函数，但不属于系统函数，在该情况下定时器会随着混合移动应用的启动而启动；或者，定时器也可以是独立于混合移动应用之外实现，但与混合移动应用关联，且需要能够随着混合移动应用的启动而启动，并在混合移动应用运行期间能够循环定时。在定时器每次定时期间，CPU会按照单线程方式依次执行被触发的目标函数，在目标函数中插装有记录代码，因此，在目标函数被执行期间，这些记录代码会被一并执行，因此可利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息以及其它信息，标识信息可以为目标函数的类名、方法名等可唯一标识目标函数的信息。下面以渲染函数render()为例，给出插装前的部分程序代码与插装后对应的程序代码分别如下：

插装前：

render(){

if(this.state.isError){

return this.renderErrorView()；

}

return this.renderViews()；

}

插装后：

render(){

global.callStack.unshift(new Date().getTime()+类名+方法名)

if(this.state.isError){

return this.renderErrorView()；

}

return this.renderViews()；

}

上述插装前的部分程序代码与插装后对应的程序代码相比，增加了“global.callStack.unshift(new Date().getTime()+类名+方法名)”语句，该语句的作用是记录当前执行函数的执行时间、类名及方法名。需要说明的是，这里记录代码的名称并不限于global.callStack.unshift()，仅为示例，具体可根据应用需求自行定义该记录代码的名称。

在一可选实施例中，记录代码可以位于目标函数的主体代码之前或目标函数的开始位置处，如上述代码示例所示，“global.callStack.unshift(newDate().getTime()+类名+方法名)”语句在render()中最开始的代码位置，但并不限于此。基于此，利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息，可通过以下方式实现：在目标函数被触发时，在执行目标函数的主体代码之前，先执行记录代码，由处于执行态的记录代码获取并记录目标函数的执行时间和目标函数对应的类名和方法名，类名和方法名形成目标函数的标识信息。其中，方法名为目标函数的名称，目标函数对应的类名可以为存储目标函数的文件夹的名称。

在本实施例中，在定时器每次被回调时，可以获取定时器每次的实际定时时长，并可以将定时器的实际定时时长与其设定的时长阈值进行比较，其中，实际定时时长表示在定时器此次挂起期间被执行的一个或多个目标函数的总运行时长；时长阈值反映从用户触发页面请求到向用户输出响应数据，用户所能承受的最大等待时间，关于时长阈值的详细描述可参见前述实施例，在此不再详述。若实际定时时长大于该时长阈值，说明混合移动应用运行过程中可能出现了页面卡顿现象，则可以根据各目标函数中的记录代码已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。其中，在大于时长阈值的实际定时时长内被执行的目标函数是导致定时器的实际定时时长大于时长阈值(简称为定时超时)的目标函数，在一定程度上意味着这些目标函数的运行时长可能较长，即这些目标函数对页面请求的响应时间较长，故可以输出这些目标函数的标识信息，以供重点从这些目标函数入手对混合移动应用的页面响应状态进行分析。需要说明的是，这些目标函数可能是影响混合移动应用的页面响应状态的函数，最终是否是真正影响混合移动应用的页面响应状态的函数可以经过人工的进一步分析而定。例如，如果在定时器被挂起期间，被实际执行的目标函数包括两个或两个以上，这两个或两个以上的目标函数的总运行时长构成定时器的实际运行时长，在该情况下，如果实际运行时长大于设定的时长阈值，并不意味着每个目标函数的运行时长一定大于时长阈值，只能粗略判断这些目标函数可能会对混合移动应用的页面响应状态有影响，进一步结合每个目标函数的实际运行时长，可作为准确判断。

在一可选实施例中，可以通过循环链表记录执行的目标函数的执行时间和标识信息，循环链表是一种链式存贮结构，其特点是表中最后一个结点的指针域指向头结点，整个链表形成一个环。可选地，本申请实施例中的循环链表可以采用单循环链表，单循环链表是将终端结点的指针域NULL改为指向表头结点或开始结点。本实施例使用循环链表可以加快数据信息的添加、查找、替换及存储等过程的速度，提高数据信息的处理效率。基于此，利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息，可通过以下方式实现：在循环链表未满的情况下，由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息直接记录到循环链表中；在循环链表已满的情况下，根据执行时间的早晚，将循环链表中已记录的至少一个目标函数的执行时间和标识信息删除，并由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息记录到循环链表中。其中，执行时间的早晚指目标函数执行时间的先后顺序，在本实施例中，在循环链表已满时，先删除执行时间在先的至少一个目标函数的执行时间和标识信息。例如，在循环链表已满时，记录了已执行完成且执行时间不同的10个目标函数，这10个目标函数按时间先后顺序排列分别为目标函数1、目标函数2……目标函数10，目标函数1的执行时间最早，目标函数10的执行时间最晚。另外，目标函数11处于执行态。那么循环链表中记录的执行时间最早的目标函数1的执行时间和执行信息会被删除，将处于执行态的目标函数11的执行时间和标识信息记录到循环链表中。

进一步地，在本实施例中，所记录的目标函数的执行时间可以包括目标函数的执行开始时间和执行结束时间，基于此，应用运行状态监测方法还包括：根据目标函数的执行开始时间和执行结束时间，确定目标函数的执行时长；以及在输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息时，一并输出在大于时长阈值的实际定时时长内执行的目标函数的执行时长，以供对混合移动应用的页面响应状态进行分析。基于各目标函数的执行时长，可以方便开发人员快速定位引起页面卡顿的具体函数是哪个。例如，每个目标函数都有一个预期的执行时长，当其实际执行时长大于其预期的执行时长时，可以认为该目标函数是存在问题的，或者是代码逻辑问题，或者是代码冗余度问题等。或者，也可以将各目标函数的实际执行时长进行比较，优先对执行时长较长的部分目标函数进行问题分析，只有在执行时长较长的目标函数没有问题的情况下，再进一步对执行时长较短的目标函数进行问题分析，这样可以减少代码分析的数量，有利于减轻开发人员的工作量，也有利于提高定位问题目标函数的效率。

在本实施例中，在开发端进行混合移动应用的开发时，在对混合移动应用对应的源程序代码进行编译过程中，可以利用代码插装工具在各目标函数的主体代码之前，例如开始位置插装记录代码。代码插装工具用于在待插装程序的指定位置上插入程序代码，以执行统计、度量、调试、跟踪等任务，例如，代码插装工具可以是BABEL插装工具、PIN动态插装工具及基于GCC的嵌入式程序插装工具等。需要说明的是，在各目标函数的主体代码之前，除了插装记录代码之外，也可以插装用于实现其他功能的代码，例如，用于设置循环链表长度的功能代码，插装其他功能代码的实现方法与插装记录代码的实现方法是类似的，在此不做赘述。

进一步地，在对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码，可以通过以下方式实现：对混合移动应用对应的源程序代码进行语法分析和语义分析，得到混合移动应用对应的抽象语法树，在本实施例中，抽象语法树(Abstract Syntax Tree，AST)，或简称语法树(Syntax tree)，是源代码语法结构的一种抽象表示，其以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。抽象语法树上至少包括多个函数节点，每个函数节点代表源程序代码中包含的一个函数；按照是否响应页面请求的分类原则，对抽象语法树上的多个函数节点进行类型分析，以获取响应页面请求的目标函数节点，目标函数节点对应目标函数；在编译到抽象语法树上的目标函数节点时，利用代码插装工具在目标函数节点对应的目标函数的主体代码之前插装记录代码。

进一步地，应用运行状态监测方法还包括：利用以用户为核心的性能模型，预测用户可接受的页面响应时间；根据用户可接受的页面响应时间，确定定时器的时长阈值。其中，用户可接受的页面响应时间也就是上述提到的卡顿现象所允许的最大响应时间，在超过该时间后，就会发生页面卡顿现象。在本实施例中，可通过RAIL(Response,Animation,Idle,Load)性能模型分析确定出与该混合移动应用适配的定时器的时长阈值，在用户触发需求后，响应于用户的触发需求，对应的目标函数被执行，同时定时器记录执行时长，若在时长阈值内收到页面响应，用户不会感受到页面卡顿现象，由此提高了混合移动应用的性能和用户体验。在本实施例中，经过RAIL性能模型分析确定出定时器设定的时长阈值可以是100ms或其它时长阈值。

本申请各实施例提供的技术方案，针对支持单线程运行的混合移动应用，为了监测其运行状态，在混合移动应用中实现了一种具有设定的时长阈值且具有循环定时功能的定时器，在定时器每次定时期间，以单线程方式依次执行被触发的目标函数，同时利用预先在目标函数中插装的记录代码记录在定时器每次定时期间被执行的目标函数的标识信息及目标函数的执行时间，在定时器每次被回调时，结合定时器每次的实际定时时长，便可以得到在其实际定时时长大于设定的时长阈值的情况下，在该实际定时时长内执行的目标函数的标识信息，这些目标函数可能为导致混合移动应用的页面卡顿的函数，通过这些目标函数可以对混合移动应用的页面卡顿的情况进行分析，以便于对导致混合移动应用页面卡顿的目标函数进行优化，从而提高混合移动应用的页面性能及客户体验。

图2为本申请一示例性实施例提供的应用运行状态监测装置的结构示意图。如图2所示，该装置包括：

启动模块21，用于在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时，混合移动应用包含多个用于响应页面请求的目标函数；

执行模块22，用于以单线程方式，在定时器每次定时期间，依次执行被触发的目标函数，并利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息；

获取模块23，用于在定时器每次被回调时，获取定时器每次的实际定时时长，若实际定时时长大于时长阈值，根据已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；

输出模块24，用于输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。

进一步地，记录代码位于目标函数的主体代码之前，则执行模块22在用于利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息时，具体用于：在目标函数被触发时，在执行目标函数的主体代码之前，先执行开始位置处的记录代码，由处于执行态的记录代码获取并记录目标函数的执行时间和目标函数对应的类名和方法名，类名和方法名形成目标函数的标识信息。

进一步地，执行模块22在用于利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息时，具体用于：在循环链表未满的情况下，由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息直接记录到循环链表中；在循环链表已满的情况下，根据执行时间的早晚，将循环链表中已记录的至少一个目标函数的执行时间和标识信息删除，并由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息记录到循环链表中。

进一步地，目标函数的执行时间包括目标函数的执行开始时间和执行结束时间，则应用运行状态监测装置还包括：确定模块，用于根据目标函数的执行开始时间和执行结束时间，确定目标函数的执行时长；以及输出模块24还用于在输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息时，一并输出将在大于时长阈值的实际定时时长内执行的目标函数的执行时长，以供对混合移动应用的页面响应状态进行分析。

进一步地，应用运行状态监测装置还包括：插装模块，用于在对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码。

进一步地，插装模块在用于在对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码时，具体用于：对混合移动应用对应的源程序代码进行语法分析和语义分析，得到混合移动应用对应的抽象语法树，抽象语法树上至少包括多个函数节点，每个函数节点代表源程序代码中包含的一个函数；按照是否响应页面请求的分类原则，对抽象语法树上的多个函数节点进行类型分析，以获取响应页面请求的目标函数节点，目标函数节点对应目标函数；在编译到抽象语法树上的目标函数节点时，利用代码插装工具在目标函数节点对应的目标函数的主体代码之前插装记录代码。

进一步地，确定模块还用于利用以用户为核心的性能模型，预测用户可接受的页面响应时间；根据用户可接受的页面响应时间，确定定时器的时长阈值。

关于本申请实施例中上述各模块或单元具体实现的原理以及各步骤的详细实施方式可参见上文中相同或相应步骤的描述，在此不再赘述。

图3为本申请一实施例提供的移动终端的结构示意图。如图3所示，移动终端包括：存储器30a和处理器30b；存储器30a用于存储混合移动应用对应的目标程序代码，处理器30b与存储器30a耦合，用于执行目标程序代码，以用于实现以上应用运行状态监测方法中的步骤；其中，目标程序代码是对混合移动应用对应的源程序代码进行编译得到的。具体地，处理器30b用于执行以下步骤：

在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时，混合移动应用包含多个用于响应页面请求的目标函数；

以单线程方式，在定时器每次定时期间，依次执行被触发的目标函数，并利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息；

在定时器每次被回调时，获取定时器每次的实际定时时长，若实际定时时长大于时长阈值，根据已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；

输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。

进一步地，记录代码位于目标函数的主体代码之前，则处理器30b在用于利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息时，具体用于：在目标函数被触发时，在执行目标函数的主体代码之前，先执行所述记录代码，由处于执行态的记录代码获取并记录目标函数的执行时间和目标函数对应的类名和方法名，类名和方法名形成目标函数的标识信息。

进一步地，处理器30b在用于利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息时，具体用于：在循环链表未满的情况下，由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息直接记录到循环链表中；在循环链表已满的情况下，根据执行时间的早晚，将循环链表中已记录的至少一个目标函数的执行时间和标识信息删除，并由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息记录到循环链表中。

进一步地，目标函数的执行时间包括目标函数的执行开始时间和执行结束时间，基于此，处理器30b还用于根据目标函数的执行开始时间和执行结束时间，确定目标函数的执行时长；以及在输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息时，一并输出将在大于时长阈值的实际定时时长内执行的目标函数的执行时长，以供对混合移动应用的页面响应状态进行分析。

进一步地，处理器30b还用于在对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码。

进一步地，处理器30b在用于对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码时，具体用于：对混合移动应用对应的源程序代码进行语法分析和语义分析，得到混合移动应用对应的抽象语法树，抽象语法树上至少包括多个函数节点，每个函数节点代表源程序代码中包含的一个函数；按照是否响应页面请求的分类原则，对抽象语法树上的多个函数节点进行类型分析，以获取响应页面请求的目标函数节点，目标函数节点对应目标函数；在编译到抽象语法树上的目标函数节点时，利用代码插装工具在目标函数节点对应的目标函数的主体代码之前插装记录代码。

进一步地，处理器30b还用于利用以用户为核心的性能模型，预测用户可接受的页面响应时间；根据用户可接受的页面响应时间，确定定时器的时长阈值。

进一步，如图3所示，该移动终端还包括：显示器30c、通信组件30d、电源组件30e、音频组件30f等其它组件。图3中仅示意性给出部分组件，并不意味着电子终端只包括图3所示组件。本实施例的电子终端可以实现为台式电脑、笔记本电脑、智能手机或IOT设备等移动终端。

关于本申请实施例中上述各模块或单元具体实现的原理以及各步骤的详细实施方式可参见上文中相同或相应步骤的描述，在此不再赘述。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器能够实现以上所述的应用运行状态监测方法中的步骤。具体地，处理器用于执行以下步骤：

在启动混合移动应用时，启动一定时器，定时器按照设定的时长阈值循环定时，混合移动应用包含多个用于响应页面请求的目标函数；

以单线程方式，在定时器每次定时期间，依次执行被触发的目标函数，并利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息；

在定时器每次被回调时，获取定时器每次的实际定时时长，若实际定时时长大于时长阈值，根据已记录的各目标函数的执行时间，确定在实际定时时长内执行的目标函数的标识信息；

输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息，以供对混合移动应用的页面响应状态进行分析。

进一步地，记录代码位于目标函数的主体代码之前，则处理器在用于利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息时，具体用于：在目标函数被触发时，在执行目标函数的主体代码之前，先执行所述记录代码，由处于执行态的记录代码获取并记录目标函数的执行时间和目标函数对应的类名和方法名，类名和方法名形成目标函数的标识信息。

进一步地，处理器在用于利用目标函数中插装的记录代码记录目标函数的执行时间和标识信息时，具体用于：在循环链表未满的情况下，由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息直接记录到循环链表中；在循环链表已满的情况下，根据执行时间的早晚，将循环链表中已记录的至少一个目标函数的执行时间和标识信息删除，并由处于执行态的记录代码将当前待记录的目标函数的执行时间和标识信息记录到循环链表中。

进一步地，目标函数的执行时间包括目标函数的执行开始时间和执行结束时间，则处理器还用于根据目标函数的执行开始时间和执行结束时间，确定目标函数的执行时长；以及在输出在大于时长阈值的实际定时时长内执行的目标函数的标识信息时，一并输出将在大于时长阈值的实际定时时长内执行的目标函数的执行时长，以供对混合移动应用的页面响应状态进行分析。

进一步地，处理器还用于在对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码。

进一步地，处理器在用于对混合移动应用对应的源程序代码进行编译过程中，利用代码插装工具在各目标函数的主体代码之前插装记录代码时，具体用于：对混合移动应用对应的源程序代码进行语法分析和语义分析，得到混合移动应用对应的抽象语法树，抽象语法树上至少包括多个函数节点，每个函数节点代表源程序代码中包含的一个函数；按照是否响应页面请求的分类原则，对抽象语法树上的多个函数节点进行类型分析，以获取响应页面请求的目标函数节点，目标函数节点对应目标函数；在编译到抽象语法树上的目标函数节点时，利用代码插装工具在目标函数节点对应的目标函数的主体代码之前插装记录代码。

进一步地，处理器还用于利用以用户为核心的性能模型，预测用户可接受的页面响应时间；根据用户可接受的页面响应时间，确定定时器的时长阈值。

关于本申请实施例中上述各模块或单元具体实现的原理以及各步骤的详细实施方式可参见上文中相同或相应步骤的描述，在此不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。