Overview of the relationship between Android application and surfaceflinger service and learning plan [turn]

Turn from https://blog.csdn.net/luoshengyang/article/details/7846923

The surfaceflinger service is responsible for drawing the UI of Android applications. Its implementation is quite complex. It is not easy to analyze its implementation from the front. Since we can't analyze it from the front, we'll try to analyze it from the side. In the final analysis, no matter how complex the surfaceflinger service is, it serves Android applications. Therefore, we will start with the relationship between Android applications and surfaceflinger services to outline and formulate the learning plan of surfaceflinger services.

The surfaceflinger service runs in the system process of the Android system and is responsible for managing the frame buffer of the Android system. For the relevant knowledge of the frame buffer of Android system, you can refer to the analysis of the boot screen display process of Android system and the implementation principle analysis of the hardware abstraction layer (HAL) module of Android frame buffer in the previous two articles. In order to draw their UI on the frame buffer of the system, Android applications must communicate with the surfaceflinger service, as shown in Figure 1:

Figure 1 Relationship between Android application and surfaceflinger service

Note that Android applications and surfaceflinger services run in different processes, so they use binder inter process communication mechanism to communicate. For the relevant knowledge of binder interprocess communication mechanism of Android system, please refer to the series of articles on binder brief introduction and learning plan of Android interprocess communication (IPC) mechanism.

Add an anonymous shared memory used to transfer UI metadata to the connection between each Android application and surfaceflinger service, and we get Figure 2, as shown below:

In the view of application and client, the native anonymous shared memory block between them is a living fat circle. Therefore, application and client don't like this native anonymous shared memory. Therefore, this native anonymous shared memory was angry at that time and determined to counter attack and become baifumei, as shown in Figure 3:

After Tu feiyuan's counter attack, it became a white Fumei named sharedclient. From then on, it lived a happy life with application and client.

How white, rich and beautiful is sharedclient? See Figure 4:

In each sharedclient, there are at most 31 sharedbuffersacks. Literally, sharedbufferstack is a shared buffer stack. How to understand? First, shared indicates that the stack is shared. So who will share it? Android apps and surfaceflinger services, of course. Second, buffer indicates that the contents of the stack are buffers. What kind of buffer? Of course, it is the buffer used to describe UI metadata. Furthermore, stack indicates that the buffer used to describe UI metadata needs to be accessed according to certain rules. Taken together, we can think that each shared buffer stack is used to describe a series of buffers that need to be accessed according to certain rules.

Still can't seem to understand sharedbufferstack? Well, recall that when we draw the UI, we usually use a technology called "double buffering". Double buffering means using two buffers, one called front buffer and the other called back buffer. The UI is always drawn in the back buffer first, then exchanged with the front buffer and rendered to the display device. Now you can understand the meaning of shared buffer stack? The surfaceflinger service just sublimates and abstracts the traditional "double buffering" technology into a sharedbufferstack. Don't underestimate this sublimation and abstraction. With sharedbufferstack, the surfaceflinger service can draw the UI using N buffer technologies. The value of N ranges from 2 to 16. For example, in Android 2.3, the value of n is equal to 2, while in Android 4.1, it is said to be equal to 3.

What does sharedbufferstack look like? See Figure 5:

Free buffers are easy to understand. Next, we will focus on the buffers that have been used, namely buffer-1 and buffer-2 in Figure 5.

As we mentioned 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 the graphicbuffer, which will be described later. Therefore, in order to completely describe a UI, each used buffer in sharedbufferstack corresponds to a graphicbuffer to describe the real UI data. When the surfaceflinger service slows buffer-1 and buffer-2, it will find the corresponding graphicbuffer, so that the corresponding UI can be drawn.

When an Android application needs to update a surface, it will find its corresponding sharedbufferstack and take out a free buffer from the end of its free buffer list. Let's assume that the number of the extracted free buffer is index. Next, the Android application requests the surfaceflinger service to allocate a graphics buffer graphicbuffer for the buffer numbered index. After the surfaceflinger service allocates the graphics buffer graphicbuffer, it will set its number to index, and then return the graphics buffer graphicbuffer to the Android application for access. After the Android application obtains the graphics buffer graphicbuffer returned by the surfaceflinger service, it writes UI data in it. After writing, insert the buffer corresponding to it, that is, the buffer numbered index, into the header of the used buffer list of the corresponding sharedbufferstack. After this step is completed, the Android application notifies the surfaceflinger service to draw the graphic buffer described in the used buffer. Using the example in Figure 5, the surfaceflinger service needs to draw the graphics buffer graphicbuffer corresponding to the buffers numbered 1 and 2. Since the surfaceflinger service knows where the graphics buffer graphicbuffer corresponding to the buffers numbered 1 and 2 is, the Android application only needs to tell the surfaceflinger service the number of the buffer to be drawn. When a used buffer is drawn, it becomes an idle buffer again.

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

Sharedbufferstack is shared between Android applications and surfaceflinger services. However, Android applications and surfaceflinger services use sharedbufferstack differently. Specifically, Android applications care about the list of free buffers in it, The surfaceflinger service cares about the list of buffers that have been used in it. From the perspective of the surfaceflinger service, the used buffers stored in the sharedbufferstack are actually queued for rendering.

In order to facilitate the access of sharedbufferstack in Android application and surfaceflinger service, the Android system uses sharedbufferclient and sharedbufferserver to describe sharedbufferstack respectively. Sharedbufferclient is used to access the free buffer list of sharedbufferstack on this side of Android application, Sharedbufferserver is used to access the queued buffer list of sharedbufferstack on the side of surfaceflinger service.

In the view of sharedbufferclient, sharedbufferstack looks as shown in Figure 6:

As long as the number of available buffers in the sharedbufferstack is greater than 0, the sharedbufferclient will move the pointer tail one step forward and reduce the available value so that an idle buffer can be obtained. After the Android application writes data to the idle buffer, it will add it to the end of the queued buffer list in the sharedbufferstack through the sharedbufferclient, that is, the pointer queue_ Head's next position.

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, the sharedbufferserver will draw the next buffer of the pointer head, move the pointer head forward one step, and reduce the value of queued by 1.

We mentioned the graphic buffer many times above. What is it? Let's look at figure 8:

Each graphicbuffer contains a buffer for storing UI data, which uses a buffer_ handle_ T object. See buffer_ handle_ t. Does it look familiar? In the previous article on the analysis of the implementation principle of Android frame buffer hardware abstraction layer (HAL) module grassoc, we said that the graphics buffer allocated by the grassoc module of Hal layer uses a buffer_ handle_ T object, and buffer_ handle_ The graphics buffer described by the t object is either allocated in the system frame buffer or anonymous shared memory. In this way, we can associate the surfaceflinger service with the gradoc module in the Hal layer.

So far, the relationship between Android application and surfaceflinger service has been summarized, but our task has not been completed. We need to further study it specifically, for example: