探究 Android View 绘制流程，Activity 的 View 如何展现到屏幕

时间  2019-11-06
标签 探究 android view 绘制 流程 activity 如何 展现 屏幕 栏目 Android 繁體版
原文   原文链接
基于 Android API 26 Platform 源码

写做背景

在上一篇探究Android View 绘制流程，Xml 文件到 View 对象的转换过程咱们了解了setContentView(resId) 如何把 xml 文件转换成 Java 中的 View 对象。本篇文章再次基础上继续探究，View 是如何展现到 Activity 上的。android

不少 Android 开发者都知道一个事情app

当 Activity 执行 onResume() 方法后，表明 Activity 显示到前台
复制代码

这句话很短，可是背后隐藏了多少方法的调用呢？下面咱们将一层一层的剥开源码寻找真相。ide

onion.jpg

先从 setContentView(resId) 入手

先说明一下，从 Android 的 Launcher 上点击应用的 Icon 的启动过程比较复杂，本人仍在学习。若是想了解如何启动一个 Activity 的过程能够参考Android Launcher 启动 Activity 的工做过程，这里咱们只从关注 Activity 中的 View 显示出来。因此直接从 Activity 的一些方法入手。oop

在 Activity 的 onCreate(savedInstanceState) 中调用 setContentView(resId)，而setContentView(resId)则会调用 PhoneWindow.setContentView(layoutResID)布局

源码并非太长post

@Override
public void setContentView(int layoutResID) {
    // Note: FEATURE_CONTENT_TRANSITIONS may be set in the process of installing the window
    // decor, when theme attributes and the like are crystalized. Do not check the feature
    // before this happens.
    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);
    }
    mContentParent.requestApplyInsets();
    final Callback cb = getCallback();
    if (cb != null && !isDestroyed()) {
        cb.onContentChanged();
    }
}
复制代码

这里忽略转场动画和一些回调相关的逻辑代码后以下学习

if (mContentParent == null) {
     installDecor();
 } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
     mContentParent.removeAllViews();
 }
 mLayoutInflater.inflate(layoutResID, mContentParent);
 mContentParent.requestApplyInsets();
复制代码

其中 mContentParent 是一个 ViewGroup 引用动画

private ViewGroup mContentParent;
复制代码

这样开代码比较简单明了this

1. 判断 mContentParent 是否为空，若是为空执行 installDecor()
2. 若是 mContentParent 不为空，清除 mContentParent 的全部子 View
3. 把传入的布局文件转换为 View 对象添加到 mContentParent
复制代码

分析 installDecor()

而后咱们再看下 installDecor() ，由于源码比较长，咱们分红几个部分解读spa

第一部分
if (mDecor == null) {
        mDecor = generateDecor();
        mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
        mDecor.setIsRootNamespace(true);
        if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
            mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
        }
    }
复制代码

这几行代码最重要的是调用了方法 generateDecor() 其实就是建立一个 DecorView。这里是否是能想到探究Android View 绘制流程，Canvas 的由来中最后的那张图，咱们作个相似的截图截个图

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new TextView(getApplicationContext()));
    }

    @Override
    protected void onResume() {
        super.onResume();
    }
}
复制代码

activity_view_01.png

咱们看到一个 Activity 页面最底层的 View 就是咱们刚看到的 DecorView

第二部分
if (mContentParent == null) {
    mContentParent = generateLayout(mDecor);
    ……
}
复制代码

这里看到了对 mContentParent 的赋值操做，调用了 generateLayout(mDecor)

