【Android OS】显示系统之Vsync Event

最新推荐文章于 2023-09-01 23:00:00 发布

原创最新推荐文章于 2023-09-01 23:00:00 发布 · 174 阅读

0 ·

CC 4.0 BY-SA版权

博客提及了Vsync，它在信息技术领域常用于图形显示同步等方面，可避免画面撕裂等问题，提升视觉体验。

Vsync

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

margin_zh

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

VSync事件处理流程分析(Android4.3)

山庄来客的专栏

11-23

7106

我们先看收到VSync事件是如何处理的，再看底层是怎样向上层通知VSync事件。

Android VSYNC事件传递流程

xlnaan的博客

02-12

2083

我一直以为DisplayEventReceiver是跟Input一样，通过BitTube的两个socket进行跨进程的通信，也就是SF-APP之间的通信，但实际上不是的。实际上的逻辑是，每次VSYNC事件到来从HAL的线程调之后， 01-01 00:35:01.163 2963 3017 D SurfaceFlinger: onVSyncEvent EventThread会将这个vsync事...

参与评论您还未登录，请先登录后发表或查看评论

vsync event处理过程总结

qwaszx523的博客

01-09

892

1、对vsync event感兴趣的对象有两个，一个是SF，另外一个是APP。 2、kitkat对vsync进行虚拟化，引入dispsync模型，输出两个带有相位偏移的vsync分别供SF和APP使用。 3、hwc将HW vsync event传递给SF，SF交给dispsync模型进行处理。 dispsync模型通过eventlistener的回调函数（onDispSyncEvent）将处

android vsync

02-23

921

http://blog.youkuaiyun.com/wanna_ku/article/details/7819742 http://www.uml.org.cn/mobiledev/201301081.asp

vsync信号产生与分发

weixin_30763455的博客

03-19

579

以下分析基于android 4.4代码 vsync信号的产生、分发涉及到以下几个类，先主要了解下他们各自的功能： HWComposer：产生hardware vsync，post fb VSyncThread : 如果没有硬件支持，那么通过软件方式模拟hw vsyncDispSync,DispSyncThread: 接受HWComposer的hw vsync信号作为校准，开始模拟产生v...

Android 进阶——图形显示系统之VSync和 Choreographer的创建详解(一)

最美不过，心中有梦，身旁有你！

09-01

1950

VSync和 Choreographer的创建详解

深入Android系统（十二）Android图形显示系统-2-SurfaceFlinger与图像输出

apigfly的博客

05-03

1881

最近有些忙，切实体验了一把拖更的羞耻感 ( *︾▽︾) 本文和上一篇深入Android系统（十二）Android图形显示系统-1-显示原理与Surface关系比较密切，撸完前篇更易理解本文啦 (๑‾ ꇴ ‾๑) 了解SurfaceFlinger之前我们需要先了解下OpenGL相关的一些知识 OpenGL ES与EGL OpenGL 一般OpenGL被认为是一个API(Application Programming Interface, 应用程序编程接口)，包含了一系列可以操作图形、图像的函数。然而，Op

Android VSync与渲染

liyangzmx的专栏

07-07

1558

Android VSync与渲染

Android消息机制Looper与VSync的传播

houliang120的专栏

03-22

7100

1 主要内容本文主要简单记录在native层Looper消息机制的相关内容，主要着手于下面几个问题：（1）消息机制的原理；（2）VSync是如何借助消息机制进行传播的；2 Android消息机制2.1 应用进程的创建说起Android的消息机制，先大致的理一下Android应用的运行机制，Android上层是基于消息机制的，首先考虑一个问题，描述如下：Android应用作为运行在Linux平

Android graphic: How vsync signal is passed from LCD to app?

weixin_33767813的博客

03-20

142

Android graphic: How vsync signal is passed from LCD to app? step 1: from LCD to eventthread. EventThread and SF are two different threads in one process. it take care of dispatch vsync sig...

Android性能优化：定性和定位Android图形性能问题

05-11

2561

作者：飞起来_飞过来转载地址：https://juejin.cn/post/7096288511053004830 简介本文记录一次Android图形性能问题的分析过程——发现、定性和定位图形性能问题，以及探讨的性能优化方案。环境：Android Q + MTK + ARM Mali-G72。所分析的性能问题（下称case）：打开录屏应用并启动后台录屏，滑动前台应用（滑屏）。性能表现差：CPU、GPU负载显著升高、掉帧、用户明显卡顿感，帧率不足30帧，帧渲染、合成耗时急剧飙升（渲染耗时平均为29.

07.显示系统：第005课_Vsync机制：第002节_Vsync框架第003节_初始化代码分析

