CN117097883A - 一种丢帧故障原因确定方法、电子设备和存储介质 - Google Patents

Abstract

本申请提供一种丢帧故障原因确定方法、电子设备和存储介质，涉及终端设备领域，能够方便快捷的确定出丢帧故障原因。该方法包括：在播放动效或视频的过程中，获取显示屏显示的每个图像帧的耗时数据和帧绘制完成信息；耗时数据包括第一耗时信息和第二耗时信息，第一耗时信息包括帧绘制过程中各个阶段的耗时信息，第二耗时信息包括未知原因造成的耗时信息；帧绘制完成信息包括帧绘制完成时刻；在根据所有图像帧的帧绘制完成信息确定存在丢帧故障的情况下，基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段；基于目标耗时阶段和系统状态数据，确定丢帧故障原因。

Description

一种丢帧故障原因确定方法、电子设备和存储介质

技术领域

申请涉及终端技术领域，尤其涉及一种丢帧故障原因确定方法、电子设备和存储介质。

背景技术

随着手机等电子设备技术的不断发展，越来越多的电子设备可以进行动态画面（例如动效、视频等）的显示。动态画面的显示则需要电子设备在短时间内连续完成多帧画面的显示。而出于硬件性能、软件性能或者其他可能的原因，电子设备在连续显示多帧画面时，常常会出现丢帧的情况，产生显示卡顿等现象，降低了用户的使用体验。

发明内容

本申请实施例提供一种丢帧故障原因确定方法、电子设备和存储介质，能够方便快捷的确定出丢帧故障原因。

为了达到上述目的，本申请实施例采用如下技术方案：

第一方面，本申请实施例提供一种丢帧故障原因确定方法，应用于电子设备，该方法包括：电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的耗时数据和帧绘制完成信息；耗时数据包括第一耗时信息和第二耗时信息，第一耗时信息包括帧绘制过程中各个阶段的耗时信息，第二耗时信息包括未知原因造成的耗时信息；帧绘制完成信息包括帧绘制完成时刻；在电子设备根据所有图像帧的帧绘制完成信息确定存在丢帧故障的情况下，基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段；电子设备基于目标耗时阶段和系统状态数据，确定丢帧故障原因；其中，系统状态数据用于指示电子设备在播放动效或视频过程中与帧绘制过程相关的数据。

基于本申请提供的技术方案，在电子设备播放动效或者视频的过程（开始播放到结束播放之间）中，电子设备可以采集每和图像帧在帧绘制过程中各个阶段的耗时，以及每个图像帧的绘制完成时刻。在动效或视频播放结束后，电子设备则可以在确定存在丢帧故障的情况下，则可以结合引起丢帧故障的目标图像帧的帧绘制阶段中各个阶段的耗时情况确定出引起丢帧故障的目标耗时阶段。进一步的，结合电子设备的系统状态数据，则可以确定出丢帧故障的原因。由于整个确定丢帧故障原因的过程，均可以在动效或视频播放期间，利用帧绘制过程中容易收集到的数据确定出丢帧故障原因，所以本申请提供的技术方案可以在各类动效或视频的播放场景中方便的确定出丢帧故障和丢帧故障原因，避免了现有技术中丢帧故障原因不易确定，进而不能针对性解决丢帧故障的问题。

在第一方面的一种可能的实现方式中，电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的耗时数据，包括：电子设备在开始播放动效或视频的情况下，在渲染线程中注册第一耗时监听，并在表面控制模块中注册第二耗时监听，以从渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及从表面控制模块开始获取显示屏显示的图像帧的第二耗时信息；电子设备在结束播放动效或视频的情况下，在渲染线程中移除第一耗时监听，并在表面控制模块中移除第二耗时监听，以停止从渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及停止从表面控制模块开始获取显示屏显示的图像帧的第二耗时信息。

基于上述可能的实现方式，电子设备通过在渲染线程和表面控制模块中注册监听，便可以顺利得到动效或视频播放过程中图像帧的耗时数据，为后续丢帧故障原因的确定提供了数据支持。

在第一方面的一种可能的实现方式中，电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的帧绘制完成信息，包括：电子设备在开始播放动效或视频的情况下，开始获取显示屏显示的图像帧的帧绘制完成信息；电子设备在结束播放动效或视频的情况下，停止获取显示屏显示的图像帧的帧绘制完成信息。

基于上述实现方式，电子设备可以顺利的得到动效或视频播放过程中图像帧的帧绘制完成信息，为后续丢帧故障的确定提供了数据支持。

在第一方面的一种可能的实现方式中，该方法还包括：电子设备根据所有图像帧的帧绘制完成时刻，计算每个图像帧与前一个图像帧的帧间隔；在存在任一帧间隔与系统帧间隔的差值的绝对值大于预设阈值的情况下，电子设备确定存在丢帧故障，且将任一帧间隔对应的两个图像帧中帧绘制完成时刻在后的图像帧，确定为引起丢帧故障的目标图像帧。

由于丢帧故障出现时，大概率是由于某个图像帧的帧绘制时长过长导致的，而帧绘制时长过长也会导致该图像帧与其前一图像帧之间的帧间隔过大。所以基于上述实现方式，电子设备可以通过相邻图像帧之间的帧间隔与系统帧间隔的差值，准确的确定出是否出现了丢帧故障。

在第一方面的一种可能的实现方式中，电子设备基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段，包括：电子设备将目标图像帧的耗时数据中耗时时长大于系统绘制时长的预设百分比的阶段确定为目标耗时阶段。

基于上述实现方式，可以顺利的确定出目标图像帧的帧绘制过程中是哪个阶段耗费的时长超出了正常界限，进而将其确定为目标耗时阶段。

在第一方面的一种可能的实现方式中，系统状态数据包括： UI线程跨进程通信超时或未超时、UI线程消息处理超时或不超时、各线程对应中央处理器CPU算力值与标准值的大小关系；电子设备基于目标耗时阶段和系统状态数据，确定丢帧故障原因，包括：若目标耗时阶段为UI线程处理输入事件的阶段，且UI线程对应的CPU算力小于标准值，则电子设备确定丢帧故障原因为UI线程对应的CPU算力不足导致输入事件处理超时，产生丢帧故障；若目标耗时阶段为UI线程进行动画处理的阶段，且在目标耗时阶段进行的时间段内出现了UI线程Binder通信超时，则电子设备确定丢帧故障原因为UI线程Binder通信超时导致动画处理超时，产生丢帧故障；若目标耗时阶段为UI线程进行布局与测量的阶段，且在目标耗时阶段进行的时间段内出现了UI线程消息处理超时，则电子设备确定丢帧故障原因为UI线程消息处理超时导致布局超时，产生丢帧故障；若目标耗时阶段为显示合成系统的主线程进行GPU合成的阶段，且显示合成系统的主线程对应的CPU算力小于标准值，则电子设备确定丢帧故障原因为显示合成系统的主线程对应的CPU算力不足导致GPU合成超时，产生丢帧故障。

基于上述实现方式，电子设备可以结合目标耗时阶段和与丢帧故障密切相关的系统状态数据，方便快捷的确定出丢帧故障的原因。

在第一方面的一种可能的实现方式中，第二耗时信息还包括卡顿类型；方法还包括：电子设备不将无关帧确定为目标图像帧；无关帧为所有图像帧中耗时数据包括的卡顿类型与丢帧故障无关的图像帧。

基于上述实现方式，电子设备便可以避免将不是引起丢帧故障的无关帧确定为目标图像帧，也就使得确定出引起丢帧故障的目标图像帧更为准确，后续确定的丢帧故障原因也就更为准确。

在第一方面的一种可能的实现方式中，电子设备基于目标耗时阶段和系统状态数据，确定丢帧故障原因之后，方法还包括：电子设备向云端上报丢帧故障原因的相关数据；相关数据包括：目标图像帧的帧标识、目标耗时阶段和丢帧故障原因。

基于上述实现方式，云端便可以获取到电子设备确定出的丢帧故障原因的相关数据，进而电子设备的厂商便可以基于多个不同电子设备上报的数据，更为准确的确定出丢帧故障是为何出现，进而针对性的解决相应的丢帧故障，提高用户的使用体验。

第二方面，本申请实施例还提供一种丢帧故障原因确定装置，该装置可以应用于电子设备。该装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，例如，获取模块和处理模块。

其中，获取模块，可以用于获取电子设备播放动效或视频过程中，显示屏显示的每个图像帧的耗时数据和帧绘制完成信息；耗时数据包括第一耗时信息和第二耗时信息，第一耗时信息包括帧绘制过程中各个阶段的耗时信息，第二耗时信息包括未知原因造成的耗时信息；帧绘制完成信息包括帧绘制完成时刻。

处理模块，在用于在根据获取模块获取的所有图像帧的帧绘制完成信息确定存在丢帧故障的情况下，还用于基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段。

处理模块还用于基于目标耗时阶段和系统状态数据，确定丢帧故障原因；其中，系统状态数据用于指示电子设备在播放动效或视频过程中与帧绘制过程相关的数据。

第三方面，本申请提供一种电子设备，该电子设备包括显示屏、存储器和一个或多个处理器；显示屏、存储器与处理器耦合；其中，存储器中存储有计算机程序代码，计算机程序代码包括计算机指令，当计算机指令被处理器执行时，使得电子设备执行如第一方面及其任一种可能的设计方式提供的丢帧故障原因确定方法。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得电子设备执行如第一方面及其任一种可能的设计方式提供的丢帧故障原因确定方法。

第五方面，本申请提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如第一方面及其任一种可能的设计方式提供的丢帧故障原因确定方法。

可以理解地，上述提供的第二方面至第五方面提供的技术方案所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的帧绘制过程的示意图；

图2为相关技术提供的一种丢帧故障检测方法的实施环境示意图；

图3为本申请实施例提供的一种丢帧故障确定方法的原理示意图；

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

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

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

图7为本申请实施例提供的一种丢帧故障确定方法的流程示意图；

图8为本申请实施例提供的手机桌面的示意图；

图9为本申请实施例提供的桌面图层结构示意图；

图10为本申请实施例提供的另一种丢帧故障确定方法的流程示意图；

图11为本申请实施例提供的一种帧间隔的示意图；

图12为本申请实施例提供的丢帧故障原因确定逻辑示意图；

图13为本申请实施例提供的又一种丢帧故障确定方法的流程示意图；

图14为本申请实施例提供的再一种丢帧故障确定方法的流程示意图；

图15为本申请实施例提供的一种丢帧故障确定装置的结构示意图。

具体实施方式

本申请以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本申请所描述的实施例可以与其它实施例相结合。

本申请以下实施例中的术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

首先，对本申请实施例中涉及名词进行如下说明：

垂直同步信号（Vertical synchronization，Vsync）：显示屏显示完一行的像素称为行扫描，显示屏显示所有行的像素称为场扫描。显示屏开始扫描一场的物理信号称为垂直同步信号。显示屏扫描完一场可以显示一帧图像数据，即显示屏在一个Vsync信号的周期内，显示屏可以显示一帧图像数据。显示屏每秒钟能够刷新几场，即显示屏每秒钟能够显示几帧图像数据，电子设备每秒钟就需要生成多少个Vsync信号。