protected ViewGroup generateLayout(DecorView decor) {
    // Apply data from current theme.

    TypedArray a = getWindowStyle();
    //设置 Windows Style ，title 、action_bar 、设置键盘弹出方式之类的属性
    //……
    //……
    int layoutResource;
    int features = getLocalFeatures();
    // System.out.println("Features: 0x" + Integer.toHexString(features));
    if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
        layoutResource = R.layout.screen_swipe_dismiss;
    } else if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON))) != 0) {
        ……
    } else if ((features & ((1 << FEATURE_PROGRESS) | (1 << FEATURE_INDETERMINATE_PROGRESS))) != 0
            && (features & (1 << FEATURE_ACTION_BAR)) == 0) {
        ……
    } else if ((features & (1 << FEATURE_CUSTOM_TITLE)) != 0) {
        ……
    } else if ((features & (1 << FEATURE_NO_TITLE)) == 0) {
        ……
    } else if ((features & (1 << FEATURE_ACTION_MODE_OVERLAY)) != 0) {
        ……
    } else {
        // Embedded, so no decoration is needed.
        layoutResource = R.layout.screen_simple;
        // System.out.println("Simple!");
    }

    mDecor.startChanging();

    View in = mLayoutInflater.inflate(layoutResource, null);
    decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
    mContentRoot = (ViewGroup) in;
    //……
    //……
    mDecor.finishChanging();

    return contentParent;
}
复制代码

这里把 generateLayout(mDecor) 作了很大的简化，大部分都是设置一些窗体属性，软键盘弹出方式之类的东西。咱们关心的 View 相关的就如下几行

View in = mLayoutInflater.inflate(layoutResource, null);
    decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
    mContentRoot = (ViewGroup) in;
    mDecor.finishChanging();
复制代码

layoutResource 是什么呢？咱们随便选择一个 R.layout.screen_simple 在 AndroidSdk 中搜到这个文件，内容以下

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true"
    android:orientation="vertical">
    <ViewStub android:id="@+id/action_mode_bar_stub"
              android:inflatedId="@+id/action_mode_bar"
              android:layout="@layout/action_mode_bar"
              android:layout_width="match_parent"
              android:layout_height="wrap_content"
              android:theme="?attr/actionBarTheme" />
    <FrameLayout
         android:id="@android:id/content"
         android:layout_width="match_parent"
         android:layout_height="match_parent"
         android:foregroundInsidePadding="false"
         android:foregroundGravity="fill_horizontal|top"
         android:foreground="?android:attr/windowContentOverlay" />
</LinearLayout>
复制代码

这个时候再回到咱们刚的那个截图，咱们找到了第二层内容 LinearLayout 的来源，这一层LinearLayout包含两个部分

1. id 为 action_mode_bar_stub 的 ViewStub ,用来设置 actionBar 之类的
2. id 为 android.R.id.content 的 FrameLayout。里面会存放咱们在 Activity.setContentView(resId) 传入的文件布局
复制代码

而后再看下最后 mDecor.finishChanging()

public void finishChanging() {
        mChanging = false;
        drawableChanged();
    }
    
private void drawableChanged() {
        if (mChanging) {
            return;
        }

        //……
        //……
        requestLayout();
        invalidate();

        //……
        //……
       
    }
复制代码

nani.jpg

根据咱们对 View 的了解，requestLayout() 和 invalidate() 会引起 View 的从新布局和从新绘制，难道这个时候就绘制 View 了。 这不科学

而事实上，这个真的不科学。此时并不会执行绘制和计算。 缘由是此时的 View 尚未和 ViewRootImpl 关联上 。留个悬念，这个咱们在后面的章节会讲解。

第三部分

第三部分就是第二部分省略的代码,代码特别长，这里也缩减一下。

final DecorContentParent decorContentParent = (DecorContentParent) mDecor.findViewById(
         R.id.decor_content_parent);
 if (decorContentParent != null) {
     //……
 } else {
     mTitleView = (TextView)findViewById(R.id.title);
     //……
 }
 if (mDecor.getBackground() == null && mBackgroundFallbackResource != 0) {
     mDecor.setBackgroundFallback(mBackgroundFallbackResource);
 }
 // Only inflate or create a new TransitionManager if the caller hasn't
 // already set a custom one.
 if (hasFeature(FEATURE_ACTIVITY_TRANSITIONS)) {
    //……
 }
