Overview of the relationship between Android apps and Surfaceflinger services and learning Plans

Article reprinted to CSDN community Luo Shenyang's Android tour, original address: http://blog.csdn.net/luoshengyang/article/details/7846923

surfaceflinger service is responsible for drawing the Span style= "color:black;" >android application ui It's very complex to implement, It is not an easy task to analyze its implementation from the front. Since we cannot analyze it from the front, we will try to analyze it from the side. In the final analysis, whether surfaceflinger How complex the service is, it's all for android application services, so we're going from application with surfaceflinger Service, to outline and formulate surfaceflinger service Learning Plan.

The Surfaceflinger service runs in the system process of Android, and it is responsible for managing the frame buffer of the Android system. The knowledge of the frame buffer of the Android system can be referenced in the previous two articles on the Android system's boot screen display process analysis and the implementation of the Android Framebuffer (frame buffer) Hardware abstraction layer (HAL) module GRALLOC. Android applications must communicate with the Surfaceflinger service in order to be able to draw their own UI on the frame buffer of the system, as shown in 1:

Figure 1 The relationship between the Android application and the Surfaceflinger service

Note that Android applications and Surfaceflinger services are running in different processes, so they use the binder interprocess communication mechanism to communicate. The knowledge of the binder interprocess communication mechanism of the Android system can refer to the Android interprocess communication (IPC) Mechanism Binder Brief introduction and Learning plan for this series of articles.

In Figure 1, each Android application has a connection to the Surfaceflinger service, which is described by a Binder object of type client. These client objects are created by the Surfaceflinger service when the Android application connects to the Surfaceflinger service, and when the Android application successfully connects to the Surfaceflinger service, You can obtain a Binder agent interface for the corresponding client object. With these binder proxy interfaces, the Android application can notify the Surfaceflinger service to draw its own UI.

When the Android application notifies the Surfaceflinger service to draw its own UI, it needs to pass the UI metadata to the Surfaceflinger service, such as the area, location, and so on, to draw the UI. An Android application may have many windows, and each window has its own UI metadata, so the UI metadata that Android applications need to pass to the Surfaceflinger service is quite impressive. In this case, it is inappropriate to pass the UI metadata between the Android application and the Surfaceflinger service through the binder interprocess communication mechanism, when the anonymous shared memory mechanism of the Android system (Anonymous shared Memory) comes in handy. Knowledge of the anonymous shared memory mechanism of the Android system, you can refer to the Android system anonymous shared memory Ashmem (Anonymous shared Memories) for a brief introduction and learning plan for this series of articles.

With the addition of an anonymous shared memory that is used to pass the UI metadata to the connection between each Android application and the Surfaceflinger service, we get Figure 2 as follows:

Figure 2 Anonymous shared memory used to pass UI metadata between Android applications and the Surfaceflinger service

In application and client the two high-handsome, the original anonymous shared memory between them is a berthelot off the soil and fertilizer circle. As a result, application and client do not see this native anonymous shared memory. So, this native anonymous shared memory was angry at the time, determined to reverse the attack into white rich beauty, 3:

Figure 3 A structured block of anonymous shared memory used to pass UI metadata

After the reverse attack, it became a name for sharedclient white rich beauty, from then on, and application, the client has a happy pa pa life.

Sharedclient how white and rich and beautiful? See Figure 4:

Figure 4 Sharedclient to describe the UI metadata for an Android application

Within each sharedclient, there are up to 31 sharedbufferstack. In the literal sense, sharedbufferstack is the shared buffer stack. How do you understand it? First, GKFX indicates that the stack is shared. So who's going to share it? Android apps and Surfaceflinger services, of course. Second, buffer indicates that the contents of this stack are buffers. What kind of buffer is it? Is, of course, the buffer used to describe the UI metadata. In addition, stack indicates that the buffer used to describe the UI metadata needs to be accessed according to certain rules. Together, we can assume that each sharedbufferstack is used to describe a series of buffers that need to be accessed according to certain rules.

Doesn't seem to understand the sharedbufferstack? Well, remember, usually when we draw the UI, we use a technique called "double buffering." Double buffering means using two buffers, one of which is called front buffer, and the other is called back buffer. The UI is always drawn in the back buffer and then swapped with front buffer to render to the display device. Can you understand the meaning of sharedbufferstack? Surfaceflinger service is simply the sublimation and abstraction of traditional "double buffering" technology for a sharedbufferstack. Don't underestimate this sublimation and abstraction, with Sharedbufferstack, the Surfaceflinger service can draw the UI using N buffer technology. The values for n values range from 2 to 16. For example, in Android 2.3, the value of N equals 2, while in Android 4.1 it is said to be equal to 3.

We can also further understand Sharedbufferstack. In the Surfaceflinger service, each sharedbufferstack corresponds to a surface, which is a window. In this way, we can see why each sharedclient contains a series of sharedbufferstack instead of a single sharedbufferstack: A sharedclient corresponds to an android application, An Android application may contain multiple windows, surface. As you can see from here, an Android app can contain up to 31 surface.

What does Sharedbufferstack look like? Look at Figure 5:

Figure 5 Structure of the Sharedbufferstack

