GUI系统之SurfaceFlinger(13)VSync信号的处理

最新推荐文章于 2024-05-19 21:38:21 发布

转载最新推荐文章于 2024-05-19 21:38:21 发布 · 842 阅读

Android 同时被 2 个专栏收录

149 篇文章

订阅专栏

Android SurfaceFlinger

24 篇文章

订阅专栏

本文深入剖析了Android系统中SurfaceFlinger模块如何处理VSync信号。从建立连接到信号处理，再到最终屏幕显示，全面解析了涉及的关键函数及其工作流程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章都是通过阅读源码分析出来的，还在不断完善与改进中，其中难免有些地方理解得不对，欢迎大家批评指正。
转载请注明：From LXS. http://blog.youkuaiyun.com/uiop78uiop78/

GUI系统之SurfaceFlinger章节目录：
blog.youkuaiyun.com/uiop78uiop78/article/details/8954508

1.1.1 VSync信号的处理

经过上一小节的分析，现在我们已经明白了系统是如何通过硬件设备或者软件模拟来产生VSync信号的，也明白了它的流转过程。VSync最终会被EventThread::threadLoop()分发给各监听者，在当前版本中是MessageQueue。

MessageQueue通过与EventThread建立一个Connection来监听事件，简图如下：

图 11‑35 Connection代表了EventThread和对事件感兴趣的对象的连接

对VSYNC等事件感兴趣的对象，比如MessageQueue，首先要通过EventThread::createEventConnection()来建立一个连接，实际上就是生成了一个EventThread::Connection对象。这个对象将对双方产生如下影响：

l 当Connection::onFirstRef()时，它会主动调用EventThread::registerDisplayEventConnection()来把自己加入到mDisplayEventConnections中，这是保证事件发生后EventThread能找到“连接”的关键一步

l 当MessageQueue得到Connection后，它会马上调用getDataChannel来获得一个BitTube。从逻辑关系上看，Connection只是双方业务上连接，而BitTube则是数据传输通道，各种Event信息就是通过这里传输的

void MessageQueue::setEventThread(const sp<EventThread>&eventThread)

{

mEventThread =eventThread;

mEvents = eventThread->createEventConnection(); //建立一个Connection

mEventTube = mEvents->getDataChannel();//马上获取BitTube

mLooper->addFd(mEventTube->getFd(), 0,ALOOPER_EVENT_INPUT, MessageQueue::cb_eventReceiver, this);

}

从扮演的角色上来看，EventThread是Server，不断地往Tube中写入数据;而MessageQueue是Client，负责读取数据。可能有人会很好奇，MessageQueue如何得知有Event到来，然后去读取它呢？答案就是它们之间的数据读写模式采用的是Socket(AF_UNIX域)。

上面这个函数的末尾，通过Looper添加了一个fd，这实际上就是Socket pair中的一端。然后Looper将这个fd与其callback函数(即MessageQueue::cb_eventReceiver)加入全局的mRequests进行管理。

KeyedVector<int, Request> mRequests;

这个Vector会集中所有需要监测的fd，这样当Looper进行pollInner时，只要有事件需要处理，它就可以通过回调函数通知“接收者”。这里面的实现细节主要包括BitTube.cpp和Looper.cpp，有兴趣的读者可以自行研究下。

当Event发生后，MessageQueue::cb_eventReceiver开始执行，进而调用eventReceiver。如果event的类型是DisplayEventReceiver::DISPLAY_EVENT_VSYNC，这是我们想要监听的事件，所以再调用mHandler->signalRefresh()：

void MessageQueue::Handler::signalRefresh() {

if((android_atomic_or(eventMaskRefresh, &mEventMask) & eventMaskRefresh)== 0) {

mQueue.mLooper->sendMessage(this, Message(MessageQueue::REFRESH));

}

根据前几个小节我们分析的SurfaceThread工作模式，这个Message会进入它的消息处理队列，然后在SurfaceFlinger::onMessageReceived()中得到处理：

void SurfaceFlinger::onMessageReceived(int32_t what)

{…

switch (what) {

caseMessageQueue::REFRESH: {

const uint32_tmask = eTransactionNeeded | eTraversalNeeded;

uint32_ttransactionFlags = peekTransactionFlags(mask);

if(CC_UNLIKELY(transactionFlags)) {

handleTransaction(transactionFlags);

}

handlePageFlip();

handleRefresh();

constDisplayHardware& hw(graphicPlane(0).displayHardware());

…

if(CC_LIKELY(hw.canDraw())) {

handleRepaint();

hw.compositionComplete();

postFramebuffer();

} else {

hw.compositionComplete();

}

} break;

}

经过几个版本的变迁，现在SurfaceFlinger只处理REFRESH一个消息，不过源码中遗留下了很多没用的代码J，大家注意辨别。我们将重点的部分通过高显帮大家划出来，即下面几个函数：

l handleTransaction

即处理事务，什么样的事务呢？在SurfaceFlinger::setTransactionState()中我们可以看到，假如当前的orientation和新的不符合时，会将eTransactionNeeded置位;当应用程序请求createSurface、removeSurface，或者addLayer、removeLayer时也会把它置位。另一个flag被置位的情况则包括：layer的size、alpha、matrix、transparentregion、visibility变化等等。

总结起来，就是当与系统显示相关的状态(比如新增/减少了Surface，显示屏的变化等等)改变，或者某个Layer自身状态(比如它的大小尺寸、可见性、透明度等等)改变时，就需要执行Transaction。

l handlePageFlip

由前面的分析我们知道，每个Layer对应着最多32个BufferSlot，这样系统在进行一次刷新时，必须先决定使用哪个buffer，并利用这一缓冲区更新纹理。另外，我们还需要计算所有图层的可见区域和“脏区域”，以便最终的合成显示。

l handleRefresh

版本更新遗留下的函数，当前实现中没有起到作用，相信在后续升级中会进一步完善。

l handleWorkList

创建HWComposer中的mList，这个列表将用于后续的layer合成。这个函数比较简单，我们不单独介绍。

l handleRepaint

计算出最终的脏区域，并执行实际的合成工作(composeSurfaces)，我们将做详细源码分析。

l postFramebuffer

将上一步中生成的缓冲区数据post到framebuffer中，这样才能真正在物理屏幕上显示出来。分为两条路径，即HWComposer::commit和直接调用eglSwapBuffers()

这些函数基本涵盖了SurfaceFlinger的所有功能，接下来的几个小节我们将详细分析它们，各个击破