探究Android View 绘制流程，Canvas 的由来

基于 Android API 26 Platform 源码

写作背景

Google 搜索关键字 『android view 绘制』能得到很多资料。通常从以下几个方面讲解：

1. Measure -> layout -> draw 过程解析。
2. Paint 、Canvas 、Drawable 、Bitmap 的使用。
3. View/ViewGroup 的绘制顺序。
4. View 的测量过程。
5. 自定义 View 要重载

大部分文章写的都非常棒，讲的很详细。

但是始终有一个问题一直困扰着我: View如何绘制到屏幕上!!!

所以本文重点只讲 View 如何绘制到屏幕上的，其他 View 绘制流程大家自行 Google 或者参考Android视图绘制流程完全解析，带你一步步深入了解View(二)

自定义一个简单的 View

本应该从 View 的源代码入手，但是发现 View.java 文件的源码大概有 26488 行。这么长的代码，直接啃下去不知道要耗费多少头发。只好另辟蹊径。

先看一段代码

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        final Paint mPaint = new Paint();
        mPaint.setColor(0xffff0000);
        mPaint.setStrokeWidth(10);
        setContentView(new View(this) {
            @Override
            protected void onDraw(Canvas canvas) {
                canvas.drawLine(0, 0, getWidth(), getHeight(), mPaint);

            }
        });
    }
}

代码比较简单，我们从屏幕左上方到右下方画了一条红色的直线。

1. 把绘制的代码放在 onDraw() 方法中
2. 创建一个 Paint（画笔） ，设置颜色画笔宽度。
3. 调用 canvas.drawLine(0, 0, getWidth(), getHeight(), mPaint)
   前四个参数两两组合，代表直线的起点坐标和终点坐标。

上面的解释看起来 特别的自然，但是！好像 哪里不对？？？？

Canvas 从哪里来？？？

看下 View 源码，我们会回答：从父类的 draw(Canvas canvas) 方法来啊！

但是！父类的 draw(Canvas canvas) 是谁调用的？

这时候很多人就

好了，我们正式进入下个环节。

追踪 onDraw() 调用栈

为了获得 onDraw() 方法的调用情况，我们进行第一次尝试。

AndroidStudio Find Usages

AndroidStudio 的Find Usages 功能非常强大可以迅速帮我们查找到调用 onDraw() 的地方。

但是！我们得到了 77 个结果。

77 个虽然不是特别多，但是也是一个不小的工作量。所以: 此路不通

祭出万能的 debug

静态分析的路已经被堵死了，这时候感觉只有单步调试能迅速帮我们从 77 个结果中找到最重要的。

为了单步调试，我们需要做以下准备

1. 下载 Android 源码。如果没有下载，当你点击查看 View 源码的时候 AndroidStudio 的右上角会有提示，点击下载即可。
2. 准备虚拟机。并且虚拟机的 Android 版本和项目的 compileSdkVersion 一致。
3. 在我们自定义 View 的 onDraw() 方法中打一个断点
4. 选择 『Debug app』

下图就是断点信息，右侧为断点处的方法调用栈。由于屏幕有限，堆栈的信息没有完全截出。

通过点击右侧的方法我们可以追踪对应的源码。由于方法栈过长，我们选择从栈低开始分段梳理。

分析 onDraw() 调用栈

第一部分

  at android.os.Looper.loop(Looper.java:164)
  at android.app.ActivityThread.main(ActivityThread.java:6541)
  at java.lang.reflect.Method.invoke(Method.java:-1)
  at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)

Zygote 进程是所以Android进程的父进程，用来孵化Android进程。想要了解更多的可以自行 Google 或者查看Zygote 进程启动时做了哪些事？

ActivityThread 便是我们的 Android 进程了，其中 ActivityThread main() 方法便是我们整个Android应用程序入口之处。main() 方法会调用 Looper.loop() 方法阻塞线程，从而开启整个 Android 应用（如果不阻塞，main() 方法结束整个进程也就结束）。这个线程也就是 Android 中著名的 UI 线程，这里的 Looper 便是 MainLooper 。

综上，从这部分代码只是 Android 进程启动过程。但是和 View 绘制关系不大。

第二部分

  at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1386)
  at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6733)
  at android.view.Choreographer$CallbackRecord.run(Choreographer.java:911)
  at android.view.Choreographer.doCallbacks(Choreographer.java:723)
  at android.view.Choreographer.doFrame(Choreographer.java:658)
  at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:897)
  at android.os.Handler.handleCallback(Handler.java:789)
  at android.os.Handler.dispatchMessage(Handler.java:98)

handler 收到并处理了一个消息 FrameDisplayEventReceiver.run() ，表示我们收到了一个绘制页面的消息。其中 Choreographer 是 Android4.1 以后增加的统一调度界面绘制机制。

