A brief analysis of Android drawing principles

background

For Android development, during the interview, I am often asked, "Can you talk about the drawing process of View?" I also often ask the interviewer, "The drawing process of View".

For developers with more than 3 years of experience, knowing the basics of onMeasure/onLayout/onDraw and what they do is enough?

If you come to our company and I am your interviewer, I may examine what you have done in the past three years, what you know about View, and ask more detailed questions, such as LinearLayout's onMeasure and onLayout processes? When are they initiated and what is the execution order?

If you know all the above questions, you may be ready to join our company (if you need an internal recommendation, you can contact me, both Android and IOS positions are needed). I may check where your draw canvas comes from, how it is created and displayed on the screen? See how deep you are.

As the current mobile development market is gradually becoming mature and saturated, many companies that are not short of people need senior programmers. Besides, as we all know, the interview requires you to build airplanes and cannons, and then screw in the screws. For an Android developer with more than 3 or 5 years of experience, it is not easy to get along without knowing a little bit about Android. After talking about so many useless things, let's get back to today's topic, a brief analysis of Android's drawing principles.

This article introduces the idea

From a few relatively easy questions in the interview, we go deeper and deeper, until we get to the drawing principle of the screen.

Before talking about the drawing principles of Android, let's first introduce the basic working principles of View in Android. This article will not introduce the event transmission process.

How View Drawing Works

Let's first understand a few important classes, which are also often asked in interviews.

The relationship between Activity, Window (PhoneWindow) and DecorView

To understand the relationship between the three, let's look at the code directly, starting with setContentView at the beginning of Activity (Note: the code deletes some codes that are not part of this analysis process to avoid being too long)

 //Activity
 /**
 * Set the activity content from a layout resource. The resource will be
 * inflated, adding all   top - level views to the activity.
 *
 * @param layoutResID Resource ID to be inflated.
 *
 * @see #setContentView(android. view . View )
 * @see #setContentView(android. view . View , android. view .ViewGroup.LayoutParams)
 */
 public void setContentView(@LayoutRes int layoutResID) {
 getWindow().setContentView(layoutResID);
 initWindowDecorActionBar();
 } 
  
 public Window getWindow() {
 return mWindow;
 }

The setContentView of getWindow called inside is discussed next. So when is this mWindow created?

 //Activity
 private Window mWindow;
 final void attach(Context context, ActivityThread aThread,····) {
 attachBaseContext(context);
 mFragments.attachHost( null /*parent*/);
 mWindow = new PhoneWindow(this, window, activityConfigCallback);
 }

PhoneWindow is created in Activity's attach, and PhoneWindow is the implementation class of Window.

Continue with the previous setContentView

 //PhoneWindow
 @Override
 public void setContentView( int layoutResID) {
 if (mContentParent == null ) {
 installDecor();
 } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
 mContentParent.removeAllViews();
 }
 if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
 final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
 getContext());
 transitionTo(newScene);
 } else {
 mLayoutInflater.inflate(layoutResID, mContentParent);
 }
 }

In setContentView, if mContentParent is empty, installDecor will be called, and finally the layout will be infalte to mContentParent. Let's take a look at installDecor

 //PhoneWindow
 // This is the view   in which the window contents are placed. It is either
 // mDecor itself, or a child of mDecor where the contents go.
 ViewGroup mContentParent; 
  
 private DecorView mDecor; 
  
 private void installDecor() {
 mForceDecorInstall = false ;
 if (mDecor == null ) {
 mDecor = generateDecor(-1);
 } else {
 mDecor.setWindow(this);
 }
 if (mContentParent == null ) {
 mContentParent = generateLayout(mDecor);
 }
 }
 protected DecorView generateDecor( int featureId) {
 return new DecorView(context, featureId, this, getAttributes());
 }

In installDecor, a DecorView is created. Looking at the comment of mContentParent, we can know that it is mDecor itself or the contents part of mDecor.

In summary, we roughly know the relationship between the three.

• Activity contains a PhoneWindow.
• PhoneWindow is inherited from Window
• Activity sets the View to PhoneWindow via setContentView
• PhoneWindow contains DecorView, and the final layout is added to Decorview.

Understand the relationship between ViewRootImpl, WindowManager, and WindowManagerService (WMS)

After looking at the relationship between the above three, we know that the layout is finally added to DecorView. So how is DecorView added to the system's Framework layer?

When the Activity is ready, makeVisible in the Activity will be called and View will be added through WindowManager. The code is as follows

 //Activity
 void makeVisible() {
 if (!mWindowAdded) {
 ViewManager wm = getWindowManager();
 wm.addView(mDecor, getWindow().getAttributes());
 mWindowAdded = true ;
 }
 mDecor.setVisibility( View .VISIBLE);
 }

