Three major processes of Android View drawing

introduce

The workflow of View mainly refers to the three major processes of measure, layout and draw, i.e., measure determines the measured width and height of View, layout determines the positions of the four vertices of View in its parent View according to the measured width and height, and draw draws View to the screen, so that through the recursive traversal of ViewGroup, a View tree is displayed on the screen. It is simple to say, let's analyze it step by step from the source code:

Android's View is a tree structure:

Basic Concepts

Before introducing the three major processes of View, we must first introduce some basic concepts to better understand the whole process.

The concept of Window

Window represents the concept of a window, which is an abstract concept from the perspective of WindowManagerService. All views in Android are presented through Windows, whether it is Activity, Dialog or Toast, as long as there is a View, there must be a Window.

It should be noted here that this abstract Window concept is not the same as the PhoneWindow class. PhoneWindow represents the abstraction of the mobile phone screen. It acts as a medium between Activity and DecorView. Even if there is no PhoneWindow, View can be displayed.

Putting everything aside, from the perspective of WindowManagerService alone, the Android interface is displayed by stacking windows, and Window is an abstract concept. It does not actually exist. It exists in the form of View, and this View is DecorView.

Regarding Window, let's first understand a general

Concept of DecorView

DecorView is the top-level View of the entire Window interface. The measurement, layout, drawing, and event distribution of the View are all done by DecorView traversing the View tree downwards. As the top-level View, DecorView generally contains a vertical LinearLayout inside. There are two parts in this LinearLayout (the specific situation depends on the Android version and theme), the upper part is the [title bar], and the lower part is the [content bar]. In the Activity, the layout file we set through setContentView is actually loaded into the [content bar], and the id of the content bar is content, so the method to specify the layout is called setContent().

The concept of ViewRoot

ViewRoot corresponds to the ViewRootImpl class, which is the link between WindowManager and DecorView. The three major processes of View are all completed through ViewRoot. In ActivityThread, when the Activity object is created, DecorView will be added to Window, and the corresponding ViewRootImpl will be created at the same time, and the ViewRootImpl and DecorView will be associated and saved in the WindowManagerGlobal object.

 WindowManagerGlobal.java 
 
 root = new ViewRootImpl( view .getContext(), display);
 root.setView( view , wparams, panelParentView);

Java

The drawing process of View starts from the performTraversals method of ViewRoot. It goes through three processes: measure, layout, and draw to finally draw a View. The general process is as follows:

Measure

In order to better understand the measurement process of View, we also need to understand MeasureSpec, which is an internal class of View and represents the measurement specifications of View. MeasureSpec represents a 32-bit int value, the upper 2 bits represent SpecMode (measurement mode), and the lower 30 bits represent SpecSize (measurement size). Let's take a look at its specific implementation:

 MeasureSpec.java 
 
 public   static class MeasureSpec {
        private static final int MODE_SHIFT = 30;
        private static final int MODE_MASK = 0x3 << MODE_SHIFT; 
 
 /**
 * UNSPECIFIED mode:
 * The parent View does not have any restrictions on the child View , the child View can be as large as needed
 */
 public   static final int UNSPECIFIED = 0 << MODE_SHIFT; 
 
 /**
 * EXACTYLY mode:
 * The parent View has measured the exact size required by the child View, and the final size of the View is now
 * is the value specified by SpecSize. Corresponds to the two modes of match_parent and exact value
 */
 public   static final int EXACTLY = 1 << MODE_SHIFT; 
 
 /**
 * AT_MOST mode:
 * The final size of the child View is the SpecSize value specified by the parent View , and the size of the child View cannot be larger than this value.
 * This corresponds to the wrap_content mode
 */
 public   static final int AT_MOST = 2 << MODE_SHIFT; 
 
 //Pack size and mode into a 32-bit int value
 //The upper 2 bits represent SpecMode, the measurement mode, and the lower 30 bits represent SpecSize, the specification size under a certain measurement mode
 public   static   int makeMeasureSpec( int   size , int mode) {
            if (sUseBrokenMakeMeasureSpec) {
 return   size + mode;
 } else {
 return ( size & ~MODE_MASK) | (mode & MODE_MASK);
 }
 } 
 
 // Unpack the 32-bit MeasureSpec and return SpecMode, measurement mode
 public   static   int getMode( int measureSpec) {
 return (measureSpec & MODE_MASK);
 } 
 
 // Unpack the 32-bit MeasureSpec and return SpecSize, the specification size in a certain measurement mode
 public   static   int getSize( int measureSpec) {
 return (measureSpec & ~MODE_MASK);
 }
 //...
 }

