Android图形系统（十三）-Vsync信号处理

在整个Android视图绘制渲染流程中，Vsync信号都扮演着非常重要的作用，那么本篇文章就简单捋一下Vsync信号处理流程。在此之前先来回顾一下SurfaceFlinger的启动流程。

一、SurfaceFlinger的启动流程：

SurfaceFlinger自身拥有独立进程，由init进程启动。对应如下：

frameworks/native/services/surfaceflinger/surfaceflinger.rcservice surfaceflinger /system/bin/surfaceflinger   class core animation   user system   group graphics drmrpc readproc   onrestart restart zygote //挂掉后会重启Zygote   writepid /dev/stune/foreground/tasks   …

然后执行main_surfaceflinger对应main函数

frameworks/native/services/surfaceflinger/main_surfaceflinger.cpp72int main(int, char**) {...    // 限制binder线程池中线程数最多不超过4，加上主线程一共5个。    ProcessState::self()->setThreadPoolMaxThreadCount(4);    // 启动线程池    sp ps(ProcessState::self());    ps->startThreadPool();    // 创建SurfaceFlinger, 执行SF::onFirstRef 最终调用MessageQueue.cpp ::init()方法创建Handler和Looper    sp flinger = DisplayUtils::getInstance()->getSFInstance();...    // 客户端连接前的一系列初始化 包括,初始化DispSyncSource 以及EventThread.其中EventThread有两个：mEventThread对应app , mSFEventThread对应SurfaceFlinger.并初始化显示设备。    flinger->init();...    // surfaceFlinger执行主线程run方法，waitForEvent等待消息，接受invalidate消息并开始对应工作流。    flinger->run();    return 0;}

事实上到这里，从主线上看SurfaceFlinger进程就已经启动了。

二、SurfaceFlinger处理Vsync信号：

Vsync信号的产生有两种来源，一种是硬件，一种是软件模拟，因为目前基本都是硬件产生的。硬件源就是HWComposer，它属于HAL,硬件抽象层的类，主要就是把硬件Vsync信号传递到上层来。

Vsync分发流程(android m的代码流程，Android p上对比了下大流程是基本一致的，局部重构不影响大局)：

from 张奎力

Vsync信号主要作用：同步应用层的视图绘制任务和 Native层视图合成任务。下面通过一幅图来简单描述下整个过程：

from a372048518

Vsync产生：HWComposer作为硬件vsync信号。
Vsync处理：周期性唤醒DipsSyncThread产生虚拟化Vsync信号。
Vsync注册与回调：EventThread负责注册app和surfaceFinger的vsync请求和分发DipsSyncThread产生的虚拟化vsync信号到app和SurfaceFlinger。

总结一个vsync信号原则就是app和SurfaceFlinger按需请求，按请求分发。

三、app和SurfaceFlinger的vsync请求和接收过程

app的注册和回调都是通过Choreographer，它主要负责input 、animation和traversals.

App端

请求vsync-app:

Choreographer postCallback 发起vsync请求，最终调用FrameDisplayEventReceiver#scheduleVsync，然后进入native层，执行DisplayEventReceiver::requestNextVsync()，最终通过一个BpDisplayEventConnection来发起requestNextVsync操作。

这个过简单理解为客户端和底层建立了一个connection连接，通过这个connection向EventThread注册一个callback.

接收vsync-app:

DipsSyncThread周期性转发vsync给EventThread上注册的callback，经过层层回调，app端最终通过FrameDisplayEventReceiver#onVsync来接收回调，但并不是立即执行，而是通过Handler.sendMessageAtTime加入消息池等待调度。调度到了执行其run方法，走doFrame回调流程。

SurfaceFlinger

请求vsync-sf:

触发请求vsync位置在SurfaceFlinger.cpp中的两个方法：

//事务变化(如增加window window大小变化等)void SurfaceFlinger::signalTransaction() {    mEventQueue.invalidate();}

// layer发生变化,主要发生在queuebuffer的时候void SurfaceFlinger::signalLayerUpdate() {    mEventQueue.invalidate();}

另外还有个refresh方法，表示需要刷新屏幕 ,一般为处理完事务发现需要重新绘制的时候触发。

void SurfaceFlinger::signalRefresh() {mEventQueue.refresh();}

而MessageQueue执行invalidate最终还是建立connection连接向EventThread注册一个callback。

void MessageQueue::invalidate() {    mEvents->requestNextVsync();}

触发点比较分散，但是总结一点就是：页面变化引起重绘的地方就会触发vsync请求。

接收vsync-sf:

EventThread传递Invalidate消息给SurfaceFlinger主线程run方法waitForEvent来执行。

Android系统Vsync信号生成、分发包括端的注册和接收整个过程还是非常复杂的，本篇文章并没有对整个细节进行详细分析，只是捋了下主要矛盾，对于整个Vsync信号处理流程有了一个宏观的了解。

参考：
https://www.cnblogs.com/hushpa/p/6579570.html
https://blog.csdn.net/a372048518/article/details/77871474
https://www.cnblogs.com/liusiluandzhangkun/p/9196187.html
https://blog.csdn.net/u012439416/article/details/79735081

一、SurfaceFlinger的启动流程：

二、SurfaceFlinger处理Vsync信号：

三、app和SurfaceFlinger的vsync请求和接收过程

更多相关文章

随机推荐