CN116708753A - 预览卡顿原因的确定方法、设备及存储介质 - Google Patents

Abstract

本申请提供了一种预览卡顿原因的确定方法、设备及存储介质。该方法在具备拍摄功能的目标应用的图像预览界面出现预览卡顿异常时，通过根据显示图像预览界面过程中，获取显示在图像预览界面中的预览图像帧在流转的通路中各处理环节流转的时间信息，进而根据预览图像帧在各处理环节流转的时间信息，确定造成预览卡顿异常的预览卡顿原因，从而能够精准的确定预览卡顿异常由哪一处理环节或硬件造成，使得后续能够根据预览卡顿原因进行优化处理，从而减少卡顿提升流畅度，提升用户体验。

Description

预览卡顿原因的确定方法、设备及存储介质

技术领域

本申请涉及图像处理技术领域，尤其涉及一种预览卡顿原因的确定方法、设备及存储介质。

背景技术

当前，诸如手机等终端设备的拍摄功能越来越完善，用户对拍摄的体验要求也越来越高。但是，在使用具备拍摄功能的应用的过程中，常常会出现画面卡顿的问题，尤其是在预览界面、视频录制界面。而减少卡顿提升流畅度是产品体验的重要指标，因此如何精准的确定预览卡顿原因尤为重要。

发明内容

为了解决上述技术问题，本申请提供一种预览卡顿原因的确定方法、设备及存储介质，旨在精准的确定造成画面卡顿的原因，以便后续能够根据预览卡顿原因进行优化处理，从而减少卡顿提升流畅度，提升用户体验。

第一方面，本申请提供一种预览卡顿原因的确定方法。该方法应用于第一终端设备，包括：显示目标应用的图像预览界面，目标应用为具有拍摄功能的应用；在显示图像预览界面的过程中，获取基于目标应用持续下发的图像预览请求采集的预览图像帧从摄像头输出后，在预览图像帧流转的通路中各处理环节流转的时间信息；在图像预览界面出现预览卡顿异常时，根据预览图像帧在各处理环节流转的时间信息，确定造成预览卡顿异常的预览卡顿原因。

其中，目标应用例如可以是第一终端设备自带的相机应用，或者其他具备拍摄功能的三方应用。

其中，第一终端设备例如可以是手机、平板电脑、笔记本电脑、智能传递设备等安装了具备拍摄功能应用的设备。

示例性的，在一些实现方式中，第一终端设备中具备拍摄功能应用的运行可以基于第一终端设备自带的摄像头，也可以是外接的摄像头。

其中，图像预览界面例如可以是下文中所说的界面10b。

其中，图像预览请求的下发流程，以及摄像头基于目标应用持续下发的图像预览请求采集预览图像帧，并将采集到的预览图像帧输送至相机应用，在图像预览界面显示的流程可以参见下文针对图3的描述部分，此处不再赘述。

由此，通过获取预览图像帧在流转的通路中各处理环节中流转的时间信息，进而根据各处理环节对应的时间信息进行检测，根据预览图像帧与时间信息量化每一个环节中出现的卡顿位置(出现卡顿时的图像帧)，以及同一卡顿位置的预览卡顿原因，从而可以快速、准确的追溯到源头，实现了对每一次卡顿对应的预览卡顿原因的精准确定。

根据第一方面，根据图像帧在通路中的流转顺序，处理环节包括出帧环节、缓存环节、合成环节和送显环节；根据预览图像帧在各处理环节流转的时间信息，确定造成预览卡顿异常的预览卡顿原因，包括：根据预览图像帧在出帧环节流转的时间信息，确定出现预览卡顿异常时，出帧环节在预览卡顿异常对应的预览图像帧附近输出的预览图像帧是否存在丢帧现象；在出帧环节在预览卡顿异常对应的预览图像帧附近输出的预览图像帧存在丢帧现象时，确定造成预览卡顿异常的预览卡顿原因来自出帧环节；在出帧环节在预览卡顿异常对应的预览图像帧附近输出的预览图像帧不存在丢帧现象时，根据预览图像帧在送显环节流转的时间信息，确定预览图像帧的送显时间是否均匀；在预览图像帧的送显时间均匀时，确定造成预览卡顿异常的预览卡顿原因来自第一终端设备的显示屏；在预览图像帧的送显时间不均匀时，根据预览图像帧在合成环节流转的时间信息，确定预览图像帧的合成时间是否均匀；在预览图像帧的合成时间均匀时，确定造成预览卡顿异常的预览卡顿原因来自送显环节；在预览图像帧的合成时间不均匀时，根据预览图像帧在缓存环节流转的时间信息，确定预览图像帧添加到缓存队列的入队时间是否均匀；在预览图像帧添加到缓存队列的入队时间均匀时，确定造成预览卡顿异常的预览卡顿原因来自合成环节；在预览图像帧添加到缓存队列的入队时间不均匀时，确定造成预览卡顿异常的预览卡顿原因来自出帧环节。

其中，出帧环节，即下文所说的由摄像头驱动输出图像帧的环节；缓存环节，即下文所说的将摄像头硬件抽象层服务进程(CameraProvider)处理后的图像帧经CameraService添加到CameraBufferQuene的环节；合成环节，即下文所说的由SF线程通过BBQ从CameraBufferQuene读取出图像帧进行合成处理的环节；送显环节，即下文所说的由硬件合成器在接收到VSync-HW信号时，将SF线程合成的图像帧传输给显示驱动，由显示驱动去驱动显示屏显示图像帧的环节。

关于对上述4个处理环节的检测，可以参见下文针对图8至图13所示部分的描述，此处不再赘述。

此外，上述各处理环节涉及的时间信息，例如为下文文针对图8至图13所示部分的描述中，在各个处理环节的检测中涉及的时间戳。

由此，基于上述4个环节的在预览图像帧送显流程中对预览图像帧的处理顺序，可以快速、准确的追溯到源头，对于某一环节中新增的卡顿位置，则可以确定该帧造成的预览卡顿原因来自该环节，从而实现了对每一次卡顿对应的预览卡顿原因的精准确定。

根据第一方面，或者以上第一方面的任意一种实现方式，缓存环节进行的操作为将摄像头硬件抽象层服务进程输出的预览图像帧添加到缓存队列的的操作；根据预览图像帧在缓存环节流转的时间信息，确定预览图像帧添加到缓存队列的入队时间是否均匀，包括：获取每一帧预览图像帧添加到缓存队列的入队时间；根据每一帧预览图像帧对应的入队时间，确定相邻两个预览图像帧之间的入队时间间隔；根据入队时间间隔和合成环节遵循的VSync信号周期，确定理论合成时间；根据理论合成时间，确定预览图像帧添加到缓存队列的入队时间是否均匀。

示例性的，此部分的实现可以参见下文针对图8、图12、图13所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据入队时间间隔和合成环节遵循的VSync信号周期，确定理论合成时间，包括：根据接收到的VSync-SF信号对应的时间和VSync-SF信号对应的的VSync信号周期，周期性的检测缓存队列中是否存在预览图像帧，VSync-SF信号用于指示合成环节从缓存队列中获取预览图像帧进行合成处理；对于每一个检测周期对缓存队列的检测，在缓存队列中存在预览图像帧时，对预览图像帧进行合成处理，将本次合成处理的预览图像帧对应的入队时间间隔和预览图像帧合成处理后的首个检测周期检测到的缓存队列中的预览图像帧对应的入队时间间隔之间的差值，作为理论合成时间。

此外，可理解的，在缓存队列中不存在预览图像帧时，在到达下一次周期性检测缓存队列中是否存在预览图像帧的时间时，检测缓存队列中是否存在预览图像帧。

示例性的，此部分的实现可以参见下文针对图8、图12、图13所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，出帧环节指摄像头驱动输出摄像头根据图像预览请求采集的预览图像帧的环节；根据预览图像帧在出帧环节流转的时间信息，确定出现预览卡顿异常时，出帧环节在预览卡顿异常对应的预览图像帧附近输出的预览图像帧是否存在丢帧现象，包括：在预览卡顿异常对应的预览图像帧附近，对于每两个相邻的预览图像帧，获取摄像头驱动输出相邻的两个预览图像帧分别对应的输出时间；根据相邻的两个预览图像帧分别对应的输出时间，确定相邻的两个预览图像帧对应的第一时间间隔；根据第一时间间隔，确定摄像头驱动输出的预览图像帧是否存在丢帧现象。

其中，输出时间为下文针对图8、图9所示部分中的时间戳，第一时间间隔即为根据两个时间戳确定的时间间隔。