So what is the relationship between them? (The client and server mentioned below are the client and server concepts in Binder communication.)

The following content is the key part that needs to be understood

• ViewRootImpl (client): View holds mAttachInfo linked to WMS, and mAttachInfo holds ViewRootImpl. ViewRootImpl is the implementation of ViewRoot. When WMS manages the window, it needs to notify the client to perform some operations, such as event response. ViewRootImpl has an internal class W, which inherits IWindow.Stub, which is actually a Binder, and is used to interact with WMS IPC. ViewRootHandler is also its internal class that inherits Handler, and is used to make asynchronous calls with the data returned by the remote IPC.
• WindowManger (client): The client needs to create a window, and the specific task of creating a window is completed by WMS. WindowManger is like a department manager. Whoever has any needs tells it. It interacts with WMS. The client cannot interact directly with WMS.
• WindowManagerService (WMS) (server): responsible for window creation, display, etc.

Redrawing of View

From the above relationship, ViewRootImpl is used to receive messages from WMS. Then let's take a look at some View drawing codes in ViewRootImpl.

Here I would like to emphasize that ViewRootImpl has two important internal classes

• The W class inherits Binder and is used to receive messages from WMS.
• The ViewRootHandler class inherits Handler and receives asynchronous messages from the W class

Let's take a look at the ViewRootHandler class. (Take View's setVisible as an example.)

 // ViewRootHandler (an inner class of ViewRootImpl, used for asynchronous message processing, very similar to the startup of Acitivity)
 //The first step Handler receives the message passed by W (Binder)
 @Override
 public void handleMessage(Message msg) {
 switch (msg.what) {
 case MSG_INVALIDATE:
 (( View ) msg.obj).invalidate();
 break;
 case MSG_INVALIDATE_RECT:
 final View .AttachInfo.InvalidateInfo info = ( View .AttachInfo.InvalidateInfo) msg.obj;
 info.target.invalidate(info. left , info. top , info. right , info.bottom);
 info.recycle();
 break;
 case MSG_DISPATCH_APP_VISIBILITY://Handling Visible
 handleAppVisibility(msg.arg1 != 0);
 break;
 }
 } 
  
 void handleAppVisibility(boolean visible) {
 if (mAppVisible != visible) {
 mAppVisible = visible;
 scheduleTraversals();
 if (!mAppVisible) {
 WindowManagerGlobal.trimForeground();
 }
 }
 } 
  
 void scheduleTraversals() {
 if (!mTraversalScheduled) {
 mTraversalScheduled = true ;
 mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
 //Start the next refresh and traverse the View tree
 mChoreographer.postCallback(
 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null );
 if (!mUnbufferedInputDispatch) {
 scheduleConsumeBatchedInput();
 }
 notifyRendererOfFramePending();
 pokeDrawLockIfNeeded();
 }
 }

Take a look at mTraversalRunnable

 final class TraversalRunnable implements Runnable {
 @Override
 public void run() {
 doTraversal();
 }
 }
 final TraversalRunnable mTraversalRunnable = new TraversalRunnable(); 
  
 void doTraversal() {
 if (mTraversalScheduled) {
 mTraversalScheduled = false ;
 mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
 performTraversals();
 }
 }

In TraversalRunnable, execute doTraversal. And execute performTraversals() in doTraversal. Do you see the familiar performTraversals()? Yes, the drawing of View starts here.

In ViewRootImpl's performTraversals(), this method code is very long (about 800 lines of code), the general process is

1. Determine whether the view size needs to be recalculated, and if necessary, execute performMeasure()
2. Do you need to relocate the location, performLayout()
3. Do you need to redraw performDraw()?

So what causes the View to be redrawn? Here are three main reasons:

1. Changes in the internal state of the view itself (enable, pressed, etc.) may cause redrawing
2. View is added or deleted inside View
3. The size and visibility of the View itself has changed

View drawing process

In the previous section, performTraversals() is called by WMS IPC. The drawing process of View is generally

From performTraversals -> performMeasure() -> performLayout() -> performDraw().

