CN117093441A - 电子设备的性能监控方法及装置 - Google Patents

Abstract

本申请提供了一种电子设备的性能监控方法及装置，应用于穿戴式设备，该方法包括可以记录显示一帧画面的整个过程中各个关键处理节点的时间信息，进一步根据相邻两个关键处理节点的时间信息计算得到各处理阶段对应的处理时间，以及计算得到整个过程的总耗时。进一步地，分析各处理阶段的处理时间及总耗时，得到电子设备运行当前运行的应用程序时的性能分析结果。该方案可以获得显示过程中的各个处理阶段的处理时间，因此可以准确定位出现的故障问题类型，而且，故障问题类型层次分明，能够准确且快速地定位出故障所在的软件层级。

Description

电子设备的性能监控方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及电子设备的性能监控方法及装置。

背景技术

电子设备(如智能手表等智能穿戴设备)经常遇到性能问题(如卡顿现象)，在宏观层面很难定位问题所在，其原因在于：缺少问题发现手段、缺少问题定位手段，而且用户使用过程中发生的性能问题无法复现，因此无法快速定位到性能问题所在。

发明内容

有鉴于此，本申请提供了一种电子设备的性能监控方法及装置，以解决上述的至少部分技术问题，其公开的技术方案如下：

第一方面，本申请提供了一种电子设备的性能监控方法，电子设备包括按键和触摸屏，方法包括：从接收到按键或触摸屏上报的中断事件到响应中断事件显示第一界面的过程中，记录各关键处理节点的时间信息；根据相邻两个关键处理节点的时间信息计算得到各处理阶段对应的处理时间，以及根据各处理阶段对应的处理时间获得总耗时；分析各处理阶段的处理时间和总耗时，获得电子设备运行当前运行的应用程序时的性能分析结果。可见，该方案可以获得显示过程中的各个处理阶段的处理时间，因此可以准确定位出现的故障问题类型，而且，故障问题类型层次分明，能够准确且快速地定位出故障所在的软件层级。

在第一方面的一种可能的实现方式中，从接收到按键或触摸屏上报的中断事件到响应中断事件显示第一界面的过程中，记录各关键处理节点的时间信息，包括：检测到电子设备的处理器接收到按键或触摸屏上报中断事件时，记录第一时刻点；检测到电子设备当前运行的应用程序接收到中断事件时，记录第二时刻点；检测到第一界面所需资源文件读取完成时，记录第三时刻点；检测到资源文件处理并开始渲染时，记录第四时刻点；检测到渲染完成时，记录第五时刻点；检测到触摸屏刷新显示完成时，记录第六时刻点。

在第一方面的一种可能的实现方式中，根据相邻两个关键处理节点的时间信息计算得到各处理阶段对应的处理时间，包括：计算第二时刻点与第一时刻点之间的时间差，得到事件消息处理阶段的处理时间；计算第三时刻点与第二时刻点之间的时间差，得到资源读取阶段的处理时间；计算第四时刻点与第三时刻点之间的时间差，得到资源处理和加载阶段的处理时间；计算第五时刻点与第四时刻点之间的时间差，得到渲染阶段的处理时间；计算第六时刻点与第五时刻点之间的时间差，得到刷屏送显阶段的处理时间。这样，根据各个关键处理节点的时间点可以进一步获得各处理阶段对应的处理时间，进而根据各处理阶段的处理时间快速定位性能问题对应的处理阶段及对应的责任域(即软件层级)。

在第一方面的一种可能的实现方式中，分析各处理阶段的处理时间和总耗时，获得电子设备运行当前运行的应用程序时的性能分析结果，包括：基于总耗时计算得到真实帧率；计算真实帧率与电子设备对应的标准帧率之间的帧率差值；当帧率差值大于预设值时，确定存在卡顿故障；根据各处理阶段的处理时间确定导致卡顿现象的目标处理阶段，以及目标处理阶段所属的软件层级。这样，根据显示一帧画面的总耗时可以快速判定是否存在丢帧故障(也可称为帧率故障)，进一步，根据各个处理阶段的处理时间快速定位出现丢帧故障的具体责任域。

在第一方面的一种可能的实现方式中，当帧率差值大于预设值时，确定存在卡顿故障，包括：当帧率差值大于或等于第一预设值时，确定存在严重卡顿故障；当帧率差值大于或等于第二预设值且小于第一预设值时，确定存在明显卡顿；当帧率差值大于第三预设值且小于第二预设值时，确定存在轻微卡顿；第一预设值大于第二预设值，第二预设值大于第三预设值。可见，该方案可以标记出性能卡顿的严重程度，而且，该方案可以针对不同设备类型设置不同的阈值，即该方案可以适配不同的设备产品。

在第一方面的一种可能的实现方式中，根据各处理阶段的处理时间确定导致卡顿现象的目标处理阶段，以及目标处理阶段所属的软件层级，包括：当事件消息处理阶段的处理时间大于或等于第一预设时长时，确定事件消息处理阶段异常，以及确定电子设备的操作系统中的底层软件层存在故障；当资源读取阶段的处理时间大于或等于第二预设时长时，确定资源读取阶段异常，以及确定底层软件层存在故障；当资源处理和加载阶段的处理时间大于或等于第三预设时长时，确定资源处理和加载阶段异常，以及确定应用程序层存在故障；当渲染阶段的处理时间大于或等于第四预设时长时，确定渲染阶段异常，以及确定应用程序层存在故障；当刷屏送显阶段的处理时间大于或等于第五预设时长时，确定刷屏送显阶段异常，以及确定底层软件层存在故障。这样，根据各处理阶段的处理时间确定出现故障的具体阶段及相应的责任域(即出现问题的软件层级)。

