CN110618933B - 性能分析方法与系统、电子设备与存储介质 - Google Patents

Abstract

本申请提供一种性能分析方法与系统、电子设备与存储介质，该方法利用探测代码对目标程序进行采样得到事件信息，并利用PMU对目标程序进行Simpleperf采样，得到栈信息，从而，获取所述第一采样数据与所述第二采样数据之间的时间映射关系，基于该时间映射关系，能够实现事件信息与所述栈信息之间的关联和对应，从而，由此，生成目标程序的性能图，该性能图既可用于表征目标程序中，事件对应的调用栈的信息，也能够表征各栈的耗时时长，为用户提供了衡量目标程序性能的时间与空间信息，开发人员基于该性能图，能够清楚的确定目标程序在运行过程中，一个事件对应调用了什么栈(函数)，调用了多长时间，能够辅助开发人员快速定位软件问题、优化软件性能。

Description

性能分析方法与系统、电子设备与存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种性能分析方法与系统、电子设备与存储介质。

背景技术

随着计算机技术的发展，软件产品的更新换代也越来越快，用户对软件程序的要求也随之增高，软件程序的系统流畅性、低内存消耗、低卡顿、快速启动等性能指标已经成为高质量产品重要的一环。

但是，软件程序的性能分析一直是软件开发过程中最难的一部分，其难度甚至超越了软件的功能开发本身。对后台开发人员而言，软件程序的时间信息与源码细节都是重要的性能分析内容，这直接影响到后台开发人员定位软件问题、优化软件性能的准确性和难度。因此，如何实现对软件程序的性能分析，以辅助开发人员快速定位软件问题、优化软件性能，一直是本领域的重点关注问题。

发明内容

本申请提供一种性能分析方法与系统、电子设备与存储介质，用以从时间信息和源码细节两方面体现目标程序的性能，能够辅助开发人员快速定位软件问题、优化软件性能。

第一方面，本申请提供一种性能分析方法，利用探测代码对目标程序进行采样得到事件信息，以及，利用PMU对目标程序进行Simpleperf采样，得到栈信息，从而，获取所述第一采样数据与所述第二采样数据之间的时间映射关系，基于该时间映射关系，能够实现事件信息与所述栈信息之间的关联和对应，从而，由此，生成目标程序的性能图，该性能图既可用于表征目标程序中，事件对应的调用栈的信息，也能够表征各栈的耗时时长，为用户提供了衡量目标程序性能的时间与空间信息，开发人员基于该性能图，能够清楚的确定目标程序在运行过程中，一个事件对应调用了什么栈(函数)，调用了多长时间，能够辅助开发人员快速定位软件问题、优化软件性能。

在第一方面的一种可能的设计中，可以获取第一采样数据所采用的第一时间轴，与第二采样数据所采用的第二时间轴之间的偏差时长，以作为所述时间映射关系；此时，事件对应的第一时间轴上的时间信息，与该事件对应的栈在第二时间轴上的时间信息之间，存在一定的偏差时长。

在第一方面的另一种可能的设计中，可以同步所述第一时间轴与所述第二时间轴，以作为所述时间映射关系。此时，事件对应的第一第一时间轴上的时间信息，与该事件对应的栈在第二时间轴上的时间信息，是一致的，不存在偏差。其中，同步时间轴可以通过获取前述偏差时长，然后，利用所述偏差时长，调整所述第一时间轴或所述第二时间轴，使得所述第一时间轴与所述第二时间轴同步即可。

此外，偏差时长可以通过预设的校准Tag实现。其中，校准Tag为该目标程序中一定会出现的一个事件Tag。具体的，可以获取预设的校准Tag在第一时间轴上的起始时刻，以及，在第二时间轴上，获取所述校准Tag对应的第一个采样点时刻，从而，获所述起始时刻与所述第一个采样点时刻之差，以作为所述偏差时长。可知，若起始时刻与所述第一个采样点时刻相同，则第一时间轴与第二事件轴本身即同步，以二者同步作为该时间映射关系。

在第一方面的另一种可能的设计中，考虑到采样过程可能会过量采样，因此，为了得到更为精确的性能图，还可以在生成所述目标程序的性能图时，对所述第二采样数据进行剪裁，并利用所述裁剪后的第二采样数据，生成所述目标程序的所述性能图。这有利于多滤掉非关注区间的数据，也有利于缩减数据处理量，加快处理效率。

具体而言，裁剪所述第二采样数据时，可以通过获取所述第一采样数据中的目标事件来实现，根据前述时间映射关系，确定所述目标事件对应的目标栈，从而，裁剪出所述目标栈对应的第二采样数据。

其中，目标事件可以通过目标事件标识来进行指示。目标事件标识可以表示为事件Tag(事件标签)或目标时间区间。只需要将事件Tag对应的事件确定为目标事件，或者，将目标时间区间中的事件确定为目标事件即可。而目标事件标识，则可以有多种获取途径。一种可能的设计中，可以将目标事件标识预设或默认配置在裁剪配置信息(可以表示为一个裁剪配置文件)中，或者，也可以输出可供用户操作的可操作面板，并由此获取用户的操作信息所选择的事件Tag或时间区间，以作为目标事件标识；或者，还可以利用自学习模型，来处理第一采样数据，从而获取到该自学习模型所输出的目标事件标识。综上，本申请可以为用户提供自定义裁剪数据的可能性，方便用户的个性化处理，满足不同业务不同裁剪范围的性能评估需求，更便于用户对感兴趣事件进行分析，灵活性较高。

本申请的一种实现场景中，目标程序可以为一个被测试程序，此时，生成该被测试程序的性能图，可用于用户对单一程序的性能评估需求。

本申请的另一种实现场景中，目标程序除被测试程序之外，还可以包括至少一个对照程序，如此，可以生成被测试程序与各对照程序各自的性能图，或者，可以直接得到一个多维性能图(或称为多列性能图)，便于用户横向比较对照程序与被测试程序，更方便用户有针对性的定位程序问题。

另一种可能的设计中，所述多维性能图中还可以包括但不限于：所述被测试程序与所述对照程序之间的对比数据；而所述对比数据可以包括但不限于：至少顶层栈的函数耗时数据、所述被测试程序相对于所述对照程序的优异函数、所述被测试程序相对于所述对照程序的待改进函数；其中，针对任意一个函数，若所述被测试程序中该函数的耗时时长，小于所述对照程序中该函数的耗时时长，该函数为所述优异函数；若所述被测试程序中该函数的耗时时长，大于所述对照程序中该函数的耗时时长，该函数为所述待改进函数。

另一种可能的设计中，本申请中，性能图上还可以包括但不限于：性能提升参数、热点函数和瓶颈函数中的至少一种。

在第一方面的另一种可能的设计中，还可以实时采集用户在所述性能图上的操作信息。

从而，若所述操作信息为光标移动信息，将所述操作信息所指示的指定栈突出显示，和/或，输出所述指定栈的耗时时长。如此，用户通过简单的鼠标移动动作，就可以查看指定栈的耗时时长，和/或，可以轻易看出用户所要查看或操作的栈，便于用户后续操作。

或者，若所述操作信息指示将指定栈降维展示，根据所述性能图，获取降维性能图；其中，所述降维性能图的底层栈为所述指定栈；显示所述降维性能图。如此，用户能够方便的指定一个栈进行降级，方便用户对比查看。

在第一方面的另一种可能的设计中，本申请还可以获取所述被测试程序的性能提升参数，输出所述性能提示参数。所述性能提升参数用于表征所述被测试程序相对于所述对照程序的性能优化空间的大小。

具体而言，本申请中，可以获取性能图中的单层性能提升参数，也可以获取多层性能提升参数。一方面，可以在所述性能图上，获取所述被测试程序与所述对照程序在每一层上的相同栈；从而，对所述性能图中的任意一层，若相同栈在该层所有栈中的数目占比超过预设的比例阈值，获取该层中所有相同栈的时长差之和，得到该层的单层性能提升参数。另一方面，还可以按照所述性能图由顶层至底层的顺序，逐层获取各层的所述单层性能提升参数，从而，若当前累积层数达到指定层数，获取各层的所述单层性能提升参数的加权平均值，以作为多层性能提升参数。

在第一方面的另一种可能的设计中，本申请还可以获取并输出目标程序中的热点函数，其中，所述热点函数为所述目标数据中热度较高的至少一个函数。具体的，对所述性能图中的任意一个函数，获取该函数在不同独立分支上的个数之和，以作为该函数的热度；从而，按照热度由高至低的顺序，获取至少一个函数，以作为所述热点函数。例如，可以按照热度由高至低的顺序，获取排序靠前的5个函数作为热点函数；又例如，还可以获取热度高于预设热度阈值的函数，以作为热点函数。具体输出时，还可以将热点函数作为热点函数列表输出，热点函数列表可以按照热度由高至低的顺序排序。基于输出的热点函数，用户可以很便捷的知道哪些函数被多次调用，方便用户定位程序问题。

在第一方面的另一种可能的设计中，本申请还可以获取并输出所述目标程序中的瓶颈函数，所述瓶颈函数为所述目标数据中耗时占比较高的至少一个函数。具体的，对所述性能图中的任意一个函数，获取该函数的耗时时长在所属调用栈的总时长中所占的比例，以作为该函数的覆盖度，从而，按照覆盖度由高至低的顺序，获取至少一个函数，以作为所述瓶颈函数。

在获取瓶颈函数的另一种可能的实现方式中，还可以结合热点函数的判断结果来实现。首先，获取所述目标程序中的热点函数，然后，获取各所述热点函数的覆盖度，进而，按照覆盖度由高至低的顺序，获取至少一个热点函数，以作为所述瓶颈函数。如此，输出的瓶颈函数是耗时较长，且被调用次数较多的函数，这些函数具备更大的优化空间。

除此之外，本申请中，所述PMU采用offline cpu模式工作，其工作状态与中央处理器CPU的运行状态无关。换言之，无论CPU处于何种工作模式，PMU都按照预设的采样周期进行数据采集。这能够在一定程度上避免由于CPU休眠而无法获知调用栈信息的情况。

第二方面，本申请提供一种电子设备，包括：一个或多个处理器、一个或多个存储器、一个或多个传感器；以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如第一方面任一实现方式所述的方法。

第二方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在电子设备上运行时，使得所述电子设备执行如第一方面任一实现方式所述的方法。

第三方面，本申请提供一种性能分析系统，该系统包括第一电子设备与第二电子设备，其中，第一电子设备用于运行所述目标程序，第二电子设备用于执行如第一方面任一实现方式所述的方法。

第四方面，本申请提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如如第一方面任一实现方式所述的方法。

