Window management can be said to be the most complex part of the Android system, mainly because it involves more modules, although it is said to be window management, Windows ManagerService includes SurfaceFlinger service, Linux shared memory and TMPFS file system, Binder communication, InputManagerService, animation, VSYNC synchronization, etc. However, you can first have a general outline of the window display and management, and then decompose it into blocks. The knowledge points involved are as follows:

PNG window management knowledge graph

The role of WMS is that window management is not responsible for View drawing

Since this is an overview, let’s think about how an Activity is rendered on the screen, or how a View is drawn on the screen. More or less, developers know that WindowManagerService is responsible for managing Windows on Android, but it is really only responsible for managing Windows, such as adding, removing, reordering, etc. As for drawing and compositing images, it is not the domain of WMS management. WMS is more like an abstraction of The Android window at a higher level. It is the APP side that really completes the image drawing, and SurfaceFlinger service that completes the layer composition. Here is a simple floating window to explore the general flow:

TextView mview=new TextView(context); . <! MWindowManager = (WindowManager) getSystemService(context.window_service); WindowManager.LayoutParams wmParams = new WindowManager.LayoutParams(); wmParams.type = WindowManager.LayoutParams.TYPE_TOAST; wmParams.format = PixelFormat.RGBA_8888; wmParams.width = 800; wmParams.height = 800; mWindowManager.addView(mview, wmParams);Copy the code

The above code can add a TextView to the home screen and display it, and the TextView occupies a window. TextView’s onDraw will not be called until a window is added using WindowManager.addView, so the View must be added to the window before it can be drawn. When an APP adds a window to it through a WindowManagerService agent, The WindowManagerService needs to apply for a Surface canvas from The SurfaceFlinger service. In fact, it is mainly a piece of memory corresponding to the back of the canvas. Only after this piece of memory is successfully applied, can the APP end have the target of drawing, and this piece of memory is shared by the APP end and SurfaceFlinger server, which saves the copy of drawing resources. The schematic diagram is as follows:

Drawing principle. JPG

The above is the abstract layer correspondence. It can be seen that APP side can communicate with SurfaceFlinger directly through unLockCanvasAndPost for redrawing, that is to say, the drawing of graphics has nothing to do with WMS. WMS is only responsible for window management, not window drawing. This can also be seen with IWindowSession’s Binder interface:

interface IWindowSession {

    int add(IWindow window, int seq, in WindowManager.LayoutParams attrs,
            in int viewVisibility, out Rect outContentInsets,
            out InputChannel outInputChannel);

    int addToDisplay(IWindow window, int seq, in WindowManager.LayoutParams attrs,
            in int viewVisibility, in int layerStackId, out Rect outContentInsets,
            out InputChannel outInputChannel);

    int relayout(IWindow window, int seq, inWindowManager.LayoutParams attrs, int requestedWidth, int requestedHeight, int viewVisibility, int flags, out Rect outFrame, out Rect outOverscanInsets, out Rect outContentInsets, out Rect outVisibleInsets, out Configuration outConfig, out Surface outSurface); void remove(IWindow window); . }Copy the code

As can be seen from the parameters, APP communicates with WindowManagerService without any view-related information, let alone passing the View data to WMS. The basic unit of communication is IWindow, so the operations involved are also for Windows. For example, the whole window is added, removed, resized, grouped, etc. From the perspective of the window display alone, the role of WMS is really clear, is to register the current live window on the server, as you will see later, this will affect the SurfaceFlinger layer mixing, can be said to serve SurfaceFlinger.

For example, Dialog must use the Context of an Activity, PopupWindow cannot be used as the parent window, especially avoid being used as a Webview container, etc. These are all related to the organization of the WMS window. PopupWindow, Dialog and Activity all have the concept of a window, but they are different. Activity belongs to an application window, PopupWindow belongs to a sub-window, and Dialog is located between them. In nature, it belongs to an application window, but intuitively, More like a child window (it’s not). Android Windows are mainly divided into three types: system window, application window and sub-window. Toast belongs to system window, while Dialog and Activity belong to application window. However, Dialog can exist only if it is attached to Activity. PopupWindow is a child window that must be attached to another window, either an application window or a system window, but not a child window.

Window organization form.jpg

Of course, WMS does more than just manage Windows. It is also responsible for window animations, Touch events, and so on, which will be analyzed module-by-module later.

View rendering and data transfer

Since THE role of WMS is just window management, how are graphics drawn? And how does this drawing information get passed to the SurfaceFlinger service? Each View has its own onDraw callback, developers can draw their own image in onDraw, it is obvious that the View drawing is in the APP side, intuitively understood, View drawing will not be handed over to the server, otherwise it is too independent, but when is the memory of View drawing allocated? Who distributed it? We know that each Activity can be regarded as a layer, and its corresponding drawing Surface is actually a Surface. The memory corresponding to the Surface drawing Surface is actually applied by SurfaceFlinger, and the memory is shared between APP and SurfaceFlinger process. The implementation mechanism is shared memory based on Linux, which is actually MAP+ TMPFS file system. SF applies for a piece of memory for APP, and then transmits the information related to this memory to APP end through binder. APP end draws content in this memory, and notifies SF to mix layers after drawing. SF then renders the data to the screen. In fact, this is reasonable, because the image memory is large, common binders and sockets can not meet the requirements, memory sharing schematic diagram is as follows:

View drawing with shared memory. JPG

conclusion

In fact, the entire Android window management simplification can be divided into the following three parts

  • WindowManagerService: WMS controls the addition and ordering of Surface canvases, animations, and touch events
  • SurfaceFlinger: SF is responsible for blending layers and transferring the results to hardware display
  • APP side: Each APP is responsible for drawing the corresponding layer,
  • APP communicates with SurfaceFlinger: Data sharing between APP and SF layer is achieved through anonymous memory.

Analysis of Android window management (1) : Window management and subjective understanding

For reference only, welcome correction