示例性的，关于出帧环节的检测，可以参见下文针对图8、图9所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据第一时间间隔，确定摄像头驱动输出的预览图像帧是否存在丢帧现象，包括：确定每两个相邻的预览图像帧对应的第一时间间隔是否相同；在每两个相邻的预览图像帧对应的第一时间间隔相同时，确定摄像头驱动输出的预览图像帧连续；在摄像头驱动输出的预览图像帧连续时，确定摄像头驱动输出的预览图像帧不存在丢帧现象；在每两个相邻的预览图像帧对应的第一时间间隔不相同时，确定摄像头驱动输出的预览图像帧不连续；在摄像头驱动输出的预览图像帧不连续时，确定摄像头驱动输出的预览图像帧存在丢帧现象。

示例性的，此部分的实现可以参见下文针对图8、图9所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，在每两个相邻的预览图像帧对应的第一时间间隔不相同时，方法还包括：确定第一时间间隔是否大于第一时间间隔阈值，第一时间间隔阈值基于摄像头采集预览图像帧时遵循的采样频率确定；在第一时间间隔不大于第一时间间隔阈值时，确定摄像头驱动输出的预览图像帧连续；在第一时间间隔大于第一时间间隔阈值时，确定摄像头驱动输出的预览图像帧不连续。

示例性的，此部分的实现可以参见下文针对图8、图9所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据预览图像帧在送显环节流转的时间信息，确定预览图像帧的送显时间是否均匀，包括：确定每一帧预览图像帧在图像预览界面显示的显示时长；在每一帧图像预览帧对应的显示时长均相同时，确定预览图像帧的送显时间均匀；否则，确定预览图像帧的送显时间不均匀。

示例性的，在一些实现方式中，在每一帧图像预览帧对应的显示时长在设定的范围内波动，或者不大于对应的VSync信号周期时，也可以确定预览图像帧的送显时间均匀。

示例性的，此部分的实现可以参见下文针对图8、图10所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，确定每一帧预览图像帧在图像预览界面显示的显示时长，包括：在接收到第一VSync-HW信号，且从合成环节中获取到第一预览图像帧时，记录当前的***时间，得到第一***时间；在接收到第二VSync-HW信号，且从合成环节中获取到第二预览图像帧时，记录当前的***时间，得到第二***时间；根据第一***时间和第二***时间，确定第一预览图像在图像预览界面显示的显示时长。

示例性的，此部分的实现可以参见下文针对图8、图10所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，根据预览图像帧在合成环节流转的时间信息，确定预览图像帧的合成时间是否均匀，包括：确定每一帧预览图像帧在合成环节的合成时间；在每一帧图像预览帧对应的合成时间均相同时，确定预览图像帧的合成时间均匀；否则，确定预览图像帧的合成时间不均匀。

示例性的，在一些实现方式中，在每一帧图像预览帧对应的合成时间在设定的范围内波动，或者不大于对应的VSync信号周期时，也可以确定预览图像帧的合成时间均匀。

示例性的，此部分的实现可以参见下文针对图8、图11所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，确定每一帧预览图像帧在合成环节的合成时间，包括：在接收到第一VSync-SF信号时，从缓存队列中获取到第一预览图像帧时，记录当前的***时间，得到第三***时间；在第二VSync-SF信号到达前，合成环节对第一预览图像进行合成处理，第二VSync-SF信号是合成环节对第一预览图像帧合成后接收到的首个VSync-SF信号；在接收到第二VSync-SF信号时，记录当前的***时间，得到第四***时间；根据第三***时间和第四***时间，确定每一帧预览图像帧在合成环节的合成时间。

示例性的，此部分的实现可以参见下文针对图8、图11所示部分的描述，此处不再赘述。

根据第一方面，或者以上第一方面的任意一种实现方式，在显示图像预览界面的过程中，方法还包括：监测图像预览界面的刷新频率；在刷新频率大于设定的刷新频率阈值时，确定图像预览界面出现预览卡顿异常。

由此，根据实际的刷新频率实现对图像预览界面预览卡顿异常的监测，使得预览卡顿异常有了标准，而非根据用户感知。

根据第一方面，或者以上第一方面的任意一种实现方式，预览卡顿原因还包括造成预览卡顿异常的预览图像帧，以及预览卡顿异常持续的时间。

由此，能够便于后续根据预览卡顿原因针对具体的预览卡顿异常作出对应的优化处理策略，进而使得优化处理后的效果能够更好的满足用户需求。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：存储预览卡顿异常对应的预览卡顿原因。

由此，可以便于用户(研发人员、测试人员、维修人员等)从第一终端设备中指定路径下获取第一终端设使用拍摄功能时出现的预览卡顿原因，以便根据预览卡顿原因对预览通路上造成预览卡顿异常的处理环节、硬件等进行优化处理。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：响应于接收到的预览卡顿原因请求，将预览卡顿原因输出至第二终端设备，和/或，在第一终端设备的显示界面显示预览卡顿原因。

示例性的，在一些实现方式中，第二终端设备可以为服务端设备，如服务器，也可以为客户端设备，如笔记本电脑、平板电脑、手机等，本申请对此不作限制。

由此，在接收到预览卡顿原因请求后，通过将预览卡顿原因输出，和/或直接显示，从而能够便于用户(研发人员、测试人员、维修人员等)获知第一终端设备中安装的具备拍摄功能的应用在图像预览界面中出现预览卡顿异常的具体原因，从而能够根据预览卡顿原因中记录的造成预览卡顿异常的处理环节或硬件，以及出现预览卡顿异常时对应的预览图像帧、预览卡顿异常持续的时间等，对预览通路上造成预览卡顿异常的处理环节、硬件等进行优化处理。

示例性的，在一些实现方式中，根据预览卡顿原因作出的优化处理，例如可以是调节出帧、合成等节点的帧率、采样频率等，将出帧和合成调节为相同帧率，如下图14至图15示出的场景，或者合成的帧率小于出帧的帧率，从而保证预览界面中画面的流畅性。

示例性的，在另一些实现方式中，在出帧和合成的帧率相同时，根据预览卡顿原因作出的优化处理，例如可以是通过优化返帧均匀性，从而保证预览界面中画面的流畅性。

第二方面，本申请提供了一种终端设备。该终端设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述终端设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的终端设备的硬件结构示意图；

图2为示例性示出的终端设备的软件结构示意图；

图3为示例性示出的预览流送显过程中涉及的功能模块和硬件交互的示意图；

图4为示例性示出的绘制渲染不超时、无丢帧情况下，图像帧与时间之间对应关系的示意图；

图5a至图5c为示例性示出的绘制渲染不超时、无丢帧情况下，显示界面显示内容的变化示意图；

图6为示例性示出的绘制渲染超时、丢帧情况下，图像帧与时间之间对应关系的示意图；

图7a和图7b为示例性示出的绘制渲染超时、丢帧情况下，显示界面显示内容的变化示意图；

图8为示例性示出的确定预览卡顿原因时检测的节点与预览卡顿原因之间关系的示意图；

图9为示例性示出的摄像头驱动输出图像帧的示意图；

图10为示例性示出的部分送显的图像帧与对应的送显时间间隔之间的示意图；

图11为示例性示出的部分图像帧与对应的合成时间之间的示意图；

图12为示例性示出的部分经CameraProvider处理后的图像帧添加到CameraBufferQuene的时间示意图；

图13为示例性示出的对图12所示的返帧曲线转换的返帧曲线的示意图；

图14为示例性示出的部分经CameraProvider处理后的图像帧添加到CameraBufferQuene的时间示意图；

图15为示例性示出的送显的图像帧与对应的送显时间间隔之间的关系示意图；

图16为示例性示出的优化后的送显的图像帧与对应的送显时间间隔之间的关系示意图。

具体实施方式

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

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

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

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个***是指两个或两个以上的***。

为了更好的理解本申请提供的技术方案，在对本申请的技术方案说明之前，首先结合附图对本申请适用于的具有拍摄功能的终端设备(例如手机、平板电脑、可触控PC机等)的硬件结构进行说明。

参见图1，终端设备100可以包括：处理器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，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。

示例性的，在一些实现方式中，传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等，此处不再一一例举，本申请对此不作限制。

基于上述传感器，在使用终端设备的过程中，当用户对显示屏194作出操作，如单击、双击、滑动、不离手滑动时，便可以精准确定当前作出的操作，以及该操作作用于的位置、所在位置的报点信息等。这样，就可以精准确定当前的操作行为作用于的应用对应的图标，如确定用户点击了显示屏194中显示的相机应用的图标，进而启动相机应用，显示相机应用的预览界面。

此外，需要说明的是，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

可理解的，控制器可以是终端设备100的神经中枢和指挥中心。在实际应用中，控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

此外，还需要说明的是，处理器110中还可以设置存储器，用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了***的效率。