此外我们发现方法调用栈进入了 ViewRootImpl 对象之中。这时候我们需要了解 ViewRootImpl 。如果不了解 ViewRootImpl 的可以先移步到Android Window 机制探索，了解一下 View 、ViewRootImpl、window 之间的关系。或者看下面两条简单的总结

1. Android 中所有视图，都是在 window 上面绘制的。
2. 每个应用窗口创建的时候，都会创建一个对应的 ViewRootImpl 对象。
3. ViewRootImpl 是一个根节点，负责 View 和 WindowManagerSerive 之间的通信。

总结第二部分：接收到了一个页面绘制消息，调用 ViewRootImpl.doTraversal() 方法。

第三部分（重点）

  at android.view.View.updateDisplayListIfDirty(View.java:18073)
  at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:643)
  at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:649)
  at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:757)
  at android.view.ViewRootImpl.draw(ViewRootImpl.java:2980)
  at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2794)
  at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2347)

这里又出现了一个新的对象 ThreadedRenderer ,从名字是我们可以猜测和渲染页面有关。
通过 ThreadedRenderer 一系列调用

draw()  -> updateRootDisplayList()  -> updateViewTreeDisplayList() 

会调用到 View.updateDisplayListIfDirty()

public RenderNode updateDisplayListIfDirty() {
    final RenderNode renderNode = mRenderNode;
    ……
    if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0
            || !renderNode.isValid()
            || (mRecreateDisplayList)) {
        ……
        int width = mRight - mLeft;
        int height = mBottom - mTop;
        int layerType = getLayerType();

        final DisplayListCanvas canvas = renderNode.start(width, height);
        canvas.setHighContrastText(mAttachInfo.mHighContrastText);

        try {
            ……
        } finally {
            renderNode.end(canvas);
            setDisplayListProperties(renderNode);
        }
    } else {
        mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
        mPrivateFlags &= ~PFLAG_DIRTY_MASK;
    }
    return renderNode;
}

这里注意

final DisplayListCanvas canvas = renderNode.start(width, height);

天啊撸！！！我们终于看到 canvas 对象的赋值代码了。

赶快看看 renderNode.start(width, height)

public DisplayListCanvas start(int width, int height) {
    return DisplayListCanvas.obtain(this, width, height);
}

发现调用了 obtain() 方法

static DisplayListCanvas obtain(@NonNull RenderNode node, int width, int height) {
    if (node == null) throw new IllegalArgumentException("node cannot be null");
    DisplayListCanvas canvas = sPool.acquire();
    if (canvas == null) {
        canvas = new DisplayListCanvas(node, width, height);
    } else {
        nResetDisplayListCanvas(canvas.mNativeCanvasWrapper, node.mNativeRenderNode,
                width, height);
    }
    canvas.mNode = node;
    canvas.mWidth = width;
    canvas.mHeight = height;
    return canvas;
}

然后我们发现进入了 JNI 领域。

private DisplayListCanvas(@NonNull RenderNode node, int width, int height) {
    super(nCreateDisplayListCanvas(node.mNativeRenderNode, width, height));
    mDensity = 0; // disable bitmap density scaling
}

@CriticalNative
private static native long nCreateDisplayListCanvas(long node, int width, int height);
@CriticalNative
private static native void nResetDisplayListCanvas(long canvas, long node,
        int width, int height);

遇到了 JNi 我们的追踪也就到此为止了o(╯╰)o，但是我们已经知道 Canvas 是从哪里创建的了。至于底层东西，有能力的时候再追踪下去。

第四部分

经过前面三部分的分析，第四部分就比较简单了。很容易发现其实就是一个循环调用。刚好对应了 View 绘制规则中的：先绘制父 View 然后再绘制子 View。

这里还有一个疑问： 为什么嵌套了 6 层才到我们自顶一个的 View ？

这里我们可以使用 AndroidStudio -> Tools -> Android -> Layout Inspector
刚好发现是 6 层嵌套

需要注意的是：Activity 的 ContentView 我们只放了一个简单的 View 就已经有 6 层嵌套了

结尾说几句

这里只是介绍了 Android View 绘制过程中，Canvas 的赋值过程。通过 Canvas 的 Api 调用我们便可以在屏幕上绘制出各种各样的页面。

但是，这只是 Android 绘制流程中的一小步。如果不想追究 Canvas 的来源，这一步甚至可以忽略。

剩下的内容，大家可以自己去阅读源码，或者阅读其他人的博客。如有疑问，欢迎留言。

参考

Android视图绘制流程完全解析，带你一步步深入了解View(二)

Zygote 进程启动时做了哪些事？