CN110688314B - 一种应用的性能分析方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请实施例提供一种应用的性能分析方法、装置、电子设备和存储介质，该应用的性能分析方法应用于移动终端，移动终端上运行有宿主应用，宿主应用创建有虚拟安全空间，且虚拟安全空间内安装有至少一个寄宿应用，性能分析方法包括：在第一寄宿应用的进程创建完成前，通过宿主应用将监控代码注入到第一寄宿应用的进程中；在第一寄宿应用运行的过程中，通过宿主应用根据监控代码获取第一寄宿应用的状态信息；通过宿主应用向服务器发送第一寄宿应用的状态信息，以便于服务器根据第一寄宿应用的状态信息分析第一寄宿应用的性能。因此，本申请实施例能够解决现有技术中存在着的会在一定程度上改造应用的代码结构的问题。

Description

一种应用的性能分析方法、装置、电子设备和存储介质

技术领域

本申请涉及应用的性能分析领域，具体而言，涉及一种应用的性能分析方法、装置、电子设备和存储介质。

背景技术

伴随着移动互联网的兴起与发展，移动APP(Application，手机软件)已经进入生活和工作的方方面面，应用的性能是软件质量的一个重要方面，好的软件必须要在性能上达到一定的标准，不合标准的应用程序性能会产生各种问题。对于移动终端上的应用程序来讲，更是如此，移动互联网的红海竞争，如果应用的性能差，肯定会缺少竞争力的，为确保移动APP满足或超过设计的期望值，有必要分析应用程序的性能以发现潜在的问题。

为实现移动应用性能的监控与分析，不同的应用分析厂商都提供了SDK(SoftwareDevelopment Kit)供待分析的APP集成，并在应用程序进程初始化的过程中，埋入探针代码，以便对应用做崩溃分析，卡顿分析以及交互分析等。

在实现本发明的过程中，发明人发现现有的技术方案虽然能够实现应用的性能分析，但是现有的技术方案会在一定程度上改造APP的代码结构。

发明内容

本申请实施例的目的在于提供一种应用的性能分析方法、装置、电子设备和存储介质，以解决现有技术中存在着的现有的技术方案会在一定程度上改造APP的代码结构的问题。

第一方面，本申请实施例提供了一种应用的性能分析方法，应用的性能分析方法应用于移动终端，移动终端上运行有宿主应用，宿主应用创建有虚拟安全空间，且虚拟安全空间内安装有至少一个寄宿应用，性能分析方法包括：在第一寄宿应用的进程创建完成前，通过宿主应用将监控代码注入到第一寄宿应用的进程中，其中，第一寄宿应用为至少一个寄宿应用中的任意一个寄宿应用；在第一寄宿应用运行的过程中，通过宿主应用根据监控代码获取第一寄宿应用的状态信息；通过宿主应用向服务器发送第一寄宿应用的状态信息，以便于服务器根据第一寄宿应用的状态信息分析第一寄宿应用的性能。

因此，本申请实施例通过宿主应用将监控代码动态注入到第一寄宿应用的进程中，从而通过监控代码来获取第一寄宿应用的状态信息，并将状态信息发送到服务器，以便于服务器根据状态信息对第一寄宿应用的性能进行分析，且虚拟安全空间中的第一寄宿应用的分析也无需改造第一寄宿应用的代码结构，从而本申请实施例能够解决现有技术中存在着的会在一定程度上改造应用的代码结构的问题。

以及，本申请实施例是基于虚拟安全空间实现的，以及寄宿应用的应用数据与移动终端的系统数据是隔离的，从而保证应用数据无法通过其他应用传播出去，进而能够保证虚拟安全空间中的数据的安全性。

在一个可能的实施例中，通过宿主应用根据监控代码获取第一寄宿应用的状态信息，包括：在确定卡顿超过预设时长后，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

因此，本申请实施例通过确定卡顿超过预设时长后，通过宿主应用根据监控代码获取第一寄宿应用的状态信息，从而能够精准地获取第一寄宿应用的卡顿相关的状态信息。

在一个可能的实施例中，通过宿主应用根据监控代码获取第一寄宿应用的状态信息，包括：在确定第一寄宿应用崩溃时，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