Java

MeasureSpec avoids excessive object memory allocation by packing SpecMode and SpecSize into an int value and provides packing and unpacking methods.

There are three types of SpecMode, each with a special meaning:

UNSPECIFIED

The parent container does not impose any restrictions on the View. It can be as large as required. This situation is generally used within the system to indicate a measurement state.

EXACTLY

The parent container has detected the exact size required by the View, and the final size of the View is the value specified by SpecSize. It corresponds to the two modes of match_parent and specific values ​​in LayoutParams.

AT_MOST

The parent container specifies an available size, SpecSize, and the size of the View cannot be larger than this value. The specific value depends on the specific implementation of different Views. It corresponds to wrap_content in LayoutParams.

The MeasureSpec of a View is determined by the MeasureSpec of its parent container and its own LayoutParams, but it is a little different for DecorView because it has no parent class. The following code in the measureHierarchy method in ViewRootImpl shows the creation process of DecorView's MeasureSpec, where desiredWindowWidth and desireWindowHeight are the screen sizes:

ViewGroup measure

 childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth, lp.width); 
 
 childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight, lp.height); 
 
 performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

Java

Let's take a look at the getRootMeasureSpec method:

 private static   int getRootMeasureSpec( int windowSize, int rootDimension) {
 int measureSpec;
        switch (rootDimension) { 
 
 case ViewGroup.LayoutParams.MATCH_PARENT:
            // Window can't resize. Force root view   to be windowSize.
            measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY);
 break;
 case ViewGroup.LayoutParams.WRAP_CONTENT:
            // Window can resize. Set   max   size   for root view .
            measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
 break;
 default :
            // Window wants to be an exact size . Force root view   to be that size .
            measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
 break;
 }
 return measureSpec;
 }

Java

Through the above code, the generation process of DecorView's MeasureSpec is very clear, because DecorView is a subclass of FrameLyaout and belongs to ViewGroup. For ViewGroup, in addition to completing its own measure process, it will also traverse and call the measure method of all child elements, and each child element will recursively execute this process. Unlike View, ViewGroup is an abstract class, and it does not override View's onMeasure method. This is easy to understand, because each specific ViewGroup implementation class has different functions, and how to measure should be decided by itself, such as LinearLayout and RelativeLayout.

Therefore, it is necessary to traverse and measure the child View in the specific ViewGroup. Here we look at the measureChildWithMargins method provided in ViewGroup to measure the child View:

 protected void measureChildWithMargins( View child,
 int parentWidthMeasureSpec, int widthUsed,
 int parentHeightMeasureSpec, int heightUsed) {
        final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams(); 
 
        final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
                mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin
                        + widthUsed, lp.width);
        final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
                mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin
                        + heightUsed, lp.height); 
 
        child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
 }

Java

