android 13/14高版本SurfaceFlinger出现VSYNC-app/VSYNC-appSf/VSYNC-sf剖析

2023-10-22 15:02
文章标签 android 剖析 app 版本 14 13 surfaceflinger sf vsync appsf

本文主要是介绍android 13/14高版本SurfaceFlinger出现VSYNC-app/VSYNC-appSf/VSYNC-sf剖析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

问题背景：

了解surfaceflinger的vsync同学都可能知道vsync属于一个节拍器，主要用来控制有节奏的渲染，不至于会产生什么画面撕裂等现象。
一般vsync都有会有2部分：
app部分vsync，控制各个app可以有节奏的上帧
surfaceflinger部分vsync,控制surfaceflinger的一个合成画面送显示的节奏

上面2部分其实大家了解vsync都知道，但是近期再看android 13的surfaceflinger trace时候发现有如下情况：

老版本：
systrace查看发现老版本其实只有app和sf的VSYNC情况
在这里插入图片描述

新版本
systrace出现了3个，多了一个VSYNC-appSf：
在这里插入图片描述

这个地方就有学员朋友在群里问这个问题，刚好我近期也在修炼surfaceflinger相关，针对这个问题，其实大部分人我估计态度都是忽略哈，，网上也基本找不到答案，哪怕问人也很难问到哈。
那么这个VSYNC-appSf到底是啥，为啥老版本没有新版本会有这个？这个就是本blog要讲解的重点 。

更多framework干货课程优惠获取相关可以+V（androidframework007）
视频：https://www.bilibili.com/video/BV1ah411d7Y3
在这里插入图片描述

线索追踪及官方解释

在对appSf的修改进行git log追踪时候发现有如下一个commit，这个commit有专门写明原因哈：

appSf产生原因，官方解释：

SurfaceFlinger: decouple EventThread from SF wakeupToday we have two instances of EventThread:1. 'app' - used to wake up Choreographer clients2. 'sf' - used to wake up SF mian thead *and*Choreographer clients that uses sf instanceNow this creates an ambiguity when trying to reason about the expectedvsync time and deadline of 'sf' EventThread:- SF wakes up sfWorkDuration before a vsync and targets that vsync- Choreographer users wakes up with SF main thread but targets thevsync that happens after the next SF wakeup.To resolve this ambiguity we are decoupling SF wakeup from 'sf'EventThread. This means that Choreographer clients that uses 'sf'instance will keep using the EventThread but SF will be waking updirectly by a callback with VSyncDispatch. This allows us to correctthe expected vsync and deadline for both.Test: Interacting with the device and observe systracesTest: new unit test added to SF suiteBug: 166302754Change-Id: I76d154029b4bc1902198074c33d38ff030c4601b

不过比较遗憾哈，全是英文的，这个要看懂可能不难哈，但是要完全领悟贯通那就要很了解surfaceflinger的vsync了。不然那就只能停留在字面意思啦，根本无法理解精华。
下面马哥带大家来理解一下吧，都把相关翻译写下来啦，不一定全对哈。
带马哥注释理解

  SurfaceFlinger: decouple EventThread from SF wakeup//标题就是把EventThread分离出sf，大概意思就是不想让EventThread管sf相关vsyncToday we have two instances of EventThread://这个是解释修改前的现状和背景，目前有两个EventThread实例，一个app一个sf1. 'app' - used to wake up Choreographer clients //app的EventThread属于用来唤醒app端2. 'sf' - used to wake up SF mian thead *and* Choreographer clients that uses sf instance//sf的EventThread有2个责任，一个是自己来唤醒Sf的主线程，另一个也是关键一点，有对应的clients端也需要使用//下面讲述修改背景，本质就是说sf的EventThread因为有2个责任，一个是自己sf的唤醒，一个是client端唤醒，二者共用情况，可能会有时候排查vsync会有模棱两可的情况，即没办法准确确认vsync问题原因Now this creates an ambiguity when trying to reason about the expectedvsync time and deadline of 'sf' EventThread:- SF wakes up sfWorkDuration before a vsync and targets that vsync- Choreographer users wakes up with SF main thread but targets thevsync that happens after the next SF wakeup.//为了解决这类可能导致模棱两可的情况，那么就需要吧sf的EventThread进行相关的分离，sf原本负责的2个功能拆开，把sf自己唤醒自己的转移到了直接让VSyncDispatch进行callback调用，另一个对于client端的功能就保留在EventThread中，这样就不会造成上面的模棱两可疑惑。也就是我们看到的会多了一个appSfTo resolve this ambiguity we are decoupling SF wakeup from 'sf'EventThread. This means that Choreographer clients that uses 'sf'instance will keep using the EventThread but SF will be waking updirectly by a callback with VSyncDispatch. This allows us to correctthe expected vsync and deadline for both.Test: Interacting with the device and observe systracesTest: new unit test added to SF suiteBug: 166302754Change-Id: I76d154029b4bc1902198074c33d38ff030c4601b