因此，本申请实施例通过在确定第一寄宿应用崩溃时，通过宿主应用根据监控代码获取第一寄宿应用的状态信息，从而能够精准地获取第一寄宿应用的崩溃相关的状态信息。

在一个可能的实施例中，通过宿主应用向服务器发送第一寄宿应用的状态信息，包括：通过宿主应用对第一寄宿应用的状态信息进行分类，得到分类后的状态信息；通过宿主应用向服务器发送分类后的状态信息。

因此，本申请实施例通过对第一寄宿应用的状态信息进行分类，并将分类后的状态信息发送给服务器，从而由于减少了服务器侧在生成性能分析结果时的数据归类的步骤，能够使得服务器快速的根据分类后的状态信息来快速地实现应用的性能分析。

第二方面，本申请实施例提供了一种应用的性能分析装置，应用的性能分析装置应用于移动终端，移动终端上运行有宿主应用，宿主应用创建有虚拟安全空间，且虚拟安全空间内安装有至少一个寄宿应用，性能分析装置包括：注入模块，用于在第一寄宿应用的进程创建完成前，通过宿主应用将监控代码注入到第一寄宿应用的进程中，其中，第一寄宿应用为至少一个寄宿应用中的任意一个寄宿应用；获取模块，用于在第一寄宿应用运行的过程中，通过宿主应用根据监控代码获取第一寄宿应用的状态信息；发送模块，用于通过宿主应用向服务器发送第一寄宿应用的状态信息，以便于服务器根据第一寄宿应用的状态信息分析第一寄宿应用的性能。

在一个可能的实施例中，获取模块，还用于在确定卡顿超过预设时长后，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

在一个可能的实施例中，获取模块，还用于在确定第一寄宿应用崩溃时，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

在一个可能的实施例中，发送模块包括：分类模块，用于通过宿主应用对第一寄宿应用的状态信息进行分类，得到分类后的状态信息；发送子模块，用于通过宿主应用向服务器发送分类后的状态信息。

第三方面，本申请提供一种电子设备，包括：处理器、存储器和总线，存储器存储有处理器可执行的机器可读指令，当电子设备运行时，处理器与存储器之间通过总线通信，机器可读指令被处理器执行时执行第一方面或第一方面的任一可选的实现方式的方法。

第四方面，本申请提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行第一方面或第一方面的任一可选的实现方式的方法。

第五方面，本申请提供一种计算机程序产品，计算机程序产品在计算机上运行时，使得计算机执行第一方面或第一方面的任意可能的实现方式中的方法。

为使本申请实施例所要实现的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种应用的性能分析方法的流程图；

图2示出了本申请实施例提供的一种应用的性能分析方法的具体流程图；

图3示出了本申请实施例提供的一种应用的性能分析装置的结构示意图；

图4为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

目前，为了监控移动终端上的应用的运行时，需要往待监控的应用中植入一个第三方的SDK，从而通过第三方的SDK来监控应用的运行时。

但是，现有的技术方案虽然能够实现应用的性能分析，但是，现有的方案会在一定程度上改造应用的代码结构，以及在应用运行时，还需要移动终端集成性能分析SDK。

基于此，本申请实施例巧妙地提出了一种应用的性能分析方法、装置、电子设备和存储介质，通过宿主应用将监控代码动态注入到第一寄宿应用中，从而通过监控代码来获取第一寄宿应用的状态信息，并将状态信息发送到服务器，以便于服务器根据状态信息对第一寄宿应用的性能进行分析，且虚拟安全空间中的第一寄宿应用的分析也无需改造第一寄宿应用的代码结构，从而本申请实施例能够解决现有技术中存在着的会在一定程度上改造应用的代码结构的问题。

以及，由于本申请实施例将宿应用运行在安全虚拟空间中，该安全虚拟空间与系统运行环境隔离，从而也能够保障数据的安全性。

为了便于理解本申请实施例，首先在此对本申请实施例中的一些术语进行解释如下：

宿主应用是指虚拟安全空间的运行环境。也就是说，虚拟安全空间需要依赖于宿主应用，宿主应用创建虚拟安全空间。