在第一方面的一种可能的实现方式中，该方法还包括：当检测到屏幕同步信号时，输出性能监控数据及性能分析结果，性能监控数据包括各阶段对应的处理时间。这样，可以得到显示每一帧画面对应的性能数据及性能分析结果。

在第一方面的一种可能的实现方式中，输出性能监控数据及性能分析结果，包括：向云端服务器上传性能监控数据及性能分析结果；或者，存储性能监控数据及性能分析结果；或者，通过总线接口输出性能监控数据及性能分析结果。这样，产品研发人员可以在产品的不同阶段通过不同的途径获得电子设备的性能数据。

在第一方面的一种可能的实现方式中，电子设备的操作系统包括由下至上排列的底层软件层、应用程序框架层和应用程序层，其中，应用程序框架层包括用户界面UI架构服务和性能分层打点服务；记录各关键处理节点的时间信息，包括：UI架构服务接收到第一类事件，向性能分层打点服务传递第一类时刻记录消息，触发性能分层打点服务记录第一类事件对应的时刻点；底层软件层接收到第二类事件后，向性能分层打点服务传递第二类时刻记录消息，触发性能分层打点服务记录第二类事件对应的时刻点。可见，该方案通过底层软件层和UI架构服务触发性能分层打点服务记录不同阶段对应的时间点。

在第一方面的一种可能的实现方式中，底层软件层接收到第二类事件后，向性能分层打点服务传递第二类时刻记录消息，触发性能分层打点服务记录第二类事件对应的时刻点，包括：当底层软件层接收到按键或触摸屏上报的中断事件时，向性能分层打点服务传递第一时刻记录消息，触发性能分层打点服务记录底层软件层接收到中断事件的第一时刻点；当底层软件层接收到触摸屏发送的刷新完成信号时，向性能分层打点服务传递第六时刻记录消息，触发性能分层打点服务记录触摸屏刷屏送显完成的第六时刻。可见，该方案通过底层软件层触发性能分层打点服务记录按键或触摸屏上报中断事件的时刻点，以及，触摸屏送显完成的时刻点。

在第一方面的一种可能的实现方式中，UI架构服务接收到第一类事件，向性能分层打点服务传递第一类时刻记录消息，触发性能分层打点服务记录第一类事件对应的时刻点，包括：UI架构服务接收到应用程序层的第一调用请求后，向性能分层打点服务传递第二时刻记录消息，触发性能分层打点服务记录应用程序接收到中断事件时对应的第二时刻点，第一调用请求用于调用UI架构服务读取第一界面的资源文件；UI架构服务响应于第一调用请求读取完第一界面的资源文件后，向性能分层打点服务传递第三时刻记录消息，触发性能分层打点服务记录资源读取完成时对应的第三时刻点；UI架构服务读取渲染所需的资源文件后，向性能分层打点服务传递第四时刻记录消息，触发性能分层打点服务记录资源处理和加载完成的第四时刻点；UI架构服务将渲染得到的页面内容写入显示缓存区后，向性能分层打点服务传递第五时刻记录消息，触发性能分层打点服务记录渲染完成的第五时刻点。可见，该方案通过UI架构服务触发性能分层打点服务记录按键或触摸屏上报中断事件后直到刷屏显示完成这一过程中各处理节点的时刻点。

在第一方面的一种可能的实现方式中，电子设备的操作系统包括由下至上排列的底层软件层、应用程序框架层和应用程序层，其中，应用程序框架层包括用户界面UI架构服务和性能分层打点服务；当检测到屏幕同步信号时，输出性能监控数据及性能分析结果，包括：底层软件层接收触摸屏发送的屏幕同步信号后，向性能分层打点服务传递性能数据输出消息；性能分层打点服务响应于性能数据输出消息，输出性能监控数据及性能分析结果。

第二方面，本申请还提供了一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器和触摸屏；所述存储器用于存储程序代码；所述处理器用于运行所述程序代码，使得所述电子设备实现第一方面任一项所述的电子设备的性能监控方法。

第三方面，本申请还提供了一种计算机可读存储介质，其特征在于，其上存储有指令，当所述指令在电子设备上运行时，使得所述电子设备执行第一方面任一项所述的电子设备的性能监控方法。

第四方面，本申请还提供了一种计算机程序产品，其上存储有执行，当所述计算机程序产品在电子设备上运行时，使得所述电子设备实现如第一方面任一项所述的电子设备的性能监控方法。

应当理解的是，本申请中对技术特征、技术方案、有益效果或类似语言的描述并不是暗示在任意的单个实施例中可以实现所有的特点和优点。相反，可以理解的是对于特征或有益效果的描述意味着在至少一个实施例中包括特定的技术特征、技术方案或有益效果。因此，本说明书中对于技术特征、技术方案或有益效果的描述并不一定是指相同的实施例。进而，还可以任何适当的方式组合本实施例中所描述的技术特征、技术方案和有益效果。本领域技术人员将会理解，无需特定实施例的一个或多个特定的技术特征、技术方案或有益效果即可实现实施例。在其他实施例中，还可在没有体现所有实施例的特定实施例中识别出额外的技术特征和有益效果。

附图说明

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

图1是本申请实施例提供的一种电子设备的硬件结构示意图；

图2是本申请实施例提供的一种电子设备的软件架构示意图；

图3是本申请实施例提供的一种电子设备显示一帧画面的硬件交互过程示意图；

图4是本申请实施例提供的一种电子设备显示一帧画面的各个阶段示意图；

图5是本申请实施例提供的基于软件架构的电子设备的性能监控过程数据流向示意图；

图6是本申请实施例提供的一种电子设备的性能监控方法的流程图；

图7是本申请实施例提供的一种预警信息示意图；

图8是本申请实施例提供的一个电子设备的性能曲线示意图。

具体实施方式

本申请说明书和权利要求书及附图说明中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于限定特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