综上，本申请所提供的一种提供一种性能分析方法与系统、电子设备与存储介质，能够为用户提供具备时间信息和源码细节的性能图，从而，能够辅助开发人员快速定位软件问题、优化软件性能。

附图说明

图1为本申请所提供的性能分析系统的示意图；

图2为本申请所提供一种电子设备的结构示意图；

图3为本申请所提供的一种性能分析方法的流程示意图；

图4为本申请中Systrace采样的示意图；

图5为现有技术中基于Systrace采样数据的一种分析结果的示意图；

图6为现有技术中基于Simpleperf采样数据的一种分析结果(火焰图)示意图；

图7为本申请中环状缓存区(Ring Buffer)的存储机制示意图；

图8为本申请中同步第一时间轴和第二时间轴的示意图；

图9为本申请所提供的一种性能火焰图的示意图；

图10为本申请所提供的另一种性能火焰图的示意图；

图11为本申请所提供的另一种性能火焰图的示意图；

图12为图9所示的性能火焰图降维后的性能火焰图的示意图；

图13A为一种性能火焰图的降维展示示意图；

图13B为另一种性能火焰图的降维展示示意图；

图14为本申请所提供的一种多列性能火焰图的示意图；

图15为本申请所提供的另一种多列性能火焰图的示意图；

图16为本申请所提供对比分析结果示意图；

图17为图15所示的性能火焰图降维后的性能火焰图的示意图；

图18为本申请所提供一种热点函数的处理方式示意图；

图19为本申请所提供一种瓶颈函数的处理方式示意图；

图20为本申请所提供的一种瓶颈函数的输出结果示意图。

具体实施方式

本申请所提供的技术方案用于对软件程序(为便于说明，后续简称待测试程序)进行性能分析。具体而言，开发人员在开发一款软件产品时，一般以运行流畅、低内存消耗、低卡顿、快速启动等性能指标来对该软件产品的性能进行评估。但是，软件性能分析和优化分析对开发人员的能力要求较高，本申请意在提供一种软件的性能分析方法，以辅助开发人员完成对软件的性能分析。

图1示出了一种具体的应用场景，在该场景中，性能分析系统由第一电子设备与第二电子设备构成，其中，第一电子设备用于运行所述目标程序，第二电子设备用于对目标程序进行性能分析。如图1所示，手机作为第一电子设备，电脑端作为第二电子设备，被测试程序设置于手机上，手机可以与电脑端进行通信与数据交互。由此，如图1所示，开发人员在具体对手机上安装的某一被测试程序进行性能分析时，考虑到性能分析的数据处理量较大，一般是在手机上运行被测试程序，并在手机上进行数据采集，然后，将采集到的数据发送给电脑(Personal Computer，PC)端，由PC端进行数据分析和处理，得到性能分析结果。如图1所示，PC端还进一步输出可视化性能分析结果(图1中的可视化性能分析结果为示意性的，具体展示内容后续详述)，用户可以通过鼠标、键盘等输入设备对该性能分析结果做个性化处理和操作。例如，将可视化表格进行格式转换，又例如，还可以将可视化示意图进行格式转换，生成报告等。在这种实现场景中，只要任意两个电子设备可以实现(有线或无线的)数据交互，就可以采用本方案实现对任意一个电子设备上安装的待测试程序的性能分析。

除此之外，本申请所提供的技术方案，还可以在一个电子设备上实现。例如，开发人员需要对电脑上的一个绘图程序进行性能分析，就可以在电脑上完成数据采集、分析数据并得到性能分析结果的全过程。另一种实现场景中，本申请所提供的技术方案，还可以集成在一个应用程序(APPlication，APP)中，例如，作为手机管家中的一个插件功能等，又例如，作为一个独立的性能分析APP，用户可以通过该APP来对手机中安装的应用程序的性能进行评估。

综上，本申请所提供的技术方案，可以在一个电子设备上实现，或者，由至少一个电子设备组合实现本方案。例如，除前述举例的实现方式之外，还可以在一个安装有待测试程序的电子设备上采集数据，在另外的至少一个电子设备上分析数据，再在其他电子设备上输出性能分析结果，这些电子设备之间可以进行有线或无线通信。为便于理解，后续以如图1所示的场景进行说明，不再额外赘述。

图2示出了本申请所涉及到的电子设备的结构示意图。如图2所示，电子设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serialbus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在本申请另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。例如，当电子设备为智能电视时，智能电视无需设置SIM卡接口195、摄像头193、按键190、受话器170B、麦克风170C、耳机接口170D中的一个或多个。图示的部件可以以硬件，软件，或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。在一些实施例中，电子设备也可以包括一个或多个处理器110。其中，控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。这就避免了重复存取，减少了处理器110的等待时间，因而提高了电子设备的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。其中，USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备充电，也可以用于电子设备与外围设备之间传输数据，也可以用于连接耳机，通过耳机播放音频。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本申请另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks，WLAN)，蓝牙，全球导航卫星系统(global navigation satellitesystem，GNSS)，调频(frequency modulation，FM)，NFC，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括GSM，GPRS，CDMA，WCDMA，TD-SCDMA，LTE，GNSS，WLAN，NFC，FM，和/或IR技术等。上述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

电子设备通过GPU，显示屏194，以及应用处理器等可以实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备可以通过ISP，一个或多个摄像头193，视频编解码器，GPU，一个或多个显示屏194以及应用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光、色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐、照片、视频等数据文件保存在外部存储卡中。