复制代码

这里简单的概括一下代码作的事情

1. 设置 title
2. 设置背景色
3. 处理 FEATURE_ACTIVITY_TRANSITIONS 属性
复制代码

requestLayout() 和 invalidate() 源码追踪

requestLayout() 和 invalidate() 的源码都在 View 类里面

先看 requestLayout()

public void requestLayout() {
    if (mMeasureCache != null) mMeasureCache.clear();

    if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == null) {
        // Only trigger request-during-layout logic if this is the view requesting it,
        // not the views in its parent hierarchy
        ViewRootImpl viewRoot = getViewRootImpl();
        if (viewRoot != null && viewRoot.isInLayout()) {
            if (!viewRoot.requestLayoutDuringLayout(this)) {
                return;
            }
        }
        mAttachInfo.mViewRequestingLayout = this;
    }

    mPrivateFlags |= PFLAG_FORCE_LAYOUT;
    mPrivateFlags |= PFLAG_INVALIDATED;

    if (mParent != null && !mParent.isLayoutRequested()) {
        mParent.requestLayout();
    }
    if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == this) {
        mAttachInfo.mViewRequestingLayout = null;
    }
}
复制代码

咱们看到此时的 View 会调用 mParent.requestLayout() 。mParent 会是 ViewGroup 吗？咱们看下声明变量的地方

protected ViewParent mParent;
复制代码

而后再搜下mParent赋值的地方，发现只有一处

void assignParent(ViewParent parent) {
    if (mParent == null) {
        mParent = parent;
    } else if (parent == null) {
        mParent = null;
    } else {
        throw new RuntimeException("view " + this + " being added, but"
                + " it already has a parent");
    }
}
复制代码

那接下来就看 assignParent(parent) 被谁调用了，发现 View 中只有声明，没有调用。因此咱们就去 ViewGroup 看看。发现也只有一处调用

private void addViewInner(View child, int index, LayoutParams params,
        boolean preventRequestLayout) {

    ……
    // tell our children
    if (preventRequestLayout) {
        child.assignParent(this);
    } else {
        child.mParent = this;
    }

    ……
}
复制代码

顺着这个方法追溯一下，以下图

activity_view_02.png

这时候咱们又疑问了：

DecorView 的 mParent 是谁呢？？？

question.png

答案只有一个，是 NULL

咱们刚说了 mDecor.finishChanging()不会执行绘制和计算相。 缘由是此时的 View 尚未和 ViewRootImpl 关联上 。

先看 invalidate()

public void invalidate() {
    invalidate(true);
}

public void invalidate(boolean invalidateCache) {
    invalidateInternal(0, 0, mRight - mLeft, mBottom - mTop, invalidateCache, true);
}



void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
        boolean fullInvalidate) {
    ……
        if (p != null && ai != null && l < r && t < b) {
            final Rect damage = ai.mTmpInvalRect;
            damage.set(l, t, r, b);
            p.invalidateChild(this, damage);
        }

        ……
    }
}
复制代码

咱们又在跟踪 invalidate() 方法时发现了 p.invalidateChild(this, damage) 这里彷佛又是一层一层的向上迭代。为了确保，咱们去看下 ViewGroup 的 invalidateChild()

public final void invalidateChild(View child, final Rect dirty) {
    ……

    ViewParent parent = this;
    if (attachInfo != null) {
        ……

        do {
            ……
            parent = parent.invalidateChildInParent(location, dirty);
            ……
            }
        } while (parent != null);
    }
}

public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
    if ((mPrivateFlags & (PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID)) != 0) {
         ……
         
        return mParent;
    }

    return null;
}
复制代码

因此和 requestLayout() 同样层层追溯，又到了 DecorView 中。咱们能够准确的说 DecorView 的 mParent 实际上是 ViewRootImpl。可是怎么证实呢？？？