电子设备的日志中很难直观地看到每个线程每次调度的时长，从日志中很难推到出性能相关的数据流程是否合理。如果通过实时帧率打印实现性能监控，必然会影响用户体验。

本申请实施例提供了一种电子设备的性能监控方法，该方案在电子设备的底层软件服务中增加性能分层打点模块，该性能分层打点模块记录响应于对按键或触摸屏输出的操作显示一帧的过程中各阶段的时间点，例如，Input上报触摸中断事件的时间点t1、APP接收到触摸中断事件的时间点t2、显示所需资源读取完成的时间点t3、资源处理和加载完成的时间点t4、渲染完成的时间点t5及送显完毕的时间点t6。进一步，性能分层打点模块可以根据记录的一帧显示过程中的各时间点计算得到各阶段的耗时，即T1＝t2-t1是消息处理时间，T2＝t3-t2是资源读取时间、T3＝t4-t3是资源处理和加载时间、T4＝t5-t4是渲染时间、T5＝t6-t5是刷屏时间。以及，根据各阶段的耗时计算得到一帧显示过程的总耗时，即T_Z＝T1+T2+T3+T4+T5是显示一帧的总耗时。当底层软件服务生成屏幕同步信号TE时，触发性能分层打点服务输出记录的时间参数，即各个时间点、各阶段的耗时及一帧显示过程的总耗时，根据上述的时间参数可以量化分析电子设备的性能问题，快速定位到问题所在。提高了电子设备的性能分析效率和准确率。

在本申请中，电子设备可以是穿戴式智能设备，如智能手表、运动手表、智能手环、穿戴式音频耳机、穿戴式眼镜等。本申请提供的电子设备性能监控方法还可以应用到所有嵌入式设备中，该嵌入式设备是以嵌入式单片机(也称为嵌入式微控制器)作为主处理器的电子设备。

如图1所示，电子设备可以包括：处理器，存储器件，显示屏，音频模块，通信模块，传感器模块，通用串行总线(universal serial bus，USB)接口，充电管理模块，电源管理模块，按键等，通信模块还可以连接天线。

其中，音频模块可以包括扬声器，受话器，麦克风等，传感器模块可以包括压力传感器，陀螺仪传感器，磁传感器，加速度传感器，距离传感器，接近光传感器等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器可以采用嵌入式单片机(Microcontroller Unit，MCU)，也称为嵌入式微控制器。

在一些实施例中，存储器件可以包括内部存储器和外部存储器。内部存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器通过运行存储在内部存储器的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备的各种功能应用以及数据处理。

外部存储器可以通过外部存储器接口与处理器通信，实现数据存储功能。例如，在本申请实施例中，

用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器通过运行存储在存储器的指令，从而执行电子设备的各种功能应用以及数据处理。例如，在本实施例中，处理器可以通过运行内部存储器中的指令执行本申请提供的方法。

在本申请实施例中，外部存储器可以包括嵌入式多媒体卡(embedded multimedia card，EMMC)、伪静态SRAM存储器(pseudo static randomaccess memory，PSRAM)。本实施例中，EMMC用于存储电子设备显示所需的资源文件，资源文件包括页面图片、背景图片，字库，显示的元素等。PSRAM可以扩展电子设备的内存空间即作为片外内存。

显示屏用于显示图像，视频、一系列图形用户界面(Graphical User Interface，GUI)等。在一些实施例中，显示屏可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot light emitting diodes，QLED)等。

本申请实施例中的显示屏可以是触摸屏，其中，触摸屏可以包括触摸传感器和显示屏，触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸中断事件类型。通过显示屏提供与触摸操作相关的视觉输出。

在一些实施例中，触摸传感器可以设置于显示屏中。在另一些实施例中，触摸传感器也可以设置于电子设备的表面，与显示屏所处的位置不同。

另外，在上述部件之上，运行有操作系统。在该操作系统上可以安装运行应用程序。电子设备的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的操作系统为例，示例性说明电子设备的软件结构。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。

在一些实施例中，如图2所示，操作系统可从上至下分别为应用程序层，应用程序框架层，内部库、内核、硬件抽象(Hardware Abstraction Layer，HAL)以及硬件驱动，其中，内核、硬件抽象和硬件驱动均位于软件架构的底层。

应用程序层可以包括一系列应用程序包。如图2所示，应用程序包可以包括三方应用、通信应用、应用商城、运动健康和钱包等应用程序。运动健康是用于监测用户身体状态，钱包用于进行快捷支付。通信应用为电子设备提供通信服务。三方应用是指第三方应用商开发的应用程序。

应用程序框架层可以为应用程序层的应用提供一系列的服务，如应用程序框架层包括用户界面(User Interface，UI)架构服务、运动健康服务、底层软件服务和硬件服务等。

UI架构服务用于为应用程序层提供界面服务，如在运行钱包应用时提供钱包的界面。运动健康服务是为运动健康应用提供数据支撑。硬件服务用于提供与传感器等硬件相关的服务。底层软件服务用于提供基础软件服务，如底层软件服务包括：关机服务，电源管理服务等。在本实施例中，底层软件服务还包括性能分层打点服务。性能分层打点服务用于记录电子设备响应对APP操作显示相应画面的过程中，记录各个关键节点的时间信息并进行电子设备各阶段的性能分析。

内部库包括基础库、算法库和协议栈等，基础库包括消息库、文件操作库等；算法库是数据处理及数据校验，如对传感器采集到的数据进行校验；协议栈中记录了通信过程中应用的通信协议。

内核是操作系统中连接硬件层的桥梁，具备任务调度、消息分发、时钟调度等功能。HAL定义了供硬件供应商实施的标准接口，硬件驱动用于提供各种硬件的驱动，如提供显示驱动，音频驱动，传感器驱动等。

