Android GUI系統之SurfaceFlinger(13) VSync信號的處理

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，有興趣的讀者可以自行研究下。