内部存储器121可以用于存储一个或多个计算机程序，该一个或多个计算机程序包括指令。处理器110可以通过运行存储在内部存储器121的上述指令，从而使得电子设备执行本申请一些实施例中所提供的语音切换方法，以及各种功能应用以及数据处理等。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统；该存储程序区还可以存储一个或多个应用程序(比如图库、联系人等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如照片，联系人等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。在一些实施例中，处理器110可以通过运行存储在内部存储器121的指令，和/或存储在设置于处理器110中的存储器的指令，来使得电子设备执行本申请实施例中所提供的语音切换方法，以及各种功能应用及数据处理。

电子设备可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。其中，音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备可以通过扬声器170A收听音乐，或收听免提通话。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备可以设置至少一个麦克风170C。在另一些实施例中，电子设备可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，还可以是美国蜂窝电信工业协会(cellular telecommunications industry association ofthe USA，CTIA)标准接口。

传感器180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

其中，压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备根据压力传感器180A检测所述触摸操作强度。电子设备也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

陀螺仪传感器180B可以用于确定电子设备的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定电子设备围绕三个轴(即，x，y和z轴)的角速度。陀螺仪传感器180B可以用于拍摄防抖。示例性的，当按下快门，陀螺仪传感器180B检测电子设备抖动的角度，根据角度计算出镜头模组需要补偿的距离，让镜头通过反向运动抵消电子设备的抖动，实现防抖。陀螺仪传感器180B还可以用于导航，体感游戏场景等。

加速度传感器180E可检测电子设备在各个方向上(一般为三轴)加速度的大小。当电子设备静止时可检测出重力的大小及方向。还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

距离传感器180F，用于测量距离。电子设备可以通过红外或激光测量距离。在一些实施例中，拍摄场景，电子设备可以利用距离传感器180F测距以实现快速对焦。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。电子设备通过发光二极管向外发射红外光。电子设备使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时，可以确定电子设备附近有物体。当检测到不充分的反射光时，电子设备可以确定电子设备附近没有物体。电子设备可以利用接近光传感器180G检测用户手持电子设备贴近耳朵通话，以便自动熄灭屏幕达到省电的目的。接近光传感器180G也可用于皮套模式，口袋模式自动解锁与锁屏。

环境光传感器180L用于感知环境光亮度。电子设备可以根据感知的环境光亮度自适应调节显示屏194亮度。环境光传感器180L也可用于拍照时自动调节白平衡。环境光传感器180L还可以与接近光传感器180G配合，检测电子设备是否在口袋里，以防误触。

指纹传感器180H(也称为指纹识别器)，用于采集指纹。电子设备可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。另外，关于指纹传感器的其他记载可以参见名称为“处理通知的方法及电子设备”的国际专利申请PCT/CN2017/082773，其全部内容通过引用结合在本申请中。

触摸传感器180K，也可称触控面板。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称触控屏。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备的表面，与显示屏194所处的位置不同。

骨传导传感器180M可以获取振动信号。在一些实施例中，骨传导传感器180M可以获取人体声部振动骨块的振动信号。骨传导传感器180M也可以接触人体脉搏，接收血压跳动信号。在一些实施例中，骨传导传感器180M也可以设置于耳机中，结合成骨传导耳机。音频模块170可以基于所述骨传导传感器180M获取的声部振动骨块的振动信号，解析出语音信号，实现语音功能。应用处理器可以基于所述骨传导传感器180M获取的血压跳动信号解析心率信息，实现心率检测功能。

按键190包括开机键，音量键等。按键190可以是机械按键，也可以是触摸式按键。电子设备可以接收按键输入，产生与电子设备的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备的接触和分离。电子设备可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。所述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。电子设备通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在电子设备中，不能和电子设备分离。

本申请所提供的技术方案，利用Systrace采样数据具备良好时间信息的特性，以及，Simpleperf采样数据具备良好源码细节的特性，结合二者来实现对待测试程序的性能分析。

可以参考图3，图3示出了本申请所提供的性能分析方法的流程示意图，如图3所示，该方法可以包括如下步骤：

S302，获取目标程序的第一采样数据与第二采样数据。

其中，所述第一采样数据是通过所述目标程序中插入的探测代码采集得到的事件信息，所述第二采样数据是通过性能监控单元PMU采集得到的栈信息。

具体实现场景中，目标程序即可以为被测试程序。除此之外，当应用于程序对比这一具体的应用场景时，目标程序还可以包括至少一个对照程序。

S304，获取所述第一采样数据与所述第二采样数据之间的时间映射关系，所述时间映射关系用于关联所述事件信息与所述栈信息。

换言之，通过时间映射关系，将第一时间轴上的事件信息与第二时间轴上的栈信息对应起来。

S306，生成所述目标程序的性能图，所述性能图的纵轴表示事件所对应的栈信息，横轴表示栈对应的时间长度。

可以理解，若目标程序有多个，则分别生成每个目标程序的性能图。例如，一种可能的实现场景中，若目标目标程序包括：被测试程序与对照程序，那么，该步骤所生成的所述性能图可以为多维性能图，所述多维性能图包括：所述被测试程序的性能图与所述对照程序的性能图。

本申请所生成的性能图可以由多个不同颜色的方块堆叠而成，类似火焰，因此可以将其称之为火焰图，或性能火焰图。以下，对本方案的具体实现方式进行具体说明。

一方面，第一采样数据为Systrace采样数据。

Systrace采样及其变种方案，例如trace compass，trace view，perfetto等，是基于追踪技术(或称为“探测技术”)实现，其主要是通过在被测试程序的关键位置(例如，System Service，虚拟机，Binder驱动等)插入探测代码的方式实现采样的。

图4示出了Systrace采样的实现方式。如图4所示，用户可以将追踪系统内核(Ftrace Framework Core)的控制信息写入调试文件系统(debugfs)，如此，在具体执行Systrace采样时，Ftrace Framework Core首先就需要从debugfs中读取控制信息，控制信息所提供的内容可以包括但不限于：探测代码的位置、探测代码的数目中的至少一种。从而，在内核层(Kernel Space，或内核空间)中，追踪系统内核(Ftrace Framework Core)在被测试程序的内核(Kernel)中插入探测代码(Tracers，或称为Label)；进而，在被测试程序的Kernel运行过程中，Tracers可以采集被测试程序中发生的事件信息，并将这些事件信息存储到环状缓存区(Ring Buffer)，如此，调试文件系统(debugfs)可以读取Ring Buffer中记录的事件信息，并反馈给前端的用户层(User Space，或用户空间)。此外，如图4所示，探测代码还需要向追踪系统内核进行注册，以便于完成事件信息的采集和存储。

如前所述，对于任意一个被测试程序而言，Ftrace Framework Core在该被测试系统的内容中插入的探测代码(Tracers)的数目可以为一个或多个，任意两个探测代码的位置一般不相同(可以相同，对此无限制)，当被测试程序运行到任意探测代码所在位置时，探测代码都采集被测试程序中的事件信息。例如，Tracers可分别用于采集tracepoint、IRQ-flags、kprobe、Debug Store等事件信息。

基于前述处理方式，Systrace采样方法能够对探测代码所在位置附近的事件信息进行记录，这种记录方式同时还记录了各事件的时间信息。也就是，Systrace采样数据(也就是第一采样数据)实际为事件-时间信息，其中，时间信息可以包括：事件起始时刻与持续时长(Duration Time)。后续为了便于说明，将Systrace的时间信息所采用的时间轴作为第一时间轴。

为便于直观了解Systrace采样数据，可以参考图5所示的现有技术中的Systrace采样数据的事件-时间示意图。如图5所示，一个进程中可以包含多个线程，例如图5左侧栏中显示的一个进程名下包含多个线程，图5示出了4个进程，而图5右侧栏则示出了其中一个线程中的事件-时间示意图，其中，纵坐标表示各Tracers采集到的进程上的事件，横坐标表示时间信息，如图5所示，单位可以为毫秒(ms)。

如图5所示的一个线程中，可以包含多个事件，在图5中，每个事件都表示为一个方块，每个方块上显示的文字即为该事件的事件Tag(标签)。对于图5中任意一个方块而言，该方块在横坐标上的宽度表示该事件的持续时长。一个方块可以和Tracers一一对应，一个Tracers可以记录一个事件。从纵向上看，一个Tracers中还可以设计多个子Tracers，如图5所示，事件Tag为“Activity Start”的事件对应Tracers中还设计了多个子Tracers，例如，图5中示出的事件Tag为“onCreate”的事件。可以理解，图5中的事件Tag为示意性的，其中存在部分方块，由于事件的持续时长较短，未在图5中示出事件Tag，或者，在图5中未完全示出事件Tag。实际场景中，Tracers按照预设的定义来记录事件，这些定义是提前预设好的，因此，Tag等事件信息也是按照预设的定义来记录的。这也要求开发人员必须了解预设的事件定义，也即，清楚定义的每个事件，才能以此为依据来实现进一步分析。此外，图5中的F表示绘图帧。

在如图5所示的事件-时间示意图中，采集得到的事件是基于Tracers获取得到的，因此，在图5中不同方块之间的空白区域，可能是由于未设置Tracers造成的，因此，虽然该空白区域中未标记事件，并非表示没有事件发生。可知，以Systrace采样方式完全依赖于插入的Tracers的位置。

综上，Systrace采样方法得到的Systrace采样数据(可作为第一采样数据)可以为开发人员提供精确的时间信息，可以还原被测试程序在运行过程中系统功能内核的各类事件，这相当于历史见证者，并且会把发生过的历史一五一十都记录下来，以便于后续分析使用。但是，这种采样方式缺乏事件发生时候的细节信息，尤其是关键的源码细节，这也给开发人员对被测试程序中的函数定位造成了不便。

另一方面，第二采样数据为Simpleperf采样数据。

基于采样技术Simpleperf及其变种方案则是利用中央处理器(centralprocessing unit，CPU)中的性能监视器单元(Performance Monitor Unit，PMU)来实现数据采集的。目前，PMU普通设置于CPU中，用于记录CPU周期数、执行指令数、执行指令位置、缓存失效次数等信息。如此，在进行性能分析时，可以利用PMU采样得到指令执行位置，从而，就可以找到程序的调用堆栈，根据调用堆栈就可以还原程序执行时候的源码信息。

具体实现时，PMU可以按照预设的采样周期进行数据采集，PMU采集得到的Simpleperf采样数据(为便于区分，可作为第二采样数据)可以包括但不限于：栈以及各栈对应的时间点。换言之，第二采样数据为栈-时间信息，为便于区分，本申请将PMU采样过程所使用的时间轴称为第二时间轴。

为便于直观了解PMU采集到的Simpleperf采样数据，可以参考图6所示的现有技术中的火焰图，该火焰图是以PMU采集得到的Simpleperf采样数据为基础，将这些栈进行堆叠合并后绘制出来的，其中，该火焰图的横坐标为采样数，纵坐标为堆栈信息。另外，如图6所示，每个栈也有各自对应的栈Tag，实际场景中，栈Tag可以表示栈对应函数的函数名。可以理解，由于栈的横向宽度不同，图6中部分栈的栈Tag未完全显示。在图6所示的现有技术的火焰图中，可以提供详细的源码堆栈等关键信息，这相当于一种空间见证者，可以在某个时间点定格当前系统，然后采集所有需要的硬件信息甚至源码堆栈，因此可以给开发者提供直观的参考。但是，由于相同的栈被堆叠合并，这完全破坏了时间信息，这种采样方式的时间信息是不精确甚至是颠倒错误的，因此，无法准确知道某个时间段内是否正在执行哪些代码，可能会引导开发者做出误判，对性能分析和优化有很大不利影响。

此外，需要说明的是，本申请中，Tag表示标签，在不同的图示场景汇总，Tag表示的含义有所不同。在如图5所示的事件-时间示意图中，Tag为事件标签，展示在用于表示事件的方块上；而在如图6所示的火焰图中，Tag为栈标签，可用于表示栈对应函数的函数名，也显示在用于表示栈的方块上面。此外，由于Tag的长度较长，或者，由于Tag对应的显示位置较小(例如，图5和图6中部分方块的横向宽度较短)，这导致部分Tag可能未完全显示，或者，导致部分Tag完全未显示。可以理解，若将图5或图6进行放大，也是可以由充足的显示位置来显示Tag的。后续示意图中涉及到Tag显示不充分的问题，不再赘述。

基于此，本申请将Systrace采样数据中携带的时间信息、Simpleperf采样数据中携带的源码细节信息进行结合，来对待测试程序进行性能分析，以期精确定位场景发生时间，并且能够对应展开所有事件细节内容，防止误判。

在S302步骤中，本申请利用Systrace方式与Simpleperf方式分别对被测试程序进行数据采集。采样方式和采样数据如前所述。

本申请对Systrace所插入的tracers的位置无特别限定。在以Systrace进行数据采集时，可以调用Systrace程序接口来采集数据，Systrace在待测试程序中插入Tracers时，可以按照系统默认或自定义的规则，或者，用户指定的目标位置。例如，用户在启动Systrace采样之前，预先输入Systrace配置文件，该Systrace配置文件所携带的信息可以包括但不限于：Tracers的数目和位置。

本申请的PMU采取offline cpu模式工作，PMU的工作状态与中央处理器CPU的运行状态无关。也就是，无论CPU处于何种工作模式，PMU都按照预设的采样周期进行数据采集。如此，在CPU运行时或休眠状态下，或者，其他非运行状态下，PMU都能够正常采样工作，这也能够消除在CPU非工作状态下不采集数据导致的采样空洞问题。除此之外，对于Simpleperf采样而言，采样周期可以根据需要预设，本申请对此亦无特别限定。具体的，一种可能的设计中，PMU可以采用绝对时钟模式进行采样，也就是，PMU按照固定时长间隔(或数值固定的频率)进行采样，以保证按照时间顺序采集的采样点所对应时间能够线性增长，也即，第二时间轴上各采样点之间的时间间隔相等。或者，另一种可能的设计中，PMU可以采用相对时钟模式进行采样，这采样模式不要求采样间隔(或采样频率)固定，在第二时间轴上，两个相邻采样点之间的时间间隔可能相同或不同。

除此之外的一种可能的设计中，在前述任意一种采样过程中，还可以对采样过程中使用的Ring Buffer进行溢出检测。图7示出了Ring Buffer的存储机制和溢出情况。RingBuffer为一个环形存储结构，为便于说明，图7示出了将Ring Buffer展开后的存储结构，其中，箭头表示数据接续关系，该存储结构具备8个存储位置。一开始，Ring Buffer为空，当开始在Ring Buffer中写入数据时，可存储在任意一个位置，如图7所示，将数据“1”写入第3个存储位置；当在Ring Buffer中继续写入数据，则以当前第3个存储位置为起点(START)，开始按照顺时针或逆时针方式，依次存储数据，如图7所示，在Ring buffer中存入3个数据，第3个存储位置为起点，第5个存储位置为终点；当Ring Buffer中写满数据时，若需要在继续存储数据，就会导致Ring Buffer溢出，导致采样点数据无法继续被存储，导致采样丢失。

因此，若检测到Ring Buffer溢出，则可以采取防溢出处理，来降低采样丢失率，提高数据的准确性与可靠性。其中，防溢出处理可以包括但不限于如下至少一种：降低采样负载、调整采样参数(例如采样频率)或者增大Ring Buffer的缓存区大小(增大缓存位置)等。例如，针对Simpleperf采样，可以降低采样频率和/或增大Ring Buffer缓存区大小。又例如，针对Systrace采样，可以减少探测代码的数目和/或增大Ring Buffer缓存区大小。

其次，在得到Systrace采样数据和Simpleperf采样数据之后，本申请在想执行S304时，还进一步获取所述第一采样数据与所述第二采样数据之间的时间映射关系，以便于后续使用这些采样数据时，Simpleperf采样数据与Systrace采样数据能够对应，具体的，使得事件信息与所述栈信息之间能够准确关联和对应。

本申请中，可以获取第一时间轴与第二时间轴之间的偏差时长，以作为所述时间映射关系；或者，也可以同步所述第一时间轴与所述第二时间轴，以作为所述时间映射关系。

请参考图8，可以利用校准Tag(图8中表示为校准标签)来获取时间映射关系。其中，校准tag为提前预设的某一个事件的Tag，更具体的，可以为该目标程序中一定会出现的一个事件Tag。在预设校准Tag时，可以将校准Tag的起始时刻对应于Simpleperf的某一个采样点。示例性的，图8所示场景中，校准Tag的起始点对应于第二时间轴上的第2个采样点。

如图8所示，通过Systrace采样时，可以在第一时间轴中获取得到校准Tag起始时刻S1与持续时长；而通过Simpleperf采样时，也可以在第二时间轴中获取到该校准Tag的第一个标准采样点，也即第二时间轴中的第2个采样点S2。可知，S1与S2在实际场景中均对应校准Tag的起始时刻，因此，二者是对应的。

由此，若S1时刻与S2的时刻一致，则第一时间轴与第二时间轴本身即是同步的，无需再次进行同步。此时，第一时间轴与第二时间轴同步，即为二者的时间映射关系。

若S1时刻与S2时刻不一致，可以参考图8，S1与S2之间存在偏移时长S3，则此时，可以将偏移时长S3作为二者的时间映射关系。此时，第一时间轴上任意时刻Sx对应于第二时间轴上的Sx’，且Sx与Sx’之间相差S3。

或者，若S1时刻与S2时刻不一致，还可以利用该偏移时长S3，来调整所述第一时间轴或所述第二时间轴，使得所述第一时间轴与所述第二时间轴同步。例如，可以利用第一时间轴来同步第二时间轴，将第二时间轴上各采样点对应的时刻与该偏移时长S3进行相加或相减处理，来得到各采样点实际对应的时刻。仍以图8为例，若S2的时刻晚于S1时刻，则将第二时间轴上各采样点对应的时刻减去S3，以解决第二时间轴晚于第一时间轴的情况，如图8右侧所示，时间轴同步后的S2’时刻为S2时刻减去S3时刻得到的，且S2’时刻与第一时间轴上的S1时刻相同；反之，若S2的时刻比S1时刻早，则将第二时间轴上各采样点对应的时刻加上S3，以解决第二时间轴早于第一时间轴的情况；如此，实现第一时间轴与第二时间轴的同步。可以理解，还可以利用第二时间轴来同步第一时间轴，不作赘述。

通过对第一时间轴与第二时间轴进行对齐，能够在一定程度上提高Simpleperf采样数据与Systrace采样数据的数据准确率，这也有利于在后续裁剪数据时能够得到正确对应的数据。

基于此，即可绘制如S306所述的性能图。

在具体处理时，还可能涉及到一种特殊的处理，也就是，虑到采样过程可能会过量采样，因此，为了得到更为精确的性能图，还可以在生成所述目标程序的性能图时，对所述第二采样数据进行剪裁，并利用所述裁剪后的第二采样数据，生成所述目标程序的所述性能图。这有利于多滤掉非关注区间的数据，也有利于缩减数据处理量，加快处理效率。

在实际场景中，过量采集能够防止数据缺失，数据采集的时长会超出被测试程序真正运行的时间范围。需要说明的是，本申请所涉及到的被测试程序，可以是一个单独的软件程序，也可以是任意软件程序中的部分程序。以一个购物类APP为例，可以将该购物类APP的整个软件程序都作为被测试程序，或者，也可以将购物类APP中的启动程序、搜索程序、聊天程序等子程序中的至少一种作为被测试程序。可以理解，若混淆多个场景或功能，则会导致数据量大幅增大，且不同场景或功能之间存在相互干扰，因此，在实际场景中，更多的是对单一场景或单一功能的性能分析。因此，前述所提及的被测试程序真正运行的时间范围，是指被测试程序自身的运行时长。例如，若将该购物类APP的搜索程序作为被测试程序进行数据采样，则前述Systrace采样与Simpleperf采样可以从该购物类APP启动之前，就开始进行数据采集，也即，数据采集的时长超出了该搜索程序的运行时长。

针对这种情况，就需要对采集到的Simpleperf采样数据进行裁剪，以截取被测试程序运行过程中的目标数据。本申请中，裁取目标数据的范围可以由开发人员自定义设计，也可以按照默认设置进行裁剪。具体而言，裁剪所述第二采样数据时，可以通过获取所述第一采样数据中的目标事件来实现，根据前述时间映射关系，确定所述目标事件对应的目标栈，从而，裁剪出所述目标栈对应的第二采样数据。

其中，目标事件可以通过目标事件标识来进行指示。目标事件标识可以表示为事件Tag(事件标签)或目标时间区间。只需要将事件Tag对应的事件确定为目标事件，或者，将目标时间区间中的事件确定为目标事件即可。而目标事件标识，则可以有多种获取途径。一种可能的设计中，可以将目标事件标识预设或默认配置在裁剪配置信息(可以表示为一个裁剪配置文件)中，或者，也可以输出可供用户操作的可操作面板，并由此获取用户的操作信息所选择的事件Tag或时间区间，以作为目标事件标识；或者，还可以利用自学习模型，来处理第一采样数据，从而获取到该自学习模型所输出的目标事件标识。综上，本申请可以为用户提供自定义裁剪数据的可能性，方便用户的个性化处理，满足不同业务不同裁剪范围的性能评估需求，更便于用户对感兴趣事件进行分析，灵活性较高。

此时，一种可能的实现场景中，开发人员可以在裁剪配置文件中预设裁剪范围。例如，用户可以在配置文件中输入一个或多个事件Tag，如此，在完成对前述时间轴的同步之后，本方案可以自动根据裁剪配置文件中的事件Tag，来确定这些事件Tag对应的第一时间轴范围，并映射到第二时间轴上，从而，在第二时间轴上进行裁剪，得到目标数据。又例如，用户可以在配置文件中输入需要裁剪出来的至少一个时间区间(或称为裁剪区间)，若有多个时间区间，则任意两个时间区间可以不连续，从而，在执行裁剪动作时，只需要在第二坐标轴上将采样数据裁剪出来即可。

另一种可能的实现场景中，本申请还可以在完成时间轴同步步骤之后，输出可视化输入渠道，以供用户在可视化输入渠道上操作来确定需要的裁剪范围。例如，可以在电子设备的显示界面上，输出两个可供输入时间信息的输入框，一个输入框用于输入裁剪的起始点，另一个输入框用于输入裁剪的结束点。用户只需要在输入框中输入需要裁剪的时间区间即可。此时，为了便于处理，还可以在用户输入时间点时，在图4中显示裁剪范围。又例如，还可以在电子设备的显示界面上，输出如图4所示的事件-时间示意图，并设置可供用户操作以移动位置的两个可移动光标，如此，用户可以拖动这两个光标，以在事件-时间示意图上选择出裁剪范围。又例如，还可以在电子设备的显示界面上，输出如图4所示的事件-时间示意图，用户可以通过点击Tag的方式，选择裁剪范围，此时，为便于用户了解自己所选择的范围，还可以将用户点击确定的Tag进行突出显示，例如高亮显示。

另一种可能的实现场景中，还可以通过自学习的方式，自动确定裁剪范围。这种实现方式需要大量的样本数据来训练自学习模型，对模型训练过程不额外赘述。自学习模型的输入和输出可以由多种设计。例如，自学习模型可以用于对输入数据进行裁剪，以输出裁剪后的输出数据；换言之，自学习模型的输入数据为前述Systrace采样数据与Simpleperf采样数据，输出数据为裁剪后的Systrace采样数据与Simpleperf采样数据。又例如，自学习模型用于确定输入数据的裁剪范围，例如，输入数据可以为Systrace采样数据，输出数据为目标事件标识，具体的，可以为至少一个时间区间；或者，输入数据可以为Systrace采样数据，输出数据为目标事件标识，具体的，可以为一个或多个Tag。

在前述实现场景中，若确定的裁剪范围为一个Tag，则将该Tag的起始时刻作为裁剪起点，并根据该Tag的起始时刻和持续时长，获取Tag的结束时刻，并将该结束时刻作为裁剪终点。若确定的裁剪范围为多个Tag，此时，多个Tag中的任意两个Tag可以连续，也可以不连续，那么，可以按照的单个Tag的方式，分别对每个Tag所在范围分别进行裁剪；或者，无论Tag是否连续，可以将最早的一个Tag的起始时刻作为裁剪起点，将最后一个Tag的结束时刻作为裁剪终点。

此外，若确定的裁剪范围为一个时间区间，若该时间区间的起点位于某一个Tag上，则将该Tag的起始时刻作为裁剪起点；若该时间区间的终点位于某一个Tag上，则将该Tag的结束时刻作为裁剪终点。或者，若该时间区间的一个端点(起点或终点)位于空白位置，则在第一时间轴上寻找最接近的Tag，并将该最接近的Tag的端点作为时间区间的端点，这种情况下，确定的时间区间中包含至少一个Tag。其中，最接近的Tag是指在第一时间轴上最接近。例如，若在第一时间轴上，依次存在Tag A、Tag B和Tag C，且任意相邻的两个Tag之间存在空白区域。那么，若前述确定的时间区间的起点位于Tag A和Tag B之间，且更接近Tag B，该时间区间的终点位于Tag B和Tag C之间，且更接近Tag B，此时，可以将Tag B两侧端点作为时间区间进行裁剪。或者，若前述确定的时间区间的起点位于Tag A和Tag B之间，且更接近Tag A，该时间区间的终点位于Tag B和Tag C之间，且更接近Tag B，此时，可以将Tag A的起始时刻作为时间区间起点，将Tag B的结束时刻作为时间区间终点。或者，若前述确定的时间区间的起点与终点均位于Tag A和Tag B之间，那么，可以将Tag A的起始时刻作为时间区间起点，将Tag A的结束时刻作为时间区间终点；或者，也可以将A的起始时刻作为时间区间起点，将Tag B的结束时刻作为时间区间终点。

前述处理过程中，可以基于第一时间轴上的事件信息确定出裁剪范围的起点和终点，如此，在进行数据裁剪时，只需要调用裁剪器对第二时间轴上的Simpleperf采样数据进行裁剪即可。当然，具体实现场景中，也可以同时对第一时间轴上的Systrace采样数据进行裁剪，本申请对此无特别限定。

在前述确定裁剪范围的方案过程中，本申请对于各事件是否属于同一个线程无特别限定，例如，前述举例中，Tag A可能属于线程A，而Tag B可能属于线程B。因此，本申请实际提供了一种跨进程(或线程)的裁剪方案。在实际场景中，线程可能会休眠或被调度到其他地方，这种情况下，可能导致采样时的事件缺失，在面对这种情况时，本申请所提供的跨进程(或线程)裁剪方案，就能够避免局限于主进程导致数据缺失的问题，裁剪范围的起点和终点可位于不同进程的不同线程上，实现了业务驱动裁剪的自适应方案。

本申请中，是以Simpleperf采样数据来绘制性能火焰图的，该性能火焰图的纵轴表示事件所对应的栈信息，横轴表示栈对应的时间长度。

示例性的，图9示出了本申请所提供的一种性能火焰图的示意图。如图9所示，本申请所提供的性能火焰图是在Simpleperf采样数据基础上，将相同的栈进行堆叠，并以堆叠后的栈的耗时时长为横轴，以栈的层级关系为纵轴，堆叠绘制出来的。为便于查看，图9仅示出部分火焰图，在火焰图上，各方块表示栈，方块上显示的文字即为栈的标签(Tag)，针对任意一个栈而言，方块的横轴宽度即表示调用该栈的耗时时长。由于部分栈的耗时时长较短，图9中存在部分栈的栈Tag未完全示出，或完全未示出，可以理解，当该性能火焰图放大到一定程度时，也可以在栈所在的方块上显示栈的Tag。

具体而言，在性能火焰图中，以任意具备上下层关系的栈为例，下层栈是上层栈的父级栈，下层栈对应函数是上层栈对应函数的父函数；反之，上层栈为下层栈的子级栈，上层栈对应函数为下层栈对应函数的子函数。按照该规律，依次堆叠，形成函数的堆栈。对于任意一个堆栈而言，该堆栈由多个栈构成，该堆栈中的顶层栈可以作为该堆栈的叶子节点，底层栈则作为该堆栈的根节点，一个堆栈可以具备多个叶子节点(即顶层栈)，但具备一个根节点(即底层栈)。

如此，如图9所示的性能火焰图中，既包含与Systrace采样数据一致的时间信息，还包含堆栈的信息，包含有各事件的所有源码细节，融合了Systrace采样的时间特性，与Simpleperf的空间特性，由此，开发人员可以据此确定在裁剪确定的时间区间里，具体在执行哪些代码，这也能够避免现有技术中仅利用Simpleperf方案绘制如图6所示的火焰图时，由于时间信息不准确导致开发人员误判的几率。

本申请在在图9所示的性能火焰图基础上，进一步设计了该性能火焰图的响应机制。

在生成并输出前述火焰图后，还可以实时采集用户在所述性能图上的操作信息，若所述操作信息为光标移动信息，将所述操作信息所指示的指定栈突出显示，和/或，输出所述指定栈的耗时时长。如此，用户通过简单的鼠标移动动作，就可以查看指定栈的耗时时长，和/或，可以轻易看出用户所要查看或操作的栈，便于用户后续操作。

一种可能的设计中，用户可以控制鼠标在该电子设备的显示界面上移动，若鼠标的光标由空白区域移动到该性能火焰图上的某一个栈上时，或者，从光标移动到该栈上开始计时的累积时长达到预设时长阈值时，则可以将该栈的耗时时长输出，和/或，将该栈突出显示。

例如，当用户控制鼠标在图9所示的性能火焰图上移动，使得鼠标的光标移动到指定栈时，如图9所示，该指定栈高亮显示。

示例性的，图10示出了性能火焰图的几种展示情况示意图。在如图10所示的显示界面上示出了一种性能火焰图，该性能火焰图中示出了10个栈的情况。当用户控制鼠标的光标在显示界面上移动，且该鼠标光标在栈5的位置停留超过500ms(预设的时长阈值，可自定义设计，本申请对此无特别限定)，则可以如图10所示，将栈5在显示界面上突出显示。具体的，可以将栈5作高亮显示，或变色显示。除此之外，若用户控制鼠标，使得鼠标光标在栈5的位置停留超过600ms(可预设另一个时长阈值，仍可自定义设计，本申请无特别限定)，则如图10所示，获取栈5的耗时时长，假设为30ms，并在该显示界面上显示栈5的耗时时长30ms。本申请对输出耗时时长的位置无特别限定，图10所示显示方式仅为一种可能的设计，实际场景中，还可以在侧边空白位置显示栈5的耗时时长。此外，如图10所示，还可以同时突出显示并输出耗时时长。可以理解，实际场景中，将光标停留位置进行突出显示和输出耗时情况的时长阈值可以相同或不同，图10仅为示意性的，本申请对此无特别限定，自定义设计即可。此外，输出耗时时长时，可以显示耗时时长的单位，或采用默认单位；例如，默认单位可以为毫秒(ms)，则在输出耗时时长时，只需要显示具体的数值即可。

此外，本申请所提供的性能火焰图中，栈的Tag可以为栈对应函数的函数名，这种情况下，会存在不同栈具备相同Tag的情况。例如，该被测试软件中存在函数重载的情况时，会存在重名函数，也即，多个函数共用一个函数名，但各函数的参数可能不同，此时，以函数名作为栈的Tag，就会存在不同栈具备相同Tag的情况。又例如，一个函数可以被不同的上一级函数调用，例如，函数1可以调用函数2，函数3也调用函数2，若函数1和函数3处于不同的分支，例如在上一级函数可以执行函数1或函数3，那么，函数2会分别被函数1和函数3调用，函数2的栈存在两块，一块位于函数1的上层，另一块位于函数3的上层。又例如，函数还可能是递归的，也就是，函数可以自己调用自己，而且可以调用多次，则在该函数的堆栈上，会出现多个同样的函数，这也会导致栈的Tag相同。

那么，在这种情况下，若用户控制鼠标的光标停留在某一个栈上，则可以在该性能火焰图的栈上，查找与该光标所在栈的Tag相同的其他栈。若不存在其他栈，则按照如图10所示方式进行显示响应即可。若存在Tag相同的其他栈，则在进行显示响应时，可以将性能火焰图上的这些栈都做类似处理。

示例性的，请参考图11所示的显示界面。在如图11所示的显示界面上示出了一种性能火焰图，该性能火焰图中示出了10个栈，其中，存在3个Tag相同的栈，如图11所示的栈3。此时，若用户控制鼠标的光标移动，使得光标在其中一个栈3处的停留时长超过预设的时长阈值，假设为300ms，或者，如图4所示，用户控制鼠标移动使得光标移动到其中的一个栈3上，就可以将所有栈3都作突出显示。或者，还可以在显示界面上显示3个栈3的耗时时长。或者，既对这3个栈3突出显示，也显示这3个栈3的耗时时长。或者，还可以同时对3个栈3都突出显示，但只对光标所在的栈3显示耗时时长。

此外，考虑到如图9～图11所示的性能火焰图中堆叠的栈过多，开发人员可能还需要进行一步查看某一个指定栈的详细情况，此时，本申请还进一步提供了性能火焰图的降维展示功能，以满足开发人员的查看需求。所谓降维展示，也就是，将用户选择的指定栈作为底层栈，忽略该指定栈的父级栈，并展示该指定栈及其子级栈。例如，图12即示出了一种性能火焰图的降维展示情况，具体的，图12是对图9所示的性能火焰图中突出显示的栈进行降维展示的情况。

因此，在生成并输出前述火焰图后，还可以实时采集用户在所述性能图上的操作信息，若所述操作信息指示将指定栈降维展示，根据所述性能图，获取降维性能图；其中，所述降维性能图的底层栈为所述指定栈；显示所述降维性能图。如此，用户能够方便的指定一个栈进行降级，方便用户对比查看。

以下，结合图13A～图13B对本申请所提供更多降维展示方法进行说明。

示例性的，请参考图13A所示的显示界面，本申请中，根据裁剪得到的Simpleperf采样数据绘制的初始的性能火焰图上包含10个栈，此时，用户需要查看其中Tag为4的栈的情况，那么，就以用户指定的栈4为底层栈，忽略栈4以下的父级栈，如栈1和栈2和栈3，并将栈4的子函数对应栈(栈5～栈10)进行展开显示，形成如图13A右侧示意图所示的性能火焰图。在该性能火焰图上，栈4作为该堆栈的底层栈。

如图13B所示，若初始的性能火焰图上包含10个栈，且10个栈中包含多个栈4，为便于区分，在图13B中，将Tag为4的栈示意为41、42、43。如图13B所示，栈41和栈42位于同一个堆栈上，且栈42位于栈41的上方；而栈41和栈43位于不同的堆栈上，二者为不同的处理分支。那么，若用户指定了某一个具体的栈，例如，栈41，为指定栈，则如图13B右侧示意图所示，仅将用户选中的栈41为底层栈进行降维展示，此时，降维后的性能火焰图上不再包含栈43。

除此之外，若用户仅指定了降维展示的Tag，则可以从性能火焰图上的根节点(底层栈)出发，来确定出降维展示的底层栈，该底层栈的Tag为用户指定的Tag。仍以图13B为例，若用户仅指定了将Tag为4的栈进行降维展示，则可以将所有的栈4都进行降维展示，此时，从图13B的根节点开始逐层确定各栈的Tag是否为4，此时，找到栈41、栈42和栈43，且栈42堆叠在栈41的上层，那么，可以将更下层的栈41作为底层栈；以及，栈43与栈41属于不同的两个堆栈分支，则也可以将栈43作为底层栈。由此，在这种场景下，图13B经过降维展示后，该性能火焰图上可以示出两个堆栈，一个堆栈的底层栈为栈41，另一个堆栈的底层栈为栈43。

如前所述，用户选择降级展示的指定栈时，指定方式可以有多种。例如，用户可以仅指定Tag，来降维展示该Tag对应的所有栈；或者，如图13B所示，用户也可以指定某一个具体的栈，此时，仅对该栈进行降维展示。具体而言，用户可以通过在配置文件中添加指定栈信息来进行指定。或者，还可以在输出的性能火焰图上，输出降维展示的功能入口，例如，显示一个降维展示的虚拟按键，用户可以点击该功能入口来配置需要降维展示的Tag。或者，用户还可以直接在前述性能火焰图上，选中需要降维展示的某一个栈，并通过作出指定动作，例如，右键选择降维展示，或者，对选中的栈进行双击或长按，来触发对该指定栈的降维展示。

除前述设计之外，考虑到具体针对软件产品进行性能测试时，还可能会涉及到对照程序。基于这种情况，本申请还进一步示出了对照程序与被测试程序的性能火焰图的对照情况，也即，提供一种多维性能图(或称为多维性能火焰图，或多列火焰图，或多维火焰图)。请参考图14和图15。

图14示出了两列数据，其中，第一列数据为按照前述方式处理对照程序，得到的对照程序的性能火焰图；而第二列数据为按照前述方式处理被测试程序得到的性能火焰图。实际场景中，二者位置也可以相反，即第一列数据为被测试程序的性能火焰图，第二列数据为对照程序的性能火焰图。本申请对此无特别限定。除此之外，对照程序和被测试程序的性能火焰图还可以上下形式展示。可以理解，图14为示例性的，实际场景中，对照程序的性能火焰图与被测试程序的性能火焰图中的栈Tag可以相同，也可以不同；堆栈结构可以相同可以不同；这都由实际程序决定。而且，在分别利用前述方式生成该多列火焰图时，对照程序的裁剪范围与被测试程序的裁剪范围可能不同，这也是由程序来决定。

本申请对照程序无特别限定。一种可能的实现场景中，开发人员需要观察某一应用程序的不同迭代更新版本之间的性能差异情况，以对被测试程序进行优化，就可以将被测试程序的其他版本程序作为对照程序。另一种可能的场景中，开发人员需要了解被测试程序与类似程序产品之间的性能差异情况，就可以将类似程序产品(或称之为竞品程序)作为对照程序。总之，对照程序可以根据实际场景需要由开发人员自定义选择确定。可以理解，针对不同的被测试程序，甚至针对同一应用程序的不同功能的被测试程序，所采用的对照程序都可以不同，以实现更有针对性的对比。自然，一些实现场景中，也可以采用同一种对照程序，只是在对照效果上可能表现较差。

图15则示出了三列数据，其中，第一列数据为对照程序的性能火焰图，第二列数据为被测试程序的性能火焰图，第三列数据为对照程序和被测试程序的分析数据。与图14类似，本申请对于这三列数据的展示顺序无特别限定。除此之外，亦可以上下形式展示，或者，部分上下显示，部分左右显示。例如，对照程序的性能火焰图和被测试程序的性能火焰图，位于同一列上下显示，而分析数据则与性能火焰图这一列左右显示。

本申请中，如图15所示的三列火焰图中，第三列分析数据可以包括但不限于如下至少一种对比数据：被测试程序中至少顶层栈(图15中Level1指顶层栈)的耗时数据、相对于对照程序，被测试程序的优异栈Tag(图15中示出的优异函数)、相对于对照程序，被测试程序的待改进栈Tag(图15中示出的待改进函数)。可以理解，实际场景中，第三列分析数据还可以包含Level2(由上之下第二层栈)的耗时数据，以及其他层栈的耗时数据。除此之外，第三列分析数据还可以包括但不限于后续涉及到的性能提升参数、热点函数、瓶颈函数中的至少一种信息，后续详述。

与图14类似，图15仅为示意性的，对照程序与被测试程序的性能火焰图也为示意性的，第三列对比数据也为示意性的，所显示的数据可以有其他表现形式，例如，“优异函数”还可以表示为“Improved”，“待改进函数”也可以表示为“Degradated”等，仅为表现形式的差别。以及，图15未详细示出“优异函数”等的具体内容，实际场景中，可以在此显示优异栈tag、优异栈Tag对应的耗时时长等信息，实际场景中自定义设计即可，不作赘述。

对于任意一个程序而言，堆栈越深，其调用的函数越多，位于顶层的栈就是正在执行的函数，顶层栈(叶子节点)越宽，即顶层出现“平顶”(plateaus)，说明该函数运行的时间越长，该函数就可能存在性能问题。因此，在对被测试软件进行性能分析时，可以优先将被测试软件中，每个堆栈的顶层栈的耗时时长中，较长的顶层栈筛选出来，这些耗时较长的顶层栈很可能存在性能问题，是开发人员要重点关注的对象。

具体实现时，可以获取被测试软件的性能火焰图中的各堆栈的叶子节点，也即顶层栈，的耗时数据，然后，按照耗时由长至短的顺序进行排序，并将排序靠前的至少一个栈的Tag展示在第三列的分析数据处。或者，在获取到各顶层栈的耗时数据之后，还可以通过与耗时阈值进行比较，将耗时超过该耗时阈值的栈作为重点关注对象，在第三列的分析数据处进行展示。

如前所述，第三列分析数据除包含顶层栈的时长数据之外，还可以包括其他层的耗时数据。例如，可以按照由顶层至底层方向上的5层栈的耗时时长进行筛选和展示。其中，对于任意两层栈的耗时数据，其展示的栈的数目、耗时阈值和展示方式(排序或阈值的方式确定展示对象)均可以相同或不同。

除此之外，第三列分析数据还进一步给出了被测试程序与对照程序之间的对比情况，主要涉及被测试程序的优异表现情况(被测试程序的优异Tag)和待改进情况(被测试程序的待改进Tag)。具体的，针对被测试程序的任意一个Tag(简称被测试Tag)，都在对照程序中进行遍历，找到该Tag在对照程序中相对应的对照Tag，然后，比较被测试Tag的耗时与对照Tag的耗时情况，若被测试Tag的耗时时长大于对照Tag的耗时时长，则对照程序在被测试Tag对应函数上耗时更少，性能更优异，因此，将被测试Tag作为被测试程序的待改进Tag；反之，若被测试Tag的耗时时长小于对照Tag的耗时时长，则被测试程序在被测试Tag对应函数上耗时更长，性能更优异，因此，将被测试Tag作为被测试程序的优异Tag。从而，在初步确定出待改进Tag和优异Tag后，按照被测试Tag和对照Tag之间的时长差由高至低的顺序排序，并将排序靠前的至少一个Tag，在第三列分析数据处进行展示。

相对于图15，图14所示的两列火焰图缺少对被测试程序和对照程序的对比分析数据，基于此，在实际实现场景中，当以图14所示方式展示被测试程序的性能测试结果时，还能够将图15所示的分析内容文本化，并输出对照程序与被测试程序之间的对比分析结果。该对比分析结果可以表现为一个表格，或表现为文本，或表现为分析报告，本申请对其表现形式无特别限定。

示例性的，图16示出了一种对比分析结果示意图。具体的，图16示出了对照程序与被测试程序在部分函数的对比结果。其中，“对照程序耗时”表示对照程序中相应函数的耗时时长，“被测试程序耗时”表示被测试程序中相应函数的耗时时长，“时长差”则为对照程序耗时减去被测试程序耗时的时长差，也即对照程序与被测试程序在相应函数上的时长差，“时长差占比”则表示时长差在对照程序耗时中所占的比例，其中，N/A表示无结果。在如图16所示的对比分析结果示意图中，若对照程序耗时为0，则说明对照程序中不存在该函数，因此不存在耗时，这种情况下，时长差占比的结果为N/A。可以理解，图16未示出具体的函数名，仅以函数1～函数23进行示例性的说明，实际场景中，则在该列显示具体的函数名。

可以理解，图14和图15仅是当存在一个对照程序时的性能分析结果，而本申请实际上对对照程序的数目无特别限定，其数目可以为至少一个。当存在多个对照程序时，只需要按照前述方式分别处理各对照程序，得到各对照程序的性能火焰图，并基于每个对照程序的性能火焰图与被测试程序的性能火焰图，分别获取分析数据即可。

图14和图15所示的多列火焰图，为被测试程序提供了相对于对照程序的、更有针对性的分析结果，更加有利于开发人员了解被测试程序的优缺点，方便了开发人员对被测试程序的进一步优化。

除此之外，针对图14和图15所示的多列火焰图，类似的，本申请也为多列火焰图提供类似的响应策略。

与单列火焰图类似，在输出多列火焰图后，实时采集用户在所述性能图上的操作信息。

从而，若所述操作信息为光标移动信息，将所述操作信息所指示的指定栈突出显示，和/或，输出所述指定栈的耗时时长。

一种可能的设计中，若用户控制鼠标移动，使得鼠标的光标在多列火焰图中的任意一列火焰图上移动，若光标移动到任意一个栈上，或光标在任意一个栈上的停留时长达到预设时长阈值，则可以将该栈作为指定栈，输出指定栈的耗时时长，和/或，将指定栈突出显示。此时，考虑到光标停留的该栈可能在其他程序(被测试程序或对照程序)的性能火焰图中也存在，因此，可以对该多列火焰图中其他涉及到该相同Tag的栈也作同样处理。例如，图14与图15中，若用户控制光标在被测试程序的性能火焰图上的栈3(假设Tag为3)处停留了2ms，超过预设的时长阈值，则对栈3突出显示，以及，对其他对照程序中检测是否存在Tag为3的栈，若存在，则对对照程序中的栈3也同时突出显示。此外，输出指定栈的耗时时长的设计，也可以在多列火焰图上联动响应，例如，若在对照程序的性能火焰图上输出栈3的耗时时长，则在被测试程序的性能火焰图上也输出对照程序中栈3的耗时时长。如此，用户可以通过一个简单的操作，就将对照程序与被测试程序中的相同Tag突出显示或输出时长，从而，开发人员一眼就可以追踪到相同的Tag，并查看这些相同Tag的对比情况。

此外，若所述操作信息指示将指定栈降维展示，根据所述性能图，获取并显示降维性能图。此时，还可以设计多列火焰图的联动响应。

另一种可能的设计中，针对前述单列的性能火焰图设计的降维展示，也可以适用于多列火焰图。并进一步的，可以实现多列火焰图的联动降维展示。请参考图17，图17是对图15所示的性能火焰图中突出显示的栈3进行降维展示的情况。例如，用户可能指定对对照程序中的栈3作降维展示，则如图17所示，则也会自动在被测试程序中查找栈3，若查找到，则同时在被测试程序的性能火焰图中，也对栈3进行降维展示。如图17所示，被测试程序与对照程序以同一个指定栈(图17中未栈3)为底层栈，进行同样的降维展示。反之，若用户指示对被测试程序中的栈3作降维展示，则其他对照程序也可作类似处理，不赘述。如此，用户可以快速实现对多列火焰图的降维展示和同级对比。

此外，多列性能火焰图中联动降维展示为一种可能的设计方案，更方便用户同级对比，但在一些实现场景中，多列性能火焰图也可以不联动处理，也就是，也可以仅针对用户选中的指定栈作降维展示，其他程序(对照程序或被测试程序)中的同一Tag的栈则不作降维展示。

除通过前述单列或多列的性能火焰图实现对被测试程序的分析之外，本申请还进一步给出如下至少一种数据处理方式，以辅助开发人员评估被测试程序的性能。

一方面，可以获取所述被测试程序的性能提升参数，输出所述性能提示参数。所述性能提升参数用于表征所述被测试程序相对于所述对照程序的性能优化空间的大小。可以理解，性能提升参数越高，被测试程序与对照程序之间的差距越大，被测试程序的提升空间越大。

具体的，基于如图14～图15、图17所示的多列火焰图，开发人员可以方便快捷的确定被测试程序与对照程序之间的差距。但是，在实际实现场景中，被测试程序与对照程序之间的调用栈非常复杂和繁琐，开发人员往往难以通过肉眼看出其中的差距，因此，虽然多列火焰图给出了函数级别的对比度情况，但是，当函数众多时，开发人员很难基于这些函数级别的差异，来确定出被测试程序与对照程序之间的整体差异情况的。面对这种现状，本申请提出性能提升参数的概念，用以给出一种对被测试程序进行整体评估的方法。

具体而言，本申请中，可以获取性能图中的单层性能提升参数，也可以获取多层性能提升参数。

一方面，可以在所述性能图上，获取所述被测试程序与所述对照程序在每一层上的相同栈；从而，对所述性能图中的任意一层，若相同栈在该层所有栈中的数目占比超过预设的比例阈值，获取该层中所有相同栈的时长差之和，得到该层的单层性能提升参数。

在计算性能提升参数时，可以从函数堆栈的叶子节点(也即最顶层)开始，逐层计算每一层中，被测试程序与对照程序中相同的Tag数，并获取相同Tag数在该层Tag总数之中所占的比例。对任意一层，若该层中相同Tag所占的比例达到预设的比例阈值，则说明对照程序与被测试程序在这一层的函数构成比较接近，则计算该层的性能差值；反之，若相同Tag所占的比例小于预设的比例阈值，则说明对照程序与被测试程序在这一层的函数构成相差较大，则继续对下一层的函数构成情况进行分析。其中，性能差值是指对照程序与被测试程序在相同Tag上的时长差值。在具体实现场景中，可以按照性能差值由劣到优的顺序进行顺序输出，以作为本层的性能提升参数。在具体对单层函数进行性能提升参数的计算时，每计算出一层的性能提升参数，就可以重置缓存区，以便于进行下一层的性能提升参数计算。

另一方面，还可以按照所述性能图由顶层至底层的顺序，逐层获取各层的所述单层性能提升参数，从而，若当前累积层数达到指定层数，获取各层的所述单层性能提升参数的加权平均值，以作为多层性能提升参数。此时，还可以进一步设计预设的指定层数。在前述针对每一层进行性能提升参数的计算过程中，是按照堆栈中由上至下的顺序一层层计算的。那么，若计算的层数达到预设的指定层数，假设为n层，则可以对n层函数，进行一次统一的性能提升参数的评估。此时，n层函数的性能提升参数可以按照如下方式获取得到：

其中，Yi表示i层的性能提升参数，i的范围在0到n之间，n表示层数，Xi表示第i层的函数的时长差值，f(x)表示差值权重。

在实际场景中，各函数的权重可以不同。例如，可以预设重要函数的白名单，并为白名单中的函数设计较高的权重值，例如，可以预设为1。而白名单可以根据实际需要预设，例如，可以将Monitor函数，Java指令函数，RC函数，Allocator函数等预设为白名单中的函数，些函数的权重为1。而对于非白名单的函数，则可以适当缩小其权重。例如，可以将非白名单的函数权重设置为f(x)＝1-1/i，如前所述，i表示该函数所在的层数。

此外，在以前述方式计算n层函数的性能提升参数时，可以在每计算一次n层函数的性能提升参数时，都可以重置缓存区，以便于进行后续的n层函数的性能提升参数的计算。

另一方面，获取并输出目标程序中的热点函数，其中，所述热点函数为所述目标数据中热度较高的至少一个函数。本申请中，热点函数用于从性能火焰图中识别出高频函数。本申请中根据函数的热度高低来区分任意一个函数是否高频。

一种可能的方式中，对于任意一个函数来说，可以获取该函数在性能火焰图中出现的次数，并将该出现次数作为函数的热度。

前述的实现方式在实际场景中是可行的，但是，由于调用栈中一般会出现很多相同但是无意义的函数Tag，若直接以函数的出现次数作为热度来确定热点函数，无疑会导致这些无意义的函数会覆盖掉真正的热点函数，导致性能识别结果的准确度较低。

面对这种情况，本申请还提供了热度的另一种处理方式：一个函数可以出现在多个调用栈分支上，在任意一个分支上，该函数还可能存在堆叠的情况，那么，可以获取该函数在性能火焰图中分布的不同独立分支的个数之和，以作为该函数的热度。

为便于理解，现结合图18对函数热度的计算方式进行说明。图18所示的性能火焰图中，A1、A2、A3和A4的tag都是A，都对应于A函数，数值用于区分，B函数和C函数的情况类似。

本申请后续利用Callee来指代被调用者，也就是性能火焰图中位于堆栈上层的函数；利用Caller来指代调用者，也就是性能火焰图中位于堆栈底层的函数。如图18所示，对于栈A2和栈C1而言，栈A2位于栈C1的顶层，栈A2属于该堆栈中的Callee，栈C1属于该堆栈中的Caller。

在进行热度计算时，对于处于同一堆栈分支中的函数，Callee覆盖Caller，也就是，顶层函数覆盖底层函数。例如，图18中的A3和A4，在进行热度计算时，A4属于Callee，A3属于Caller，A4覆盖A3。而对于不同堆栈分支但具备继承关系的函数，Caller被覆盖丢弃且不再统计。例如，图18中A1处于A2-C1-A1-B1的分支，且A1也处于A4-C2-A3-B2-A1-B1所在的分支，若在A4-C2-A3-B2-A1-B1分支中，Callee覆盖Caller，得到的函数是A4；而在计算A2-C1-A1-B1的分支时，A1已经被处理过，被A4覆盖，此时，不再统计A1，得到该分支上的函数为A2。也就是，得到函数A在两个独立分支上的个数，也即，函数A的热度为2。

图18还进一步以函数A为例，对函数A的热度计算方法做出了示例。图18中，首先根据性能火焰图，得到A1～A4共4个A函数从根节点到当前节点的路径列表(pathlist)，如图18所示。预设结果集(Result)，结果集中各栈的数字定义为色值，那么，假设结果集预设为空，则各堆栈的色值均为0。从而，按照如图18所示，将A3-A1-A2-A4的顺序来确定A函数用于计算热度的独立分支函数，首先，从A3开始确定A函数的分支函数，则Result的结果为A3，之后，考虑A1，A3覆盖A1，此时，Result的结果仍为A3；之后，考虑A2，此时，Result的结果为A3和A2，最后，考虑A4，则A4会覆盖掉A3，那么，Result的结果为A4和A2。可以理解，图18所示方式仅为一种可能的设计方式，在实际场景中，对任意一个函数的路径以及计算方式都可以根据需要自定义设计。

具体而言，对于任意一个函数，本申请是按照性能火焰图中从上层的叶子节点到下层的根节点的顺序，依次梳理出该函数在该性能火焰图中的独立分支个数，从而得到函数热度。例如，对图18所示性能火焰图进行梳理，函数B中，B2覆盖B1，函数B的热度为1；函数C则具备两个独立分支：C1和C2，其热度为2。如此，能够在一定程度上避免函数堆叠重复造成的热点函数统计失误问题。

本申请中，在获取到函数热度之后，就可以按照热度由高至低的顺序，获取到热度靠前的至少一个函数，以作为热点函数。例如，按照热度由高至低的顺序，获取热度靠前的5个函数作为热点函数；又例如，获取热度大于预设热度阈值的函数，以作为热点函数。

具体输出时，还可以将热点函数作为热点函数列表输出，热点函数列表可以按照热度由高至低的顺序排序。基于输出的热点函数，用户可以很便捷的知道哪些函数被多次调用，方便用户定位程序问题。

再一方面，本申请还可以获取并输出所述目标程序中的瓶颈函数，所述瓶颈函数为所述目标数据中耗时占比较高的至少一个函数。具体而言，瓶颈函数用于从性能火焰图中识别出耗时较长的函数。

在实际场景中，热点函数往往只能体现高频低频性质，但是并不能体现出耗时情况。也就是说出现次数多并不一定就慢，而导致程序运行慢的那些节点，正是开发人员对被测试程序进行优化的关键所在，因此，本申请中还根据前述性能火焰图来识别其中耗时较长的瓶颈函数，以辅助开发人员对被测试函数进行优化改进。

如前所述，本申请中，性能火焰图的横轴表示的是函数被调用时的耗时时长，因此，可以利用函数对应的栈的宽度，在整个调用栈中的占比情况(可视作覆盖度)，来衡量该函数是否为瓶颈函数。换言之，对所述性能图中的任意一个函数，获取该函数的耗时时长在所属调用栈的总时长中所占的比例，以作为该函数的覆盖度，从而，按照覆盖度由高至低的顺序，获取至少一个函数，以作为所述瓶颈函数。

瓶颈函数与热点函数相反，在进行覆盖度计算时，对于处于同一堆栈分支中的函数，Caller覆盖Callee，也就是，底层函数覆盖顶层函数。而对于不同堆栈分支但具备继承关系的函数，Callee被丢弃。

为便于理解，现结合图19对覆盖度的计算方式进行说明。如图19所示的性能火焰图中，A1、A2、A3和A4的tag都是A，都对应于A函数，数值用于区分，B函数和C函数的情况类似，不赘述。对于图19所示性能火焰图上的A函数而言，在A2-C1-A1-B1的分支中，A1作为Caller，覆盖A2(Callee)，而在A4-C2-A3-B2-A1-B1分支中，A1作为Caller，覆盖A3和A4(A3和A4作为Callee)。如此，A函数的覆盖度可以通过A1的宽度在该堆栈中的占比得到。

图19还进一步以函数A为例，对函数A中用以计算覆盖度的函数(简称覆盖度函数)的处理方法作出了示例。图19中，首先根据性能火焰图，得到A1～A4共4个A函数从根节点到当前节点的路径列表(pathlist)，如图19所示。预设结果集(Result)，结果集中各栈的数字定义为色值，此时，假设结果集预设为[A1，A2，A3，A4]，其他栈的色值均为0。从而，按照如图19所示，按照A3-A1-A2-A4的顺序来确定A函数的覆盖度函数，首先，从A3开始，将A3输入覆盖度算法，则Result的结果为[A1，A2，A3，A4]；之后，考虑A1，A1覆盖A3，此时，Result的结果为[A1，A2，A4]；之后，考虑A2，此时，A1再次覆盖A2，Result的结果为[A1，A4]，最后，考虑A4，A1再次覆盖A4，Result的结果为[A1]。可以理解，图18所示方式仅为一种可能的设计方式，在实际场景中，对任意一个函数的路径以及计算方式都可以根据需要自定义设计。

对于图19所示性能火焰图上的B函数，B1作为Caller，覆盖B2，则利用B1的宽度在该堆栈中的占比得到B函数的覆盖度。对于C函数而言，C1和C2处于不同的调用栈分支上，则通过C1的宽占比与C2的宽度占比之和，来获取得到C函数的覆盖度。

可以理解，对于被测试程序的性能火焰图而言，可以根据任意函数的覆盖度由高至低的顺序进行排序，得到排序靠前的至少一个函数，以作为瓶颈函数。

此外，一种更优选的实现场景中，还可以结合热点函数的识别结果，来识别瓶颈函数。首先，获取所述目标程序中的热点函数，然后，获取各所述热点函数的覆盖度，进而，按照覆盖度由高至低的顺序，获取至少一个热点函数，以作为所述瓶颈函数。如此，输出的瓶颈函数是耗时较长，且被调用次数较多的函数，这些函数具备更大的优化空间。

具体的，可以按照前述热点函数的处理方式，对性能火焰图上的各函数进行处理，得到各函数的热度，从而，按照热度由高至低的顺序，得到热点函数列表。例如，在图18所示的性能火焰图上，A函数的热度为2，B函数的热度为1，C函数的热度为2，则可以得到热点函数列表：A函数、C函数、B函数。

在此基础上，对热点函数列表中的每一个函数，按照前述确定覆盖度函数的方法，确定每个热点函数对应的覆盖度函数。此时，图19示出了获取覆盖度函数的方法，如前所述，从性能火焰图的根节点遍历到叶子节点，得到A函数对应的覆盖度函数A1，C函数对应的覆盖度函数C1和C2，B函数对应的覆盖度函数B1。

之后，获取前述各覆盖度函数的耗时占比情况，得到各函数的覆盖度，从而，按照覆盖度由大至小的顺序输出即可。

此外，若在排序时，出现覆盖度相同的函数，则可以将热度更高的函数排在前面。若出现覆盖度与热度均相同的至少两个函数，则可以任意排序，或按照栈的层级关系，将更靠近叶子节点的栈对应的函数排在前面。

如此，即可得到瓶颈函数列表。

本申请中，前述数据分析结果(性能提升参数、热点函数、瓶颈函数)均可以通过文本格式输出。示例性的，图20示出了一种瓶颈函数的输出结果示意图，其中示出了各函数(示例性的示出函数1～函数15)的调用次数、函数的耗时情况和耗时占比(覆盖度)。图20中，是按照耗时由高至低的顺序输出瓶颈函数的。在实际实现场景中，若按照前述结合热点函数的方式来确定瓶颈函数，则此处输出的瓶颈函数列表则综合考虑了热度和耗时情况，并最终以耗时由长至短的顺序排序得到的。此外，可以理解，热点函数则可以按照调用次数由高至低的次序输出，不赘述。

综上所述，本申请通过对被测试程序进行采样分析，生成横轴坐标表示耗时时长的性能火焰图，该火焰图同时具备精确地时间信息和源码细节，便于开发人员定位分析，降低了由于时间信息或源码细节不清楚导致开发人员误判的发生几率。

并且，本申请还提供了对照程序与被测试程序的同级对比方案，通过多列火焰图，开发人员可以一目了然的获知被测试程序相较于对照程序的优势和劣势，便于开发人员后续分析、维护和优化，这也降低了对开发人员的要求，能够适用初级入门性能分析人群的分析需求。

此外，本申请还进一步基于性能火焰图，提供了被测试程序的进一步分析方式，本申请能够自动为用户查找到被测试程序的热点函数、瓶颈函数，以及相对于对照函数的优化空间，方便了开发人员定位分析问题。

本申请的各实施方式可以任意进行组合，以实现不同的技术效果。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid StateDisk)等。