Let's take a look at performMeasure()

 //ViewRootImpl
 private void performMeasure( int childWidthMeasureSpec, int childHeightMeasureSpec) {
 if (mView == null ) {
 return ;
 }
 Trace.traceBegin(Trace.TRACE_TAG_VIEW, "measure" );
 try {
 mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
 finally
 Trace.traceEnd(Trace.TRACE_TAG_VIEW);
 }
 } 
  
 public final void measure( int widthMeasureSpec, int heightMeasureSpec) {
 MeasureSpec.getMode(widthMeasureSpec) == MeasureSpec.EXACTLY
 && MeasureSpec.getMode(heightMeasureSpec) == MeasureSpec.EXACTLY;
 final boolean matchesSpecSize = getMeasuredWidth() == MeasureSpec.getSize(widthMeasureSpec)
 && getMeasuredHeight() == MeasureSpec.getSize(heightMeasureSpec);
 final boolean needsLayout = specChanged
 && (sAlwaysRemeasureExactly || !isSpecExactly || !matchesSpecSize);
 if (forceLayout || needsLayout) {
 mPrivateFlags &= ~PFLAG_MEASURED_DIMENSION_SET;
 resolveRtlPropertiesIfNeeded();
 int cacheIndex = forceLayout ? -1 : mMeasureCache.indexOfKey( key );
 if (cacheIndex < 0 || sIgnoreMeasureCache) {
 //The onMeasure method is called here
 onMeasure(widthMeasureSpec, heightMeasureSpec);
 mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
 }
 }
 }

Finally, the measure method of View is called, and the measure() method in View is defined as final type to ensure the execution of the entire process. performLayout() and performDraw() are similar processes.

For programmers, customizing View only requires paying attention to the corresponding methods it provides, onMeasure/onLayout/onDraw. There are many online materials introducing this knowledge, and you can also easily see the code in View and ViewGroup. It is recommended to read the source code of LinerLayout to understand this part of knowledge, which will not be elaborated here.

A Brief Analysis of Android's Drawing Principles

Android screen drawing

As for drawing, we have to start with performDraw(). Let's take a look at how this process is drawn.

 //ViewRootImpl
 //1
 private void performDraw() {
 try {
 draw(fullRedrawNeeded);
 finally
 mIsDrawing = false ;
 Trace.traceEnd(Trace.TRACE_TAG_VIEW);
 }
 } 
  
 //2
 private void draw(boolean fullRedrawNeeded) {
 Surface surface = mSurface;
 if (!surface.isValid()) {
 return ;
 } 
  
 if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {
 return ;
 }
 } 
  
 //3
 private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,
 boolean scalingRequired, Rect dirty) {
 Canvas canvas = mSurface.lockCanvas(dirty);
 }

Look at the code execution flow, 1—>2->3, finally get the Java layer canvas, and then perform a series of drawing operations. The canvas is obtained through Suface.lockCanvas().

So what is Surface? Here Surface is just an abstraction. When the APP creates a window, it will call WindowManager to initiate a request to the WMS service, carrying the surface object. Only when it is allocated a screen buffer can it actually correspond to a window on the screen.

Let's take a look at the drawing architecture in the Framework. Better understanding of Surface

Surface essentially represents only a plane. Drawing different patterns is obviously an operation, not a piece of data. Android uses the Skia drawing driver library to draw on the plane, and uses canvas to represent this function in the program.

Introduction to Double Buffering Technology

In ViewRootImpl, we see that after receiving the drawing message, it does not draw immediately but calls scheduleTraversals, and calls Choreographer.postCallback() in scheduleTraversals. Why is this? This actually involves the principle of screen drawing (other platforms are similar except Android).

We all know that the display refreshes at a fixed frequency, such as 60Hz for iPhone and 120Hz for iPad Pro. When one frame of image is drawn and ready to draw the next frame, the display will send a vertical synchronization signal (VSync), so a 60Hz screen will send such a signal 60 times in one second.

And generally speaking, in a computer system, the CPU, GPU, and display work together in a specific way: the CPU submits the calculated display content to the GPU, the GPU renders it and puts it into the frame buffer, and then the video controller takes the frame data from the frame buffer according to the VSync signal and passes it to the display for display.

However, if the screen has only one buffer, when the VSync signal is sent, the screen starts to refresh, and what you see on the screen is data changing line by line. In order to make the screen look like frame by frame data, there are usually two buffers (also called double buffers). When the data is to be refreshed, the data in the other buffer is directly replaced.

In double buffering technology, if the data in the buffer cannot be refreshed within a specific time (if it is 60HZ, it is within 16ms), the screen sends a VSync synchronization signal, and the switching between the two buffers cannot be completed, then it will cause a freeze.

Back to scheduleTraversals(), this is where double buffering technology (or triple buffering technology) is used. Choreographer receives the synchronization signal of VSync, and when the screen is refreshed, it starts the screen refresh operation.