示例性的，在一些实现方式中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identitymodule，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

继续参见图1，示例性的，充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实现方式中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实现方式中，充电管理模块140可以通过终端设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为终端设备100供电。

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

继续参见图1，示例性的，终端设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

需要说明的是，天线1和天线2用于发射和接收电磁波信号。终端设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实现方式中，天线可以和调谐开关结合使用。

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

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

继续参见图1，示例性的，无线通信模块160可以提供应用在终端设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星***(global navigation satellitesystem，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near fieldcommunication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

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

继续参见图1，示例性的，显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(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)等。在一些实现方式中，终端设备100可以包括1个或N个显示屏194，N为大于1的正整数。

此外，还需要说明的是，终端设备100可以通过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的正整数。

具体到本申请实施例提供的技术方案中，相机应用或其他具备拍摄功能的三方应用对应的预览界面中显示的画面，即为通过摄像头193采集到，并经图像处理(检测算法处理、色彩调优等)后的图像帧绘制渲染合成的画面。

此外，还需要说明的是，数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当终端设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

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

继续参见图1，示例性的，外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

继续参见图1，示例性的，内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行终端设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作***，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flashstorage，UFS)等。

具体到本申请实施例提供的技术方案中，确定的预览卡顿原因可以以预览卡顿原因的形式，存储在内部存储器121中的指定目录下，以便后续获取使用。

此外，还需要说明的是，终端设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

此外，还需要说明的是，音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实现方式中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

继续参见图1，示例性的，按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。终端设备100可以接收按键输入，产生与终端设备100的用户设置以及功能控制有关的键信号输入。

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

继续参见图1，示例性的，指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

关于终端设备100的硬件结构就介绍到此，应当理解的是，图1所示终端设备100仅是一个范例，在具体实现中，终端设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

为了更好的理解图1所示终端设备100的软件结构，以下对终端设备100的软件结构进行说明。在对终端设备100的软件结构进行说明之前，首先对终端设备100的软件***可以采用的架构进行说明。

具体的，在实际应用中，终端设备100的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。

此外，可理解的，目前主流的终端设备使用的软件***包括但不限于Windows***、Android***和iOS***。为了便于说明，本申请实施例以分层架构的Android***为例，示例性说明终端设备100的软件结构。

此外，后续关于本申请实施例提供的预览卡顿原因的确定方案，在具体实现中同样适用于其他***。

参见图2，为本申请实施例的终端设备100的软件结构框图。

如图2所示，终端设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，将Android***分为五层，从上至下分别为应用程序层(Application，APP)，应用程序框架层(Application Framework，FWK)，安卓运行时(Android runtime)和***库，硬件抽象层(Hardware AbstractionLayer，HAL)，以及内核层(kernel)。

其中，应用程序层可以包括一系列应用程序包。如图2所示，应用程序包可以包括相机、图库、日历、通话、地图、导航、WLAN、蓝牙、视频等应用程序，此处不再一一列举，本申请对此不作限制。

其中，应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。在一些实现方式中，这些编程接口和编程框架可以描述为函数。如图2所示，应用程序框架层可以包括窗口管理器、内容提供器、视图***、摄像头服务、跨进程同步缓存模块、显示合成模块(SurfaceFlinger)等函数，此处不再一一列举，本申请对此不作限制。

需要说明的是，在本实施例中垮进程同步缓存模块具体用于创建BlastBufferQueue(BBQ)。所谓BBQ实质为一个缓冲区(Buffer)，用于在相机应用和SurfaceFlinger之间提供沟通桥梁，实现垮进程沟通，同时提供同步接口，对相机应用向SurfaceFlinger提交的缓存(Buffer)进行同步。

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

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

视图***包括可视控件，例如显示文字的控件，显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

摄像头服务(CameraService)用于响应于相机应用(或其他具备拍摄功能的三方应用)的请求，调用摄像头(包括前置摄像头和/或后置摄像头)，以使相机应用启动后，被调用的摄像头能够持续采集图像帧，并将采集到的图像帧以图像流的形式向上传输至硬件抽象层的摄像头硬件抽象层服务进程(CameraProvider)进行处理。

相应地，CameraProvider会将处理后的图像帧传输给CameraService，由CameraService将接收到的图像帧缓存到相机应用对应的缓存队列。

BBQ用于从相机应用对应的缓存队列中取出需要处理的图像帧，并将取出的图像帧添加到CameraBufferQuene时的时间戳同步给显示合成模块(SurfaceFlinger)，由SurfaceFlinger，进行合成处理。最终，SurfaceFlinger会将合成的内容输出给HAL层中的硬件合成器(HardWare Composer，HWC)，由HWC将合成的内容传输给显示驱动，进而驱动显示屏显示。

Android Runtime包括核心库和虚拟机。Android Runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维(3D)图形处理库(例如：OpenGL ES)，二维(2D)图形引擎(例如：SGL)等。

表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

可理解的，上述所说的2D图形引擎是2D绘图的绘图引擎。

其中，硬件抽象层可包括各种硬件对应的HAL，例如音频模块对应的音频HAL，传感器模块对应的传感器HAL、显示屏对应的显示HAL等。具体到本实施例中，针对拍摄内容的图像处理，需要涉及与摄像头相关的HAL，如图2所示的摄像头硬件抽象层服务进程，即CameraProvider，以及上文所说的用于接收SurfaceFlinger合成的内容的硬件合成器(HWC)和虚拟信号生成模块。

CameraProvider用于根据当前选中的拍摄模式对应的检测算法，对摄像头采集到的图像帧进行检测处理，如人脸检测、场景检测、物体检测、笑脸检测等，此处不再一一列举，本实施例对此不作限制。

虚拟信号生成模块(后续用DispSync表示)用来根据硬件合成器生成的垂直同步(vetical synchronization，VSync)信号(硬件VSync信号，VSync-HW信号)，为相机应用分配对应的软件信号，具体为VSync-APP信号，以及为SurfaceFlinger分配对应的软件信号，具体为VSync-SF信号。关于VSync-HW信号、VSync-APP信号和VSync-SF信号的用途，详见下文针预览流送显流程的描述部分，此处不再赘述。

继续参见图2，示例性的，Android***中的内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动等。

示例性的，摄像头驱动可用于将相机应用通过CameraService下发的图像预览请求下发给摄像头，进而驱动摄像头根据持续下发的图像预览请求采集图像帧。

示例性的，摄像头驱动还可用于将摄像头持续上报的原始图像流传输给HAL层中的CameraProvider进行处理。

示例性的，显示驱动用于驱动显示屏显示硬件合成器合成的图像。

关于终端设备100的软件结构就介绍到此，可以理解的是，图2示出的软件结构中的层以及各层中包含的部件，并不构成对终端设备100的具体限定。在本申请另一些实施例中，终端设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

为了便于理解，示例性的给出部分与本申请实施例相关概念的说明以供参考。

1、帧：是指界面显示中最小单位的单幅画面。一帧可以理解为一副静止的画面，快速连续地显示多个相连的帧可以形成物体运动的假象。

2、帧率：是指在1秒钟时间里刷新图片的帧数，也可以理解为终端设备中图形处理器每秒钟刷新画面的次数。高的帧率可以得到更流畅和更逼真的动画。每秒钟帧数越多，所显示的动作就会越流畅。

需要说明的是，界面显示帧前通常需要经过绘制、渲染、合成等过程。

3、帧绘制：是指显示界面的图片绘制。显示界面可以由一个或多个视图组成，各个视图可以由视图***的可视控件绘制，各个视图由子视图组成，一个子视图对应视图中的一个小部件，例如，其中的一个子视图对应图片视图中的一个符号。

4、帧渲染：是将绘制后的视图进行着色操作或增加3D效果等。例如：3D效果可以是灯光效果、阴影效果和纹理效果等。

5、帧合成：是将多个上述一个或多个渲染后的视图合成为显示界面的过程。

6、垂直同步(vetical synchronization，VSync)信号：用于控制帧的绘制渲染、合成、送显等进程起始的信号。

需要说明的是，为了保证显示的流畅性，避免出现显示卡顿等现象，终端设备一般基于VSync信号进行显示，以对图像的绘制、渲染、合成和屏幕刷新显示等流程进行同步。

可以理解的是，VSync信号为周期性信号，VSync信号周期可以根据屏幕刷新率进行设置，例如，屏幕刷新率为60Hz时，VSync信号周期可以为16.6ms，即终端设备每间隔16.6ms生成一个控制信号使VSync信号周期触发。还例如，屏幕刷新率为90Hz时，VSync信号周期可以为11.1ms，即终端设备每间隔11.1ms生成一个控制信号使VSync信号周期触发。