Vsync信号可以由电子设备的硬件编写器(Hardware Composer，HWC)产生。在HWC产生Vsync信号之后，应用程序可以在该Vsync信号的周期内将需要显示的图像发送给显示屏，从而显示屏可以显示该图像数据。也就是说，在一个Vsync信号对应的周期内，应用程序结合电子设备进行图像帧回执的模块可以绘制一帧图像数据，并将该帧图像数据发送给显示屏，从而显示屏可以显示出该帧图像数据。

动效： 动效是指画面动态变化的效果，亦可称为动态效果或动画效果等。动效的实质是图像帧更新（或者可以认为是不同图像帧的显示）带来的画面变化效果。因此，任意由于图像帧更新带来的画面变化效果，均属于本申请实施例的动效范围。基于此，本申请实施例不对动效具体的类型做过多限定。

在本申请实施例中，涉及的动效包括但不限于以下可能的动效：通过手势导航从主页（home）进入到多任务界面时的动效；使用手势导航从应用界面进入到多任务界面的动效；使用三键导航从主页进入到多任务的动效；使用三键导航从应用界面进入到多任务界面的动效；使用上滑手势从应用界面返回到主页的动效；使用上滑手势从负一屏的常驻卡片返回到主页的动效；使用上滑手势从微件（widght）返回到主页的动效；从桌面打开应用的动效；从多任务界面进入到应用页面时的动效；桌面滑动（例如主页滑动到负一屏）的动效；无密码解锁到桌面的动效；密码解锁到桌面的动效；下拉收起通知栏的动效等。

用户界面线程（UI线程）：UI线程，也被称为主线程，是负责处理用户界面(UI)的核心线程。它负责渲染UI元素，包括各种控件，例如绘图事件，以及处理用户的输入事件，例如触摸屏幕。所有这些操作都由主线程来调度和控制。安卓Android^®规定，活动Activity中的控件由主线程负责刷新，其它线程不能直接刷新。

帧：帧是指电子设备的显示画面时，最小单位的单幅画面。一帧可以理解为一幅静止的画面，快速连续地显示多个相连的帧可以形成物体运动的假象。在电子设备显示一帧画面之前，需要完成帧的绘制，即帧绘制。帧绘制完成后，电子设备则可以显示绘制完成的帧。

以使用安卓系统的电子设备为例，在该电子设备中，帧绘制过程涉及的线程主要有用户界面（user interface，UI）线程（或称为主线程）、渲染线程（Render Thread）和显示合成系统SurfaceFlinger服务。

其中，UI线程用于负责处理应用程序或者系统服务的UI事件和绘制操作的主线程。当UI组件（例如按钮、文本框等）需要更新时，UI线程会将更新指令发送给渲染线程。同时，UI线程也会接收用户输入Input事件（例如点击、滑动等）、动画Animation事件和遍历Traversal事，并处理这些事件，然后再次将更新指令发送给渲染线程。实际中，一帧图像是否开始绘制由Vsync信号决定。所以，在完成某帧的帧绘制后，UI线程可以处于等待Vsync信号的状态，一旦Vsync信号到来，UI线程将被唤醒，然后开始一帧的绘制工作。在处理完一帧的事件后，UI线程会同步渲染数据，即指示渲染Render线程完成渲染工作。

在一些实施例中，UI线程在帧绘制过程中进行的操作可以称为绘制帧DoFrame。

渲染线程用于负责执行UI线程发送的绘制指令的线程。渲染线程会使用开放式图形库（open graphics library，OpenGL）指令将UI组件绘制到帧缓冲区（Frame Buffer）中。在这个过程中，渲染线程还可以使用一些渲染技巧来优化绘制性能（例如批处理、裁剪等）。在一些实施例中，渲染线程在帧绘制过程中进行的操作可以称为绘制帧缓冲DrawFrame。

SurfaceFlinger服务是Android^®系统中的核心服务之一，它负责管理系统的帧缓冲区，将渲染后的窗口内容显示到手机屏幕上。在帧绘制过程中，SurfaceFlinger用于负责合成多个帧缓冲区，并将合成的图像数据输出到电子设备的显示器进行显示。SurfaceFlinger通过使用OpenGL和硬件合成器（Hardware Composer，HWC）来进行帧缓冲区的合成和输出操作。当SurfaceFlinger接收到UI线程或渲染线程的更新指令时，它会将这些指令转换为OpenGL指令，并将指令发送到Hardware Composer中进行合成操作。合成后的图像数据会被输出到显示设备中，以实现应用程序的动效显示。

在一些实施例中，一次帧绘制流程可以如图1所示。其中，UI线程主要完成帧绘制（DoFrame）操作。

示例性的，参照图1所示，在帧缓冲操作中，可能会导致帧缓冲操作超时进而产生丢帧故障的环节可能包括有：获取视图（obtainView）、布局（Layout）、预备树（preparetree）和请求下一个垂直同步信号（requestNextVsync）。这四个环节属于UI线程进行测量与布局（Measure和Layout）过程中产生的耗时。由于这四个环节所产生的耗时均很小，不易用于确定丢帧故障原因，所以在后续本申请提供的一些实施例中，在获取图像帧在帧绘制过程中的耗时数据时，可以获取到测量与布局产生的耗时，而不去更细化的获取这四个环节的耗时。

渲染线程（Render Thread）则用于接收UI线程的指令，将UI线程指示的UI组件绘制到帧缓冲区中，即执行绘制帧缓冲（DrawFrame）操作。

示例性的，参照图1所示，在帧缓冲操作中，可能会导致帧缓冲操作超时进而产生丢帧故障的环节可能包括有：冲命令（Flushcommands）、队列缓冲区/出列缓冲区（queueBuffer/dequeueBuffer）、释放缓冲区回调releaseBufferCallback和锁等待。其中，Flushcommands和锁等待产生的耗时属于渲染线程在同步渲染时产生的同步耗时SyncDuration中的一部分；queueBuffer/dequeueBuffer产生的耗时则属于渲染线程在交换缓冲区swap_buffer过程中产生的交换缓冲区耗时SwapBufferDuration中的一部分。releaseBufferCallback产生的耗时则可根据其具体作用决定属于SwapBufferDuration中的一部分或者属于渲染线程开始渲染之前等待UI线程的绘制命令的等待耗时CommandDuration中的一部分。具体的，若releaseBufferCallback是与释放缓冲区相关的回调函数或方法，那么其耗时属于；若releaseBufferCallback是与渲染相关的回调函数或方法，则其耗时可能属于CommandDuration中的一部分。

由于这四个环节所产生的耗时均很小，不易用于确定丢帧故障原因，所以在后续本申请提供的一些实施例中，在获取图像帧在帧绘制过程中的耗时数据时，可以获取到SyncDuration、SwapBufferDuration和CommandDuration，而不去更细化的获取这四个环节的耗时。

在帧缓冲区中存在有帧数据的情况下，显示合成系统（SurfaceFlinger）则进行消息无效化（onMessageInvalidata）操作。其中，消息无效化操作具体指显示合成系统在帧绘制过程中处理各种消息事务，包括帧数据的合成和处理，渲染指令和数据的处理。通过消息无效化操作，显示合成系统可以将多个帧缓冲区中的图像数据进行合成，并将合成后的内容发送到显示缓冲区中。

示例性的，参照图1所示，在消息无效化操作中，可能会导致操作超时进而产生丢帧故障的环节可能包括有：图形处理器（graphics processing unit，GPU）合成。

在显示合成系统执行了消息无效化操作之后，显示合成系统则可以借助硬件合成器中的合成器线程（composer binder）和合成器服务（composer service）将显示缓冲区中的图像数据送给硬件合成器进行合成。

其中，合成器线程可以根据当前显示缓冲区中的状态和硬件合成器的状态来决定执行提交操作还是准备操作。如果当前显示缓冲区已经准备好被合成，并且硬件合成器处于空闲状态，那么就会执行提交操作（Commit），将显示缓冲区的内容提交给硬件合成器进行合成。如果当前显示缓冲区还没有准备好被合成，或者硬件合成器正在忙于合成其他帧，那么就会执行准备操作（Prepare）。准备操作主要是将显示缓冲区的内容写入到内存中，以便在下一个Vsync信号到来时可以迅速地进行合成操作。

合成器服务则用于将准备好的显示缓冲区中的缓冲区数据提交给硬件合成器（Hardware Composer）进行合成，具体可以通过PerformHwCommit方法完成。具体来说，PerformHwCommit方法会根据当前的显示缓冲区的状态和硬件合成器的状态来决定是否执行提交操作。如果当前显示缓冲区已经准备好被合成，并且硬件合成器处于空闲状态，那么就会执行提交操作（Commit），将显示缓冲区的内容提交给硬件合成器进行合成。如果当前显示缓冲区还没有准备好被合成，或者硬件合成器正在忙于合成其他帧，那么就会进行等待操作（Wait），直到硬件合成器空闲为止。一旦硬件合成器空闲，就会立即执行提交操作，将准备好的缓冲区数据提交给硬件合成器进行合成。

示例性的，参照图1所示，合成器线程和合成器服务工作的过程中可能会导致帧缓冲操作超时进而产生丢帧故障的环节可能包括有：释放操作系统中空闲内存releasefreeMemoryToOS和抠图。

在合成器线程和合成器服务决定好需要执行提交操作后，显示器控制器提交（Composition and Retransmission Controller commit ，crtc_commit）模块，则可以将通过complete_commit方法将显示缓冲区中的数据提交给硬件合成器进行合成。合成完成后，crtc_commit则会调用显示串行接口（Display Serial Interface，dsi）将合成的结果显示到电子设备的屏幕上。

示例性的，参照图1所示，显示器控制器提交模块工作过程中可能会导致帧缓冲操作超时进而产生丢帧故障的环节可能包括有：撕裂效应（tearing effect，TE）信号产生和切帧。

当然，上述帧绘制流程仅为大致概述，实际中每个模块（例如UI线程、渲染线程、显示合成系统等）的执行的动作或操作可以包括更多的子动作或子操作，本申请对此不做具体限制，在此不做详细阐述。

需要说明的是，由于合成器线程、合成器服务和显示器控制器提交模块这几部分的流程数据难以获取，且对丢帧与否的影响较小，所以后续本申请实施例提供的技术方案中获取的图像帧的耗时数据仅包括UI线程、渲染线程和显示合成系统部分在帧绘制过程中产生的一些耗时信息，后续对此不再赘述。

在现有技术中，电子设备通常基于同一时间基准（例如，垂直同步信号Vsync）对图像帧的绘制（这里可以指帧绘制过程中UI线程完成的工作）、渲染、合成和屏幕刷新等操作进行同步，以此保证显示的流畅性，减少出现显示掉帧等现象。Vsync为周期性信号， Vsync可以根据屏幕刷新率进行设置。以屏幕刷新率为120Hz为例，为确保显卡输出帧率与屏幕刷新率同步，保持画面显示的连续性和稳定性， Vsync周期可以是1000/120=8.3ms或其倍数。假设按照时间顺序，电子设备显示的内容依次对应于帧1、帧2、帧3、帧4和帧5。以帧3为例，假设因各类可能的原因（例如系统负载过大），帧3的绘制过程无法在8.3ms内完成。则电子设备在进行内容显示时，帧2显示时长则会增加，从而导致电子设备出现卡顿，用户体验下降。

目前，手机、平板电脑等电子设备在播放动效、动画、视频等场景中，需要连续显示多帧画面，以提供流畅的显示效果。但是，处于各类可能原因，电子设备在显示过程中可能发生丢帧故障，使得显示过程出现卡顿，降低了用户的使用体验。