总结一下：
简单说就是吧以前的sf的EventTread功能中，自己唤醒触发vsync的部分移除EventTread，让VSyncDispatch直接进行（后面有机会讲解vsync再深入分析），不在使用EventThread来搞对于的sf的vsync了。
但是sf还有一个功能就是对待客户端的，这个部分保留在EventTread中，变成我们看到的appSf

哈其实你是不是有点懂又还是没彻底领悟，特别是为啥sf还有两个功能？以前不是说了只是来产生sf的vsync么？正常哈，因为上面的结论其实都是相当于一个结论哈，要彻底理解还需要其他相关的补充哈。

千里马实战解读理解appSf

理解sf为啥会有两个功能，以前不是只有一个产生sf端的vsync么?
我们注意看看人家的解释哈：

1. 'app' - used to wake up Choreographer clients 
2. 'sf' - used to wake up SF mian thead *and* Choreographer clients that uses sf instance

sf另一个功能是 Choreographer clients 需要使用这个sf的EventThread,这里应该是大家最不可以理解的地方。这里看看上面的app也是用的Choreographer clients ，表面意识就是Choreographer的客户端，其实就是各个需要上帧的应用的Choreographer客户端。
那么这里说的 Choreographer clients that uses sf instance，难道是sf的也有对于的客户端吗？Choreographer也有直接指定sf这个EventTread线程的？哈哈其实确实有的具体可以看以下代码：

    private Choreographer(Looper looper, int vsyncSource) {mLooper = looper;mHandler = new FrameHandler(looper);mDisplayEventReceiver = USE_VSYNC? new FrameDisplayEventReceiver(looper, vsyncSource): null;mLastFrameTimeNanos = Long.MIN_VALUE;mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];for (int i = 0; i <= CALLBACK_LAST; i++) {mCallbackQueues[i] = new CallbackQueue();}// b/68769804: For low FPS experiments.setFPSDivisor(SystemProperties.getInt(ThreadedRenderer.DEBUG_FPS_DIVISOR, 1));}

大家注意没有这个Choreographer构造时候就有个vsyncSource，这个是不是大家都没有注意过哈，它到底有哪些值呢？

  /*** When retrieving vsync events, this specifies that the vsync event should happen at the normal* vsync-app tick.* <p>* Needs to be kept in sync with frameworks/native/include/gui/ISurfaceComposer.h*/public static final int VSYNC_SOURCE_APP = 0;/*** When retrieving vsync events, this specifies that the vsync event should happen whenever* Surface Flinger is processing a frame.* <p>* Needs to be kept in sync with frameworks/native/include/gui/ISurfaceComposer.h*/public static final int VSYNC_SOURCE_SURFACE_FLINGER = 1;

可以看到有两个
一个最常见的的app
另一个就是sf的
sf这个，也就是app端可以指定vsync是跟随surfaceflinger的合成vsync的，所以这里也就是被叫做Choreographer clients ，这里大家就可以理解了吧，具体有没有谁使用呢？
可以看看有谁使用Choreographer getSfInstance方法:
在这里插入图片描述

可以看到还是有一些场景就是使用的sf的vsync，自然使用vsync就会涉及到回调获取vsync和请求vsync。所以这里就是上面的说的client可能会使用相关的sf vsync情况，sf自身也有请求获取情况，所以这个两个业务混一起了，那确实有时候一些问题就不好排查了。

结合systrace验证

1、确定是不是真的有有clinet链接到了sf的EventThread
这个其实可以通过相关的dumpsys SurfaceFlinger来实现，看看是否appSf是否有对于的connection，不过比较遗憾哈，默认的dumpsys并没有吧appSf的EventThread打印，只打印了app的EventTread，所以这里就需要我们修改一下相关dumpsys如下：