应理解，本申请实施例中的宿主应用可以为一个APP(Application，手机软件)(或者为一个运行平台)，且该宿主应用的软件类型可以根据实际需求来进行设置，本申请实施例并不局限于此。

例如，宿主应用可以为聊天软件(如微信、QQ等)，也可以为订餐软件(如美团外卖、饿了么等)，也可以为办公软件(如视频会议软件等)等。

虚拟安全空间是在操作系统上创建的一套运行环境，且虚拟安全空间不是指单独存在的空间，而是由宿主应用运行时创建的，当宿主应用运行后，创建出一套虚拟运行环境，该虚拟运行环境具有独立的隔离空间。虚拟安全空间的特性如下：

1、虚拟安全空间可以支持虚拟安全空间中的多个寄宿应用在不做任何修改的情况下安装、运行、卸载等应用生命周期的管理。

此外，所有的应用安装包或多或少都是以压缩文件格式zip的格式封装的，虚拟安全空间在安装应用时，会调用系统的安装包解析API(Application ProgrammingInterface，应用程序编程接口)，得到解析后的应用程序，从而模拟了操作系统的应用安装过程。

以及，虚拟安全空间是对操作系统的各种服务以代理的模式提供，即虚拟安全空间是寄宿应用与真实操作系统之间的中介。

此外，虚拟安全空间还支持多个寄宿应用的同时安装或者同时卸载等，本申请实施例并不局限于此。

2、在虚拟安全空间中的多个寄宿应用不做任何修改的情况下实现寄宿应用的数据隔离(操作系统(或者说虚拟安全空间之外)的应用无法访问到虚拟空间中的寄宿应用产生的数据)，进程实现了隔离(虚拟安全空间内的应用安装后，虚拟安全空间外不可见)。

也就是说，宿主应用里面的操作或者动作与操作系统隔离，操作系统不可见，操作系统只知道有宿主应用这样一个应用，但是宿主应用内的一些动作，操作系统是不知道的。

此外，虚拟安全空间还支持多个寄宿应用的同时运行，本申请实施例并不局限于此。

3、在寄宿应用不做任何修改的情况下，虚拟安全空间可以实现寄宿应用的数据存储安全(或者数据加密存储)，且寄宿应用运行时安全(进程隔离)，网络传输安全(传输数据加密)。

寄宿应用是指可以安装在虚拟安全空间中的应用。

应理解，本申请实施例中的寄宿应用可以为APP，且该寄宿应用的软件类型可以根据实际需求来进行设置，本申请实施例并不局限于此。

例如，该寄宿应用也可以为聊天软件，也可以为订餐软件，也可以为办公软件，也可以为打车软件等。

代码注入是用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据。

运行时是指一个程序在运行(或者在被执行)的状态。例如，当用户打开一个程序使它在电脑上运行的时候，那个程序就是处于运行时刻。

图1示出了本申请实施例提供的一种应用的性能分析方法的流程图，该应用的性能分析方法可以应用于移动终端，如图1所示的方法包括：

步骤S110，移动终端通过宿主应用创建虚拟安全空间。

应理解，移动终端可以为手机，也可以为平板电脑，也可以为膝上型电脑。也就是说，移动终端的具体设备类型可以根据实际需求来进行设置，本申请实施例并不局限于此。

还应理解，虚拟安全空间还可称为虚拟空间，也可称为安全虚拟空间，也可称为虚拟安全存储空间。

换句话说，虚拟安全空间可根据实际需求来更改名称，只要保证其具备本申请实施例中的虚拟安全空间的功能即可，本申请实施例并不局限于此。

还应理解，一个移动终端上可设置有一个宿主应用或者多个宿主应用，对应地，一个移动终端上也可以设置有多个虚拟安全空间，且当用户通过操作移动终端来显示某一宿主应用的界面后，移动终端可通过该宿主应用来运行或者创建对应的虚拟安全空间，本申请实施例并不局限于此。

具体地，移动终端上可运行有宿主应用，且在宿主应用运行的过程中，宿主应用可以创建虚拟安全空间。

步骤S120，移动终端通过宿主应用在虚拟安全空间中安装至少一个寄宿应用。