下面先结合图3～图4，以智能手表为例介绍显示一帧画面的硬件交互过程。

如图3所示，显示一帧画面的过程涉及的硬件包括处理器，以及分别与处理器连接的输入装置(即触摸屏、按键)、外部存储器EMMC、片外内存PSRAM和显示装置(如，触摸屏)。在一示例中，EMMC通过安全数字输入输出(secure digital input and output，SDIO)接口与处理器连接，PSRAM通过高速并行接口(high-speed parallel interface，HSPI)与处理器连接，显示装置通过移动产业处理器接口(mobile industry processor interface，MIPI)与处理器连接。

如图4所示，电子设备显示一帧画面的整个过程可以包括图3所示的T1～T5五个阶段，即显示一帧画面的总耗时T_ALL＝T1+T2+T3+T4+T5。

在一示例中，T1表示控制消息处理时间，此处的控制是指通过输入装置控制电子设备，控制消息是指输入装置检测到的操作产生的消息，如按压按键的操作、滑动屏幕的操作、屏幕跟手操作(即按压的同时滑动)。T2表示从EMMC中读取资源文件所需的时间。T3表示资源处理和加载的时间。T4表示渲染过程的耗时。T5表示刷屏送显的时间。

(1)消息处理时间T1

如图3所示，当用户按下智能手表的按键，或者，在屏幕上进行滑动、拖拽、跟手(即按压的同时滑动)等操作时，触摸屏或按键向处理器的底层软件层上报相应的中断事件。例如，对于用户在触摸屏上的跟手操作而言，触摸屏向处理器中的底层软件层(如图2所示)发送触摸中断事件，性能分层打点服务记录此时刻点，即图4所示的t1，也即触摸屏上报触摸中断事件的时刻点。

此外，如图3所示，对于在触摸屏上的滑动操作而言，底层软件层接收到触摸屏上报的触摸释放事件后，触发性能分层打点服务记录此时刻点t1。同理，对于按压按键的操作，性能分层打点服务记录底层软件层接收到按键上报的按键释放事件的时刻点，即t1。

目标应用程序(即智能手表当前运行的应用)接收底层软件层上报的触摸中断事件。性能分层打点服务检测到目标应用程序接收到触摸中断事件后，记录该时间点，即图4中的t2时刻点。同理，对于滑动操作/按键按压操作，性能分层打点服务记录目标应用程序接收到触摸释放/按键释放事件的时刻。

进一步，性能分层打点服务可以计算t2时刻与t1时刻的时间差，该时间差即消息处理时间T1。如果T1的时长过长表明底层软件层存在问题。

(2)资源读取时间T2

如图3所示，目标应用程序接收到触摸中断事件后调用UI架构服务准备渲染待显示画面的工作，如UI架构服务调用文件系统从EMMC中读取相应的资源文件并存储至PSRAM。

本实施例的资源文件包括字库、表盘、显示的元素等。EMMC中存储了所有应用程序的资源文件，目标应用程序向EMMC发送资源文件读取请求，该请求携带目标应用标识及读取的资源文件的信息，EMMC解析该请求获得目标应用的应用标识及待读取资源文件的信息，进一步地，根据应用标识查找到目标应用对应的资源文件以及根据待读取资源文件的信息查找对应的资源文件发送至PSRAM中。

UI架构服务从EMMC中读取完相应的资源文件后，触发性能分层打点服务记录此时刻点，即图4中的t3时刻。进一步地，性能分层打点服务计算t3时刻与t2时刻的时间差，即资源读取时间T2。

(3)资源处理和加载时间T3

如图3所示，UI架构服务控制PSRAM对资源文件进行处理，如，解压缩图片(从EMMC中读取的资源文件是压缩文件)、页面布局、查找对应的资源等。进一步地，UI架构服务将PSRAM处理后的资源文件加载至GPU/MCU中进行渲染，并触发性能分层打点服务记录此时刻，即图4中的t4时刻。进一步地，性能分层打点计算t4时刻与t3时刻的时间差，即资源处理和加载时间T3。

在电子设备不包含GPU的场景中，采用MCU进行渲染。在电子设备包含GPU的场景中，采用GPU进行渲染。

(4)渲染时间T4

GPU/MCU加载完处理后的资源文件后，基于此资源文件进行渲染，并在渲染完成后输出到显示缓存区，并触发性能分层打点服务记录此时刻点，即图4的t5时刻。进一步地，性能分层打点服务计算t5时刻与t4时刻的时间差，即渲染时间T4。

执行渲染过程的硬件可能是GPU或MCU。渲染过程可以包括：图像混合、颜色填充、图形旋转、平移图形等。本申请对渲染过程不做限定。

(5)刷屏送显时间T5

刷屏送显即显示控制器从显示缓存区中读取需要显示的图像并发送至屏幕显示的过程，底层软件层接收到显示屏发送刷新完成信号后触发性能分层打点服务记录此时刻点，即图4中的t6。

进一步地，性能分层打点服务计算t6时刻与t5时刻的时间差，即刷屏送显时间T5。

综上可知，性能分层打点服务可以记录显示每一帧对应的时刻点t1～t6，分别计算得到各阶段的耗时T1～T5，以及显示一帧画面的总耗时即T_ALL。进一步根据总耗时可以快速判定是否存在性能问题，以及根据各个阶段的耗时可以快速定位到性能问题所在层。例如，T1大于正常耗时时长，则确定消息处理阶段异常，进一步确定出底层软件层出现性能问题。T2大于正常耗时时长，则确定资源读取阶段异常，并确定底层软件层出现性能问题。T3大于正常耗时时长，则确定资源处理和加载阶段异常，并确定应用层出现性能问题。T4大于正常耗时时长，则确定渲染阶段异常，确定应用层出现性能问题。T5大于正常耗时时长，则确定刷屏送显阶段异常，确定底层软件层出现性能问题。