此外，还需要说明的是，VSync信号包括软件VSync信号，如上文所说的VSync-APP信号和VSync-SF信号，以及硬件VSync信号，如上文所说的VSync-HW信号。其中，VSync-APP用于触发绘制渲染流程；VSync-SF用于触发合成流程。VSync-HW用于触发屏幕显示刷新流程。通常情况下，软件VSync和硬件VSync保持周期同步。以60Hz和120Hz变化为例，若VSync-HW信号从60Hz切换到120Hz，VSync-APP信号、VSync-SF信号同步变化，从60Hz切换到120Hz。

下面以具备拍摄功能的应用为终端设备自带的相机应用为例，对预览流送显过程进行说明。

参见图3，示例性的，在接收到作用于相机应用的操作行为，响应于该操作行为，启动相机应用的过程中，会在创建相机应用对应的进程(后续描述为相机进程)，实例化CameraService、相机应用对应的缓存队列(CameraBufferQuene)、BBQ、SurfaceFlinger、CameraProvider、HWC、DispSync等，并在相机进程中创建需要显示的控件的图层，如图3中控件1、控件2、控件3、控件4等的图层。

继续参见图3，示例性的，HWC根据频率刷新频率，周期性的生成VSync-HW信号，DispSync则根据周期性生成的VSync-HW信号，为相机应用对应的用户界面(UserInterface，UI)线程分配对应的VSync-APP信号，并周期性的将生成的VSync-APP信号发送给相机应用的UI线程，以便该UI线程能够在接收到VSync-APP信号后，触发绘制渲染处理，如对控件1、控件2、控件3、控件4等的绘制渲染。

继续参见图3，示例性的，DispSync还会根据周期性生成的VSync-HW信号，为SurfaceFlinger分配对应的VSync-SF信号，并周期性的将生成的VSync-SF信号发送给SurfaceFlinger，以便SurfaceFlinger能够在接收到VSync-SF信号后，通过BBQ从CameraBufferQuene中获取图像帧’，进而对获取到的图像帧’进行合成处理。

继续参见图3，示例性的，关于CameraBufferQuene中缓存的图像帧’，具体是由CameraProvider对摄像头采集到的原始图像流中的图像帧进行处理后图像帧。关于原始图像流的采集，例如为由摄像头根据相机应用生成的图像预览请求，如图3中的Request持续采集得到的。

示例性的，关于图像预览请求的生成，例如可以是在相机应用启动后，由相机应用根据当前所处的拍摄模式生成的。

可理解的，不同的拍摄模式对应的检测算法、图像处理逻辑可能不同，因此根据拍摄模式生成图像预览请求，在将图像预览请求经CameraService传输至CameraProvider时，CameraProvider能够获知对摄像头根据该图像预览请求采集到的原始图像流中的图像帧进行哪些检测和处理。

继续参见图3，示例性的，CameraProvider接收到CameraService传输的图像预览请求后，会将该图像预览请求传输给摄像头驱动，进而由摄像头驱动将该图像预览请求下发给摄像头，并驱动摄像头根据持续下发的图像预览请求(Request)采集图像帧。

继续参见图3，示例性的，摄像头根据持续下发的图像预览请求(Request)采集到图像帧后，便会向摄像头驱动持续上报原始图像流中的图像帧，进而由摄像头驱动按照固定的帧率，将图像帧传输给CameraProvider，由CameraProvider对图像帧进行相应的检测和处理。

示例性的，以当前选中的拍摄模式为人像模式为例，则如果人像模式对应的检测算法涉及人脸检测算法时，则CameraProvider会基于人脸检测算法对图像帧进行人脸检测，进而确定当前处理的图像帧中人脸的特征点信息，如人脸所在位置的坐标信息，以便根据确定的坐标信息将人脸使用设定的形状框出。相应地，最终框出人脸的图像帧即为图3中所示的图像帧’。

示例性的，CameraProvider将处理后的图像帧’传输至CameraService，由CameraService将图像帧’添加到CameraBufferQuene，即图3中的queue操作。

通过上述描述可知，SurfaceFlinger对CameraBufferQuene中缓存的图像帧’进行合成处理，是基于DispSync周期性生成的VSync-SF信号触发的。故而，SurfaceFlinger在接收到VSync-SF信号后，便会通过BBQ从CameraBufferQuene中获取缓存的图像帧’，即图3中的acquire操作，而BBQ也会将每一次获取到的图像帧’添加到CameraBufferQuene时的时间戳同步给SurfaceFlinger，即图3中的Apply/setTransactionState操作。

继续参见图3，示例性的，如果SurfaceFlinger通过BBQ从CameraBufferQuene中获取到缓存的图像帧’，则对该图像帧’进行合成处理，得到该图像帧’对应的合成图像，并将得到的合成图像传输给HWC。同时，SurfaceFlinger会发送销毁(图3中的release)该图像帧’的指令给BBQ，BBQ将该销毁指令传输给CameraBufferQuene，CameraBufferQuene通知CameraService调用dequeue函数，将CameraBufferQuene中缓存的该图像帧’删除。

可理解的，dequeue函数是用于移除每个匹配元素的指定队列中的第一个函数，并执行被移除的函数，即将位于队首的图像帧’删除。而SurfaceFlinger通过BBQ从CameraBufferQuene获取缓存的图像帧’时，是从队首获取，因此在合成图像后，按照上述方式调用dequeue函数，便可以将已经使用过的图像帧’从CameraBufferQuene中删除。

继续参见图3，示例性的，HWC会将SurfaceFlinger下发的合成图像送往显示驱动，由显示驱动去驱动显示屏显示合成图像对应的画面。

示例性的，以相机应用中的控件1为显示预览图像的表面视图(Surface View)控件为例，则最终会在显示屏中显示的控件1中显示按照上述处理得到的画面。

可理解的，通过上述描述可知，SurfaceFlinger线程(SF线程)对图像帧’进行的合成操作是基于VSync-SF信号触发的，显示驱动最终驱动显示屏显示图像帧’对应的画面的操作是基于VSync-HW信号触发的，而这两个信号之间间隔的时长通常为固定的，如一个VSync信号周期。参见图4，示例性的，假设t1至t8任意相邻的两个时间点之间的时间间隔均相同，如为一个VSync信号周期。如果在t1～t8每一个时间点，SF线程都接收到了VSync-SF信号，则会通过BBQ获取对应的图像帧’进行合成。

继续参见图4，示例性的，在不存在丢帧，每一帧的合成时间都在固定时间内完成，如在一个VSync信号周期内完成的情况下，如[t1，t2)时长内，完成了对帧1的合成处理，在[t2，t3)时长内，完成了对帧2的合成处理，在[t3，t4)时长内，完成了对帧3的合成处理，在[t4，t5)时长内，完成了对帧4的合成处理，在[t5，t6)时长内，完成了对帧5的合成处理，在[t6，t7)时长内，完成了对帧6的合成处理，在[t7，t8)时长内，完成了对帧7的合成处理等。当滞后VSync-SF信号一个VSync信号周期后，在t2时间点会接收到一个VSync-HW信号，此时由于SF线程已经对帧1完成了合成处理，故而硬件合成器会从SF线程出接收到合成的帧1，进而输送给显示驱动去送显，即显示驱动会驱动显示屏在[t2，t3)这一VSync信号周期内显示帧1对应的画面。

继续参见图4，示例性的，在t3时间点会接收到下一个VSync-HW信号后，此时由于SF线程已经对帧2完成了合成处理，故而硬件合成器会从SF线程出接收到合成的帧2，进而输送给显示驱动去送显，即显示驱动会驱动显示屏在[t3，t4)这一VSync信号周期内显示帧2对应的画面。基于该原则，显示驱动会驱动显示屏在[t4，t5)这一VSync信号周期内显示帧3对应的画面，在[t5，t6)这一VSync信号周期内显示帧4对应的画面，在[t6，t7)这一VSync信号周期内显示帧5对应的画面，在[t7，t8)这一VSync信号周期内显示帧6对应的画面等。对应到终端设备(以手机为例)的显示界面，其变化如图5a至5c所述。

参见图5a中(1)，示例性的示出一个手机的界面10a。本实施例以界面10a为手机的桌面为例，示例性的界面10a上可以显示一个或多个应用程序的图标，如时钟应用的图标、日历应用的图标、图库应用的图标、备忘录应用的图标、文件管理应用的图标、电子邮件应用的图标、音乐应用的图标、计算器应用的图标、视频应用的图标、录音机应用的图标、天气应用的图标、浏览器应用的图标、设置应用的图标、通讯录应用的图标、电话应用的图标、信息应用的图标、相机应用的图标(控件)10a-1等。其中，当用户点击界面10a中的控件10a-1时，即可使用相机应用实现拍摄功能。