总之，以上所述仅为本发明技术方案的实施例而已，并非用于限定本发明的保护范围。凡根据本发明的揭露，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (20)

1.一种性能分析方法，其特征在于，包括：

获取目标程序的第一采样数据与第二采样数据，所述第一采样数据是通过所述目标程序中插入的探测代码采集得到的事件信息，所述第二采样数据是通过性能监控单元PMU采集得到的栈信息；

获取所述第一采样数据与所述第二采样数据之间的时间映射关系，所述时间映射关系用于关联所述事件信息与所述栈信息；

生成所述目标程序的性能图，所述性能图的纵轴表示事件所对应的栈信息，横轴表示栈对应的时间长度；

其中，所述获取所述第一采样数据与所述第二采样数据之间的时间映射关系，包括：

获取第一时间轴与第二时间轴之间的偏差时长，以作为所述时间映射关系；或者，

同步所述第一时间轴与所述第二时间轴，以作为所述时间映射关系；

其中，所述第一时间轴为所述第一采样数据所采用的时间轴；所述第二时间轴为所述第二采样数据所采用的时间轴。

2.根据权利要求1所述的方法，其特征在于，所述同步所述第一时间轴与所述第二时间轴，包括：

获取所述第一时间轴与所述第二时间轴之间的所述偏差时长；