下面结合图5和图6介绍显示一帧画面过程的性能监测方法。

请参见图5，示出了本申请实施例提供的基于软件架构的性能监控过程数据流向示意图。

如图5所示，UI架构服务包括UI屏幕消息监听、UI按键消息监听、资源加载、渲染等服务。UI屏幕消息监听服务用于监听屏幕上报的触摸中断事件，UI按键消息监听服务用于监听按键上报的按键中断事件。资源加载服务用于将显示当前画面所需的资源文件加载至GPU或MCU进行渲染。渲染服务用于基于加载的资源文件渲染得到页面。

底层软件服务包括电池管理服务、关机服务和性能分层打点服务等。UI架构服务和底层软件服务属于应用程序框架层，且运行在图3所示的处理器中。

本申请实施例以显示屏为触摸屏为例进行说明，触摸屏既是电子设备的输入装置(接收触摸操作)又是输出装置(输出显示内容)。

在触摸屏显示的过程中会周期性输出TE信号，而触摸屏/按键中断事件是用户操作触摸屏或按键产生具有随机性，因此，TE信号上报事件和触摸/按键中断事件可能同时发生，或者，TE信号上报事件先发生触摸/按键中断事件后发生，或者，触摸/按键中断事件先发生、TE信号上报事件后发生。本申请实施例以TE信号上报事件先发生触摸/按键中断事件后发生为例进行说明。

如图5所示，本实施例提供的性能监控过程数据流向包括：

步骤1，当触摸屏刷新完一帧图像并准备好刷新下一帧图像时产生撕裂效应(Tearing Effect，TE)信号，并向底层软件层传递该TE信号。

TE信号用于防止图像显示过程中画面刷新时的撕裂问题，TE信号也称为屏幕同步信号。

步骤1发生后会触发执行后续的步骤2～4。

步骤2，底层软件层向UI架构服务传递接收到的TE信号，触发UI架构服务进行下一帧图像的刷新送显工作。

步骤3，底层软件层接收到TE信号后，向性能分层打点服务传递触发其输出性能分层数据的消息。其中，步骤2和步骤3可以并行进行，或者先执行步骤2后执行步骤3，或者先执行步骤3后执行步骤2，本申请对此不做限定。

步骤4，性能分层打点服务接收到底层软件层发送的触发输出消息后，输出显示上一帧图像时记录的性能分层数据。

步骤5，触摸屏/按键接收到触摸/按压按键的操作后，向底层软件层上报触摸/按键中断事件。

步骤5发生后会触发执行后续的步骤6～14。

本申请实施例中，步骤5与步骤1可以并行执行，或者先执行步骤1后执行步骤5，又或者先执行步骤5后执行步骤1。

步骤6，底层软件层接收到触摸/按键中断事件后，向性能分层打点服务发送t1时刻点记录消息，性能分层打点服务接收到该消息后记录此时刻点，即图4所示的t1时刻。

步骤7，底层软件层接收到触摸/按键中断事件后向UI架构服务传递该事件。

本实施例中步骤6和7可以并行执行，或者先执行步骤6再执行步骤7，或者先执行步骤7再执行步骤6，本申请并不限定步骤6和7的执行顺序。

步骤8，UI架构服务继续向应用程序层的目标应用传递该事件。此处的目标应用是指当前运行的用户操作的应用程序。

步骤9，目标应用程序接收到触摸/按键中断事件后，调用UI架构服务读取待显示画面对应的资源文件，并基于获得的资源文件进行渲染工作。

步骤10，UI架构服务在响应应用程序层的调用请求渲染待显示图像的过程中，触发性能分层打点服务记录图4所示的时刻点t2～t5。

步骤11，UI架构服务完成待显示画面的渲染后写入显示缓存区，向底层软件层发送渲染完成送显的消息。

步骤12，底层软件层触发触摸屏去显示缓存区读取下一帧图像进行刷新显示。

步骤13，触摸屏显示读取的图像后向底层软件层返回刷新完成信号，并返回执行步骤1。

步骤14，底层软件层接收到刷新完成信号后向性能分层打点服务发送触发t6时刻点记录消息，性能分层打点服务接收到该消息后记录此时刻点，即t6。

至此，性能分层打点服务获得了时刻点t1～t6，性能分层打点服务计算相邻两个时刻点之间的时间差，得到T1～T5，进一步地，计算T1～T5的总和即显示一帧图像的总耗时T_ALL。

由于UI架构服务由TE信号驱动开始一帧图像的渲染工作，底层软件接收到TE信号后触发性能分层打点服务输出性能分层数据。性能分层数据包括刷新一帧图像的各个阶段的时间参数以及各阶段的总耗时。

请参见图6，示出了本申请实施例提供的一种电子设备的性能监控方法的流程图。该方法应用于电子设备，如图6所示，该方法可以包括以下步骤：

S101，输入装置接收触摸操作或按键按压操作。

本实施例的输入装置可以包括按键、触摸屏等，本申请对输入装置的类型不做限定。

S102，输入装置向底层软件层上报触摸/按键中断事件。

此步骤即图5中的步骤5所示的过程。

S103，底层软件层逐层向APP上报触摸/按键中断事件。

此步骤即图5中的步骤7～8所示的过程。

S104，底层软件层接收到触摸/按键中断事件后，向性能分层打点服务发送触发记录t1时刻的消息，即第一时刻记录消息。

步骤S104即图5中步骤6所示的过程。

S105，性能分层打点服务响应于第一时刻记录消息，记录输入装置上报触摸/按键中断事件的时刻点，即t1时刻。

S106，APP响应触摸/按键中断事件调用UI架构服务读取待显示画面的资源文件。