继续参见图5a中(1)，示例性的，当用户点击界面10a中的控件10a-1时，手机响应于该操作行为，识别出用户点击操作对应的控件为相机应用的控件10a-1，进而调用应用框架层中相应的接口启动相机应用，并通过调用内核层的摄像头驱动来驱动摄像头获取(采集)图像。此时，手机会从界面10a切换到图5a中(2)所示的界面10b。

参见图5a中(2)，示例性的，界面10b中可以包括一个或多个控件，如用于显示预览图像的控件10b-1、用于触发拍摄的控件10b-2、用于切换前后摄像头的控件10b-3，用于选中拍摄模式的控件10b-4。

继续参见图5a中(2)，示例性的，控件10b-4中可以提供一种或多组拍摄模式，如光圈模式、夜景模式、人像模式、拍照模式、录像模式、笑脸模式等。

示例性的，如果还有其他的拍摄模式，在控件10b-4的可是区域内无法显示全部拍摄模式时，可以提供一个“更多”选项，当用户操作该选项时，手机响应于该操作行为，可以在控件10b-4上弹出一个选择列表，以供用户滑动选择其他拍摄模式。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，其用户界面形式可以根据需要进行设置，此处不作限制。

示例性的，在启动相机应用后，如果SF线程按照上述描述，分别在[t1，t2)时间内完成了对帧1的合成，在[t2，t3)时间内完成了对帧2的合成，在[t3，t4)时间内完成了对帧3的合成，在[t4，t5)时间内完成了对帧4的合成，在[t5，t6)时间内完成了对帧5的合成，在[t6，t7)时间内完成了对帧6的合成，在[t7，t8)时间内完成了对帧7的合成，正常情况下，在[t2，t3)时间内，用于显示预览图像的控件10b-1中会显示帧1对应的画面1，如图5a中(2)所示。相应地，在[t3，t4)时间内，用于显示预览图像的控件10b-1中会显示帧2对应的画面2，如图5b中(1)所示。相应地，在[t4，t5)时间内，用于显示预览图像的控件10b-1中会显示帧3对应的画面3，如图5b中(2)所示。相应地，在[t5，t6)时间内，用于显示预览图像的控件10b-1中会显示帧4对应的画面4，如图5c中(1)所示。相应地，在[t6，t7)时间内，用于显示预览图像的控件10b-1中会显示帧5对应的画面5，如图5c中(2)所示。由此，实现了预览图像在相机应用的预览界面的显示。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

然而图4、图5a至图5c示出的仅仅是理想状态下，即不存在丢帧、合成过程过程不超时的情况下。但是，随着用户对拍摄需求的不断提高，拍摄像素的提升，以及拍摄模式涉及的检测、处理环节的增加，会增加图像处理过程的时长，导致送显示时间不均匀，甚至终端设备使用过程中，摄像头、显示屏等硬件的损坏，也会造成图像帧的传输、显示不稳定，从而导致预览界面出现卡顿。

如图6所示，示例性示出一种SF线程合成超时，以及丢帧情况下，SF线程和显示驱动处理图像帧的示意图。仍以t1至t8任意相邻的两个时间点之间的时间间隔均相同，如为一个VSync信号周期为例。其中，在[t1，t2)时间内，SF线程正常合成了帧1，在[t2，t3)时间内，SF线程正常合成了帧2，但是在[t3，t4)时间内，帧3没有合成完，在t4时间点后，t5时间点前才完成对帧3的合成，故而导致原本应该在t4时间点开始合成的帧4丢失，后续帧5，帧6，帧7的合成如图4所示，正常处理。

示例性的，对于图6所示的SF线程对图像帧’的合成处理，

如果SF线程按照图6所示，分别在[t1，t2)时间内完成了对帧1的合成，在[t2，t3)时间内完成了对帧2的合成，在[t3，t5)时间内完成了对帧3的合成，在[t5，t6)时间内完成了对帧5的合成，在[t6，t7)时间内完成了对帧6的合成，在[t7，t8)时间内完成了对帧7的合成，在[t2，t3)时间内，用于显示预览图像的控件10b-1中会显示帧1对应的画面1，如图7a中(1)所示。在[t3，t4)时间内，用于显示预览图像的控件10b-1中会显示帧2对应的画面2，由于在t4时间点接收到VSync-HW信号时，SF线程还没有对帧3完成合成处理，因此在[t4，t5)时间内，用于显示预览图像的控件10b-1中依旧会显示帧2对应的画面2，即在[t3，t5)时间内，用于显示预览图像的控件10b-1中显示的均为帧2对应的画面2，如图7a中(2)所示。

继续参见图6，示例性的，在t5时间点接收到VSync-SF信号时，由于已经完成了对帧3的合成处理，因此SF线程在t5时间点会开始对帧5进行合成处理。相应地，显示驱动则可以在t5时间点获取到SF线程合成的帧3对应的画面4，并驱动显示屏在[t5，t6)时间内显示帧3对应的画面。

继续参见图6，示例性的，由于SF线程在[t5，t6)时间内完成了对帧5的合成处理，故而显示驱动可以在t6时间点获取到SF线程合成的帧5对应的画面5，并驱动显示屏在[t6，t7)时间内显示帧5对应的画面。

也就是说，图6、图7a、图7b所示场景下，在界面10b中控件10b-1中显示的画面会出现卡顿(帧2对应的画面持续了两个VSync信号周期)，以及跳变(从画面3跳变到了画面5)。但是，由于对视频预览和拍照预览的效果，目前并没有具体的量化的标准，大多是通过主观感受给一个评价，这就导致不同的人对同一个预览图像有不同的观点，导致上述问题在测试、研发、生产等阶段没有被及时发现，进而导致存在上述问题的终端设备、相机应用被投入市场，进而影响消费者的使用体验。

有鉴于此，本申请提供了一种预览卡顿原因的确定方法，通过从摄像头出帧(采集到图像帧通过摄像头驱动输送给CameraProvider)到显示屏最终显示各个处理节点进行检测量化，然后根据各个处理节点的量化结果来确定造成画面卡顿、跳变的原因，保证确定的预览卡顿原因的精准度，从而能够在产品发布前根据精准的预览卡顿原因制定优化策略，进行优化处理，以减少卡顿提升流畅度，提升用户体验。

此外，基于本申请实施例提供的预览卡顿原因的确定方法，在产品发布后的售后环节，售后人员也可以根据该方式确定的精准的预览卡顿原因，及时定位问题，对终端设备进行维修，或对具备拍摄功能的相机应用、终端设备的***进行更新迭代。

通过图3所示的预览流送显流程的描述可知，图像帧从采集到最终显示在预览界面中，主要涉及了最开始摄像头将采集到的图像帧通过摄像头驱动传输给CameraProvider的处理环节(后续称为：出帧环节)、CameraProvider对原始的图像帧进行处理的环节，并将经CameraProvider处理后的图像帧通CameraService添加到CameraBufferQuene的处理环节(后续称为：缓存环节)、由SurFaceFlinger通过BBQ从CameraBufferQuene取出图像帧’进行合成的环节(后续称为：合成环节)、由硬件合成器将SurFaceFlinger合成的画面传输给显示驱动，进而驱动显示屏显示合成的画面的环节(后续称为送显环节)。故而，本申请实施例提供的预览卡顿原因的确定方法，主要从这4个环节出发确定造成预览界面出现画面卡顿、跳变的预览卡顿原因。即，预览卡顿原因的确定，主要通过对出帧环节检测、缓存环节检测、送显环节检测、合成环节检测这4个环节的检测量化的结果确定。

参见图8，示例性示出一种针对上述4个环节进行检测，确定预览卡顿原因的示意图。

示例性的，关于出帧环节检测，具体是判断是否丢帧。

需要说明的是，摄像头是按照固定的采样频率采样(如30fps)，是绝对均匀的，如果采样的图像帧没有被摄像头驱动及时取走传输给CameraProvider，就会导致在后的图像帧覆盖已有但未被取走的图像帧，这就会导致丢帧。而出现丢帧后，即便后续环节均正常处理，由于缺失了图像帧，预览界面显示的预览图像也会出现画面卡顿的问题。如图9所示，如果相机应用在T1时刻下发了获取预览图像的请求Request1，当Request1到达Kernel层的摄像头驱动后，摄像头驱动会驱动摄像头根据Request1，按照固定的采样频率采集图像帧，并将采集到的图像帧输出至HAL层的CameraProvider进行处理。