为了解决电子设备在播放视频或动效时因为可能的原因产生丢帧故障。参照图2所示，相关技术中，应用可以在电子设备中增加流畅度检测装置。在一些实施例中，该流畅度检测装置可以设置在显示合成系统中。

在某个应用或者系统服务可以在开始播放动效或者视频的情况下，该应用或者系统服务向流畅度检测装置发送检测开始指令。流畅度检测装置接收到该检测开始指令后，则可以开始获取动效或者视频的每一帧的绘制时刻。

在该应用或者系统服务结束播放动效或者视频的情况下，该应用或者系统服务可以向流畅度检测装置发送检测结束指令。流畅度检测装置接收到该检测结束指令后，则可以根据接收到检测开始指令和接收到检测结束指令之间，获取到的每一帧的绘制完成时刻（可以理解为帧绘制完成待显示的时刻），确定出所有相邻帧的帧间隔。基于所有的帧间隔和系统帧间隔，确定是否存在丢帧故障。该流畅度检测装置还可以在确定存在丢帧故障的情况下，计算丢帧时长。该系统帧间隔可以基于电子设备的刷新率（显示屏的刷新率）决定，例如若刷新率为60hz，则系统帧间隔可以为16.6毫秒（ms）。丢帧时长则可以为所有大于系统帧间隔的帧间隔，相比于系统帧间隔的差值之和。例如，电子设备的刷新率为120hz，显示某个动效总共显示了7帧图像，检测得到的帧间隔依次为8.3ms、8.3ms、8.3ms、8.3ms、8.3ms、10ms、8.3ms。则丢帧时长为10-8.3=1.7ms。

之后，流畅度检测装置则可以将该丢帧故障发生的帧和丢帧故障值（即丢帧时长）上报云端。云端在接收到丢帧故障相关的数据后，则可以在获取到相应的日志信息和系统分析工具（例如systrace）采集数据后，确定丢帧故障发生的原因。但是，实际中日志信息和系统分析工具采集数据常常会因为各种原因无法获取，从而使得丢帧故障原因不易确定或无法确定，也就不能针对性解决丢帧故障。

针对上述问题，本申请实施例提供一种丢帧故障原因确定方法，应用于具备显示视频或动效的电子设备中。在该技术方案中，参照图3所示，在应用或者系统服务播放动效或者视频的过程（开始播放到结束播放之间）中，采集每和图像帧在帧绘制过程中各个阶段的耗时，以及每个图像帧的绘制完成时刻。在动效或视频播放结束后，则可以基于每个图像帧的绘制完成时刻确定所有相邻两图像帧之间的帧间隔，并结合系统帧间隔确定是否存在丢帧故障。在存在丢帧故障时，则可以结合目标图像帧的帧绘制阶段中各个阶段的耗时情况确定出引起丢帧故障的目标耗时阶段。进一步的，结合电子设备的系统状态数据，则可以确定出丢帧故障的原因。之后，电子设备则可以将该丢帧故障的所有信息（丢帧故障对应的目标图像帧、目标耗时阶段和丢帧故障的原因）上传至云端，以供电子设备所属厂商基于该信息针对性的解决丢帧故障，进而提高用户的使用体验。

下面结合附图对本申请实施例提供的技术方案进行详细表述。

本申请提供的技术方案可以应用在具备动效显示功能的电子设备中。在一些实施例中，该电子设备可以是手机、平板电脑、手持计算机、个人计算机（personal computer，PC），超级移动个人计算机（ultra-mobile personal computer，UMPC）、上网本，以及蜂窝电话、个人数字助理（personal digital assistant，PDA）、增强现实（augmented reality，AR）设备、虚拟现实（virtual reality，VR）设备、人工智能(artificial intelligence，AI)设备、可穿戴式设备、车载设备、智能家居设备和/或智慧城市设备等电子设备，本申请实施例对该电子设备的具体类型不作特殊限制。

示例性的，以电子设备是手机为例，图4示出了本申请实施例提供的一种电子设备的结构示意图。

参照图4所示，电子设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，显示屏193，用户标识模块（subscriber identification module，SIM）卡接口194，以及摄像头195等。其中，传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。

处理器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可以包括一个或多个接口。接口可以包括集成电路（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）接口等。

充电管理模块140用于从供电设备（例如充电器、笔记本电能等）接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备的无线充电线圈接收无线充电输入。

充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。其中，电池142具体可以为多个电池串联组成。电源管理模块141用于连接电池142、充电管理模块140与处理器110。

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

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

内部存储器121可以包括一个或多个随机存取存储器（random access memory，RAM ）和一个或多个非易失性存储器（non-volatile memory， NVM）。随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序（例如机器指令），还可以用于存储用户及应用程序的数据等。非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。

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

环境光传感器用于感知环境光亮度。例如：环境光传感器可以测量环境光的四个通道的光强度。环境光传感器将测量到的环境光的四个通道的光强度输出给处理器110。处理器110可以对环境光传感器输出的环境光的四个通道的光强度进行处理得到环境光的光强度。在亮屏状态下，电子设备可以根据得到的环境光的光强度自适应调节显示屏亮度。

压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏193。压力传感器的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。当有触摸操作作用于显示屏193，电子设备根据压力传感器监测所述触摸操作强度。电子设备也可以根据压力传感器的监测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

在一些实施例中，电子设备可以包括1个或N个摄像头195，N为大于1的正整数。在本申请实施例中，摄像头195的类型可以根据硬件配置以及物理位置进行区分。例如，设置在电子设备的显示屏193那一面的摄像头可以称为前置摄像头，设置在电子设备的后盖那一面的摄像头可以称为后置摄像头；又例如，焦距短、视越大的摄像头可以称为广角摄像头，焦距长、视角小的摄像头可以称为普通摄像头。其中，焦距的长短、视角的大小为相对概念，并无具体的参数限定，因此广角摄像头和普通摄像头也是一个相对概念，具体可以根据焦距、视角等物理参数进行区分。

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

电子设备可以通过ISP，摄像头195，视频编解码器，GPU，显示屏193以及应用处理器等实现拍摄功能。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。本申请实施例中，每个图像帧的帧绘制过程中，都会使用的GPU的功能，以使得最终显示的画面获得更好的显示效果和性能表现。

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

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

显示屏193用于显示图像，视频等。显示屏193包括显示面板。显示面板可以采用液晶显示屏（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个显示屏193，N为大于1的正整数。

本申请实施例中，显示屏193可用于显示电子设备需要的页面（例如，向导页面（包括亮点推荐页面和外部模块接入页面）等），并在该界面中显示来自任一个或多个摄像头195拍摄的图像。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。

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

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

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

SIM卡接口194用于连接SIM卡。SIM卡可以通过插入SIM卡接口194，或从SIM卡接口194拔出，实现和电子设备的接触和分离。电子设备可以支持一个或多个SIM卡接口。SIM卡接口194可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口194可以同时插入多张卡。SIM卡接口194也可以兼容外部存储卡。电子设备通过SIM卡和网络交互，实现通话以及数据通信等功能。一个SIM卡对应一个用户号码。

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

当然，可以理解的，上述图4所示仅仅为电子设备的形态为手机时的示例性说明。若电子设备是平板电脑，手持计算机，PC，PDA，可穿戴式设备（如：智能手表、智能手环）等其他设备形态时，电子设备的结构中可以包括比图4中所示更少的结构，也可以包括比图4中所示更多的结构，在此不作限制。

可以理解的是，一般而言，电子设备功能的实现除了需要硬件的支持外，还需要软件的配合。电子设备的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android®系统为例，示例性说明电子设备的软件结构。

图5为本申请实施例提供的电子设备的软件系统的分层架构示意图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口（例如API）通信。

在一些示例中，参照图5所示，在本申请实施例中，将电子设备的软件分为五层，从上至下分别为应用程序层，框架层（或称为应用程序框架层），系统库和安卓运行时（android runtime），HAL层（hardware abstraction layer，硬件抽象层）以及驱动层（或称为内核层）。其中，系统库和安卓运行时还可以称为本地框架层或者native层。

其中，应用程序层可以包括一系列的应用程序。如图7所示，应用程序层可以包括相机、图库、日历、地图、WLAN、蓝牙、音乐、视频、短信息、通话、导航、即时通讯等应用程序（application，APP）。

框架层为应用程序层的应用程序提供应用编程接口(application programminginterface，API)和编程框架。应用程序框架层包括一些预先定义的函数或服务。例如，应用程序框架层可以包括活动管理器、窗口管理器、内容提供器、音频服务、视图系统、电话管理器、资源管理器、通知管理器、包管理器等，本申请实施例对此不做任何限制。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。这些数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。在一些实施例中，视图系统中还可以包括或启动渲染线程，以完成绘制帧缓冲等操作。

