Reprinted from: http://www.360doc.com/content/19/0927/10/8335678_863480139.shtml
I recently learned about several concepts about views in Android: Surface, View, SurfaceView, and Window. Here is a summary.
BufferQueue
Before that, we first introduce BufferQueue.
The BufferQueue class is the core of all graphics processing operations in Android. Its role is simple: connect the party that generates the graphic data buffer (the producer) to the party that receives the data for display or further processing (the consumer). Almost all the contents of the graphics data buffer in the system are dependent on BufferQueue.
In short, BufferQueue is a communication bridge in the graphics producer consumer model.
Its basic usage is simple: the producer requests an available buffer (dequeueBuffer()) and specifies a set of characteristics, including width, height, pixel format, and usage flags. The producer fills the buffer and returns it to the queue (queueBuffer()). Subsequently, the consumer acquires the buffer (acquireBuffer()) and uses the contents of the buffer. When the consumer operation is completed, the buffer is returned to the queue (releaseBuffer()).
For more detailed introduction, please refer to the official document:
https://source.android.com/devices/graphics/arch-bq-gralloc
SurfaceFlinger
Before introducing Surface, we also need to understand SurfaceFlinger.
The role of SurfaceFlinger is to accept data buffers from multiple sources, synthesize them, and then send them to the display device.
When another service requests a drawing Surface from SurfaceFlinger, it will create a new layer whose main component is BufferQueue (the layer blogger here refers to the meaning of layer by layer view), and set itself as consumption square. Most applications usually have three layers on the screen: the status bar at the top of the screen, the navigation bar at the bottom or side, and the application interface.
For more detailed introduction, please refer to the official document:
https://source.android.com/devices/graphics/arch-sf-hwc
Surface
Since 1.0, the Surface class has been part of the public API. Its description is as simple as: "Processing on the original buffer managed by the screen synthesizer".
Surface represents the producer of the buffer queue that is usually (but not always!) consumed by SurfaceFlinger. When you render to the Surface, the result will enter the relevant buffer, which is passed to the consumer.
To put it simply, the blogger thinks that we can treat the Surface as a layer of view. We draw images on the Surface, produce view data from the BufferQueue in it, and then give it to the consumer SurfaceFlinger to synthesize with other view layers, and finally display it to on the screen.
For more detailed introduction, please refer to the official document:
https://source.android.com/devices/graphics/arch-sh
https://developer.android.com/reference/android/view/Surface
Window
The Window class represents the top-level window of a view. It manages the top-most View in this view and provides standard UI processing strategies such as backgrounds, title bars, and default buttons.
At the same time, it has the only Surface for drawing its own content. When the app creates a Window through the WindowManager, the WindowManager will create a Surface for each Window and pass the Surface to the app so that the application can draw content on it.
The blogger believes that there was a one-to-one relationship between Window and Surface.
For more detailed introduction, please refer to the official document:
https://developer.android.com/reference/android/view/Window
View
I believe everyone is familiar with the View class. It is a basic unit in Android view.
It represents a rectangular area on the screen, and is responsible for drawing the area and processing click events on the area.
It and ViewGroup together form the cornerstone of the Android view through a combination of design patterns. Through the topmost ViewRootImpl, we can traverse the tree structure of View layer by layer.
The topmost View will be taken care of by a Window. After measuring, laying out, and drawing its complex hierarchical structure, all the content in it will eventually be drawn to the Surface owned by the Window.
For more detailed introduction, please refer to the official document:
https://developer.android.com/reference/android/view/View
SurfaceView
SurfaceView is a specially implemented View that has its own dedicated Surface so that the application can draw content directly in it.
It can be measured and laid out in a tree structure composed of Views like ordinary Views, but is independent of the Surface of the Window shared by ordinary Views. When it needs to be rendered, the content will become completely transparent, and the View part of the SurfaceView is just a transparent placeholder.
The working principle of SurfaceView is as follows. All it does is to ask WindowManager to create a Window and tell the Z-order of the Window created by WindowManager. This Z-order can help WindowManager decide to place the new window on SurfaceView. The front or back of the window to which it belongs.
Then, WindowManager will place the newly created Window to the position of the SurfaceView in its own Window. If the new Window is behind the Window to which the SurfaceView belongs, the SurfaceView will make the part it occupies in the Window to which it belongs to be transparent, so that the following Window can be displayed.