In Figure 5, to facilitate the description, we assume that the sharedbufferstack in the figure has 5 Buffer, where Buffer-1 and Buffer-2 are already used, while Buffer-3, Buffer-4, and Buffer-5 are idle. The pointer head and tail point to the head and tail of the free buffer list respectively, and the pointer queue_head to the head of the list of buffers already in use. As can be seen from here, the buffer between the pointer tail to the head is the free buffer table, and the buffer from the pointer head to the Queue_head is the list of buffers that have been used. Note that the 5 buffer in the figure is used in a loop.

The free buffer is better understood, and then we'll focus on the buffers that have been used, namely Buffer-1 and Buffer-2 in Figure 5.

As we said earlier, buffers in Sharedbufferstack are only used to describe UI metadata, which means that they do not contain real UI data. The real UI data is saved in Graphicbuffer, and we'll describe Gaphicbuffer later. Therefore, in order to fully describe each of the buffers that have been used in a ui,sharedbufferstack, there should be a graphicbuffer to describe the real UI data. When the Surfaceflinger service eases Buffer-1 and Buffer-2, it will find the graphicbuffer corresponding to them, so that the corresponding UI can be drawn.

When an Android application needs to update a surface, it will find the sharedbufferstack it corresponds to and take out a free buffer from the end of its list of free buffers. We assume that the number of the free buffer that is taken out is index. The Android application then requests the Surfaceflinger service to assign a graphics buffer graphicbuffer to the buffer with the number index. After the Surfaceflinger service allocates the graphics buffer Graphicbuffer, it sets its number to index, and then returns the graphics buffer Graphicbuffer to the Android application for access. After the Android application gets the graphics buffer Graphicbuffer returned by the Surfaceflinger service, it writes UI data inside. After writing, it will be inserted into the head of the buffer list that corresponds to the buffer, which is numbered index, into the corresponding sharedbufferstack. When this is done, the Android application notifies the Surfaceflinger service to draw the graphics buffer graphicbuffer that is stored in the buffer that has been used. In the example in Figure 5, the Surfaceflinger service needs to draw the graphics buffer graphicbuffer corresponding to buffer numbers 1 and 2. Since the Surfaceflinger service knows where the graphics buffers for buffer numbers 1 and 2 are Graphicbuffer, The Android app just needs to tell the Surfaceflinger service to draw the buffer number on the OK. When a buffer that has already been used is drawn, it becomes a free buffer again.

The process described above is more complex, and we will use several articles to describe it in detail later.

Sharedbufferstack is shared between Android apps and Surfaceflinger services, however, The way Android apps and Surfaceflinger services use Sharedbufferstack is different, specifically, the Android app is concerned with the list of free buffers inside it, The Surfaceflinger service is concerned with the list of buffers that are already in use within it. From the point of view of the Surfaceflinger service, the already used buffers stored in Sharedbufferstack are actually queued for rendering.

To facilitate sharedbufferstack access in Android apps and Surfaceflinger services, The Android system uses sharedbufferclient and Sharedbufferserver respectively to describe the Sharedbufferstack, where Sharedbufferclient is used to access Sharedbufferstack's free buffer list on this side of the Android application, Instead, Sharedbufferserver is used to access the list of queued buffers for sharedbufferstack on the Surfaceflinger service side.

In Sharedbufferclient's view, Sharedbufferstack looks like 6:

Fig. 6 Sharedbufferstack in Sharedbufferclient eyes

As long as the number of available in the Sharedbufferstack is greater than 0,sharedbufferclient, the pointer tail is moved one step forward and the available value is reduced so that a free buffer can be obtained. When the Android application writes good data to this free buffer, it adds it to the end of the list of queued buffer buffers in the Sharedbufferstack by Sharedbufferclient, which is the pointer queue_ The next position in the head.

In Sharedbufferserver's view, Sharedbufferstack looks like 7:

Fig. 7 Sharedbufferstack in Sharedbufferserver eyes

When the Android application notifies the Surfaceflinger service to update the UI, as long as the number of queued buffers in the corresponding Sharedbufferstack is greater than 0, Sharedbufferserver will draw the next buffer of the pointer head and move the pointer head one step forward, and subtract the value of queued by 1.

We mentioned the graphics buffer Graphicbuffer many times, what is it? Let's look at Figure 8:

Figure 8 Structure of the graphics buffer graphic

Each graphicbuffer contains a buffer that is used to hold the UI data, which is described using a buffer_handle_t object. See buffer_handle_t, is not a bit familiar? In the front of the Android Framebuffer (frame buffer) Hardware abstraction layer (HAL) module Gralloc, we have said that the graphics buffer allocated by the Gralloc module of the HAL layer is using a buffer_handle_ T object, and the graphics buffer described by the Buffer_handle_t object is allocated either in the system framebuffer (frame buffer) or in anonymous shared memory (Anonymous). In this way, we can associate the Surfaceflinger service with the Gralloc module in the HAL layer.

At this point, the relationship between the Ndroid application and the Surfaceflinger service is outlined, but our task is not yet completed, and we have to go further to learn it concretely, for example:

1. How is the Android app connected to the Surfaceflinger service?

2. How is the sharedclient used to describe the UI metadata for an Android application created?

3. How does the Android app request the Surfaceflinger service to create a surface?

4. How does the Android app request the Surfaceflinger service to render a surface?

After answering these 4 questions, I believe we can have a deep understanding of Surfaceflinger service, which can help us to analyze the implementation of Surfaceflinger service from the front. In the back we will use the Android system to start the animation as an example, with 4 articles to answer these 4 questions, please pay attention!

Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo, welcome attention!

Overview of the relationship between Android apps and Surfaceflinger services and learning Plans