继续参见图9，示例性的，摄像头驱动将当前采集到的帧1输出至CameraProvider后，会继续按照固定的采集频率采集图像帧，如帧2、帧3等。而在持续采集图像帧的过程中，CameraProvider会基于当前拍摄模对应的检测算法、图像处理算法等对摄像头驱动传输来的帧1进行检测和处理，并将处理后的帧1(后续称为；帧1’)传输给FWK层的CameraService，由CameraService将帧1’添加到CameraBufferQuene中，后续SF线程在接收到VSync-SF信号后，便会通过BBQ将CameraBufferQuene中的帧1’同步到BBQ，将帧1’传输给SF线程进行合成处理。

继续参见图9，示例性的，SF线程在完成对帧1’的合成处理后，会将合成处理后的帧1’传输给硬件合成器，进而由硬件合成器传输给显示驱动，由显示驱动去驱动显示屏显示帧1’对应的画面，即相机应用的预览界面中会显示帧1’对应的画面。

继续参见图9，示例性的，在摄像头驱动输出帧1后，至合成处理后的帧1’对应的画面显示在相机应用的预览界面的期间，摄像头按照固定的采样频率采集并向摄像头驱动上传了帧2，但是在摄像头驱动接收到帧后，由于没有接收到新的预览图像请求，如Request2。因此不会将帧2传输给CameraProvider，而在接收到Request2时，由于接收到了帧3，因此帧2会被丢弃，在接收到Request2后，会将帧3传输至CameraProvider进行处理，最终经SF进行合成处理后送显。

基于这一原则，通过对摄像头驱动输出的图像帧进行连续性的判断，便可以确定出帧环节是否丢帧。

相应地，如果确定出现了丢帧现象，则可以确定造成画面卡顿的预览卡顿原因至少是因为摄像头驱动丢帧导致卡顿(显示不流畅)；反之，如果没有出现丢帧现象，则表明画面卡顿与摄像头驱动无关，即出帧环节不存在问题。

示例性的，关于摄像头驱动输出的图像帧的连续性的判断，在一些实现方式中可以通过相邻两次输出的图像帧的时间戳，以及摄像头所遵循的采样频率确定。

可理解的，摄像头驱动每次输出图像帧时，会为图像帧添加对应的时间戳，而摄像头所遵循的采样频率是固定的，因此摄像头输出上传至摄像头驱动的图像帧中，任意相邻两帧之间的时间间隔是固定的，以T为例。故而，通过获取摄像头驱动每次传输图像帧至CameraProvider时，为传输的图像帧添加的时间戳，即当前传输的图像帧的时间戳current_time，以及该图像帧之前传输的与其相邻的图像帧对应的时间戳history_time。然后判断history_time与current_time之间的时间间隔T’是否大于T。

相应地，如果大于T，则认为current_time与history_time之间丢失了一帧或几帧图像帧。反之，则认为出帧环节不存在丢帧现象，故而当前出现的画面卡顿与摄像头驱动无关。

继续参见图8，示例性的，在不存在丢帧情况，即出帧环节不存在问题时，可以进一步对送显环节进行检测。示例性的，关于送显环节检测，例如可以是通过判断送显时间是否均匀。

示例性的，在一些实现方式中，在出帧环节无问题的情况下，可以记录硬件合成器将SF进程合成的图像帧输送至显示驱动，由显示驱动去驱动显示屏显示每一帧图像帧的显示时长，进而通过送显的图像帧对应的显示时长确定送显示时间是否均匀。

参见图10，示例性示部分送显的图像帧与对应的送显时间间隔之间的示意图。示例性的，图10中横坐标为送显的图像帧，纵坐标为送显时间间隔(单位例如为ms)。其中，第19帧、第82帧、第172帧，即帧19、帧82、帧172对应的送显时间间隔大约在66.66ms，其他帧对应的送显时间间隔则大约在33.33ms。

可理解的，如果图像帧与对应的送显时间间隔之间的示意图中示出的为一条直线，如所有图像帧对应的送显时间间隔都在33.33ms，则表明送显是均匀的，即送显环节不存在问题。反之，如果图像帧与对应的送显时间间隔之间的示意图中示出的不是一条直线，如图10所示，帧19、帧82、帧172这三帧的送显时间间隔要大于正常的33.33ms，则表明当前预览界面中显示画面在这三帧时出现了卡顿。对于这种情况，想要确定预览卡顿原因是否是因为显示屏这一硬件导致的，在出帧环节正常的情况下，则需要进一步对合成环节进行检测。

具体的，若送显环节对应的图像帧与对应的送显时间间隔之间的示意图中出现卡顿的帧与合成环节对应的图像帧与对应的合成时间之间的示意图中出现卡顿的帧不相同，对于仅在图像帧与对应的送显时间间隔之间的示意图中出现卡顿的帧对应的预览卡顿原因则来自显示屏。即图8中，对于送显时间均匀的情况下，在满足该情况时，预览卡顿原因来自显示屏。

继续参见图8，示例性的，在送显时间不均匀的情况下，可以进一步对合成环节进行检测。示例性的，关于合成环节检测，例如可以是通过判断合成时间是否均匀。

示例性的，在一些实现方式中，在出帧环节和送显环节均无问题的情况下，可以记录SF线程对每一帧图像帧进行合成处理的合成时间，进而通过合成的图像帧对应的合成时间确定合成时间是否均匀。

参见图11，示例性示部分图像帧与对应的合成时间之间的示意图。示例性的，图11中横坐标为进行合成处理的图像帧，纵坐标为合成时间(单位例如为ms)。其中，第80帧、第169帧，即帧80、帧169对应的合成时间大约在66.66ms，其他帧对应的合成时间在30ms～40ms之间，大约趋于33.33ms。

可理解的，如果图像帧与对应的合成时间之间的示意图中示出的为一条直线，如所有图像帧对应的送显时间间隔都在30ms～40ms之间，并趋于33.33ms，则表明合成是均匀的，即合成环节不存在问题。反之，如果图像帧与对应的合成时间之间的示意图中示出的不是一条直线，如图11所示，帧80、帧169这两帧的合成时间不在正常的合成时间区间如30ms～40ms之间，则表明当前预览界面中显示画面在这两帧时出现了卡顿。通过图10和图11的对比可以发现，图10中出现卡顿的帧与图11中出现卡顿的帧均不相同，因此可以确定图10中所示的帧19、帧82、帧172这三帧导致的预览卡顿原因是来自显示屏。

示例性的，如果图10所示的送显环节对应的图像帧与对应的送显时间间隔之间的示意图中出现卡顿的帧与图11中合成环节对应的图像帧与对应的合成时间之间的示意图中出现卡顿的帧相同，在送显时间均匀的情况下，当前预览界面中显示画面出现卡顿的问题，就不来自显示屏，即表明显示屏是正常的。

继续参见图11，示例性的，由于图11中出现卡顿的帧与图10中出现卡顿的帧不相同，对于这种情况，想要确定图11中帧80、帧169这两帧的预览卡顿原因是否来自合成环节，需要进一步对缓存队列进行检测。

继续参见图8，示例性的，在合成时间不均匀的情况下，可以进一步对缓存队列进行检测。示例性的，关于缓存队列检测，例如可以通判断缓存队列中图像帧的入队时间是否均匀。

需要说明的是，由于BBQ是用于将CameraBufferQuene中的图像帧同步给SF线程的，即将BBQ从CameraBufferQuene获取到，并同步给SF线程的图像帧的信息与该图像帧添加到CameraBufferQuene时的一样。因此CameraBufferQuene是HAL层中的CameraProvider经CameraService返帧给SF线程的最后一个缓存队列。故而，在一些实现方式中，在出帧环节、送显环节无问题，但合成环时间不均匀的情况下，可以记录缓存环节，即经CameraProvider处理输出的至CameraBufferQuene的入队时间，即在将CameraProvider处理后经CameraService添加至CameraBufferQuene时，为每一个图像帧添加到的时间戳。由于该时间戳会被BBQ同步给SF线程，因此通过判断CameraBufferQuene中相邻两个图像帧的入队时间之间的入队时间间隔，即判断每两帧图像帧各自对应的入队时间间隔是否均匀，就可以确定到在出现预览卡顿异常时，在经过上述判断确定合成时间不均匀的情况下，造成合成时间不均匀的原因究竟是合成环节的问题，还是返帧问题。

可理解的，由于不同拍摄模式下对应的检测算法、图像处理算法不同，另外拍摄对象的不同，故而经CameraProvider处理的时间长短也不同，因此不同的图像帧经CameraProvider处理后输出，添加到CameraBufferQuene的时间也不相同。如图12所示，示例性示出部分经CameraProvider处理后的图像帧添加到CameraBufferQuene的时间示意图。示例性的，图12中横坐标为经CameraProvider处理后添加到CameraBufferQuene的图像帧，纵坐标为添加到CameraBufferQuene的每一帧与其相邻的在前一帧的时间间隔，即入队时间间隔(单位例如为ms)。