test@test:~/nx563j_xiaomi/frameworks/native/services$ git diff surfaceflinger/SurfaceFlinger.cpp
diff --git a/services/surfaceflinger/SurfaceFlinger.cpp b/services/surfaceflinger/SurfaceFlinger.cpp
index b1b31bbd76..04f5b63dc0 100644
--- a/services/surfaceflinger/SurfaceFlinger.cpp
+++ b/services/surfaceflinger/SurfaceFlinger.cpp
@@ -5180,6 +5180,7 @@ void SurfaceFlinger::dumpVSync(std::string& result) const {mDebugDisplayModeSetByBackdoor ? "yes" : "no");mScheduler->dump(mAppConnectionHandle, result);
+    mScheduler->dump(mSfConnectionHandle, result);//加入一行吧appSf相关EventTread信息也打一下mScheduler->dumpVsync(result);StringAppendF(&result, "mHWCVsyncPendingState=%s mLastHWCVsyncState=%s\n",to_string(mHWCVsyncPendingState).c_str(), to_string(mLastHWCVsyncState).c_str());

结果如下：

app: state=Idle VSyncState={displayId=0, count=548}//正常只有这个打印pending events (count=0):connections (count=16):Connection{0x747b86b730, VSyncRequest::None,1000}Connection{0x747b879e30, VSyncRequest::None,1000}Connection{0x747b86ffd0, VSyncRequest::None,1000}Connection{0x747b8784d0, VSyncRequest::None,1000}Connection{0x747b86c1b0, VSyncRequest::None,10110}Connection{0x747b8856d0, VSyncRequest::None,10110}Connection{0x747b882db0, VSyncRequest::None,10110}Connection{0x747b87fd90, VSyncRequest::None,10110}Connection{0x747b8839f0, VSyncRequest::None,10111}Connection{0x747b883bb0, VSyncRequest::None,1000}Connection{0x747b8728f0, VSyncRequest::None,1000}Connection{0x747b870350, VSyncRequest::None,10111}Connection{0x747b882870, VSyncRequest::None,10142}Connection{0x747b880570, VSyncRequest::None,10144}Connection{0x747b871150, VSyncRequest::None,10144}Connection{0x747b86da30, VSyncRequest::None,10141}
appSf: state=Idle VSyncState={displayId=0, count=165}//额外加上这个打印pending events (count=0):connections (count=4)://client链接数量Connection{0x747b86ca70, VSyncRequest::None,1000}Connection{0x747b8833d0, VSyncRequest::None,1000}Connection{0x747b877190, VSyncRequest::None,1000}Connection{0x747b87cc90, VSyncRequest::None,10110}
VsyncController:

发现确实appSf也有4个链接，uid 1000是system和10110 是systemui

结合trace打印查看appSf相关的：

回想一下app端如果要请求vsync时候最后是跨进程调用到了如下代码：

frameworks/native/services/surfaceflinger/Scheduler/EventThread.cpp

binder::Status EventThreadConnection::requestNextVsync() {ATRACE_CALL();mEventThread->requestNextVsync(this);return binder::Status::ok();
}