利用所述偏差时长，调整所述第一时间轴或所述第二时间轴，使得所述第一时间轴与所述第二时间轴同步。

3.根据权利要求2所述的方法，其特征在于，所述获取所述第一时间轴与所述第二时间轴之间的所述偏差时长，包括：

获取预设的校准Tag在第一时间轴上的起始时刻；

在第二时间轴上，获取所述校准Tag对应的第一个采样点时刻；

获所述起始时刻与所述第一个采样点时刻之差，以作为所述偏差时长。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述生成所述目标程序的性能图，包括：

裁剪所述第二采样数据，得到裁剪后的第二采样数据；

根据所述裁剪后的第二采样数据，生成所述目标程序的所述性能图。

5.根据权利要求4所述的方法，其特征在于，所述裁剪所述第二采样数据，得到裁剪后的第二采样数据，包括：

获取所述第一采样数据中的目标事件；

根据所述时间映射关系，确定所述目标事件对应的目标栈；

裁剪出所述目标栈对应的第二采样数据。

6.根据权利要求5所述的方法，其特征在于，所述获取所述第一采样数据中的目标事件，包括：

获取目标事件标识；

在所述第一采样数据中，获取所述目标事件标识所指示的所述目标事件；

其中，所述目标事件标识包括：事件标签或所述目标事件所在的目标时间区间。