The above method will measure the child element. Before calling the child element's measure method, the child element's MeasureSpec will be obtained through the getChildMeasureSpec method. From the code, the creation of the child element's MeasureSpec is related to the parent container's MeasureSpec and its own LayoutParams, as well as the View's margin and the parent class's padding. Now let's take a look at the specific implementation of getChildMeasureSpec:

 ViewGroup.java 
 
 public   static   int getChildMeasureSpec( int spec, int padding, int childDimension) {
 int specMode = MeasureSpec.getMode(spec);
 int specSize = MeasureSpec.getSize(spec); 
 
 int   size = Math. max (0, specSize - padding); 
 
 int resultSize = 0;
 int resultMode = 0; 
 
 switch (specMode) {
    // Parent has imposed an exact size   on us
 case MeasureSpec.EXACTLY:
        if (childDimension >= 0) {
            resultSize = childDimension;
            resultMode = MeasureSpec.EXACTLY;
        } else if (childDimension == LayoutParams.MATCH_PARENT) {
            // Child wants to be our size . So be it.
            resultSize = size ;
            resultMode = MeasureSpec.EXACTLY;
        } else if (childDimension == LayoutParams.WRAP_CONTENT) {
            // Child wants to determine its own size . It can't be
            // bigger than us.
            resultSize = size ;
            resultMode = MeasureSpec.AT_MOST;
 }
 break; 
 
    // Parent has imposed a maximum size   on us
 case MeasureSpec.AT_MOST:
        if (childDimension >= 0) {
            // Child wants a specific size ... so be it
            resultSize = childDimension;
            resultMode = MeasureSpec.EXACTLY;
        } else if (childDimension == LayoutParams.MATCH_PARENT) {
            // Child wants to be our size , but our size   is   not fixed.
            // Constrain child to   not be bigger than us.
            resultSize = size ;
            resultMode = MeasureSpec.AT_MOST;
        } else if (childDimension == LayoutParams.WRAP_CONTENT) {
            // Child wants to determine its own size . It can't be
            // bigger than us.
            resultSize = size ;
            resultMode = MeasureSpec.AT_MOST;
 }
 break; 
 
    // Parent asked to see how big we want to be
 case MeasureSpec.UNSPECIFIED:
        if (childDimension >= 0) {
            // Child wants a specific size ... let him have it
            resultSize = childDimension;
            resultMode = MeasureSpec.EXACTLY;
        } else if (childDimension == LayoutParams.MATCH_PARENT) {
            // Child wants to be our size ... find out how big it should
 // be
            resultSize = View .sUseZeroUnspecifiedMeasureSpec ? 0 : size ;
            resultMode = MeasureSpec.UNSPECIFIED;
        } else if (childDimension == LayoutParams.WRAP_CONTENT) {
            // Child wants to determine its own size .... find out how
            // big it should be
            resultSize = View .sUseZeroUnspecifiedMeasureSpec ? 0 : size ;
            resultMode = MeasureSpec.UNSPECIFIED;
 }
 break;
 }
    //noinspection ResourceType
 return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
 }

Java

The above code creates the MeasureSpec of the child element based on the MeasureSpec of the parent class and its own LayoutParams. The specific process is analyzed by the students themselves. The final creation rules are as follows:

After traversing the child Views, ViewGroup needs to determine its final measured size based on the measurement results of the child elements and call the setMeasuredDimension method to save the measured width and height values.

 setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),heightSizeAndState);

Java

resolveSizeAndState is called here to determine the final size, mainly to ensure that the measured size does not exceed the maximum remaining space maxWidth of the parent container. Here we look at its implementation:

 public   static   int resolveSizeAndState( int   size , int measureSpec, int childMeasuredState) {
        final int specMode = MeasureSpec.getMode(measureSpec);
        final int specSize = MeasureSpec.getSize(measureSpec);
 final int result;
 switch (specMode) {
 case MeasureSpec.AT_MOST:
                if (specSize < size ) {
                    result = specSize | MEASURED_STATE_TOO_SMALL;
 } else {
                    result = size ;
 }
 break;
 case MeasureSpec.EXACTLY:
                result = specSize;
 break;
 case MeasureSpec.UNSPECIFIED:
 default :
                result = size ;
 }
 return result | (childMeasuredState & MEASURED_STATE_MASK);
 }

Java

