手记

探究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 进程启动时做了哪些事?

4人推荐
随时随地看视频
慕课网APP