江南才尽江南山，年少无知年少狂！

04-04

524

在上小节中，讲解了Vsync机制的框架，有了框架再去分析源代码，才不会迷失方向，毕竟andriod是的源代码是十分的复杂与庞大，我们先来回顾一下，下面是上小节的框图：通过上小节我们知道，Vsync信号可以由软件产生，也能由硬件产生，如果由软件产生，他会存在一个线程。danVsync信号到来会发送给DispSyncThread线程。 DispSyncThread会把Vsync虚拟化，分成Vsyn......

Android VSync事件分发过程源码分析

深入剖析Android系统

11-27

6629

在上一篇文章Android VSync信号产生过程源码分析中分别介绍了VSync的两种产生方式，无论是通过硬件中断产生还是通过软件模拟产生，VSync事件最终都会交给EventThread线程来分发给所有VSync事件接收者。VSync事件接收者有很多，SurfaceFlinger就是其中一个重要的VSync事件接收者。那么EventThread线程是如何知道该将VSync分发给谁呢？EventThread线程有是如何将VSync事件分发给所有VSync事件接收者的呢？本文就针对这两个问题展开分析。我们知道

Vsync从HWC到APP的传递过程

Christ的博客

04-07

4836

主要可以分成两个阶段：从HWC到SurfaceFlinger和从SurfaceFlinger到APP。 1.从HWC到SurfaceFlinger Android系统中VSYNC信号分为两种，一种是硬件生成的信号，一种是软件模拟的信号。硬件信号是由HardwareComposer提供的，HWC封装了相关的HAL层，如果硬件厂商提供的HAL层实现能定时产生VSYNC中断，则直接使用硬件的VS

Vsync事件分发主要过程

BingshuYang的博客

03-08

663

创建两个EventThread线程，一个属于SF，一个属于Choreographer，并运行创建DisSyncThread线程并运行两个EventThread初始化时会添加一个Connection，并且把自己注册给DisSyncThread的mListenners，也就是所谓的观察者模式当有信号VSync来的时候，经过HWC到SF到DisSyncThread，DisSyncThread分发...

VSync信号的虚拟化

qwaszx523的博客

01-08

1148

Android 4.1(Jelly Bean)引入了Vsync(Vertical Syncronization)用于渲染同步，使得App UI和SurfaceFlinger可以按硬件产生的VSync节奏来进行工作。图1 VSync模型

android4.4 VSync事件处理流程

ProgBelief的专栏

05-08

3240

HWComposer：：registerProcs（）-》 HWComposer：：

SurfaceFlinger原理（二）：Vsync事件的处理

Invoker123的博客

09-11

4182

SurfaceFlinger内部有两个EventThread，一个负责app端对Vsync信号的监听处理，一个负责SurfaceFlinger对Vsync信号的监听处理。SurfaceFlinger内部维持了一个MessageQueue,当SurfaceFlinger端的EventThread监测到Vsync事件，会触发INVALIDATE操作，即当前的图层失效了，需要重新计算刷新。 /fr...

android车载多屏显示实现修改点

最新发布

04-02