7.根据权利要求6所述的方法，其特征在于，所述获取目标事件标识，包括：

获取预设的裁剪配置信息中携带的所述目标事件标识；或者，

输出可操作面板，并采集用户在所述可操作面板上的操作信息，根据所述操作信息确定所述目标事件标识；或者，

将所述第一采样数据作为事件确定模型的输入，获取所述事件确定模型输出的所述目标事件标识。

8.根据权利要求1-3任一项所述的方法，其特征在于，所述目标程序为被测试程序。

9.根据权利要求1-3任一项所述的方法，其特征在于，所述目标程序包括：被测试程序与对照程序；

所述性能图为多维性能图，所述多维性能图包括：所述被测试程序的性能图与所述对照程序的性能图；

其中，所述对照程序的数目为至少一个。

10.根据权利要求9所述的方法，其特征在于，所述多维性能图还包括：所述被测试程序与所述对照程序之间的对比数据；

所述对比数据可以包括但不限于：至少顶层栈的函数耗时数据、所述被测试程序相对于所述对照程序的优异函数、所述被测试程序相对于所述对照程序的待改进函数；

其中，针对任意一个函数，若所述被测试程序中该函数的耗时时长，小于所述对照程序中该函数的耗时时长，该函数为所述优异函数；若所述被测试程序中该函数的耗时时长，大于所述对照程序中该函数的耗时时长，该函数为所述待改进函数。

