The starting and working principle of Surfaceflinger
Start of 1.1.1 Surfaceflinger
Surfaceflinger startup and ServiceManager are similar, they all belong to the system's underlying support services, must be in the early start of the device to run.
/*frameworks/base/cmds/system_server/library/system_init.cpp*/
extern "C" status_t system_init ()
{...
Property_get ("System_init.startsurfaceflinger", Propbuf, "1");
if (strcmp (Propbuf, "1") = = 0) {
Surfaceflinger::instantiate ();
}...
This system_init.cpp will be compiled into the Libsystem_server library and then loaded by systemserver at the JNI layer to start system services including Surfaceflinger, Sensorservice, and so on.
As Audioflinger/audiopolicyservice sees, it calls instantiate to create a binder server named "Surfaceflinger." And the strong pointer feature makes it call Onfirstref when it is first referenced:
void Surfaceflinger::onfirstref ()
{
Meventqueue.init (this);//Initialize event queue
Run ("Surfaceflinger", priority_urgent_display);//Start a new business thread
Mreadytorunbarrier.wait ()//Waiting for new thread to start
}
Member Variable meventqueue is a MessageQueue type of object, we have in the Process section has detailed analysis of Message Queuing and Looper, handler and other classes of use, we can go back to reference ( Although these classes in the Java layer differ somewhat from those used in Surfaceflinger, they are essentially the same. Now that there are message queues, there must be a matching event handler handler and a loop-body looper, created in the Messagequeue::init function, namely:
/*frameworks/native/services/surfaceflinger/messagequeue.cpp*/
void Messagequeue::init (const sp<surfaceflinger>& Flinger)
{
Mflinger = Flinger;
Mlooper = Newlooper (true);
Mhandler = Newhandler (*this);
}