DecorView 和 ViewRootImpl 的关系

本文开盘就已经说了 当 Activity 执行 onResume() 方法后，表明 Activity 显示到前台，这是为何呢？

咱们都是 Activity 的由 ActivityManager 管理，Activity 页面的操做必须在主线程中，而主线程就是 ActivityThread 。在 ActivityThread 的源码中，找到了一个 H 类，该类继承 Handler 。在 H 的 handleMessage(Message msg) 发现如下代码

public void handleMessage(Message msg) {
        if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
        switch (msg.what) {
            ……
            case RESUME_ACTIVITY:
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityResume");
                handleResumeActivity((IBinder) msg.obj, true, msg.arg1 != 0, true);
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                break;
            ……
    }
复制代码

而后看下 handleResumeActivity

final void handleResumeActivity(IBinder token,
           ……
           if (r.window == null && !a.mFinished && willBeVisible) {
               r.window = r.activity.getWindow();
               View decor = r.window.getDecorView();
               decor.setVisibility(View.INVISIBLE);
               ViewManager wm = a.getWindowManager();
               WindowManager.LayoutParams l = r.window.getAttributes();
               a.mDecor = decor;
               l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
               l.softInputMode |= forwardBit;
               if (a.mVisibleFromClient) {
                   a.mWindowAdded = true;
                   wm.addView(decor, l);
               }
           ……
   }
复制代码

这里咱们看到了 DecorView 被添加到了 ViewManager 之中。

ViewManager 只是一个接口，它的实现类为 WindowManagerImpl。在 WindowManagerImpl 我查找 addView() 方法

public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
      applyDefaultToken(params);
      mGlobal.addView(view, params, mDisplay, mParentWindow);
  }
复制代码

这里的 mGlobal 又是 WindowManagerGlobal 的实例。全部咱们又要跳转到 WindowManagerGlobal.addView() 。

keep.jpg

O__O "… 这时千万别放弃，胜利就在眼前，同志们要坚持往下看啊。

public void addView(View view, ViewGroup.LayoutParams params,
        Display display, Window parentWindow) {
    ……

    ViewRootImpl root;
    View panelParentView = null;

    synchronized (mLock) {
        ……
        root = new ViewRootImpl(view.getContext(), display);

        view.setLayoutParams(wparams);

        mViews.add(view);
        mRoots.add(root);
        mParams.add(wparams);
    }

    // do this last because it fires off messages to start doing things
    try {
        root.setView(view, wparams, panelParentView);
    } ……
}
复制代码

而后再看下 ViewRootImpl.setView()

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
     synchronized (this) {
         if (mView == null) {
             mView = view;
             ……
             view.assignParent(this);
         }
     }
 }
复制代码

亲人啊！终于看到 ***root.setView(view, wparams, panelParentView)***，咱们上面一直说的 View 和 ViewRootImpl 的关系终于在这关联上了。为了更清晰一点咱们画一个时序图

activity_view_03.png

ViewRootImpl 绘制 View

如今进入了本文的压轴部分，View 绘制的核心源码。

经过以上的讲解，咱们也知道要去找 ViewRootImpl 的 requestLayout() 和 invalidateChildInParent() 方法

ViewRootImpl.requestLayout()
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        scheduleTraversals();
    }
}
复制代码

scheduleTraversals() 又是什么鬼

void scheduleTraversals() {
     if (!mTraversalScheduled) {
         mTraversalScheduled = true;
         mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
         mChoreographer.postCallback(
                 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
         if (!mUnbufferedInputDispatch) {
             scheduleConsumeBatchedInput();
         }
         notifyRendererOfFramePending();
         pokeDrawLockIfNeeded();
     }
 }
复制代码

这里咱们看到了一个任务 mTraversalRunnable

final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
复制代码

mTraversalRunnable 是一个 Runnable 的子类

final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
        doTraversal();
    }
}
复制代码

