Processing of Surfaceflinger (VSYNC) signal of Android GUI system

Processing of 1.1.1 VSync signal

After the analysis of the previous section, we now understand how the system generates VSYNC signals through hardware devices or software simulations, and also understands its flow. VSync will eventually be distributed to listeners by Eventthread::threadloop (), MessageQueue in the current version.

MessageQueue through the establishment of a connection with Eventthread to monitor the event, the sketch is as follows:

Figure 11?35 Connection represents the connection of Eventthread and objects of interest to the event

Objects such as MessageQueue, which are interested in events such as VSync, first have to establish a connection through eventthread::createeventconnection (), in effect generating a eventthread: Connection object. This object will have the following effects on both sides:

L when Connection::onfirstref (), it will actively invoke eventthread::registerdisplayeventconnection () To add yourself to the mdisplayeventconnections, which is a key step in ensuring that eventthread can find a "connection" after the event occurs.

L When MessageQueue gets connection, it immediately calls Getdatachannel to get a bittube. From a logical point of view, connection is only a business connection between the two, and Bittube is the data transmission channel, all kinds of event information is transmitted through here

void Messagequeue::seteventthread (const sp<eventthread>&eventthread)

{

Meventthread =eventthread;

Mevents = Eventthread->createeventconnection (); Build a connection

Meventtube = Mevents->getdatachannel ()/immediately get Bittube

MLOOPER->ADDFD (Meventtube->getfd (), 0,alooper_event_input, Messagequeue::cb_eventreceiver, this);

}

From the role played, Eventthread is the server, constantly writing data to tube, while MessageQueue is the client, responsible for reading the data. Someone might be curious, how did MessageQueue know there was an event coming and then read it? The answer is that the data read and write mode between them is socket (Af_unix domain).

At the end of this function, an FD is added via Looper, which is actually one end of the socket pair. Then looper the FD and its callback function (that is, messagequeue::cb_eventreceiver) into the global mrequests for management.

Keyedvector<int, request> mrequests;

This vector will focus on all the FD that needs to be monitored, so that when the looper is Pollinner, whenever an event needs to be processed, it can notify the "receiver" via the callback function. The implementation details include BitTube.cpp and Looper.cpp, and interested readers can study it by themselves.