应理解，寄宿应用的安装是通过往虚拟安全空间中加载软件安装包以及通过软件安装包来实现寄宿应用的安装来实现的，本申请在此不再详细描述。

需要说明的是，本申请实施例中的虚拟安全空间的寄宿应用的安装也是不需要被改造的，从而通过虚拟安全空间来达到数据安全隔离，安全存储的效果。

具体地，在虚拟安全空间创建后，移动终端可以通过宿主应用在虚拟安全空间中进行寄宿应用的安装。此外，在虚拟安全空间中安装有寄宿应用的情况下，后续可以通过虚拟安全空间对使用寄宿应用或者寄宿应用产生的数据进行保护。

步骤S130，在第一寄宿应用的进程创建完成前，移动终端通过宿主应用将监控代码注入到第一寄宿应用的进程中，从而能够监测第一寄宿应用的运行状态。其中，第一寄宿应用为至少一个寄宿应用中的任意一个寄宿应用。

应理解，监控代码可为监控第一寄宿应用的运行状态的代码。以及，监控代码可根据实际需求来进行设置，本申请实施例并不局限于此。

还应理解，第一寄宿应用的运行状态包括第一寄宿应用的崩溃状态、第一寄宿应用的卡顿状态等。换句话说，第一寄存应用的运行状态可以任意的第一寄宿应用的异常状态，本申请实施例并不局限于此。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

可选地，在第一寄宿应用的进程创建完成之前，移动终端通过代码注入的方式，来将用于监测第一寄宿应用是否崩溃的代码动态注入到第一寄宿应用的进程中，从而在第一寄宿应用出现崩溃的状态下，可以捕获第一寄宿应用出现崩溃时的状态信息。

应理解，用于监测第一寄宿应用是否崩溃的代码也可以根据实际需求来进行设置，本申请实施例并不局限于此。

例如，在移动终端为安卓手机的情况下，用于监测第一寄宿应用是否崩溃的代码可为代码crashHandler。

可选地，在第一寄宿应用的进程创建完成之前，移动终端通过代码注入的方式，来将用于监测第一寄宿应用是否卡顿的代码动态注入到第一寄宿应用的进程中，从而在第一寄宿应用出现卡顿的状态下，可以捕获第一寄宿应用出现卡顿时的状态信息。

应理解，用于监测第一寄宿应用是否卡顿的代码也可以根据实际需求来进行设置，本申请实施例并不局限于此。

例如，在移动终端为安卓手机的情况下，用于监测第一寄宿应用是否卡顿的代码可为代码Trace Method。

步骤S140，在第一寄宿应用运行的过程中，移动终端通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

应理解，第一寄宿应用的状态信息所包含的信息可以根据实际需求来进行设置，本申请实施例并不局限于此。

例如，第一寄宿应用的状态信息包括以下信息至少之一：用户操作轨迹、上下文信息和设备信息。其中，用户操作轨迹是指第一寄宿应用运行异常时，用户对第一寄宿应用的操作轨迹信息。例如，用户点击了第一寄宿应用的那个区域或者按键等。上下文信息可以是指第一寄宿应用运行异常时，日志中记录的关于第一寄宿应用的运行异常的相关日志信息，也可以是指第一寄宿应用运行异常时，导致进程崩溃的上下文的代码信息等。设备信息可以是指第一寄宿应用运行异常时，移动终端相关的信息。例如，设备信息包括CPU利用率、内存剩余的容量等。

具体地，在第一寄宿应用运行异常时，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

应理解，由于第一寄宿应用运行异常的类型具有多种，因此，本申请实施例中的通过宿主应用根据监控代码获取第一寄宿应用的状态信息也可具有多种。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

可选地，在确定卡顿超过预设时长后，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

应理解，预设时长可根据实际需求来进行限定，本申请实施例并不局限于此。

例如，在预设时长为60ms，且用于监测第一寄宿应用是否卡顿的代码为代码TraceMethod的情况下，移动终端的第一寄宿应用的卡顿抓取可以每帧图像展示60ms为基准，通过代码Trace Method来跟踪每个显示界面从OnCreate到OnResume的时间，从而获取页面的展示时间。以及在页面的展示时间超过60ms的情况下，移动终端可以确定第一寄宿应用发生卡顿。移动终端可以通过代码Trace Method来获取第一寄宿应用的状态信息。