这个时候咱们又要去看下 doTraversal() 的源码。

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

        if (mProfile) {
            Debug.startMethodTracing("ViewAncestor");
        }

        performTraversals();

        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
    }
}
复制代码

最后咱们找到了 performTraversals() 方法， ***注意 performTraversals() 里面有重大内容***该方法很长（真的是特别长），咱们这里看一下简化后的

private void performTraversals() {
            ……
            if (!mStopped || mReportNextDraw) {
               ……
                    performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
               ……
            }
        ……
        if (didLayout) {
            performLayout(lp, desiredWindowWidth, desiredWindowHeight);
        ……
        }
        ……

                performDraw();
        ……
 }
复制代码

success.jpg

看到了 performMeasure 、 performLayout、 performDraw 这里就不用多说了吧。也就解释了为啥 View 的绘制顺序是 measure -> layout -> draw 了吧

ViewRootImpl.invalidateChildInParent()()

这里咱们不啰嗦太多，直接上源码

public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
     checkThread();
     ……

     invalidateRectOnScreen(dirty);

     return null;
 }
 
private void invalidateRectOnScreen(Rect dirty) {
    ……
    if (!mWillDrawSoon && (intersected || mIsAnimating)) {
        scheduleTraversals();
    }
}
复制代码

看到这里就不用多说了，下面的执行顺序 ViewRootImpl.requestLayout() 已经分析过了。

这个时候你们再看下网上不少分析 requestLayout() 和 invalidate() 方法区别的，你们能够去先去查一下，等后面有时间我也会写一篇分析这两个方法区别的文章。

View 到底何时绘制到屏幕上？

经过以上分析咱们知道

1. setContentView() 只是把 View 添加到 DecorView 上
  2. onResume() 中 ViewRootImpl 和 DecorView 作了关联
  3. requestLayout() 和 invalidate() 会触发 ViewRootImpl 绘制 View
复制代码

可是！setContentView() 中调用了 requestLayout() 和 invalidate() 不会触发绘制，咱们上面只讲了 onResume() 中 ViewRootImpl 和 DecorView 作了关联 。到底何时又调用了 requestLayout() 或者 invalidate() ？？？

往上翻咱们发如今 ViewRootImpl.setView() 中有一个 requestLayout

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
        synchronized (this) {
                ……
                requestLayout();
                 ……
                view.assignParent(this);
                ……
            }
        }
    }
复制代码

可是！竟然在 view.assignParent(this) 这尼玛逗我吧！

nani.jpg

咱们在回头看下 requestLayout()

void scheduleTraversals() {
     if (!mTraversalScheduled) {
         mTraversalScheduled = true;
         mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
         mChoreographer.postCallback(
                 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
         if (!mUnbufferedInputDispatch) {
             scheduleConsumeBatchedInput();
         }
         notifyRendererOfFramePending();
         pokeDrawLockIfNeeded();
     }
 }
复制代码

这里重点看一下这句

mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
复制代码

了解 Android Handler Looper 都知道 postSyncBarrier 是建立一个障碍，阻止后面的 Message 对象被执行。那这里也就解决了我刚刚的疑问， 虽然request()在 view.assignParent(this) 以前被调用，可是会被阻塞。 doTraversal() 执行的时候 DecorView 和 ViewRootImpl 已经关联了

这里留个坑

我没有找到 ViewRootImpl 怎么执行到 removeSyncBarrier(mTraversalBarrier) 的代码。

总结

对以上内容作个总结

1. View 在 Activity 的 onCreate() 方法中经过 setContentView() 方法添加到 Activity 的 DecorView 上
2. 此时 ViewRootImpl 和 DecorView 没有关联上，不会绘制 View
3. 在 Activity 的 onResume() 方法执行后，DecorView 会被添加带 ViewRootImpl 中。而后执行 requestlayout()
复制代码

参考资料

Android Launcher 启动 Activity 的工做过程

Activity究竟是何时显示到屏幕上的呢？

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程