此过程请参考图3中读取资源文件的过程，此处不再赘述。本申请的APP可以是电子设备的操作系统自带的应用或第三方应用，APP的类型不做特殊限定。

S107，UI架构服务接收到APP的调用请求后，向性能分层打点服务发送触发记录t2时刻的消息，即第二时刻记录消息。

S108，性能分层打点服务响应于第二时刻记录消息，记录APP接收到触摸/按键中断事件的时刻点t2。

S109，UI架构服务响应APP的调用，从EMMC中读取待显示画面对应的资源文件并存储至PSRAM。

本申请不限定S107和S109的执行顺序，可以执行完S106后直接执行S109，或者执行完S106后执行S107。

S110，UI架构服务读取完资源文件后，向性能分层打点服务发送触发记录t3时刻的消息，即第三时刻记录消息。

S111，性能分层打点服务响应于第三时刻记录消息，记录资源读取完成的时刻点t3。

S112，UI架构服务从PSRAM中读取处理后的资源文件并加载至GPU/MCU中进行渲染。

S113，UI架构服务加载完资源文件后向性能分层打点服务发送触发记录t4时刻的消息，即第四时刻记录消息。

S114，性能分层打点服务响应于第四时刻记录消息，记录资源处理和加载完成的时刻t4。

S115，UI架构服务调用GPU/MCU对待显示画面进行渲染，并将渲染后的画面写入显示缓存区。

S1161，UI架构服务向性能分层打点服务发送触发记录t5时刻的消息，即第五时刻记录消息。执行完S1161后继续执行S117。

S1162，UI架构服务向底层软件层传递送显的消息，以触发触摸屏进行刷屏显示。

完成渲染工作后UI架构服务向底层软件层传递送显的消息，底层软件层接收到该消息后触发触摸屏刷新显示。

执行完S1162后继续执行S118。

在一示例中，S1161和S1162并行执行，即UI架构服务向底层软件层传递送显消息的同时向性能分层打点服务传递第五时刻记录消息。

在其他实施例中，S1161和S1162也可以依次执行，如先执行S1161后执行S1162，又如，先执行S1162后执行S1161。

S117，性能分层打点服务响应于第五时刻记录消息，记录渲染完成的时刻点t5。

本实施例的S107～S117即图5的步骤11所示的过程。

S118，触摸屏从显示缓存区读取待显示图像并显示后，向底层软件层发送刷新完成信号。

S119，底层软件层响应于刷新完成信号，向性能分层打点服务发送触发记录t6时刻的消息，即第六时刻记录消息。

S120，性能分层打点服务响应于第六时刻记录消息，记录送显完成的时刻点t6。

本实施例的S119～S120即图5的步骤14所示的过程。

S121，性能分层打点服务根据记录的t1～t6，计算相邻两个时刻点之间的时间差得到T1～T5，以及计算T1～T5的总和得到显示一帧图像的总耗时T_ALL。

S122，性能分层打点服务根据T_ALL计算真实帧率。

S123，性能分层打点服务根据真实帧率及标准帧率确定卡顿程度。

性能分层打点服务根据显示一帧图像的总耗时T_ALL计算得到真实帧率，而当电子设备的标准帧率大于真实帧率时，判定存在卡顿现象。其中，标准帧率可以根据设备类型及实际需求设定，例如，智能手表的标准帧率是50～55帧，智能手环的标准帧率可以是30帧。

举例说明，电子设备A在运行某一应用时显示一帧图像的总耗时T_ALL＝20ms，则真实帧率＝1000ms/20ms＝50，该电子设备的标准帧率是55帧，50帧＜55帧即真实帧率小于标准帧率，因此，确定电子设备在运行该应用时存在卡顿现象。

进一步地，在一些实施例中，可以根据真实帧率与标准帧率之间的差值(即，单次丢帧数量)确定性能卡顿情况的严重程度，进而评估出本次卡顿对用户的影响。

示例性的，卡顿的严重程度可以包括如下三种：

(1)轻微卡顿；单次丢帧数量在2-4帧，用户勉强能够接受此类卡顿情况。在一示例中，电子设备在运行一应用时，真实帧率是47帧，标准帧率是50帧，则单次丢帧数量是3帧，在2-4帧范围内，最终确定属于轻微卡顿情况。

(2)明显卡顿；单次丢帧数量在4-8帧，用户不能接受此类卡顿情况。在一示例中，电子设备的真实帧率是42帧，标准帧率是50帧，则单次丢帧数量是8帧，在4-8帧范围内，最终确定属于明显卡顿情况。

(3)严重卡顿；单次丢帧数量在8帧以上，用户无法容忍此类卡顿情况。在一示例中，电子设备的真实帧率是40帧，标准帧率是50帧，则单次丢帧数量是10帧，在8帧以上的范围内，最终确定属于严重卡顿情况。

S124，性能分层打点服务根据各阶段耗时T1～T5分析性能问题所在位置。

示例性的，T1大于正常耗时时长，则确定消息处理阶段异常，进一步确定出底层软件层出现性能问题。T2大于正常耗时时长，则确定资源读取阶段异常，并确定底层软件层出现性能问题。T3大于正常耗时时长，则确定资源处理和加载阶段异常，并确定应用层出现性能问题。T4大于正常耗时时长，则确定渲染阶段异常，确定应用层出现性能问题。T5大于正常耗时时长，则确定刷屏送显阶段异常，确定底层软件层出现性能问题。

S125，触摸屏刷新完一帧图像后生成TE信号，并向底层软件层发送该TE信号。

S126，底层软件层响应于TE信号，向性能分层打点服务发送输出性能分层数据的消息，即性能数据输出消息。

S127，性能分层打点服务响应于性能数据输出消息，输出获得的性能分层数据。