继续参见图12，不难发现，由于CameraProvider对每一帧图像帧处理所需的时长不同，导致添加到CameraBufferQuene的入队时间间隔也不相同。因此，从图12所示的返帧曲线上很难看出对合成流程的影响。故而，在一些实现方式中，可以对图12所示的返帧曲线进行拟合处理，以得到类似图10、图11所示样式的返帧曲线。

示例性的，关于对图12所示的返帧曲线进行的拟合处理，例如可以是在SF线程接收到VSync-SF信号(将该VSync-SF信号看作第一VSync-SF信号)时，根据当前接收到VSync-SF信号对应的时间，以及VSync-SF信号所遵循的下发周期，如一个VSync信号周期，周期性的检测CameraBufferQuene中是否有待处理的图像帧，即通过BBQ获取CameraBufferQuene中缓存的图像帧时，先判断CameraBufferQuene中是否有待处理的图像帧。

相应地，如果CameraBufferQuene中有待处理的图像帧，则在当前VSync-SF信号对应的合成周期内，即接收到下一个VSync-SF信号(根据第一VSync-SF信号和固定的VSync信号周期确定，后续称为第二VSync-SF信号)前，通过BBQ从CameraBufferQuene中取出位于队首的图像帧进行合成处理，并在处理完该图像帧后，在到达第二VSync-SF信号时，若检测到CameraBufferQuene中存在待处理的图像帧，则将第一VSync-SF信号时检测到的图像帧对应的入队时间间隔和第二VSync-SF信号时检测到的图像帧对应的入队时间间隔之间的差值，作为第一VSync-SF信号时检测到的图像帧对应的理想合成时间。

相应地，在完成对第一VSync-SF信号时检测到的图像帧的合成处理后，上述第二VSync-SF信号可以作为新的第一VSync-SF信号，而在该新的第一VSync-SF信号后，根据上述处理逻辑，满足上述合成条件时的VSync-SF信号则可以看作新的第二VSync-SF信号。基于这一处理逻辑，就可以将图12所示的返帧曲线转换为如图13所示的返帧曲线。

参见图13，示例性的，横坐标为经CameraProvider处理后添加到CameraBufferQuene的图像帧，纵坐标为上述所说的理想合成时间(单位例如为ms)。其中，第80帧、第169帧，即帧80、帧169对应的理想合成时间大约在66.66ms，其他帧对应的理想合成时间在30ms～40ms之间，大约趋于33.33ms。

可理解的，如果图像帧与对应的理想合成时间之间的示意图中示出的为一条直线，如所有图像帧对应的理想合成时间都在30ms～40ms之间，并趋于33.33ms，则表明图像帧添加到CameraBufferQuene的时间是均匀的，这种情况下，如果存在画面卡顿，表明合成环节存在问题。反之，如果图像帧与对应的理想合成时间之间的示意图中示出的不是一条直线，如图13所示，帧80、帧169这两帧的理想合成时间不在正常的区间如30ms～40ms之间，则表明图像帧添加到CameraBufferQuene的时间是不均匀的，这种情况下下，如果存在画面卡顿，表明卡顿是返帧造成的，即缓存环节中，CameraProvider输出的图像帧有问题。通过图11和图13的对比可以发现，图11中出现卡顿的帧与图13中出现卡顿的帧相同，因此可以确定图11中所示的帧80、帧169这两帧导致的卡顿并非合成环节造成，因此合成环节对应的图11与图13中出现卡顿的帧相同，即表明这两帧出现的卡顿是因为图像帧添加到CameraBufferQuene的时间不均匀导致的，即是返帧问题的原因。

示例性的，如果图13示出的返帧曲线为一条直线，即在图像帧添加到CameraBufferQuene的时间均匀的情况下，图11中所示的帧80、帧169这两帧导致的卡顿就是合成环节自身的问题，与缓存环节无关，即不是返帧造成的。

由此，通过对上述4个环节进行检测，以图表的形式量化每一个环节中出现的卡顿位置(出现卡顿时的图像帧)，以及同一卡顿位置的预览卡顿原因，基于上述4个环节的在预览流送显流程中的对图像帧的处理顺序，可以快速、准确的追溯到源头，对于某一环节中新增的卡顿位置，则可以确定该帧造成的预览卡顿原因来自该环节，从而实现了对每一次卡顿对应的预览卡顿原因的精准确定。

进一步地，基于本申请实施例提供的预览卡顿原因的确定方法，在确定预览卡顿原因后，可以根据预览卡顿原因对预览流送显示过程中造成卡顿的环节进行优化处理。

示例性的，以出帧环节，即摄像头驱动输出图像帧的频率为30fps，合成环节，即SF线程合成处理时遵循的图像帧采样频率为60fps的情况下，经CameraProvider处理后，经CameraService添加到CameraBufferQuene的图像帧与对应的时间(返帧曲线)如图14所示。

示例性的，在出帧的频率为30fps，合成的频率为60fps的情况下，送显的图像帧与对应的送显时间间隔之间的关系可以如图15所示。

基于图14和图15所示，在出帧的频率为30fps，合成的频率为60fps的情况下，会因为合成的频率和出帧的频率不匹配。故而，在确定预览卡顿原因是来自出帧环节和合环节，且是因为二者的频率不匹配造成画面卡顿的情况下，在一些实现方式中，可以将合成的评论从60fps修改为30fps。这样，基于本申请实施例提供的预览卡顿原因的确定方法，重新获取送显的图像帧与对应的送显时间间隔之间的关系例如图16所示。

可理解的，通过上述对送显环节检测的描述可知，在送显的图像帧与对应的送显时间间隔之间的关系的示意图中示出的为一条直线时，表明当前环节不存在卡顿帧，故而显示在预览界面的画面不会出现卡顿，画面时流畅的。

也就是说，根据上述预览卡顿原因，通过将出帧的频率和合成的频率保持一直，能够解决返帧小幅度波动引起的合成不均匀现象。

此外，需要说明的是，图14、图15，以及图16中，横坐标均为图像帧的帧数，纵坐标均为对应的时间。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

示例性的，在另一些实现方式中，在出帧的频率为30fps，合成的频率也为30fps的情况下，如果按照本申请实施例提供的预览卡顿原因的确定方法，确定返帧间隔为0ms，33.33ms，67.6ms等，由于返帧波动较大，因此在这种返帧间隔下，即便出帧的频率和合成的频率一致，依旧会出现合成不均匀的现象。假设每一个VSync信号的周期为33.33ms，对于上述返帧间隔，在第三个VSync信号周期内，由于第三个图像帧的返帧间隔为67.6ms，超过了66.66ms，因此会导致第三个图像帧在第四个VSync信号周期内合成，这就操作显示卡顿。由于该卡顿是的预览卡顿原因是返帧不均匀，导致合成不均匀，即缓存环节中出现的返帧问题，因此基于确定的预览卡顿原因，可以对CameraProvider进行优化，如对摄像头驱动输出的图像帧进行降采样处理，即降低分辨率(尺寸大小)，仅保留关键信息，然后对降采样后的图像帧进行对应的检测和图像处理，这样就可以降低图像帧的计算量，从而保证图像帧能够在固定的周期内处理完，进而保证返帧间隔均匀。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

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

此外，需要说明的是，在实际的应用场景中由终端设备实现的上述各实施例提供的预览卡顿原因的确定方法，也可以由终端设备中包括的一种芯片***来执行，其中，该芯片***可以包括处理器。该芯片***可以与存储器耦合，使得该芯片***运行时调用该存储器中存储的计算机程序，实现上述终端设备执行的步骤。其中，该芯片***中的处理器可以是应用处理器也可以是非应用处理器的处理器。

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在终端设备上运行时，使得终端设备执行上述相关方法步骤实现上述实施例中的预览卡顿原因的确定方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在终端设备上运行时，使得终端设备执行上述相关步骤，以实现上述实施例中的预览卡顿原因的确定方法。

另外，本申请的实施例还提供一种芯片(也可以是组件或模块)，该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的预览卡顿原因的确定方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

此外，通过上述描述可知，本申请实施例提供的终端设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (17)

1.一种预览卡顿原因的确定方法，其特征在于，应用于第一终端设备，所述方法包括：

显示目标应用的图像预览界面，所述目标应用为具有拍摄功能的应用；

在显示所述图像预览界面的过程中，获取基于所述目标应用持续下发的图像预览请求采集的预览图像帧从摄像头输出后，在预览图像帧流转的通路中各处理环节流转的时间信息；

在所述图像预览界面出现预览卡顿异常时，根据所述预览图像帧在各处理环节流转的时间信息，确定造成预览卡顿异常的预览卡顿原因。