其中，函数OnCreate用于表示页面创建的时间，函数OnResume用于表示页面完全展示出来的时间，则页面的展示时间为页面创建的时间和页面完全展示出来的时间之间的时间段。

可选地，在确定第一寄宿应用崩溃时，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

例如，在用于监测第一寄宿应用是否崩溃的代码可为代码crashHandler的情况下，在第一寄宿应用出现崩溃的情况下，代码crashHandler可以记录第一寄宿应用的状态信息。

步骤S150，移动终端通过宿主应用向服务器发送第一寄宿应用的状态信息。相应地，服务器接收移动终端发送的第一寄宿应用的状态信息。

应理解，在移动终端向服务器发送第一寄宿应用的状态信息之前，移动终端可以对获取到的第一寄宿应用的状态信息进行预处理。其中，预处理可以包括数据分类和压缩。

其中，数据分类是指根据获取到的第一寄宿应用的状态信息的类型来对状态信息进行分类处理。压缩是指对第一寄宿应用的状态信息进行压缩处理以减少数据传输过程中的带宽。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

在移动终端向服务器发送第一寄宿应用的状态信息之前，移动终端先确定出第一寄宿应用的状态信息的类型，随后移动终端根据第一寄宿应用的类型来对第一寄宿应用进行分类，最后移动终端将分类后的第一寄宿应用的状态信息发送到服务器。

例如，在第一寄宿应用的状态信息的类型包括用户操作轨迹、上下文信息和设备信息的情况下，移动终端可以按照用户操作轨迹、上下文信息和设备信息这三种类型信息，将获取到的状态信息分类到对应的类别中，从而第一终端能够对状态信息进行归类，并将归类后的状态信息统一上传到服务器。

步骤S160，服务器根据第一寄宿应用的状态信息分析第一寄宿应用的性能。

具体地，服务器在接收到第一寄宿应用的状态信息后，服务器可利用状态信息来对第一寄宿应用的稳定性等性能来进行分析，进而可以实现软件性能测试。

以及，服务器还可将第一寄宿应用的性能测试结果发送给移动终端，从而便于用户根据性能测试结果来对第一寄宿应用进行调整。

需要说明的是，虽然图1以一个第一寄宿应用为例来进行了描述，但本领域的技术人员应当理解，本申请实施例还可同时进行至少两个寄宿应用的应用的性能分析，本申请实施例并不局限于此。

综上，本申请实施例通过宿主应用将监控代码动态注入到第一寄宿应用中，从而通过监控代码来获取第一寄宿应用的状态信息，并将状态信息发送到服务器，以便于服务器根据状态信息对第一寄宿应用的性能进行分析，且虚拟安全空间中的第一寄宿应用的分析也无需改造第一寄宿应用的代码结构，从而本申请实施例能够解决现有技术中存在着的会在一定程度上改造应用的代码结构的问题。

以及，本申请实施例是基于虚拟安全空间实现的，以及寄宿应用的应用数据与移动终端的系统数据是隔离的，从而保证应用数据无法通过其他应用传播出去，进而能够保证虚拟安全空间中的数据的安全性。

为了便于理解本申请的实施例，下面通过具体的实施例来进行描述。

图2示出了本申请实施例提供的一种应用的性能分析方法的具体流程图，如图2所示的方法包括：

步骤S210，在虚拟安全空间中加载应用安装包。

步骤S220，在虚拟安全空间中解析应用安装包。

具体地，当虚拟空间中的第一寄宿应用运行的时候，移动终端可以通过宿主应用来动态解析以及加载第一寄宿应用的安装文件。

步骤S230，运行子程序。

具体地，在移动终端可以通过宿主应用来动态解析以及加载虚拟应用的安装文件时，移动终端可以启动宿主应用的一子进程，在子进程运行之前，移动终端通过将宿主应用的子进程替换为第一寄宿应用的进程，从而可利用宿主应用的一个子进程来监测第一寄宿应用的状态。