在本申请一示例性实施例中，性能分层打点服务输出性能分层数据可以包括如下三种方式：

(1)同步至云端服务器

此种方式适用于电子设备上市前的试用阶段或上市后用户使用阶段，电子设备可以将获得的性能数据上传至云端服务器中，这样，产品研发人员可以打开云端服务器提供的大数据看板，查找要分析的性能问题对应的性能分层数据获得性能问题点及出现性能问题的位置，从而针对此问题制定解决方案。

示例性的，大数据看板中可以采用表1展示多个设备的性能数据：

表1

表1中的I级故障类型用于描述产生故障的软件架构层，如应用程序层还是底层软件层发生故障。II级故障类型用于描述产生故障的应用程序，如表1所示，音乐、手电筒、心率、压力、睡眠等应用。III级故障类型用于描述具体的问题类型，如启动时长、帧率(如丢帧)等。可见，性能问题(即故障类型)层次分明，责任领域清晰。

此类故障样机个数是指所有样机中出现此类故障类型的样机数量，例如，共有100台样机，其中的33台样机发生了音乐应用启动时间长的问题。

发生次数是指出现此类故障的所有样机在出现此类故障的总次数，例如，对于音乐应用启动时间长这一故障，33台样机出现此故障的总次数。

(2)存储至电子设备本地的存储器件中

此种方式适用于产品开发阶段或上市前的试用阶段，电子设备可以将存储器件中的性能数据上传至云端服务器，研发人员可以通过云端服务器提供的大数据看板查看。

(3)通过PC机的串口或USB接口等总线接口读取电子设备的实时日志

此种方式适用于产品开发测试阶段。研发人员可以通过PC机串口总线或USB总线连接电子设备，从而读取本机的实时日志。

在一示例性实施例中，对于上述(1)和(2)两种输出方式，可以采用可视化方式显示多个电子设备的性能分析结果，以及针对卡顿程度显示相应的预警信息。示例性的，可以采用不同颜色的预警灯指示该电子设备的卡顿程度，举例来说，轻微卡顿采用绿色预警灯、明显卡顿采用黄色预警灯、严重卡顿采用红色预警灯。

在一示例中，预警信息可以采用图7所示的预警信息表展示，如图7所示，每个信息项对应一个电子设备，每个信息项包括设备ID信息和预警信息。

设备ID是电子设备的唯一身份标识，如产品序列号(Serial Number，SN)。预警信息可以采用不同颜色表示不同卡顿程度。例如，信息项100是ID4对应的电子设备的预警信息，该信息项中的预警信息为严重卡顿。

在一示例性实施例中，预警信息栏包括下拉筛选菜单按钮101，点击按钮101后，显示下拉菜单102。该下拉菜单包括严重卡顿103、明显卡顿104和轻微卡顿105三个筛选项。每个筛选项包括筛选信息如预警指示灯106及选择按钮107，点击选择按钮后筛选出该筛选项对应的所有预警信息。举例来说，选中严重卡顿103对应的选择按钮后，可以筛选出所有严重卡顿的电子设备。

图7所示的预警信息表适用于上述的(1)和(2)两种输出方式。

在一示例中，对于一个电子设备的性能分析结果(例如，通过上述的第(3)种输出方式获得的某一电子设备的性能分析结果)，可以采用图8所示的帧率曲线图表示。

如图8所示，帧率曲线图的横轴表示时间，纵轴表示该电子设备的真实帧率。本示例中，电子设备在大部分时间的真实帧率均是50帧左右，而在t1时刻的真实帧率降为41帧。而且，该设备的标准帧率是50帧，因此，确定该设备在t1时刻存在严重卡顿现象。

进一步地，点击帧率曲线图中t1时刻，可以自动下载该设备在t1时刻的日志文件，通过分析t1时刻的日志文件可以获得该设备在t1时刻对应的各个时间参数及问题所在位置等性能分析结果，如可以是表1所示的一个电子设备的信息。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (14)

1.一种电子设备的性能监控方法，其特征在于，电子设备包括按键和触摸屏，所述方法包括：

从接收到所述按键或触摸屏上报的中断事件到响应所述中断事件显示第一界面的过程中，记录各关键处理节点的时间信息；

根据相邻两个关键处理节点的时间信息计算得到各处理阶段对应的处理时间，以及根据各处理阶段对应的处理时间获得总耗时；

分析所述各处理阶段的处理时间和所述总耗时，获得所述电子设备运行当前运行的应用程序时的性能分析结果。

2.根据权利要求1所述的方法，其特征在于，从接收到所述按键或触摸屏上报的中断事件到响应所述中断事件显示第一界面的过程中，记录各关键处理节点的时间信息，包括：

检测到所述电子设备的处理器接收到所述按键或所述触摸屏上报所述中断事件时，记录第一时刻点；

检测到所述电子设备当前运行的应用程序接收到所述中断事件时，记录第二时刻点；

检测到所述第一界面所需资源文件读取完成时，记录第三时刻点；

检测到所述资源文件处理并开始渲染时，记录第四时刻点；

检测到渲染完成时，记录第五时刻点；

检测到所述触摸屏刷新显示完成时，记录第六时刻点。

3.根据权利要求2所述的方法，其特征在于，根据相邻两个关键处理节点的时间信息计算得到各处理阶段对应的处理时间，包括：

计算所述第二时刻点与所述第一时刻点之间的时间差，得到事件消息处理阶段的处理时间；

计算所述第三时刻点与所述第二时刻点之间的时间差，得到资源读取阶段的处理时间；

计算所述第四时刻点与所述第三时刻点之间的时间差，得到资源处理和加载阶段的处理时间；

计算所述第五时刻点与所述第四时刻点之间的时间差，得到渲染阶段的处理时间；