The onMeasure process of specific ViewGroup is not analyzed here. Since the measurement method of each layout is different, it is impossible to analyze them one by one, but the steps in their onMeasure are regular:

1. Traverse the Children elements according to their respective measurement rules and call the getChildMeasureSpec method to get the measureSpec of the Child;

2. Call Child's measure method;

3. Call setMeasuredDimension to determine the final size.

View measure

The measure process of View is completed by its measure method. The measure method is a final type method, which means that subclasses cannot override this method. The onMeasure method will be called in the measure method of View. Here we only need to look at the implementation of onMeasure, as follows:

 View.java​ 
 
    protected void onMeasure( int widthMeasureSpec, int heightMeasureSpec) {
        setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
                getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
 }

Java

The code is very simple. Let's continue to look at the implementation of the getDefaultSize method:

 View.java​ 
 
 public   static   int getDefaultSize( int   size , int measureSpec) {
 int result = size ;
 int specMode = MeasureSpec.getMode(measureSpec);
 int specSize = MeasureSpec.getSize(measureSpec); 
 
 switch (specMode) {
 case MeasureSpec.UNSPECIFIED:
 result = size ;
 break;
 case MeasureSpec.AT_MOST:
 case MeasureSpec.EXACTLY:
            result = specSize;
 break;
 }
 return result;
 }

Java

From the above code, we can conclude that the width/height of View is determined by specSize. Custom controls that directly inherit View need to override the onMeasure method and set their own size when wrap_content is used. Otherwise, using wrap_content in the layout is equivalent to using match_parent.

The above is the general process of View measurement. After the measurement is completed, the measured width and height can be obtained through the getMeasuredWidth/Height method. This width and height is generally equal to the final width and height of the View, because the width and height of the View are set according to measureWidth/Height when the View is laid out, unless the measure value is modified in the layout.

Layout

The role of Layout is that ViewGroup is used to determine the position of child elements. When the position of ViewGroup is determined, it will traverse all child elements in onLayout and call their layout methods. In simple terms, the layout method determines the position of the View itself, while the onLayout method determines the positions of all child elements.

Let's first look at the layout method of View:

 public void layout( int l, int t, int r, int b) {
        if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) {
            onMeasure(mOldWidthMeasureSpec, mOldHeightMeasureSpec);
            mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
 } 
 
 int oldL = mLeft;
 int oldT = mTop;
 int oldB = mBottom;
 int oldR = mRight; 
 
        boolean changed = isLayoutModeOptical(mParent) ?
                setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b); 
 
        if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
            onLayout(changed, l, t, r, b); 
 
            if (shouldDrawRoundScrollbar()) {
                if(mRoundScrollbarRenderer == null ) {
                    mRoundScrollbarRenderer = new RoundScrollbarRenderer(this);
 }
 } else {
                mRoundScrollbarRenderer = null ;
 } 
 
            mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED; 
 
            ListenerInfo li = mListenerInfo;
            if (li != null && li.mOnLayoutChangeListeners != null ) {
                ArrayList<OnLayoutChangeListener> listenersCopy =
                        (ArrayList<OnLayoutChangeListener>)li.mOnLayoutChangeListeners.clone();
 int numListeners = listenersCopy. size ();
 for ( int i = 0; i < numListeners; ++i) {
                    listenersCopy.get(i).onLayoutChange(this, l, t, r, b, oldL, oldT, oldR, oldB);
 }
 }
 } 
 
        mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
        mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
 }

Due to WeChat word limit, please click the original link to view the full content

Summarize

At this point, the three major processes of View measure, layout, and draw have been discussed. Here is a summary:

• If it is a custom ViewGroup, you need to rewrite the onMeasure method, traverse and measure the child elements in the onMeasure method, and the same is true for the onLayout method. Finally, implement the onDraw method to draw yourself;
• If you customize the View, you need to write the onMeasure method to handle the wrap_content situation, and you don't need to handle onLayout. Finally, implement the onDraw method to draw yourself.