<think>好的，我现在需要帮助用户了解Android车载多屏显示的实现修改点。首先，我需要明确用户的问题范围，确保覆盖所有关键方面。用户可能对车载系统的多屏显示开发或定制感兴趣，可能涉及Android Automotive OS或者改装现有系统。首先，我应该回忆一下Android Automotive的基本架构。Android Automotive OS（AAOS）是专门为车辆设计的操作系统，支持多屏显示。多屏显示的实现可能涉及系统层、应用层以及硬件抽象层的修改。接下来，我需要分解实现多屏显示的关键点。可能的修改点包括显示管理、输入事件分发、窗口管理、内容分发、电源管理、权限控制等。每个部分都需要详细说明，并考虑Android Automotive的特性。然后，要确保覆盖技术细节，比如使用SurfaceControl、DisplayManagerService、WindowManagerService等系统服务。同时，可能需要处理多屏的同步、不同分辨率和DPI适配，以及车辆特有的需求，比如后排娱乐系统的控制。还要考虑应用层面的修改，比如Activity的显示配置，多实例应用的支持，或者使用Presentation类在不同屏幕上显示不同内容。另外，车载系统可能有严格的认证标准，如Android Automotive Compatibility Test Suite (CTS)，需要确保修改符合这些标准。用户可能还需要了解硬件抽象层的改动，比如与车辆总线（如CAN）的集成，或者与显示控制器驱动的交互。这部分可能需要与OEM合作，因为涉及到底层驱动和硬件适配。另外，电源管理也很重要，车载系统需要根据车辆状态（如熄火、ACC模式）管理屏幕的开关和亮度，这可能涉及到与车辆电子的交互。最后，需要验证和测试多屏显示的功能，包括性能测试、兼容性测试和用户体验测试。确保各个屏幕的触控、音频输出等正常工作，并处理多任务场景下的资源分配问题。总结来说，回答需要分模块详细说明每个修改点，涵盖系统层、应用层、硬件适配、权限管理、电源管理等方面，同时提到相关工具和测试要求，确保用户有一个全面的理解。</think>Android车载多屏显示的实现涉及系统底层到应用层的多维度修改，以下是关键修改点的结构化分析： --- ### 一、系统框架层改造 1. **显示管理服务(DisplayManagerService)** - 扩展多屏识别能力：需修改`DisplayDevice`配置，支持动态检测多个物理屏幕 - 屏幕参数配置：为每个屏幕定义独立的分辨率/DPI/方向属性，例如： ```java DisplayInfo displayInfo = new DisplayInfo(); displayInfo.logicalWidth = 1920; displayInfo.logicalHeight = 720; displayInfo.rotation = Surface.ROTATION_0; ``` - 实现屏幕热插拔监听：通过`DisplayManagerGlobal`注册`DisplayListener` 2. **窗口管理服务(WindowManagerService)** - 多屏窗口策略：修改`WindowContainer`逻辑，支持跨屏幕窗口堆栈管理 - 焦点策略调整：实现`InputMonitor`对多屏触控事件的分区处理 3. **SurfaceFlinger适配** - 多GPU合成支持：配置`HWComposer`处理多个显示控制器 - VSync同步策略：修改`EventThread`实现多屏刷新率同步 --- ### 二、硬件抽象层(HAL)修改 1. **显示驱动接口** - 扩展`hwc2_device`接口，支持多显示设备枚举： ```c hwc2_device->getDisplayCapabilities(displayId, &outCapabilities); ``` - 实现`VsyncCallback`多路分发 2. **车辆网络集成** - 通过CAN总线获取屏幕状态： ```cpp struct can_frame frame; read(sock, &frame, sizeof(struct can_frame)); ``` - 实现屏幕电源状态与车辆点火信号的联动 --- ### 三、应用层适配 1. **多屏内容分发** - 使用`Presentation`类实现辅助屏渲染： ```kotlin val secondaryDisplay = displays[1] Presentation(secondaryDisplay).apply { setContentView(R.layout.second_screen) } ``` - 多实例Activity支持：配置`ActivityOptions`指定启动屏幕 2. **输入事件路由** ```java public boolean onTouchEvent(MotionEvent event) { if (event.getSource() == InputDevice.SOURCE_TOUCHSCREEN) { int displayId = event.getDisplayId(); // 事件分发逻辑 } } ``` --- ### 四、关键配置文件修改 | 文件路径 | 修改内容 | |-----------------------------------|-----------------------------------| | `/frameworks/base/services/core/java/com/android/server/display/DisplayManagerService.java` | 添加多屏初始化逻辑 | | `/device/auto/xx/hardware/interfaces/display/1.0/IDisplay.hal` | 扩展显示设备接口 | | `/packages/services/Car/service/src/com/android/car/hardware/power/CarPowerManagementService.java` | 屏幕电源策略 | --- ### 五、认证与测试要求 1. **兼容性测试** - 通过Android Automotive CTS测试项： - `android.automotive.cts.MultiDisplayTest` - `android.automotive.cts.InputFocusTest` 2. **性能指标** - 主屏与副屏刷新延迟 ≤ 16ms - 跨屏窗口拖拽时延 ≤ 100ms - 冷启动多屏初始化时间 ≤ 1.5s --- ### 六、典型实现方案对比 | 方案类型 | 优点 | 缺点 | |----------------|-----------------------|-----------------------| | 扩展DisplayManager | 系统级集成度高 | 需要深度定制AOSP | | 虚拟显示方案 | 应用层实现简单 | 性能损耗较大 | | 外接显示控制器 | 硬件解码性能好 | 增加BOM成本 | --- ### 七、调试工具链 1. ADB多屏调试命令： ```bash adb shell dumpsys display # 查看显示设备信息 adb shell wm size 1920x720 # 动态修改分辨率 ``` 2. 使用`dumpsys SurfaceFlinger`分析合成策略 --- 以上实现需要特别注意： 1. 符合ASIL-B功能安全等级要求 2. 屏幕内容需通过车载EMC辐射测试 3. 满足ISO 26262道路车辆功能安全标准实际开发建议采用Android Automotive OS参考实现（如GMSCar）为基础进行扩展开发。