电话管理器用于提供电子设备的通信功能。例如，电话管理器可以管理通话应用的通话状态 (包括发起，接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

包管理器在安卓®系统中是用于管理应用程序包的。它允许应用程序获取关于已安装应用和它们的服务、权限等的详细信息。包管理器还用于管理应用程序的安装、卸载和升级等事件。

在本申请实施例中，框架层中还可以包括有帧耗时采集模块（FluencyDetector（APP））。参照图6所示，帧耗时采集模块在接收到检测开始指令的情况下，可以通过硬件渲染监听器（HardwareRendererObserver）和表面控制模块（SurfaceControl）获取目标应用或目标服务在播放动效或视频的过程中，每个图像帧的帧绘制过程中所有耗时数据。具体的，帧耗时采集模块可以通过硬件渲染监听器获取每个图像帧在帧绘制过程中各个阶段的耗时数据和帧标识。帧耗时采集模块还可以通过表面控制模块获取UI线程在每个图像帧的帧绘制过程中造成为未知原因的耗时数据（例如UnknownDelayFuration）。在帧耗时采集模块在接收到检测结束指令的情况下，则不再采集每个图像帧的帧绘制过程中每个阶段的耗时数据，并将每个图像帧对应的耗时数据发送给系统库中显示合成系统中的故障诊断模块。

在一些实施例中， 检测开始指令和检测结束指令可以不存在，帧耗时采集模块可以在目标应用或目标服务开始播放动效或视频的情况下，执行上述接收到检测开始指令后执行的相关操作；帧耗时采集模块可以在目标应用或目标服务结束播放动效或视频的情况下，执行上述接收到结束结束指令后执行的相关操作。

其中，目标应用为应用程中可以播放动效的应用，例如桌面应用、视频应用等。目标服务可以是框架层中的任意可能服务。目标应用和目标服务可以在开始播放动效或视频时向帧耗时采集模块发送检测开始指令，在结束播放动效或视频时向帧耗时采集模块发送检测结束指令。

系统库可以包括多个功能模块。例如：表面管理器(surface manager) ，媒体库(Media Libraries)，OpenGL ES，SGL等。表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。OpenGL ES用于实现三维图形绘图，图像渲染，合成，和图层处理等。SGL是2D绘图的绘图引擎。

在本申请实施例中，系统库中还可以包括有硬件渲染监听器和表面控制模块。硬件渲染监听器可以用于监听渲染进程，并在渲染进程完成一个图像帧的绘制的情况下从渲染进程获取到帧绘制过程中各个阶段的耗时数据。表面控制模块则可以用于鉴定UI线程，并获取到帧绘制过程中由于UI线程产生的未知原因的耗时数据（包括耗时时长和卡顿类型）。

安卓运行时(android runtime)包括核心库和ART虚拟机。android runtime负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在ART虚拟机中。ART虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。ART虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

在本申请实施例中，系统库中还可以显示合成系统（SurfaceFlinger，sf）和大数据模块（hiview）。显示合成系统，可以用于对显示子系统进行管理（例如控制电子设备的屏幕熄屏或者调节屏幕亮度等），并且为多个应用程序或系统服务提供图层的生成或者融合。

参照图6所示，在本申请实施例中，显示合成系统中可以包括有帧信息采集模块（SurfaceFlinger主线程）和故障诊断模块（FluencyDetector（SurfaceFlinger））。其中，帧信息采集模块可以是显示合成系统的主线程，故障诊断模块可以是显示合成系统的子线程。

帧信息采集模块可以在目标应用或目标服务在播放动效或视频的过程中，获取每个图像帧的帧绘制完成时刻（即绘制完成待显示的时刻）和帧标识。在一些实施例中，帧信息采集模块可以是接收到目标应用或目标服务在开始播放动效或视频时，向帧信息采集模块发送的开始采集指令后，开始获取每个图像帧的帧绘制完成时刻的。此外，帧信息采集模块可以是接收到目标应用或目标服务在结束播放动效或视频时，向帧信息采集模块发送的结束采集指令后，不再获取每个图像帧的帧绘制完成时刻的。

帧信息采集模块还用于在每次获取到图像帧的帧绘制完成时刻和帧标识的情况下，向故障诊断模块发送将该图像帧的帧绘制完成时刻和帧标识。

当然，帧信息采集模块还可以不考虑目标应用或目标服务是否在播放动效或视频，而是在在显示合成系统每次对图像帧进行帧合成时，均获取帧合成完成时刻作为帧绘制完成时刻，并向故障诊断模块发送。

故障诊断模块则用于在接收到采集开始指令的情况下，开始获取帧信息采集模块获取到的图像帧的帧绘制完成时刻和帧标识（具体可以是接收来自帧信息采集模块的图像帧的帧绘制完成时刻和帧标识）。故障诊断模块还用于在接收到采集结束指令的情况下，不再获取帧信息采集模块获取到的图像帧的帧绘制完成时刻和帧标识（具体可以是不再接收来自帧信息采集模块的图像帧的帧绘制完成时刻和帧标识），并基于从帧信息采集模块中获取到的所有图像帧的帧绘制完成时刻和帧标识，确定是否存在丢帧故障，以及在确定存在丢帧故障的情况下确定目标图像帧。在确定存在丢帧故障的情况下，会根据帧耗时采集模块采集的目标图像帧的耗时数据，确定引起丢帧故障的耗时阶段、耗时阶段的特征参数（所处时间段、所属线程、所属线程运行所处的CPU等）。故障诊断模块还用于将耗时阶段、耗时阶段的特征参数等信息发送给大数据模块。

在一些实施例中，采集开始指令可以是帧耗时采集模块开始采集图像帧的耗时数据时一并发送给故障诊断模块的。采集结束指令可以是帧耗时采集模块采集到的所有图像帧的所有耗时数据发送给故障诊断模块时，一并发送给故障诊断模块的。

在另一些实施例中，采集开始指令可以是目标应用或目标服务在开始播放动效或视频时向故障诊断模块发送的指令；采集结束指令可以是目标应用或目标服务在结束播放动效或视频时向故障诊断模块发送的指令。

在一些实施例中，采集开始指令和采集结束指令可以不存在，此时故障诊断模块可以在目标应用或目标服务开始播放动效或视频时，开始获取来自帧信息采集模块采集到的图像帧的帧绘制完成时刻；故障诊断模块还可以在目标应用或目标服务结束播放动效或视频时，停止获取来自帧信息采集模块采集到的图像帧的帧绘制完成时刻，并进行丢帧耗时原因的确定，并在确定完成后将耗时阶段、耗时阶段的特征参数和丢帧耗时原因等信息发送给大数据模块。

参照图6所示，大数据模块则可以基于故障诊断模块发送的丢帧故障数据（包括耗时阶段、耗时阶段的特征参数等），确定丢帧故障发生的原因（即丢帧故障原因），并将其上传至云端，以供电子设备所属厂商进行技术分析和处理。

HAL层是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化。它隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植。HAL层提供标准界面，向更高级别的 Java API 框架（即框架层）显示设备硬件功能。HAL 层包含多个库模块，其中每个模块都为特定类型的硬件组件实现一个界面，例如：audio HAL音频模块，bluetooth HAL蓝牙模块，camera HAL相机模块（还可称为相机HAL或相机硬件抽象模块），sensors HAL传感器模块（或称为Isensor service，传感器服务）。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动、电池驱动等，本申请不做限定。其中，传感器驱动具体可以包括电子设备包含的每个传感器的驱动，例如环境光传感器驱动等。示例性的，环境光传感器驱动可以响应于传感器模块获取检测数据的指示或指令，将环境光传感器的检测数据及时的发送给传感模块。

本申请实施例中提供的技术方案均可以在具有上述硬件架构或者软件架构的电子设备中实现。

基于上述图6所示的软件架构，以下结合图7所示，对本申请实施例提供的丢帧故障原因确定方法进行介绍。图7为本申请实施例提供的一种丢帧故障原因确定方法的流程示意图。参照图7所示，以电子设备为手机，播放动效或视频的为手机中的目标应用为例，该丢帧故障原因确定方法可以包括S701-S717：

S701、手机的目标应用在开始播放动效或视频的情况下，向帧耗时采集模块发送第一指示信息。

在一些实施例中，帧耗时采集模块可以是FluencyDetector（APP）。

在本申请实施例中，动效或视频可以是目标应用在任意可行的场景下向用户展示的动效或视频。例如，应用开启动效、应用关闭动效、广告视频、操作提示视频等。目标应用开始播放动效的情况可以是指用户实施了触发目标应用开始播放动效的操作时刻，例如用户实施了关闭目标应用的关闭操作的时刻，该关闭操作可以触发目标应用开始播放关闭动效。

其中，第一指示信息用于指示帧耗时采集模块开始采集每一图像帧的耗时数据。在本申请实施例中提到的图像帧为手机的显示屏在该丢帧故障原因确定方法执行过程中显示的图像帧，后续同理。

该耗时数据可以包括每一图像帧的第一耗时信息和第二耗时信息。其中，第一耗时信息包括帧绘制过程中各个阶段的耗时信息，第二耗时信息包括因为未知原因造成的耗时信息。此外，为了可以准确确定第一耗时信息和第二耗时信息的归属（即属于哪个图像帧），第一耗时信息和第二耗时信息中还可以包括帧标识。示例性的，在本申请实施例中，帧标识可以为图像帧的垂直同步信号标识-Vsync id。

在一些实施例中，第一指示信息可以为检测开始指令或动效开始提示等任意可能的内容，只要使得帧耗时采集模块可以确定当前目标应用开始播放动效需要开始采集每一图像帧的耗时数据即可。

本申请实施例提供的技术方案的主要目的是在动效或视频播放过程中出现丢帧故障的情况下，可以结合丢帧故障对应的目标图像帧在帧绘制过程中各个阶段的耗时情况确定引起丢帧故障的耗时阶段。其中，某个图像帧在帧绘制过程中各个阶段的耗时情况则由第一耗时信息和第二耗时信息表征。所以，在本申请实施例中，目标应用在开始播放动效或视频时，需要向帧耗时采集模块发送第一指示信息，以使帧耗时采集模块获取每个图像帧的第一耗时信息和第二耗时信息，以便作为后续确定耗时阶段时的依据。

需要说明的是，手机的显示屏显示的一帧图像可以是由一个或多个图层合成得到的。而手机在显示动效或者视频时，为了降低对计算资源的消耗，每次显示新的一帧图像（即屏幕刷新）是，可以是仅对图像需要产生变化（整个播放过程中仅变化了一次也算）的变化图层中的图像帧进行了帧绘制并刷新显示。例如，参照图8所示，手机显示的某一帧桌面中可以包括有状态栏801、应用程序图标托盘802和桌面背景803。该应用程序图标托盘802中展示了多个应用程序图标。图8所示的桌面可拆分为如图9中所示的多个图层。图9示例性示出了上述桌面的图层结构。如图9所示，图8所示的桌面图像可包括3个图层：交互层901、状态栏层902以及背景层903。交互层901是桌面中应用程序图标等可被用户即时操作的控件所在的图层。状态栏层902是桌面中状态栏801所在的图层。背景层903是桌面背景803（例如主题、壁纸等）所在的图层。在一些场景中，若用户实施对应用程序图标托盘802的滑动操作以切换桌面中显示的应用图标，则桌面应用则会在切换过程中显示切换动效。而在该切换动效播放的过程中，仅交互层901中的内容会产生变换，那么此时，本申请实施例提供的技术方案所针对的图像帧则为该交互层901中的图像帧。

基于此，本申请提供的丢帧故障原因确定方法针对的图像帧可以为存在变化的变化图层中的图像帧。若目标应用在播放动效或视频的过程中，仅存在一个图像需要产生变化的变化图层，则该丢帧故障原因确定方法针对该变化图层中的图像帧执行相应流程；若目标应用在播放动效或视频的过程中，存在多个图像需要产生变化的图层，则该丢帧故障原因确定方法可以分别针对每个变化图层中的图像帧执行相应流程。

当然，本申请实施例提供的丢帧故障原因确定方法针对的图像帧也可以是指所有图层合成后得到的图像帧，本申请对此不做具体限制。

S702、手机的帧耗时采集模块接收第一指示信息。

在手机向帧耗时采集模块发送了第一指示信息后，帧耗时采集模块在接收到该第一指示信息后，则需要响应于该第一指示信息获取每个图像帧的第一耗时信息和第二耗时信息。进一步的，每个图像帧在帧绘制过程中各个阶段的耗时信息主要可以由渲染线程得到。也就是说帧耗时采集模块可以从渲染线程处获取第一耗时信息。每个图像帧在帧绘制过程中因为一些未知原因造成的耗时信息则可以由目标应用的主线程-UI线程获取得到，而由于位于应用程序层的UI线程与位于框架层的帧耗时采集模块无法直接交互，所以帧耗时采集模块可以通过系统库中的表面控制模块从UI线程获取第二耗时信息。基于此，帧耗时采集模块在接收到第一指示信息后，则可以对渲染线程和表面控制模块的监听，以获取第一耗时信息和第二耗时信息。即执行S703。

在帧耗时采集模块接收到第一指示信息后，帧耗时采集模块除了需要及时的开始获取每个图像帧的耗时数据以外，为了准确在出现丢帧故障时确定导致出现丢帧故障产生的目标图像帧，进而可以基于目标图像帧的耗时数据确定引起丢帧故障的耗时阶段。基于此，在帧耗时采集模块接收到第一指示信息后，帧耗时采集模块还可以向故障诊断模块发送第二指示信息，以指示故障诊断模块开始获取图像帧的帧绘制完成时刻和帧标识。基于此，帧耗时采集模块在接收到第一指示信息后，还可以向故障诊断模块发送第二指示信息，即执行S704。

S703、手机的帧耗时采集模块响应于该第一指示信息，在渲染线程中注册第一耗时监听，并在表面控制模块中注册第二耗时监听。

其中，帧耗时采集模块在渲染线程中注册第一耗时监听，用于通过渲染线程获取每个图像帧的第一耗时信息；帧耗时采集模块在表面控制模块（SurfaceControl）中注册第二耗时监听，用于通过表面控制模块获取每个图像帧的第二耗时信息。帧耗时采集模块在渲染线程中注册第一耗时监听，以及在表面控制模块中注册第二耗时监听没有必然的先后顺序，可以是先在渲染线程中注册第一耗时监听，也可以是先在表面控制模块中注册第二耗时监听，还可以是在渲染线程中注册第一耗时监听的同时在表面控制模块中注册第二耗时监听，本申请对此不做具体限制。

帧耗时采集模块在渲染线程中注册第一耗时监听的具体实现方式可以存在以下几种：

在一种可能的实现中，结合图7，参照图10所示，在渲染线程中注册第一耗时监听具体可以是在渲染线程中注册硬件渲染监听器（HardwareRendererObserver）。在渲染线程中注册了硬件渲染监听器后，硬件渲染器监听器后续便可以从渲染线程中获取到第一耗时信息并发送给帧耗时采集模块。

示例性的，整个注册的具体实现可以大致包括以下步骤：首先创建HardwareRendererObserver实例，即实例化一个HardwareRendererObserver对象，该对象用于获取第一耗时信息。其次，在渲染线程中，调用 HardwareRenderer.registerObserver() 方法将 HardwareRendererObserver 注册到渲染线程中，使得HardwareRendererObserver能够从渲染线程中获取第一耗时信息。最后，需要在渲染线程中实现观察者 Observer 回调，具体可以是在HardwareRendererObserver中重写相应的回调函数/方法（例如onFrameDraw( 、onTimingChanged()、onBlackFrame()），以使得HardwareRendererObserver从渲染线程获取到第一耗时信息时，调用这些回调函数将第一耗时信息发送给帧耗时采集装置。

在另一种可能的实现方式中，在渲染线程中注册第一耗时监听可以是指示渲染线程主动上报每个图像帧的第一耗时信息，例如具体可以是请求渲染线程获取到图像帧的第一耗时信息时，主动向帧耗时采集模块发送第一耗时信息。其实现可以是帧耗时采集模块向渲染线程发送一个针对图像帧的第一耗时信息回调的回调函数，进而使得渲染线程获取到图像帧的第一耗时信息并将该图像帧的第一耗时信息发送给帧耗时采集模块。

在又一种可能的实现方式中，注册第一耗时监听还可以是开始监听渲染线程获取到的图像帧的第一耗时信息，例如具体可以是连续或者周期性的向渲染线程请求图像帧的第一耗时信息。渲染线程在接收到该请求，且自身获取到了图像帧的第一耗时信息时，则会将该图像帧的第一耗时信息发送给帧耗时采集模块。

当然，实际中注册第一耗时监听还可以是其他任意可行的实现方式，这里仅为示例，不做具体限制。

帧耗时采集模块在表面控制模块中注册第二耗时监听的具体实现方式可以存在以下几种：

在一种可能的实现中，结合图7，参照图10所示，在表面控制模块中注册第二耗时监听具体可以是在表面控制模块中注册卡顿数据监听器（JankDataListener）。在表面控制模块中注册了卡顿数据监听器后，卡顿数据监听器后续便可以从表面控制模块中获取到第二耗时信息并发送给帧耗时采集模块。

示例性的，整个注册的具体实现可以大致包括以下步骤：首先创建JankDataListener实例，即实例化一个JankDataListener对象，该对象具备获取第二耗时信息的能力。其次，通过调用 SurfaceControl 的 registerJankDataListener() 方法将JankDataListener 注册到SurfaceControl 上，以便监听获取第二耗时信息。最后，需要在JankDataListener中实现回调函数/方法，具体可以是在JankDataListener中重写相应的回调函数/方法（例如，onJankStarted()和onJankStopped()等）。这样，JankDataListener从表面控制模块获取到第一耗时信息时，调用这些回调函数将第二耗时信息发送给帧耗时采集装置。

在另一种可能的实现方式中，在表面控制模块中注册第二耗时监听可以是指示表面控制模块主动上报每个图像帧的第二耗时信息，例如具体可以是请求表面控制模块获取到图像帧的第二耗时信息时，主动向帧耗时采集模块发送第二耗时信息。其实现可以是帧耗时采集模块向表面控制模块发送一个针对图像帧的第二耗时信息回调的回调函数，进而使得表面控制模块获取到图像帧的第二耗时信息并将该图像帧的第二耗时信息发送给帧耗时采集模块。

在又一种可能的实现方式中，注册第二耗时监听还可以是开始监听表面控制模块获取到的图像帧的第二耗时信息，例如具体可以是连续或者周期性的向表面控制模块请求图像帧的第二耗时信息。表面控制模块在接收到该请求，且自身获取到了图像帧的第二耗时信息时，则会将该图像帧的第二耗时信息发送给帧耗时采集模块。

当然，实际中注册第二耗时监听还可以是其他任意可行的实现方式，这里仅为示例，不做具体限制。

S703后，渲染线程便可以通过硬件渲染监听器向帧耗时采集模块返回第一耗时信息，即执行S705；此外，表面控制模块也可以通过卡顿数据监听器向帧耗时采集模块返回第二耗时信息，即执行S706。

S704、手机的帧耗时采集模块向故障诊断模块发送第二指示信息。

在一些实施例中，第二指示信息可以为采集开始指令或动效开始提示等任意可能的内容，只要使得故障诊断模块可以确定当前目标应用开始播放动效需要开始获取每一图像帧的帧绘制完成时刻和帧标识即可。

在故障诊断模块接收到第二指示信息后，故障诊断模块便可以开始获取每一图像帧的帧绘制完成时刻和帧标识，即S704后执行S709。

需要说明的是，在本申请实施例中，S703和S704没有必然的先后顺序，可以是S703先执行，也可以是S704先执行，还可以是S703和S704同时执行，具体根据实际需求而定，本申请对此不做具体限制。

S705、手机的渲染线程向帧耗时采集模块发送图像帧的第一耗时信息。

在渲染线程被帧耗时采集模块注册了第一耗时监听后，可以开始在每一个新的图像帧绘制完成后向帧耗时采集模块发送该图像帧的第一耗时信息。

在一些实施例中，渲染线程可以是通过硬件渲染监听器向帧耗时采集模块发送图像帧的第一耗时信息。

在一种可能的实现方式中，渲染线程获取图像帧的第一耗时信息可以是通过onFrameMetricsAvailable方法获取的。在该实现方式中，帧耗时采集模块在渲染线程注册了第一耗时监听后，渲染线程便可以通过onFrameMetricsAvailable开始获取每一个新的图像帧的第一耗时信息并返回给帧耗时采集模块。

S706、手机的表面控制模块向帧耗时采集模块发送图像帧的第二耗时信息。

在表面控制模块被帧耗时采集模块注册了第一耗时监听后，可以在每一个新的图像帧绘制完成后向帧耗时采集模块发送该图像帧的第一耗时信息。

在一些实施例中，表面控制模块可以是通过卡顿数据监听器向帧耗时采集模块发送图像帧的第二耗时信息。

在一种可能的实现方式中，表面控制模块获取图像帧的第二耗时信息可以是通过onJankDataAvailable方法获取的。在该实现方式中，帧耗时采集模块在表面控制模块注册了第二耗时监听后，表面控制模块便可以通过onJankDataAvailable获取每一个新的图像帧的第二耗时信息并返回给帧耗时采集模块。

在S705和S706之后，为了明确每个图像帧和第一耗时信息以及第二耗时信息的对应关系，以得到每个图像帧的耗时数据。帧耗时采集模块还可以基于第一耗时信息和第二耗时信息中包括的图像帧的帧标识，从而将确定出属于同一图像帧的第一耗时信息和第二耗时信息，得到每个图像帧的耗时数据。即S705和S706后执行S707和S708。

S707、手机的帧耗时采集接收来自渲染线程的第一耗时信息和来自表面控制模块的第二耗时信息。

S708、手机的帧耗时采集模块将包括的帧标识相同的第一耗时信息和第二耗时信息组合为对应同一图像帧的耗时数据。

示例性的，某个图像帧的耗时数据可以如下表1所示。

表1-图像帧XX的耗时数据

。

其中，XX可以是该图像帧的帧标识。VsyncID和UnknownDelayduration是该图像帧的第二耗时信息；VsyncID、InputDuration、AnimationDuration、LayoutMeasureDuration、DrawDuration、SyncDuration、CommandDuration、SwapBufferDuration、GpudDuration和AppTotalDuration为该图像帧的第一耗时信息。第一耗时信息中，InputDuration、AnimationDuration、LayoutMeasureDuration、DrawDuration属于UI线程在该图像帧的帧绘制过程中进行各个阶段的耗时。AppTotalDuration则为InputDuration、AnimationDuration、LayoutMeasureDuration和DrawDuration的和。

在一些实施例中，VsyncID可以是目标应用或目标服务开始播放动效或视频后，Vsync的次序。例如某个图像帧对应的Vsync是目标应用或目标服务开始播放动效或视频后第三个Vsync，则该图像帧的VsyncID可以为3。

需要说明是，上述表1示出的耗时数据仅为示例，实际中耗时数据包括的内容可以更多也可以更少，具体根据实际需求而定，本申请对此不做具体限制。

S709、手机的故障诊断模块开始获取图像帧的帧绘制完成时刻和帧标识。

在一些实施例中，每个图像帧的帧绘制完成时刻和帧标识则可以是帧信息采集模块在显示合成系统每次对图像帧进行帧合成时获取得到。基于此，结合图7，参照图9所示，S709具体可以为S709A：

S709A、手机的故障诊断模块开始从帧信息采集模块获取图像帧的帧绘制完成时刻和帧标识。

在一种可能的实现方式中，帧信息采集模块可以在目标应用或目标服务在播放动效或视频的过程中，获取每个显示屏新显示的图像帧的帧绘制完成时刻和帧标识，并向故障诊断模块发送获取到的图像帧的帧绘制完成时刻和帧标识。此时，S709A具体可以是手机的故障诊断模块开始接收来自帧信息采集模块的图像帧的帧绘制完成时刻和帧标识。示例性的，镇信息采集模块获取的图像帧的帧绘制完成时刻可以是显示合成系统对该图像帧完成执行事务doTransaction操作时的时间戳。在显示合成系统中，doTransaction主要用于完成有关图层合成、渲染和显示的关键任务，以生成最终可以显示的屏幕图像，所以将显示合成系统对某个图像帧执行doTransaction操作完成的时间戳可以认定为相应图像帧的帧绘制完成时刻。之后，也可以基于doTransaction操作完成的时间戳来确定两个相邻图像帧的帧间隔。

在这种实现方式中，帧信息采集模块可以是接收到目标应用或目标服务在开始播放动效或视频时，向帧信息采集模块发送的开始采集指令后，开始获取每个显示屏需要显示的图像帧的帧绘制完成时刻的。此外，帧信息采集模块可以是接收到目标应用或目标服务在结束播放动效或视频时，向帧信息采集模块发送的结束采集指令后，不再获取每个图像帧的帧绘制完成时刻的。

在另一种可能的实现方式中，帧信息采集模块还可以不考虑目标应用或目标服务是否开始播放动效或视频，而是在每次获取到图像帧的帧绘制完成时刻和帧标识的情况下，均向故障诊断模块发送将该图像帧的帧绘制完成时刻和帧标识。此时，若故障诊断模块接收到了第二指示信息，则故障诊断模块可以接收到来自帧信息采集模块的图像帧的帧绘制完成时刻和帧标识。若故障诊断模块未接收到第二指示信息，或者故障诊断模块接收到了采集开始指令或动效开始提示等指示故障诊断模块不再获取图像帧的帧绘制完成时刻和帧标识的指示信息（例如后续提到的第四指示信息）时，则故障诊断模块可以不再接收或拒绝接收来自帧信息采集模块的图像帧的帧绘制完成时刻和帧标识。这种实现方式相比前一种实现方式，帧信息采集模块可能会产生多余的动作，浪费手机的处理资源，且可能在手机中产生一定量的垃圾数据。

基于S709A对应的技术方案，故障诊断模块便可以顺利开始获取到目标应用或目标服务播放动效或视频过程中，显示屏显示的每个图像帧的帧绘制完成时刻和帧标识。之后，故障诊断模块也就可以基于这些数据确定是否出现丢帧故障，并在出现丢帧故障的情况下，确定是哪个图像帧（具体为某个图像帧的帧标识）引起了丢帧故障。

在另一些实施例中，手机的故障诊断模块获取图像帧的帧绘制完成时刻和帧标识的方式还可以是主动向帧信息采集模块请求图像帧的帧绘制完成时刻和帧标识。

当然，上述S709的实现方式仅为示例，实际中还可以是其他任意可行的实现方式，本申请对此不做具体限制。

在本申请实施例中，S705-S708（S705、S706、S707、S708）可以是循环执行的，直至帧耗时采集模块接收到指示不再获取图像帧的耗时数据的指示信息为止；同理，S709也可以是循环执行的，直至故障诊断模块接收到指示不再获取图像帧的帧绘制完成时刻和帧标识的指示信息为止。即S708之后和S709之后，可以执行S710和S711。

S710、手机的目标应用在结束播放动效或视频的情况下，向帧耗时采集模块发送第三指示信息。

在本申请实施例中，目标应用结束播放动效或视频的情况可以是指目标应用播放的动效或视频结束的时刻。

第三指示信息用于指示帧耗时采集模块停止采集图像帧的耗时数据。

在一些实施例中，第三指示信息可以为检测结束指令或动效结束提示等任意可能的内容，只要使得帧耗时采集模块可以确定当前目标应用结束播放动效，需要停止采集图像帧的耗时数据即可。

在帧耗时采集模块接收到第三指示信息的情况下，帧耗时采集模块则不再采集新的图像帧的耗时数据。此时，帧耗时采集模块已经采集到了目标应用播放动效或视频的过程中显示屏显示的所有图像帧的耗时数据。后续，为了使得故障诊断模块可以在确定存在丢帧故障的情况下，基于丢帧故障对应的目标图像帧的耗时数据确定引起丢帧故障的耗时阶段，帧耗时采集模块则可以将自身采集到的所有图像帧的耗时数据发送给故障诊断模块。

需要说明的是，帧耗时采集模块也可以在每次获取到某个图像帧的耗时数据时，直接发送给故障诊断模块，而不是在接收到第三指示信息的情况下，一次性将所有图像帧的耗时数据发送给故障诊断模块。此种实现方式，则会导致帧耗时采集模块与故障诊断模块之间产生更多的信令，需要更多的信令资源。具体帧耗时采集模块何时将图像帧的耗时数据发送给故障诊断模块，可以根据实际需求而定，本申请对此不做具体限制。

此外，在帧耗时采集模块接收到第三指示信息的情况下，目标应用已经播放完了动效或视频，故障诊断模块也就不需要再进行图像帧的帧绘制完成时刻和帧标识的获取。此时，帧耗时采集模块可以移除在渲染线程注册的第一耗时监听和在表面控制模块注册的第二耗时监听。此外，帧耗时采集模块还应当向故障诊断模块发送第四指示信息，以指示故障诊断模块停止获取图像帧的帧绘制完成时刻和帧标识。

基于此，帧耗时采集模块在接收到第三指示信息后，则会向故障诊断模块发送第四指示信息和帧耗时采集模块采集到的所有图像帧的耗时数据。即S712后执行S713。

S711、手机的帧耗时采集模块接收第三指示信息，响应于第三指示信息，帧耗时采集模块移除第一耗时监听和第二耗时监听，并向故障诊断模块发送第四指示信息和帧耗时采集模块采集到的所有图像帧的耗时数据。

在帧耗时采集模块移动第一耗时监听和第二耗时监听后，渲染线程和表面控制模块便不会再向帧耗时采集模块发送图像帧的第一耗时信息和第二耗时信息。

在一些实施例中，第四指示信息可以为采集结束指令或动效结束提示等任意可能的内容，只要使得故障诊断模块可以确定当前目标应用结束播放动效，不再需要获取每一图像帧的帧绘制完成时刻和帧标识即可。

故障诊断模块在接收到第四指示信息和帧耗时采集模块采集到的所有图像帧的耗时数据后，故障诊断模块首先可以停止获取图像帧的帧绘制完成时刻和帧标识。其次，故障诊断模块可以基于已经获取到的图像帧的帧绘制完成时刻确定是否存在丢帧故障，在确定存在丢帧故障的情况下，确定引起丢帧故障的目标图像帧。之后，故障诊断模块则可以从帧耗时采集模块采集到的所有图像帧的耗时数据中找到目标图像帧的耗时数据，进而确定引起丢帧故障的耗时阶段。基于此，S711后执行S712-S715。

S712、手机的故障诊断模块接收第四指示信息，响应于第四指示信息，停止获取图像帧的帧绘制完成时刻和帧标识，并根据已获取到的所有图像帧的帧绘制完成时刻，判断是否存在丢帧故障。

在故障诊断模块确定存在丢帧故障的情况下，则可以进一步确定引起丢帧故障的目标图像帧，即执行S713；在故障诊断模块确定不存在丢帧故障的情况下，则代表目标应用播放动效或视频的过程中，没有出现丢帧，S712后结束流程。

在一些实施例中，故障诊断模块可以根据已获取到的所有图像帧的帧绘制完成时刻判断是否存在丢帧故障，具体可以是先确定出每个图像帧与前一图像帧的帧间隔，帧间隔可以是相邻两个图像帧之间帧绘制完成时刻的差值。其中，对于所有图像帧中第一个获取的图像帧而言，其与前一个图像帧的帧间隔可以是该第一个获取的图像帧的帧绘制完成时刻与故障诊断模块接收到第二指示消息的时刻的时间差（具体可以是时间差的绝对值）。例如，以故障诊断模块获取到了Z1-Z5五个图像帧的帧绘制完成时刻和帧标识为例，如图11所示，Z1-Z5的帧绘制完成时刻可以分别为T1-T5，故障诊断模块接收到第二还是信息的时刻则可以为T0。则Z1-Z5中每个图像帧与前一个图像帧的帧间隔依次为J1-J5。其中，J1为T0和T1的时间差（具体可以是时间差的绝对值，后续同理），J2为T1和T2的时间差，其余同理。

之后，故障诊断模块每个帧间隔与系统帧间隔的差值的绝对值是否小于预设阈值，若某个帧间隔与系统帧间隔的差值的绝对值小于预设阈值，则可以确定该帧间隔正常，未出现丢帧故障。若某个帧间隔系统帧间隔的差值的绝对值大于预设阈值，则可以确定产生了丢帧故障。其中，系统帧间隔可以是基于手机的屏幕刷新率得出的。例如，若屏幕刷新率为60Hz，则系统帧间隔可以为1000/60≈16.6ms。由于实际中动效或者视频的图像帧在显示时，帧间隔会收到各类影响，即便未出现丢帧，可能也不会完全与系统帧间隔相等，所以在帧间隔与系统帧间隔相差不大（即差值的绝对值小于预设阈值）的情况下，则可以认为帧间隔是正常的，否则可以认为出现了丢帧故障。预设阈值可以为任意可行的较小数值（例如0 ms或者0.5ms），本申请对此不做具体限制。

S713、手机的故障诊断模将丢帧故障对应的帧间隔相关的两个图像帧中帧绘制完成时刻在后的图像帧，确定为引起丢帧故障的目标图像帧。

示例性的，以故障诊断模块获取到了Z1-Z5五个图像帧的帧绘制完成时刻和帧标识，刷新率为60Hz为例，参照图10所示，若J1、J2、J3和J5均与系统帧间隔的差值的绝对值小于预设阈值，而J4与系统帧间隔的差值的绝对值大于预设阈值，则可以确定J4异常，出现了丢帧故障。此时，丢帧故障则可以确定是Z4帧绘制所消耗的时间过长导致的。

所以在确定出现丢帧故障的情况下，故障诊断模块可以将该帧间隔对应的两个图像帧中帧绘制完成时刻在后的图像帧确定为引起丢帧故障的目标图像帧。

S714、手机的故障诊断模块基于目标图像帧的帧标识，从来自帧耗时采集模块的所有图像帧的耗时数据中确定目标图像帧的耗时数据，并基于目标图像帧的耗时数据，确定引起丢帧故障的目标耗时阶段。

其中，自帧耗时采集模块的所有图像帧的耗时数据中帧标识与目标图像帧的帧标识相同的图像帧的耗时数据，即为目标图像帧的耗时数据。

在一种可能的实现方式中，基于目标图像帧的耗时数据，确定引起丢帧故障的目标耗时阶段可以包括：将目标图像帧的耗时数据中耗时时长大于系统绘制时长的预设百分比的阶段确定为目标耗时阶段。其中系统绘制时长可以是大多数情况下，手机将一个图像帧绘制完成所需要的时长。示例性的，预设百分比可以为50%。

例如，以系统绘制时长为6ms，预设百分比为50%，目标图像帧的耗时数据如表1所示，则若InputDuration大于3ms，则可以认为耗时阶段为InputDuration对应的Input，即UI线程处理输入事件的阶段为目标耗时阶段。

故障诊断模块在确定好目标耗时阶段后，为了进一步确定出丢帧故障的原因，则可以将目标耗时阶段发送给大数据模块，以使得大数据模块基于该目标耗时阶段和系统状态数据确定丢帧故障原因。即S714后执行S715和S716。

S715、手机的故障诊断模块向大数据模块发送目标耗时阶段。

S716、手机的大数据模块接收目标耗时阶段，并基于目标耗时阶段和系统状态数据确定丢帧故障原因。

其中，系统状态数据用于指示目标应用在播放动效或视频过程中与帧绘制过程相关的数据。示例性的，系统状态数据包括但不限于以下内容：目标应用的主线程（即UI线程）跨进程通信（例如Binder通信）超时或未超时、目标应用的主线程消息处理超时或不超时、各线程对应CPU算力值与标准值N的大小关系等。其中，标准值N为CPU可以处理大多数常规事件的情况下的算力值。

在本申请实施例中，大数据模块获取系统状态数据的方式可以为任意可行方式，本申请对此不做具体限制。

在一种可能的实现方式中，基于目标耗时阶段和系统状态数据确定丢帧故障原因的确定逻辑可以如图12所示，具体可以包括但不限于以下几条确定逻辑：

1、若目标耗时阶段为UI线程处理输入事件的阶段，且UI线程对应的CPU算力小于N，则可以确定丢帧故障原因为UI线程对应的CPU算力不足导致输入事件处理超时，产生丢帧故障。

基于上述逻辑，前述实施例中，在故障诊断模块确定了目标耗时阶段为处理输入事件后，还需要确定该目标耗时阶段所属的UI线程对应的CPU是哪个CPU。这样，后续大数据模块便可以针对性获取该CPU的算力是否较小（即CPU算力是否小于N）的系统状态数据，进而确定丢帧故障原因。

其中，目标耗时阶段所属的UI线程对应的CPU是哪个CPU可以由帧耗时信息采集模块在采集图像帧的耗时数据时一并采集，并在向故障诊断模块发送图像帧的耗时数据时一并发送。

2、若目标耗时阶段为UI线程进行动画处理的阶段，且在该目标耗时阶段进行的时间段内出现了UI线程Binder通信超时，则可以确定丢帧故障原因为UI线程Binder通信超时导致动画处理超时，产生丢帧故障。

基于上述逻辑，前述实施例中，在故障诊断模块确定了目标耗时阶段后还需要获取该目标耗时阶段所属的线程是哪个线程、该目标耗时阶段所处的时间段。这些数据可以由帧耗时信息采集模块在采集图像帧的耗时数据时一并采集，并在向故障诊断模块发送图像帧的耗时数据时一并发送。

此外，大数据模块还需要在获取UI线程Binder通信超时这一数据时，一并获取UI线程Binder通信超时这一情况发生的时刻，进而可以顺利的实施上述确定逻辑2。

3、若目标耗时阶段为UI线程进行布局与测量的阶段，且在该目标耗时阶段进行的时间段内出现了UI线程消息处理超时，则可以确定丢帧故障原因为UI线程消息处理超时导致布局超时，产生丢帧故障。

基于上述逻辑，前述实施例中，在故障诊断模块确定了目标耗时阶段后还需要获取该目标耗时阶段所属的线程是哪个线程、该目标耗时阶段所处的时间段。这些数据可以由帧耗时信息采集模块在采集图像帧的耗时数据时一并采集，并在向故障诊断模块发送图像帧的耗时数据时一并发送。

此外，大数据模块还需要在获取UI线程消息处理超时这一数据时，一并获取UI线程消息处理消息超时这一情况发生的时刻，进而可以顺利的实施上述确定逻辑3。

4、若目标耗时阶段为显示合成系统的主线程进行GPU合成的阶段，且显示合成系统的主线程对应的CPU算力小于N，则可以确定丢帧故障原因为显示合成系统的主线程对应的CPU算力不足导致GPU合成超时，产生丢帧故障。

基于上述逻辑，前述实施例中，在故障诊断模块确定了耗时阶段为处理输入事件后，还需要确定该耗时阶段所属的显示合成系统的主线程对应的CPU是哪个CPU。这样，后续大数据模块便可以针对性获取该CPU的算力是否较小（即CPU算力是否小于N）的系统状态数据，进而确定丢帧故障原因。

其中，耗时阶段所属的显示合成系统的主线程对应的CPU是哪个CPU可以由帧耗时信息采集模块在采集图像帧的耗时数据时一并采集，并在向故障诊断模块发送图像帧的耗时数据时一并发送。

在手机的大数据模块确定了丢帧故障原因后，则可以将本地丢帧故障的相关数据和丢帧故障原因上报值云端，以供电子设备所属厂商基于这些信息针对性的解决丢帧故障。即执行S717。

S717、手机的大数据模块将该丢帧故障原因的相关数据上报云端。

其中，该丢帧故障原因的相关数据包括但不限于以下内容：丢帧故障对应的目标图像帧的帧标识、目标耗时阶段和丢帧故障的原因等。

基于本申请实施例提供的技术方案，在应用或者系统服务播放动效或者视频的过程（开始播放到结束播放之间）中，手机可以采集每和图像帧在帧绘制过程中各个阶段的耗时，以及每个图像帧的绘制完成时刻。在动效或视频播放结束后，手机则可以基于每个图像帧的绘制完成时刻确定所有相邻两图像帧之间的帧间隔，并结合系统帧间隔确定是否存在丢帧故障。在存在丢帧故障时，则可以结合目标图像帧的帧绘制阶段中各个阶段的耗时情况确定出引起丢帧故障的目标耗时阶段。进一步的，结合电子设备的系统状态数据，则可以确定出丢帧故障的原因。之后，电子设备则可以将该丢帧故障的所有相关数据上传至云端，以供电子设备所属厂商基于该信息针对性的解决丢帧故障，进而提高用户的使用体验。

此外，由于整个确定丢帧故障原因的过程，均可以在动效或视频播放期间，利用帧绘制过程中容易收集到的数据确定出丢帧故障原因，所以本申请提供的技术方案可以在各类动效或视频的播放场景中方便的确定出丢帧故障和丢帧故障原因，避免了现有技术中丢帧故障原因不易确定，进而不能针对性解决丢帧故障的问题。

实际中，某些卡顿可能并不是由图像帧的帧绘制过程中的某些阶段耗时过多所导致的丢帧故障引起的。此时，本申请实施例提供的技术方案避免将这类图像帧（可称为无关帧）确定为目标图像帧。

所以，在一些实施例中，帧耗时采集模块在接收到第一指示信息后获取的图像帧的耗时数据（具体可以为第二耗时信息）中还可以包括卡顿类型JankType。之后，若某个图像帧的耗时数据中包括的卡顿类型存在且且卡顿类型不为丢帧故障对应的类型的情况下，则帧耗时采集模块后续在向故障诊断模块发送第四指令信息时，向故障诊断模块发送第五指示信息，以指示故障诊断模块不对该图像帧进行耗时阶段的相关判断。这样一来，对于不是与丢帧故障相关图像帧的卡顿，则不再将其耗时数据作为丢帧故障原因的判断。

在这种情况下，帧耗时采集模块采集到的某个图像帧的耗时数据则可以如下表2所示：

表2-图像帧XX的耗时数据

。

示例性的，卡顿类型可以为应用程序无响应卡顿、掉帧卡顿、跳帧卡顿等。其中应用程序无响应卡顿为与丢帧故障无关的卡顿类型。

基于此，在一些实施例中，结合图7，参照图13所示，在帧耗时采集模块接收到第三指示信息的情况下，该方法还包括S1301和S1302：

S1301、手机的帧耗时采集模块向故障诊断模块发送第五指示信息。

其中，第五指示信息用于指示故障诊断模块不将无关帧作为目标图像帧。无关帧为耗时信息中包括的卡顿类型为与丢帧故障无关的卡顿类型。

在一些实施例中，第五指示信息中可以携带有无关帧的帧标识，以便故障诊断模块确定哪些图像帧为无关帧。

S1302、手机的故障诊断模块接收第五指示信息，响应于第五指示信息，在确定目标图像帧的过程中不将无关帧确定为目标图像帧。

当然，上述S1301和S1302对应的实现方式仅为实例，实际中如何避免将无关帧确定为目标图像帧的方式可以为任意可行的方式，本申请对此不做具体限制。

基于上述S1301和S1302对应的技术方案，手机便可以避免将不是引起丢帧故障的无关帧确定为目标图像帧，也就使得确定出引起丢帧故障的目标图像帧更为准确，后续确定的丢帧故障原因也就更为准确。

为了便于理解，下面结合图14对本申请实施例提供的丢帧故障原因确定方法进行说明。如图14所示，该方法可以包括S1401-S1404：

S1401、电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的耗时数据和帧绘制完成信息。

其中，耗时数据包括第一耗时信息和第二耗时信息，第一耗时信息包括帧绘制过程中各个阶段的耗时信息，第二耗时信息包括未知原因造成的耗时信息；帧绘制完成信息包括帧绘制完成时刻。

在一些实施例中，S1401中获取显示屏显示的每个图像帧的耗时数据具体可以包括：电子设备在开始播放动效或视频的情况下，在渲染线程中注册第一耗时监听，并在表面控制模块中注册第二耗时监听，以从渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及从表面控制模块开始获取显示屏显示的图像帧的第二耗时信息；电子设备在结束播放动效或视频的情况下，在渲染线程中移除第一耗时监听，并在表面控制模块中移除第二耗时监听，以停止从渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及停止从表面控制模块开始获取显示屏显示的图像帧的第二耗时信息。

S1401中获取显示屏显示的每个图像帧的帧绘制完成信息具体可以包括：电子设备在开始播放动效或视频的情况下，开始获取显示屏显示的图像帧的帧绘制完成信息；电子设备在结束播放动效或视频的情况下，停止获取显示屏显示的图像帧的帧绘制完成信息。

S1401的具体实现可以参照前述实施例中，S701-S711的相关表述，此处不再赘述。

S1402、电子设备根据所有图像帧的帧绘制完成信息确定是否存在丢帧故障。

在电子设备根据所有图像帧的帧绘制完成信息确定存在丢帧故障的情况下，执行S1403；在电子设备根据所有图像帧的帧绘制完成信息确定不存在丢帧故障的情况下，流程结束。

在一些实施例中，S1402具体可以包括：电子设备根据所有图像帧的帧绘制完成时刻，计算每个图像帧与前一个图像帧的帧间隔；在存在任一帧间隔与系统帧间隔的差值的绝对值大于预设阈值的情况下，电子设备确定存在丢帧故障，且将任一帧间隔对应的两个图像帧中帧绘制完成时刻在后的图像帧，确定为引起丢帧故障的目标图像帧。在不存在任一帧间隔与系统帧间隔的差值的绝对值大于预设阈值的情况下，电子设备确定不存在丢帧故障。

S1402的具体实现可以参照前述实施例中，S712和S713的相关表述，此处不再赘述。

S1403、电子设备基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段。

在一些实施例中，S1403具体可以包括：电子设备将目标图像帧的耗时数据中耗时时长大于系统绘制时长的预设百分比的阶段确定为目标耗时阶段。

S1403的具体实现可以参照前述实施例中S714的相关表述，此处不再赘述。

S1404、电子设备基于目标耗时阶段和系统状态数据，确定丢帧故障原因。

其中，系统状态数据用于指示电子设备在播放动效或视频过程中与帧绘制过程相关的数据。

在一些实施例中，系统状态数据可以包括：UI线程跨进程通信超时或未超时、UI线程消息处理超时或不超时、各线程对应中央处理器CPU算力值与标准值的大小关系。S1405具体可以包括：

若目标耗时阶段为UI线程处理输入事件的阶段，且UI线程对应的CPU算力小于标准值，则电子设备确定丢帧故障原因为UI线程对应的CPU算力不足导致输入事件处理超时，产生丢帧故障；若目标耗时阶段为UI线程进行动画处理的阶段，且在目标耗时阶段进行的时间段内出现了UI线程Binder通信超时，则电子设备确定丢帧故障原因为UI线程Binder通信超时导致动画处理超时，产生丢帧故障；若目标耗时阶段为UI线程进行布局与测量的阶段，且在目标耗时阶段进行的时间段内出现了UI线程消息处理超时，则电子设备确定丢帧故障原因为UI线程消息处理超时导致布局超时，产生丢帧故障；若目标耗时阶段为显示合成系统的主线程进行GPU合成的阶段，且显示合成系统的主线程对应的CPU算力小于标准值，则电子设备确定丢帧故障原因为显示合成系统的主线程对应的CPU算力不足导致GPU合成超时，产生丢帧故障。

S1404的具体实现可以参照前述实施例中，S715和S716的相关表述，此处不再赘述。

基于上述S1401-S1404对应的技术方案，在电子设备播放动效或者视频的过程（开始播放到结束播放之间）中，电子设备可以采集每和图像帧在帧绘制过程中各个阶段的耗时，以及每个图像帧的绘制完成时刻。在动效或视频播放结束后，电子设备则可以在确定存在丢帧故障的情况下，则可以结合引起丢帧故障的目标图像帧的帧绘制阶段中各个阶段的耗时情况确定出引起丢帧故障的目标耗时阶段。进一步的，结合电子设备的系统状态数据，则可以确定出丢帧故障的原因。由于整个确定丢帧故障原因的过程，均可以在动效或视频播放期间，利用帧绘制过程中容易收集到的数据确定出丢帧故障原因，所以本申请提供的技术方案可以在各类动效或视频的播放场景中方便的确定出丢帧故障和丢帧故障原因，避免了现有技术中丢帧故障原因不易确定，进而不能针对性解决丢帧故障的问题。

在一些实施例中，第二耗时信息还包括卡顿类型。该丢帧故障原因确定方法还包括：电子设备不将无关帧确定为目标图像帧；无关帧为所有图像帧中耗时数据包括的卡顿类型与丢帧故障无关的图像帧。

电子设备不将无关帧确定为目标图像帧的具体实现可以参照前述实施例中，S1301和S1302的相关表述，此处不再赘述。

在一些实施例中，S1405之后，该丢帧故障原因确定方法还包括：电子设备向云端上报丢帧故障原因的相关数据；相关数据包括：目标图像帧的帧标识、目标耗时阶段和丢帧故障原因。

电子设备向云端上报丢帧故障原因的相关数据的具体实现可以参照前述实施例中S717的相关表述，此处不再赘述。

可以理解的是，上述电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

本申请实施例可以根据上述方法示例对上述电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，参照图15所示，本申请实施例还提供了一种应用在电子设备中的故障原因确定装置，该装置可以包括：获取模块1501和处理模块1502。

其中，获取模块1501，可以用于获取电子设备播放动效或视频过程中，显示屏显示的每个图像帧的耗时数据和帧绘制完成信息；耗时数据包括第一耗时信息和第二耗时信息，第一耗时信息包括帧绘制过程中各个阶段的耗时信息，第二耗时信息包括未知原因造成的耗时信息；帧绘制完成信息包括帧绘制完成时刻。

处理模块1502，在用于在根据获取模块1501获取的所有图像帧的帧绘制完成信息确定存在丢帧故障的情况下，还用于基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段。

处理模块1502还用于基于目标耗时阶段和系统状态数据，确定丢帧故障原因；其中，系统状态数据用于指示电子设备在播放动效或视频过程中与帧绘制过程相关的数据。

可选的，获取模块1501具体用于：在电子设备开始播放动效或视频的情况下，在渲染线程中注册第一耗时监听，并在表面控制模块中注册第二耗时监听，以从渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及从表面控制模块开始获取显示屏显示的图像帧的第二耗时信息；在电子设备结束播放动效或视频的情况下，在渲染线程中移除第一耗时监听，并在表面控制模块中移除第二耗时监听，以停止从渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及停止从表面控制模块开始获取显示屏显示的图像帧的第二耗时信息。

可选的，获取模块1501具体用于：在电子设备开始播放动效或视频的情况下，开始获取显示屏显示的图像帧的帧绘制完成信息；在电子设备结束播放动效或视频的情况下，停止获取显示屏显示的图像帧的帧绘制完成信息。

可选的，处理模块1502具体用于：根据获取模块1501获取的所有图像帧的帧绘制完成时刻，计算每个图像帧与前一个图像帧的帧间隔；在存在任一帧间隔与系统帧间隔的差值的绝对值大于预设阈值的情况下，确定存在丢帧故障，且将任一帧间隔对应的两个图像帧中帧绘制完成时刻在后的图像帧，确定为引起丢帧故障的目标图像帧。

可选的，处理模块1502具体用于：将目标图像帧的耗时数据中耗时时长大于系统绘制时长的预设百分比的阶段确定为目标耗时阶段。

可选的，系统状态数据包括： UI线程跨进程通信超时或未超时、UI线程消息处理超时或不超时、各线程对应中央处理器CPU算力值与标准值的大小关系；处理模块具体用于：若目标耗时阶段为UI线程处理输入事件的阶段，且UI线程对应的CPU算力小于标准值，则电子设备确定丢帧故障原因为UI线程对应的CPU算力不足导致输入事件处理超时，产生丢帧故障；若目标耗时阶段为UI线程进行动画处理的阶段，且在目标耗时阶段进行的时间段内出现了UI线程Binder通信超时，则电子设备确定丢帧故障原因为UI线程Binder通信超时导致动画处理超时，产生丢帧故障；若目标耗时阶段为UI线程进行布局与测量的阶段，且在目标耗时阶段进行的时间段内出现了UI线程消息处理超时，则电子设备确定丢帧故障原因为UI线程消息处理超时导致布局超时，产生丢帧故障；若目标耗时阶段为显示合成系统的主线程进行GPU合成的阶段，且显示合成系统的主线程对应的CPU算力小于标准值，则电子设备确定丢帧故障原因为显示合成系统的主线程对应的CPU算力不足导致GPU合成超时，产生丢帧故障。

可选的，第二耗时信息还包括卡顿类型；处理模块还用于不将无关帧确定为目标图像帧；无关帧为所有图像帧中耗时数据包括的卡顿类型与丢帧故障无关的图像帧。

可选的，该装置还可以包括发送模块。发送模块具体用于在处理模块确定了丢帧故障原因之后，向云端上报丢帧故障原因的相关数据；相关数据包括：目标图像帧的帧标识、目标耗时阶段和丢帧故障原因。

关于上述实施例中的电子设备，其中各个模块执行操作的具体方式已经在前述实施例中的丢帧故障确定方法的实施例中进行了详细描述，此处不再具体阐述。其相关的有益效果也可参照前述丢帧故障确定方法的相关有益效果，此处不再赘述。

本申请实施例还提供一种电子设备，该电子设备包括：显示屏、存储器和一个或多个处理器；显示屏、存储器与处理器耦合；其中，存储器中存储有计算机程序代码，计算机程序代码包括计算机指令，当计算机指令被处理器执行时，使得电子设备执行如前述实施例提供的丢帧故障确定方法。该电子设备的具体结构可参照图4中所示的电子设备的结构。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行如前述实施例提供的丢帧故障确定方法。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包含可执行指令，当该计算机程序产品在电子设备上运行时，使得电子设备执行如前述实施例提供的丢帧故障确定方法。

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

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

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

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

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

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

Claims (10)

1.一种丢帧故障原因确定方法，其特征在于，应用于具备显示屏的电子设备，所述方法包括：

所述电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的耗时数据和帧绘制完成信息；所述耗时数据包括第一耗时信息和第二耗时信息，所述第一耗时信息包括帧绘制过程中各个阶段的耗时信息，所述第二耗时信息包括未知原因造成的耗时信息；所述帧绘制完成信息包括帧绘制完成时刻；

在所述电子设备根据所有所述图像帧的帧绘制完成信息确定存在丢帧故障的情况下，基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段；

所述电子设备基于所述目标耗时阶段和系统状态数据，确定丢帧故障原因；其中，所述系统状态数据用于指示所述电子设备在播放动效或表视频过程中与帧绘制过程相关的数据。

2.根据权利要求1所述的方法，其特征在于，所述电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的耗时数据，包括：

所述电子设备在开始播放动效或视频的情况下，在渲染线程中注册第一耗时监听，并在表面控制模块中注册第二耗时监听，以从所述渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及从所述表面控制模块开始获取显示屏显示的图像帧的第二耗时信息；

所述电子设备在结束播放动效或视频的情况下，在渲染线程中移除第一耗时监听，并在表面控制模块中移除第二耗时监听，以停止从所述渲染线程开始获取显示屏显示的图像帧的第一耗时信息，以及停止从所述表面控制模块开始获取显示屏显示的图像帧的第二耗时信息。

3.根据权利要求1所述的方法，其特征在于，所述电子设备在播放动效或视频的过程中，获取显示屏显示的每个图像帧的帧绘制完成信息，包括：

所述电子设备在开始播放动效或视频的情况下，开始获取显示屏显示的图像帧的帧绘制完成信息；

所述电子设备在结束播放动效或视频的情况下，停止获取显示屏显示的图像帧的帧绘制完成信息。

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

所述电子设备根据所有所述图像帧的帧绘制完成时刻，计算每个所述图像帧与前一个图像帧的帧间隔；

在存在任一帧间隔与系统帧间隔的差值的绝对值大于预设阈值的情况下，所述电子设备确定存在丢帧故障，且将所述任一帧间隔对应的两个图像帧中帧绘制完成时刻在后的图像帧，确定为引起丢帧故障的目标图像帧。

5.根据权利要求1所述的方法，其特征在于，所述电子设备基于引起丢帧故障的目标图像帧的耗时数据，确定目标耗时阶段，包括：

所述电子设备将所述目标图像帧的耗时数据中耗时时长大于系统绘制时长的预设百分比的阶段确定为目标耗时阶段。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述系统状态数据包括： UI线程跨进程通信超时或未超时、UI线程消息处理超时或不超时、各线程对应中央处理器CPU算力值与标准值的大小关系；

所述电子设备基于所述目标耗时阶段和系统状态数据，确定丢帧故障原因，包括：

若所述目标耗时阶段为UI线程处理输入事件的阶段，且所述UI线程对应的CPU算力小于所述标准值，则所述电子设备确定所述丢帧故障原因为所述UI线程对应的CPU算力不足导致输入事件处理超时，产生丢帧故障；

若所述目标耗时阶段为所述UI线程进行动画处理的阶段，且在所述目标耗时阶段进行的时间段内出现了所述UI线程Binder通信超时，则所述电子设备确定所述丢帧故障原因为所述UI线程Binder通信超时导致动画处理超时，产生丢帧故障；

若所述目标耗时阶段为所述UI线程进行布局与测量的阶段，且在所述目标耗时阶段进行的时间段内出现了所述UI线程消息处理超时，则所述电子设备确定所述丢帧故障原因为所述UI线程消息处理超时导致布局超时，产生丢帧故障；

若所述目标耗时阶段为显示合成系统的主线程进行GPU合成的阶段，且所述显示合成系统的主线程对应的CPU算力小于标准值，则所述电子设备确定所述丢帧故障原因为所述显示合成系统的主线程对应的CPU算力不足导致GPU合成超时，产生丢帧故障。

7.根据权利要求4所述的方法，其特征在于，所述第二耗时信息还包括卡顿类型；所述方法还包括：

所述电子设备不将无关帧确定为所述目标图像帧；所述无关帧为所有所述图像帧中耗时数据包括的卡顿类型与丢帧故障无关的图像帧。

8.根据权利要求1-5任一项所述的方法，其特征在于，所述电子设备基于所述目标耗时阶段和系统状态数据，确定丢帧故障原因之后，所述方法还包括：

所述电子设备向云端上报所述丢帧故障原因的相关数据；所述相关数据包括：所述目标图像帧的帧标识、所述目标耗时阶段和所述丢帧故障原因。

9.一种电子设备，其特征在于，包括：显示屏、存储器和一个或多个处理器；所述显示屏、所述存储器与所述处理器耦合；其中，所述存储器中存储有计算机程序代码，所述计算机程序代码包括计算机指令，当所述计算机指令被所述处理器执行时，使得所述电子设备执行如权利要求1-8任一项所述的丢帧故障原因确定方法。

10.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-8中任一项所述的丢帧故障原因确定方法。