也就是说，在虚拟空间中的第一寄宿应用运行之前，宿主应用需要动态把第一寄宿应用的运行时拿到，并且在拿到第一寄宿应用的运行时后，通过将移动终端的操作系统的运行时替换为第一寄宿应用的运行时。

步骤S240，在第一寄宿应用的进程中注入监控代码。

具体地，通过代码注入的方式，将crashHandler、Trace Method等代码动态注入到第一寄宿应用的进程中。

步骤S250，确定第一寄宿应用的进程是否崩溃。在确定第一寄宿应用的进程崩溃的情况下，则执行步骤S260。以及，在确定第一寄宿应用的进程没有崩溃的情况下，则执行步骤S270。

步骤S260，在确定第一寄宿应用的进程崩溃的情况下，移动终端记录上下文信息、崩溃信息和设备信息。其中，崩溃信息可以包括崩溃的时间、崩溃的次数等。

步骤S270，结束。

步骤S280，确定第一寄宿应用的进程是否卡顿。

在确定第一寄宿应用的进程卡顿的情况下，则执行步骤S290。以及，在确定第一寄宿应用的进程没有卡顿的情况下，则执行步骤S270。

步骤S290，在确定第一寄宿应用的进程出现卡顿的情况下，移动终端记录用户操作轨迹、卡顿信息和设备信息。其中，卡顿时间可以包括卡顿的时间、卡顿的次数等。

需要说明的是，虽然步骤S250和步骤S280分别示出了在没有崩溃或者卡顿的情况下，结束应用的性能分析方法，但本领域的技术人员应当理解，本领域的技术人员还可根据实际需求来设置应用的性能分析方法的流程，本申请实施例并不局限于此。

例如，在步骤S250确定第一寄宿应用的进程没有崩溃的情况下，返回到步骤S240，即本申请实施例中的确定应用的进程是否崩溃可循环实现，本申请实施例并不局限于此。

再例如，在步骤S280确定第一寄宿应用的进程没有卡顿的情况下，返回到步骤S240，即本申请实施例中的确定应用的进程是否卡顿可循环实现，本申请实施例并不局限于此。

应理解，上述应用的性能分析方法仅是示例性的，本领域技术人员根据上述的方法可以进行各种变形。例如，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

请参见图3，图3示出了本申请实施例提供的一种应用的性能分析装置300的结构示意图，应理解，该装置300与上述图1或图2方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该装置300具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置300包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在装置300的操作系统(operating system，OS)中的软件功能模块。具体地，该装置300包括：

注入模块310，用于在第一寄宿应用的进程创建完成前，通过宿主应用将监控代码注入到第一寄宿应用的进程中，第一寄宿应用为至少一个寄宿应用中的任意一个寄宿应用；获取模块320，用于在第一寄宿应用运行的过程中，通过宿主应用根据监控代码获取第一寄宿应用的状态信息；发送模块330，用于通过宿主应用向服务器发送第一寄宿应用的状态信息，以便于服务器根据第一寄宿应用的状态信息分析第一寄宿应用的性能。

在一个可能的实施例中，获取模块320，还用于在确定卡顿超过预设时长后，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

在一个可能的实施例中，获取模块320，还用于在确定第一寄宿应用崩溃时，通过宿主应用根据监控代码获取第一寄宿应用的状态信息。

在一个可能的实施例中，发送模块330包括：分类模块(未示出)，用于通过宿主应用对第一寄宿应用的状态信息进行分类，得到分类后的状态信息；发送子模块(未示出)，用于通过宿主应用向服务器发送分类后的状态信息。

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

图4为本申请实施例提供的一种电子设备400的结构框图，如图4所示。电子设备400可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中，通信总线440用于实现这些组件直接的连接通信。其中，本申请实施例中设备的通信接口420用于与其他节点设备进行信令或数据的通信。处理器410可以是一种集成电路芯片，具有信号的处理能力。上述的处理器410可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。

存储器430可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。存储器430中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器410执行时，电子设备400可以执行上述图1至图2方法实施例中的各个步骤。

电子设备400还可以包括存储控制器、输入输出单元、音频单元、显示单元。