2.根据权利要求1所述的方法，其特征在于，根据所述图像帧在通路中的流转顺序，所述处理环节包括出帧环节、缓存环节、合成环节和送显环节；

所述根据所述预览图像帧在各处理环节流转的时间信息，确定造成预览卡顿异常的预览卡顿原因，包括：

根据所述预览图像帧在所述出帧环节流转的时间信息，确定出现所述预览卡顿异常时，所述出帧环节在所述预览卡顿异常对应的预览图像帧附近输出的预览图像帧是否存在丢帧现象；

在所述出帧环节在所述预览卡顿异常对应的预览图像帧附近输出的预览图像帧存在丢帧现象时，确定造成预览卡顿异常的预览卡顿原因来自所述出帧环节；

在所述出帧环节在所述预览卡顿异常对应的预览图像帧附近输出的预览图像帧不存在丢帧现象时，根据所述预览图像帧在所述送显环节流转的时间信息，确定所述预览图像帧的送显时间是否均匀；

在所述预览图像帧的送显时间均匀时，确定造成预览卡顿异常的预览卡顿原因来自所述第一终端设备的显示屏；

在所述预览图像帧的送显时间不均匀时，根据所述预览图像帧在所述合成环节流转的时间信息，确定所述预览图像帧的合成时间是否均匀；

在所述预览图像帧的合成时间均匀时，确定造成预览卡顿异常的预览卡顿原因来自所述送显环节；

在所述预览图像帧的合成时间不均匀时，根据所述预览图像帧在缓存环节流转的时间信息，确定所述预览图像帧添加到缓存队列的入队时间是否均匀；

在所述预览图像帧添加到所述缓存队列的入队时间均匀时，确定造成所述预览卡顿异常的预览卡顿原因来自所述合成环节；

在所述预览图像帧添加到所述缓存队列的入队时间不均匀时，确定造成所述预览卡顿异常的预览卡顿原因来自所述出帧环节。

3.根据权利要求2所述的方法，其特征在于，所述缓存环节进行的操作为将摄像头硬件抽象层服务进程输出的预览图像帧添加到缓存队列的的操作；

所述根据所述预览图像帧在缓存环节流转的时间信息，确定所述预览图像帧添加到缓存队列的入队时间是否均匀，包括：

获取每一帧预览图像帧添加到所述缓存队列的入队时间；

根据每一帧预览图像帧对应的入队时间，确定相邻两个预览图像帧之间的入队时间间隔；

根据所述入队时间间隔和所述合成环节遵循的VSync信号周期，确定理论合成时间；

根据所述理论合成时间，确定所述预览图像帧添加到缓存队列的入队时间是否均匀。

4.根据权利要求3所述的方法，其特征在于，所述根据所述入队时间间隔和所述合成环节遵循的VSync信号周期，确定理论合成时间，包括：

根据接收到的VSync-SF信号对应的时间和所述VSync-SF信号对应的的VSync信号周期，周期性的检测所述缓存队列中是否存在预览图像帧，所述VSync-SF信号用于指示合成环节从缓存队列中获取预览图像帧进行合成处理；

对于每一个检测周期对所述缓存队列的检测，在所述缓存队列中存在预览图像帧时，对所述预览图像帧进行合成处理，将本次合成处理的所述预览图像帧对应的入队时间间隔和所述预览图像帧合成处理后的首个检测周期检测到的所述缓存队列中的预览图像帧对应的入队时间间隔之间的差值，作为所述理论合成时间。

5.根据权利要求2所述的方法，其特征在于，所述出帧环节指摄像头驱动输出摄像头根据所述图像预览请求采集的所述预览图像帧的环节；

所述根据所述预览图像帧在所述出帧环节流转的时间信息，确定出现所述预览卡顿异常时，所述出帧环节在所述预览卡顿异常对应的预览图像帧附近输出的预览图像帧是否存在丢帧现象，包括：

在所述预览卡顿异常对应的预览图像帧附近，对于每两个相邻的预览图像帧，获取所述摄像头驱动输出相邻的两个预览图像帧分别对应的输出时间；

根据相邻的两个预览图像帧分别对应的输出时间，确定相邻的两个预览图像帧对应的第一时间间隔；

根据所述第一时间间隔，确定所述摄像头驱动输出的预览图像帧是否存在丢帧现象。

6.根据权利要求5所述的方法，其特征在于，所述根据所述第一时间间隔，确定所述摄像头驱动输出的预览图像帧是否存在丢帧现象，包括：

确定每两个相邻的预览图像帧对应的第一时间间隔是否相同；

在每两个相邻的预览图像帧对应的第一时间间隔相同时，确定所述摄像头驱动输出的预览图像帧连续；

在所述摄像头驱动输出的预览图像帧连续时，确定所述摄像头驱动输出的预览图像帧不存在丢帧现象；

在每两个相邻的预览图像帧对应的第一时间间隔不相同时，确定所述摄像头驱动输出的预览图像帧不连续；

在所述摄像头驱动输出的预览图像帧不连续时，确定所述摄像头驱动输出的预览图像帧存在丢帧现象。

7.根据权利要求6所述的方法，其特征在于，所述在每两个相邻的预览图像帧对应的第一时间间隔不相同时，所述方法还包括：

确定所述第一时间间隔是否大于第一时间间隔阈值，所述第一时间间隔阈值基于所述摄像头采集所述预览图像帧时遵循的采样频率确定；

在所述第一时间间隔不大于所述第一时间间隔阈值时，确定所述摄像头驱动输出的预览图像帧连续；

在所述第一时间间隔大于所述第一时间间隔阈值时，确定所述摄像头驱动输出的预览图像帧不连续。

8.根据权利要求2所述的方法，其特征在于，所述根据所述预览图像帧在所述送显环节流转的时间信息，确定所述预览图像帧的送显时间是否均匀，包括：

确定每一帧预览图像帧在所述图像预览界面显示的显示时长；

在每一帧图像预览帧对应的显示时长均相同时，确定所述预览图像帧的送显时间均匀；

否则，确定所述预览图像帧的送显时间不均匀。

9.根据权利要求8所述的方法，其特征在于，所述确定每一帧预览图像帧在所述图像预览界面显示的显示时长，包括：

在接收到第一VSync-HW信号，且从所述合成环节中获取到第一预览图像帧时，记录当前的***时间，得到第一***时间；

在接收到第二VSync-HW信号，且从所述合成环节中获取到第二预览图像帧时，记录当前的***时间，得到第二***时间；

根据所述第一***时间和所述第二***时间，确定第一预览图像在所述图像预览界面显示的显示时长。

10.根据权利要求2所述的方法，其特征在于，所述根据所述预览图像帧在所述合成环节流转的时间信息，确定所述预览图像帧的合成时间是否均匀，包括：

确定每一帧预览图像帧在所述合成环节的合成时间；

在每一帧图像预览帧对应的合成时间均相同时，确定所述预览图像帧的合成时间均匀；

否则，确定所述预览图像帧的合成时间不均匀。

11.根据权利要求10所述的方法，其特征在于，所述确定每一帧预览图像帧在所述合成环节的合成时间，包括：

在接收到第一VSync-SF信号时，从所述缓存队列中获取到第一预览图像帧时，记录当前的***时间，得到第三***时间；

在第二VSync-SF信号到达前，所述合成环节对所述第一预览图像进行合成处理，所述第二VSync-SF信号是所述合成环节对所述第一预览图像帧合成后接收到的首个VSync-SF信号；

在接收到第二VSync-SF信号时，记录当前的***时间，得到第四***时间；

根据所述第三***时间和所述第四***时间，确定每一帧预览图像帧在所述合成环节的合成时间。

12.根据权利要求1所述的方法，其特征在于，在显示所述图像预览界面的过程中，所述方法还包括：

监测所述图像预览界面的刷新频率；

在所述刷新频率大于设定的刷新频率阈值时，确定所述图像预览界面出现预览卡顿异常。

13.根据权利要求1所述的方法，其特征在于，所述预览卡顿原因还包括造成所述预览卡顿异常的预览图像帧，以及所述预览卡顿异常持续的时间。

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

存储所述预览卡顿异常对应的预览卡顿原因。

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

响应于接收到的预览卡顿原因请求，将所述预览卡顿原因输出至第二终端设备，和/或，在所述第一终端设备的显示界面显示所述预览卡顿原因。

16.一种终端设备，其特征在于，所述终端设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述终端设备执行如权利要求1至14任意一项所述的预览卡顿原因的确定方法。

17.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在终端设备上运行时，使得所述终端设备执行如权利要求1至14任意一项所述的预览卡顿原因的确定方法。