计算所述第六时刻点与所述第五时刻点之间的时间差，得到刷屏送显阶段的处理时间。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述分析所述各处理阶段的处理时间和所述总耗时，获得所述电子设备运行当前运行的应用程序时的性能分析结果，包括：

基于所述总耗时计算得到真实帧率；

计算所述真实帧率与所述电子设备对应的标准帧率之间的帧率差值；

当所述帧率差值大于预设值时，确定存在卡顿故障；

根据各处理阶段的处理时间确定导致卡顿现象的目标处理阶段，以及所述目标处理阶段所属的软件层级。

5.根据权利要求4所述的方法，其特征在于，所述当所述帧率差值大于预设值时，确定存在卡顿故障，包括：

当所述帧率差值大于或等于第一预设值时，确定存在严重卡顿故障；

当所述帧率差值大于或等于第二预设值且小于所述第一预设值时，确定存在明显卡顿；

当所述帧率差值大于第三预设值且小于所述第二预设值时，确定存在轻微卡顿；

所述第一预设值大于所述第二预设值，所述第二预设值大于所述第三预设值。

6.根据权利要求4或5所述的方法，其特征在于，所述根据各处理阶段的处理时间确定导致卡顿现象的目标处理阶段，以及所述目标处理阶段所属的软件层级，包括：

当事件消息处理阶段的处理时间大于或等于第一预设时长时，确定所述事件消息处理阶段异常，以及确定所述电子设备的操作系统中的底层软件层存在故障；

当资源读取阶段的处理时间大于或等于第二预设时长时，确定所述资源读取阶段异常，以及确定所述底层软件层存在故障；

当资源处理和加载阶段的处理时间大于或等于第三预设时长时，确定所述资源处理和加载阶段异常，以及确定应用程序层存在故障；

当渲染阶段的处理时间大于或等于第四预设时长时，确定所述渲染阶段异常，以及确定应用程序层存在故障；

当刷屏送显阶段的处理时间大于或等于第五预设时长时，确定所述刷屏送显阶段异常，以及确定所述底层软件层存在故障。

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

当检测到屏幕同步信号时，输出性能监控数据及所述性能分析结果，所述性能监控数据包括所述各阶段对应的处理时间。

8.根据权利要求7所述的方法，其特征在于，所述输出性能监控数据及所述性能分析结果，包括：

向云端服务器上传所述性能监控数据及所述性能分析结果；

或者，存储所述性能监控数据及所述性能分析结果；

或者，通过总线接口输出所述性能监控数据及所述性能分析结果。

9.根据权利要求1-8任一项所述的方法，其特征在于，所述电子设备的操作系统包括由下至上排列的底层软件层、应用程序框架层和应用程序层，其中，所述应用程序框架层包括用户界面UI架构服务和性能分层打点服务；

所述记录各关键处理节点的时间信息，包括：

所述UI架构服务接收到第一类事件，向所述性能分层打点服务传递第一类时刻记录消息，触发所述性能分层打点服务记录所述第一类事件对应的时刻点；

所述底层软件层接收到第二类事件后，向所述性能分层打点服务传递第二类时刻记录消息，触发所述性能分层打点服务记录所述第二类事件对应的时刻点。

10.根据权利要求9所述的方法，其特征在于，所述底层软件层接收到第二类事件后，向所述性能分层打点服务传递第二类时刻记录消息，触发所述性能分层打点服务记录所述第二类事件对应的时刻点，包括：

当所述底层软件层接收到所述按键或所述触摸屏上报的中断事件时，向所述性能分层打点服务传递第一时刻记录消息，触发所述性能分层打点服务记录所述底层软件层接收到所述中断事件的第一时刻点；

当所述底层软件层接收到所述触摸屏发送的刷新完成信号时，向所述性能分层打点服务传递第六时刻记录消息，触发所述性能分层打点服务记录所述触摸屏刷屏送显完成的第六时刻。

11.根据权利要求9或10所述的方法，其特征在于，所述UI架构服务接收到第一类事件，向所述性能分层打点服务传递第一类时刻记录消息，触发所述性能分层打点服务记录所述第一类事件对应的时刻点，包括：

所述UI架构服务接收到应用程序层的第一调用请求后，向所述性能分层打点服务传递第二时刻记录消息，触发所述性能分层打点服务记录应用程序接收到所述中断事件时对应的第二时刻点，所述第一调用请求用于调用所述UI架构服务读取所述第一界面的资源文件；

所述UI架构服务响应于所述第一调用请求读取完所述第一界面的资源文件后，向所述性能分层打点服务传递第三时刻记录消息，触发所述性能分层打点服务记录资源读取完成时对应的第三时刻点；

所述UI架构服务读取渲染所需的资源文件后，向所述性能分层打点服务传递第四时刻记录消息，触发所述性能分层打点服务记录资源处理和加载完成的第四时刻点；

所述UI架构服务将渲染得到的页面内容写入显示缓存区后，向所述性能分层打点服务传递第五时刻记录消息，触发所述性能分层打点服务记录渲染完成的第五时刻点。

12.根据权利要求7-11任一项所述的方法，其特征在于，所述电子设备的操作系统包括由下至上排列的底层软件层、应用程序框架层和应用程序层，其中，所述应用程序框架层包括用户界面UI架构服务和性能分层打点服务；

所述当检测到屏幕同步信号时，输出性能监控数据及所述性能分析结果，包括：

所述底层软件层接收所述触摸屏发送的所述屏幕同步信号后，向所述性能分层打点服务传递性能数据输出消息；

所述性能分层打点服务响应于所述性能数据输出消息，输出所述性能监控数据及所述性能分析结果。

13.一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器和触摸屏；所述存储器用于存储程序代码；所述处理器用于运行所述程序代码，使得所述电子设备实现如权利要求1-12任一项所述的电子设备的性能监控方法。

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