所述存储器430、存储控制器、处理器410、外设接口、输入输出单元、音频单元、显示单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线440实现电性连接。所述处理器410用于执行存储器430中存储的可执行模块，例如电子设备400包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户输入数据实现用户与所述服务器(或本地终端)的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

音频单元向用户提供音频接口，其可包括一个或多个麦克风、一个或者多个扬声器以及音频电路。

显示单元在所述电子设备与用户之间提供一个交互界面(例如用户操作界面)或用于显示图像数据给用户参考。在本实施例中，所述显示单元可以是液晶显示器或触控显示器。若为触控显示器，其可为支持单点和多点触控操作的电容式触控屏或电阻式触控屏等。支持单点和多点触控操作是指触控显示器能感应到来自该触控显示器上一个或多个位置处同时产生的触控操作，并将该感应到的触控操作交由处理器进行计算和处理。

可以理解，图4所示的结构仅为示意，所述电子设备400还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

本申请提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行图1或图2中的任一可选的实现方式所述的方法。

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

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

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

本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

Claims (10)

1.一种应用的性能分析方法，其特征在于，所述应用的性能分析方法应用于移动终端，所述移动终端上运行有宿主应用，所述宿主应用创建有虚拟安全空间，且所述虚拟安全空间内安装有至少一个寄宿应用，所述性能分析方法包括：

在第一寄宿应用的进程创建完成前，通过所述宿主应用将监控代码注入到所述第一寄宿应用的进程中，其中，所述第一寄宿应用为所述至少一个寄宿应用中的任意一个寄宿应用；

在所述第一寄宿应用运行的过程中，通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息，其中，所述第一寄宿应用的状态信息包括用户操作轨迹、上下文信息和设备信息；

通过所述宿主应用向服务器发送所述第一寄宿应用的状态信息，以便于所述服务器根据所述第一寄宿应用的状态信息分析所述第一寄宿应用的性能。

2.根据权利要求1所述的性能分析方法，其特征在于，所述通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息，包括：

在确定卡顿超过预设时长后，通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息。

3.根据权利要求1所述的性能分析方法，其特征在于，所述通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息，包括：

在确定所述第一寄宿应用崩溃时，通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息。

4.根据权利要求1所述的性能分析方法，其特征在于，所述通过所述宿主应用向服务器发送所述第一寄宿应用的状态信息，包括：

通过所述宿主应用对所述第一寄宿应用的状态信息进行分类，得到分类后的状态信息；

通过所述宿主应用向所述服务器发送所述分类后的状态信息。

5.一种应用的性能分析装置，其特征在于，所述应用的性能分析装置应用于移动终端，所述移动终端上运行有宿主应用，所述宿主应用创建有虚拟安全空间，且所述虚拟安全空间内安装有至少一个寄宿应用，所述性能分析装置包括：

注入模块，用于在第一寄宿应用的进程创建完成前，通过所述宿主应用将监控代码注入到所述第一寄宿应用的进程中，其中，所述第一寄宿应用为所述至少一个寄宿应用中的任意一个寄宿应用；

获取模块，用于在所述第一寄宿应用运行的过程中，通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息，其中，所述第一寄宿应用的状态信息包括用户操作轨迹、上下文信息和设备信息；

发送模块，用于通过所述宿主应用向服务器发送所述第一寄宿应用的状态信息，以便于所述服务器根据所述第一寄宿应用的状态信息分析所述第一寄宿应用的性能。

6.根据权利要求5所述的性能分析装置，其特征在于，所述获取模块，还用于在确定卡顿超过预设时长后，通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息。

7.根据权利要求5所述的性能分析装置，其特征在于，所述获取模块，还用于在确定所述第一寄宿应用崩溃时，通过所述宿主应用根据所述监控代码获取所述第一寄宿应用的状态信息。

8.根据权利要求5所述的性能分析装置，其特征在于，所述发送模块包括：

分类模块，用于通过所述宿主应用对所述第一寄宿应用的状态信息进行分类，得到分类后的状态信息；

发送子模块，用于通过所述宿主应用向所述服务器发送所述分类后的状态信息。

9.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至4任一所述的应用的性能分析方法。

10.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至4任一所述的应用的性能分析方法。

Images