11.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

采集用户在所述性能图上的操作信息；

若所述操作信息为光标移动信息，将所述操作信息所指示的指定栈突出显示，和/或，输出所述指定栈的耗时时长。

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

若所述操作信息指示将指定栈降维展示，根据所述性能图，获取降维性能图；其中，所述降维性能图的底层栈为所述指定栈；

显示所述降维性能图。

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

获取所述被测试程序的性能提升参数，所述性能提升参数用于表征所述被测试程序相对于所述对照程序的性能优化空间的大小；

输出所述性能提示参数。

14.根据权利要求13所述的方法，其特征在于，所述获取所述被测试程序的性能提升参数，包括：

在所述性能图上，获取所述被测试程序与所述对照程序在每一层上的相同栈；

对所述性能图中的任意一层，若相同栈在该层所有栈中的数目占比超过预设的比例阈值，获取该层中所有相同栈的时长差之和，得到该层的单层性能提升参数；

按照所述性能图由顶层至底层的顺序，逐层获取各层的所述单层性能提升参数；

若当前累积层数达到指定层数，获取各层的所述单层性能提升参数的加权平均值，以作为多层性能提升参数。

15.根据权利要求1-3任一项所述的方法，所述方法还包括：

获取所述目标程序中的热点函数，所述热点函数为目标数据中热度较高的至少一个函数；