这里trace中只有个方法的输出，这里可以添加一下，用来区分app还是appSf的EventTread，修改如下：

 std::string toString(const DisplayEventReceiver::Event& event) {
@@ -194,7 +194,10 @@ binder::Status EventThreadConnection::setVsyncRate(int rate) {binder::Status EventThreadConnection::requestNextVsync() {ATRACE_CALL();
+    ATRACE_BEGIN(((impl::EventThread*)mEventThread)->toNameString());//主要线程名字打出到Trace中
+    ALOGE(" EventThreadConnection::requestNextVsync() threadName %s calluid %d",((impl::EventThread*)mEventThread)->toNameString(),(int)mOwnerUid);mEventThread->requestNextVsync(this);
+        ATRACE_END();return binder::Status::ok();}

然后再看trace情况如下：
看sf的clinet端请求vsync
在这里插入图片描述
这里因为tag太小做个标记方便寻找
下面来看具体的apSf的vsync到来

在这里插入图片描述

这篇关于android 13/14高版本SurfaceFlinger出现VSYNC-app/VSYNC-appSf/VSYNC-sf剖析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/262202。

相关文章

Java进阶13讲__第12讲_1/2

Java进阶13讲__第12讲_1/2

多线程、线程池 1.  线程概念 1.1  什么是线程 1.2  线程的好处 2.   创建线程的三种方式 注意事项 2.1  继承Thread类 2.1.1 认识  2.1.2  编码实现  package cn.hdc.oop10.Thread;import org.slf4j.Logger;import org.slf4j.LoggerFactory
阅读更多...
Android实现任意版本设置默认的锁屏壁纸和桌面壁纸（两张壁纸可不一致）

Android实现任意版本设置默认的锁屏壁纸和桌面壁纸（两张壁纸可不一致）

客户有些需求需要设置默认壁纸和锁屏壁纸  在默认情况下 这两个壁纸是相同的  如果需要默认的锁屏壁纸和桌面壁纸不一样 需要额外修改 Android13实现 替换默认桌面壁纸： 将图片文件替换frameworks/base/core/res/res/drawable-nodpi/default_wallpaper.*  （注意不能是bmp格式） 替换默认锁屏壁纸： 将图片资源放入vendo
阅读更多...
Android平台播放RTSP流的几种方案探究（VLC VS ExoPlayer VS SmartPlayer）

Android平台播放RTSP流的几种方案探究（VLC VS ExoPlayer VS SmartPlayer）

技术背景 好多开发者需要遴选Android平台RTSP直播播放器的时候，不知道如何选的好，本文针对常用的方案，做个大概的说明： 1. 使用VLC for Android VLC Media Player（VLC多媒体播放器），最初命名为VideoLAN客户端，是VideoLAN品牌产品，是VideoLAN计划的多媒体播放器。它支持众多音频与视频解码器及文件格式，并支持DVD影音光盘，VCD影
阅读更多...
业务中14个需要进行A/B测试的时刻[信息图]

业务中14个需要进行A/B测试的时刻[信息图]

在本指南中，我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试，如何有效地规划和启动测试，如何评估测试是否成功，您应该关注哪些指标，多年来我们发现的常见错误等等。 什么是A/B测试？ A/B测试（有时称为“分割测试”）是一种实验类型，其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体，以查看哪一种效果最好。 本质上，A/B测
阅读更多...
android-opencv-jni

android-opencv-jni

//------------------start opencv--------------------@Override public void onResume(){ super.onResume(); //通过OpenCV引擎服务加载并初始化OpenCV类库，所谓OpenCV引擎服务即是 //OpenCV_2.4.3.2_Manager_2.4_*.apk程序包，存
阅读更多...
从状态管理到性能优化：全面解析 Android Compose

从状态管理到性能优化：全面解析 Android Compose

文章目录 引言一、Android Compose基本概念1.1 什么是Android Compose?1.2 Compose的优势1.3 如何在项目中使用Compose 二、Compose中的状态管理2.1 状态管理的重要性2.2 Compose中的状态和数据流2.3 使用State和MutableState处理状态2.4 通过ViewModel进行状态管理 三、Compose中的列表和滚动
阅读更多...
Android 10.0 mtk平板camera2横屏预览旋转90度横屏拍照图片旋转90度功能实现

Android 10.0 mtk平板camera2横屏预览旋转90度横屏拍照图片旋转90度功能实现

1.前言 在10.0的系统rom定制化开发中，在进行一些平板等默认横屏的设备开发的过程中，需要在进入camera2的 时候，默认预览图像也是需要横屏显示的，在上一篇已经实现了横屏预览功能，然后发现横屏预览后，拍照保存的图片 依然是竖屏的，所以说同样需要将图片也保存为横屏图标了，所以就需要看下mtk的camera2的相关横屏保存图片功能， 如何实现实现横屏保存图片功能 如图所示: 2.mtk
阅读更多...
android应用中res目录说明

android应用中res目录说明

Android应用的res目录是一个特殊的项目，该项目里存放了Android应用所用的全部资源，包括图片、字符串、颜色、尺寸、样式等，类似于web开发中的public目录，js、css、image、style。。。。 Android按照约定，将不同的资源放在不同的文件夹中，这样可以方便的让AAPT(即Android Asset Packaging Tool , 在SDK的build-tools目
阅读更多...
Android fill_parent、match_parent、wrap_content三者的作用及区别

Android fill_parent、match_parent、wrap_content三者的作用及区别

这三个属性都是用来适应视图的水平或者垂直大小，以视图的内容或尺寸为基础的布局，比精确的指定视图的范围更加方便。 1、fill_parent 设置一个视图的布局为fill_parent将强制性的使视图扩展至它父元素的大小 2、match_parent 和fill_parent一样，从字面上的意思match_parent更贴切一些，于是从2.2开始，两个属性都可以使用，但2.3版本以后的建议使
阅读更多...
Android Environment 获取的路径问题

Android Environment 获取的路径问题

1. 以获取 /System 路径为例 /*** Return root of the "system" partition holding the core Android OS.* Always present and mounted read-only.*/public static @NonNull File getRootDirectory() {return DIR_ANDR
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2