输出所述热点函数；

所述获取所述目标程序中的热点函数，包括：

对所述性能图中的任意一个函数，获取该函数在不同独立分支上的个数之和，以作为该函数的热度；

按照热度由高至低的顺序，获取至少一个函数，以作为所述热点函数。

16.根据权利要求1-3任一项所述的方法，所述方法还包括：

获取所述目标程序中的瓶颈函数，所述瓶颈函数为目标数据中耗时占比较高的至少一个函数；

输出所述瓶颈函数；

所述获取所述目标程序中的瓶颈函数，包括：

对所述性能图中的任意一个函数，获取该函数的耗时时长在所属调用栈的总时长中所占的比例，以作为该函数的覆盖度；

按照覆盖度由高至低的顺序，获取至少一个函数，以作为所述瓶颈函数；

或者，

所述获取所述目标程序中的瓶颈函数，包括：

获取所述目标程序中的热点函数；

获取各所述热点函数的覆盖度；

按照覆盖度由高至低的顺序，获取至少一个热点函数，以作为所述瓶颈函数。

17.根据权利要求1-3任一项所述的方法，其特征在于，所述PMU的工作状态与中央处理器CPU的运行状态无关。

18.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

一个或多个传感器；

以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求1-17中任一项所述的方法。

19.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-17中任一项所述的方法。

20.一种性能分析系统，其特征在于，包括：

第一电子设备，用于运行所述目标程序；

第二电子设备，用于执行如权利要求1-17中任一项所述的方法。

Images