View的绘制、View的事件分发与传递

FloriztW

于 2021-04-19 12:19:14 发布

阅读量264

点赞数 1

分类专栏： Android

本文链接：https://blog.csdn.net/weixin_42802049/article/details/115858529

版权

Android 专栏收录该内容

31 篇文章 1 订阅

订阅专栏

view的绘制流程

View 绘制中主要流程分为measure，layout， draw 三个阶段。

measure ：根据父 view 传递的 MeasureSpec 进行计算大小。
layout ：根据 measure 子 View 所得到的布局大小和布局参数，将子View放在合适的位置上。
draw ：把 View 对象绘制到屏幕上。

发起绘制的入口

那么发起绘制的入口在哪里呢？
在介绍发起绘制的入口之前，我们需要先了解Window，ViewRootImpl，DecorView之间的联系。

一个 Activity 包含一个Window，Window是一个抽象基类，是 Activity 和整个 View 系统交互的接口，只有一个子类实现类PhoneWindow，提供了一系列窗口的方法，比如设置背景，标题等。
一个PhoneWindow 对应一个 DecorView 跟一个 ViewRootImpl
DecorView 是ViewTree 里面的顶层布局，是继承于FrameLayout，包含两个子View，一个id=statusBarBackground 的 View 和 LineaLayout，LineaLayout 里面包含 title 跟 content，title就是平时用的TitleBar或者ActionBar，contenty也是 FrameLayout，activity通过 setContent（）加载布局的时候加载到这个View上
ViewRootImpl 就是建立 DecorView 和 Window 之间的联系

所以measure，layout， draw这三个阶段的核心入口是在 ViewRootImpl 类的 performTraversals() 方法中。

private void performTraversals() {
    ......
    int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
    int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);
    ......
    mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
    ......
    mView.layout(0, 0, mView.getMeasuredWidth(), mView.getMeasuredHeight());
    ......
    mView.draw(canvas);
    ......
 }

在源码中这个方法特别长，但是核心还是这三个步骤，就是判断根据之前的状态判断是否需要重新 measure，是否需要重新 layout ，是否需要重新 draw。

当启动一个activity，安卓系统会根据activity的布局进行绘制，绘制会从viewrootimpl的performtraversals方法开始，从上到下遍历整个视图树，每个view负责自己的绘制，同时viewgroup还要负责通知自己的子view进行绘制。

view的绘制流程就是通过measure测量view的大小，通过layout确定绘制在哪，通过draw将view绘制在屏幕上。通过viewgroup递归遍历，一个完整的视图树就展现在屏幕上了。

measure

MeasureSpec

在介绍 measure 方法之前，需要了解一个很核心的概念：MeasureSpec。在 Google 官方文档中是这么定义 MeasureSpec的

A MeasureSpec encapsulates the layout requirements passed from parent to child. Each MeasureSpec represents a requirement for either the width or the height. A MeasureSpec is comprised of a size and a mode.

大概意思是：MeasureSpec 封装了从父View 传递给到子View的布局需求。每个MeasureSpec都包含了size（大小）和mode（模式）。

后面两句不难理解。MeasureSpec 一个32位二进制的整数型，前面2位代表的是mode，后面30位代表的是size。mode 主要分为3类，分别是：

EXACTLY：父容器已经为子容器设置了尺寸,子容器应当服从这些边界,不论子容器想要多大的空间。
AT_MOST：子容器可以是声明大小内的任意大小
UNSPECIFIED：父容器对于子容器没有任何限制,子容器想要多大就多大

View 的 MeasureSpec 并不是父 View 独自决定，它是根据父 view 的MeasureSpec加上子 View 的自己的 LayoutParams，通过相应的规则转化。

对 View 进行测量，还是要看父 View，也就是 ViewGroup。

步骤：
1，ViewGroup通过自己的MeasureSpec加上子View的LayoutParams，根据下面的一些规则获取到子View的mode和size，然后构建出子View的MeasureSpec对象，并调用子View的measure方法进行测量。

2，ViewGroup的三种MeasureSpec规则和子View的MATCH_PARENT、WRAP_CONTENT的联系

2.1，父View是EXACTLY的：
- 2.1.1，子View的width或height是个精确值
  则size为精确值，mode为 EXACTLY
- 2.1.2，子View的width或height是MATCH_PAREN
  则size为父视图大小，mode为 EXACTLY
- 2.1.3，子View的width或height是WRAP_CONTENT
  则size为父视图大小，mode为 AT_MOST
2.2，父View是AT_MOST的：
- 2.2.1，子View的width或height是个精确值
  则size为精确值，mode为 EXACTLY
- 2.2.2，子View的width或height是MATCH_PAREN
  则size为父视图大小，mode为 AT_MOST
- 2.2.3，子View的width或height是WRAP_CONTENT
  则size为父视图大小，mode为 AT_MOST
23，父View是UNSPECIFIED的：
- 2.3.1，子View的width或height是个精确值
  则size为精确值，mode为 EXACTLY
- 2.3.2，子View的width或height是MATCH_PAREN
  则size的值没有任何意义，所以一般都直接设置成0，mode为 UNSPECIFIED
- 2.3.3，子View的width或height是WRAP_CONTENT
  则size的值没有任何意义，所以一般都直接设置成0，mode为 UNSPECIFIED

在这里插入图片描述

3，子View的measure方法是 final 类型，子类不能覆盖，在方法里面会调用 onMeasure()，我们可以复写 onMeasure（）方法去测量设置 View 的大小。

  public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
	          /*-----------省略代码---------------*
	
	        onMeasure(widthMeasureSpec, heightMeasureSpec);
	
	           /*-----------省略代码---------------*/
    }

4,在 onMeasure( ) 方法中
在这里插入图片描述
我们先来看下 getSuggestedMinimumWidth()，这里返回的建议最小值就是我们xml 布局中用的属性 minWidth或者是背景大小。

同理可得 getSuggestedMinimumHeight()。

看下 getDefaultSize，在这之前我们已经根据父 view 的MeasureSpec加上子vIew的自己的LayoutParams得到了子View自己的MeasureSpec ，而这里只是针对于UNSPECIFIED这种模式下，也就是父View大小未定的情况下，使用最小建议值。
在这里插入图片描述

问题：自定义一个 View 的时候，如果不对 MeasureSpec 做处理。使用这个 View 时宽高传入 wrap_content，结果会怎么样？

根据上面onMeasure( ) 方法中，getDefaultSize()方法会进行判断，如果没有对 MODE 做处理，则调用getSuggestedMinimumWidth()和getSuggestedMinimumHeight()，View 的宽高都是取父 View 的宽高。

问题： invaliate 和 requestlayout 方法的区别？

前面我们说到，ViewRootImpl 作为顶级 View 负责 View 的绘制。所以简单来说，requestlayout 和 invaliate 最终都会向上回溯调用到 ViewRootImpl 的 postTranversals 方法来绘制 View。

不同的是 requestlayout 会绘制 View 的 measure，layout 和 draw 过程。invaliate 因为只添加了绘制 draw 的标志位，只会绘制 draw 过程。

layout

measure（）方法中我们已经测量出View的大小，根据这些大小，我们接下来就需要确定 View 在父 View 的位置进行排版布局，这就是layout 作用。

对 View 进行排版布局，还是要看父 View，也就是 ViewGroup。
在这里插入图片描述
代码不多，大致作用就是判断 View 是否在执行动画，如果是在执行动画，则等待动画执行完调用 requestLayout()，如果没有添加动画或者动画已经执行完了，则调用View的 layout（）。

public void layout(int l, int t, int r, int b) {

     /*-----------省略代码---------------*/
    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);
            }
        }
    }

   /*-----------省略代码---------------*/
}

View 的 layout 的方法也是非常长。大致作用就是设置 View 的在父 View 的位置，然后判断位置是否发生变化，是否需要重新调用排版布局，如果是需要重新布局则用了 onLayout（）方法。

在OnLayout 方法中，View 里面是一个空实现，而 ViewGroup 则是一个抽象方法。为什么这么设计呢？

因为onLayout主要就是设置View在父View中的位置，既然如此，那么View中的onLayout意义就不大了，而ViewGruop 必须实现，不然没法对子View进行布局。

那么如何对 View 进行排版呢？就是遍历所有的子 View 然后调用 child.layout(l, t, r, b)。

draw

经过前面的测量跟布局之后，接下来就是绘制了，也就是真正把 View 绘制在屏幕可见视图上。draw（）作用就是绘制View 的背景，内容，绘制子View，还有前景跟滚动条。

@CallSuper
public void draw(Canvas canvas) {

    /*-----------省略代码---------------*/
    // Step 1, draw the background, if needed
    int saveCount;

    if (!dirtyOpaque) {
        drawBackground(canvas);
    }

  /*-----------省略代码---------------*/
    if (!verticalEdges && !horizontalEdges) {
        // Step 3, draw the content
        if (!dirtyOpaque) onDraw(canvas);

        // Step 4, draw the children
        dispatchDraw(canvas);

        drawAutofilledHighlight(canvas);

        // Overlay is part of the content and draws beneath Foreground
        if (mOverlay != null && !mOverlay.isEmpty()) {
            mOverlay.getOverlayView().dispatchDraw(canvas);
        }

        // Step 6, draw decorations (foreground, scrollbars)
        onDrawForeground(canvas);

        // Step 7, draw the default focus highlight
        drawDefaultFocusHighlight(canvas);

     /*-----------省略代码---------------*/
        return;
    }

draw 过程中一共分成7步，其中两步我们直接直接跳过不分析了。

第一步：drawBackground(canvas)：作用就是绘制 View 的背景。

第三步：onDraw(canvas) ：绘制 View 的内容。View 的内容是根据自己需求自己绘制的，所以方法是一个空方法，View的继承类自己复写实现绘制内容。

第三步：dispatchDraw（canvas）：遍历子View进行绘制内容。在 View 里面是一个空实现，ViewGroup 里面才会有实现。在自定义 ViewGroup 一般不用复写这个方法，因为它在里面的实现帮我们实现了子 View 的绘制过程，基本满足需求。

第四步：onDrawForeground(canvas)：对前景色跟滚动条进行绘制。

第五步：drawDefaultFocusHighlight(canvas)：绘制默认焦点高亮

View的事件分发与传递机制

当Android设备的屏幕，接收到触摸的动作时，屏幕驱动把压力信号（包括压力大小，压力位置等）传递给系统底层，然后操作系统经过一系列的处理，然后把触摸事件一层一层的向上传递，最终事件会被准确的传递到产生事件的对象上，系统会遍历每一个View对象，然后计算触摸点在哪一个View中。比如A和B两个View，是兄弟View，AView产生的触摸事件，是不会被分发到B上面的。

Android的framework层如何处理事件的分发过程？

流程讲解

触摸事件到了framework层之后，首先会被传递到Activity，然后Activity会把事件委托给它内部的Window对象进行分发处理，而Window对象又会委托它内部的DecorView进行事件分发处理，DecorView是整棵View树的根节点，它会遍历所有子View去寻找能够处理点击事件的View；如果没有找到可以处理点击事件的View，事件就会反向传递，由Activity的onTouchEvent处理。
在这里插入图片描述

需要View的三个重要方法来共同完成：

dispatchTouchEvent
它是事件分发的重要方法。
返回值：表示是否消费了当前事件，可能是View本身的onTouchEvent方法消费，也可能是子View的dispatchTouchEvent方法中消费。
- 返回true：表示事件被消费，本次的事件终止。
- 返回false：表示View以及子View均没有消费事件，将调用父View的onTouchEvent方法
onInterceptTouchEvent
事件拦截，当一个ViewGroup在接到MotionEvent事件序列时候，首先会调用此方法判断是否需要拦截。
特别注意，这是ViewGroup特有的方法，View本身是不存在分发，所以没有拦截方法。
返回值：是否拦截事件传递
- 返回true：表示拦截了事件，那么事件将不再向下分发而是调用View本身的onTouchEvent方法。
- 返回false：表示不做拦截，事件将向下分发到子View的dispatchTouchEvent方法。
onTouchEvent
真正对MotionEvent进行处理或者说消费的方法，在dispatchTouchEvent进行调用。
返回值：事件是否被消费
- 返回true：表示事件被消费，本次的事件终止
- 返回false：表示事件没有被消费，将调用父View的onTouchEvent方法

上面的三个方法可以用以下的伪代码来表示其之间的关系：

public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean consume = false;//事件是否被消费
    if (onInterceptTouchEvent(ev)){//调用onInterceptTouchEvent判断是否拦截事件
        consume = onTouchEvent(ev);//如果拦截则调用自身的onTouchEvent方法
    }else{
        consume = child.dispatchTouchEvent(ev);//不拦截调用子View的dispatchTouchEvent方法
    }
    return consume;//返回值表示事件是否被消费，true事件终止，false调用父View的onTouchEvent方法
}

在这里插入图片描述

源码分析

步骤1：点击事件产生最先传递到当前的Activity，由Acivity的dispatchTouchEvent方法来对事件进行分发。
在这里插入图片描述
跟进getWindow().superDispatchTouchEvent(ev)方法发现是Window类当中的一个抽象方法。Window的源码有说明The only existing implementation of this abstract class is
android.view.PhoneWindow，Window的唯一实现类是PhoneWindow。那么去看PhoneWindow对应的代码。
在这里插入图片描述

PhoneWindow又调用了DecorView的superDispatchTouchEvent方法。而这个DecorView就是Window的顶级View。我们通过setContentView设置的View是它的子View。

步骤2：到这里事件已经被传递到我们的顶级View中，一般是ViewGroup。
那么接下来重点将放到ViewGroup的dispatchTouchEvent方法中。我们之前说过，事件到达View会调用dispatchTouchEvent方法，如果View是ViewGroup那么会先判断是否拦截该事件。
在这里插入图片描述
当ViewGroup不拦截事件，那么事件将下发给子View进行处理，遍历子View，子View必须满足可见，没有播放动画，点击事件坐标落在子View内部这几个条件。

接下来关键来了
dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)方法
在这里插入图片描述
可以看到它被最后一个if包围，如果它返回为true，那么就break跳出循环；如果返回为false则继续遍历下一个子View。
我们跟进dispatchTransformedTouchEvent方法可以看到这样的关键逻辑

这里child是我们遍历传入的子View，此时不为null，则调用了child.dispatchTouchEvent(event);

如果子View的dispatchTouchEvent方法返回true，表示子View处理了事件，则mFirstTouchTarget 就会被addTouchTarget(child, idBitsToAssign)赋值，到此子View遍历结束；

如果子View的dispatchTouchEvent方法返回false，则继续遍历，直到child == null，此时就会反向传递，调用super.dispatchTouchEvent(event)，让ViewGroup去处理这个事件。

步骤3：通过ViewGroup对事件的分发，我们知道事件最终是调用View的dispatchTouchEvent来处理。View最终是怎么去处理事件的呢？
在这里插入图片描述
通过上面代码我们可以看到View会先判断是否设置了OnTouchListener。

如果设置了OnTouchListener并且onTouch方法返回了true，那么onTouchEvent不会被调用。

当没有设置OnTouchListener或者设置了OnTouchListener但是onTouch方法返回false，则会调用View自己的onTouchEvent方法

接下来看onTouchEvent方法：
在这里插入图片描述
可以看出即便View是disabled状态，依然不会影响事件的消费，只是它看起来不可用。只要CLICKABLE和LONG_CLICKABLE有一个为true，就一定会消费这个事件，就是onTouchEvent返回true。而View的longClickable默认为false，clickable需要区分情况，如Button的clickable默认为true，而TextView的clickable默认为false。

假如我们想让View默认不可点击，将View的clickable设置成false，在合适的时候需要可点击所以我们又给View设置了OnClickListener，那么你会发现View默认依然可以点击，也就是说setClickable失效了。这是因为：
View的setOnClickListener会默认将View的clickable设置成true。
View的setOnLongClickListener同样会将View的longClickable设置成true。
在这里插入图片描述

这里有四点需要特别强调一下：

子View可以通过requestDisallowInterceptTouchEvent方法干预父View的事件分发过程（ACTION_DOWN事件除外），而这就是我们处理滑动冲突常用的关键方法。
对于View（注意！ViewGroup也是View）而言，如果设置了onTouchListener，并且View是enable的，如果onTouch方法返回false，那么onTouchEvent方法会被调用；如果onTouch方法返回true，则onTouchEvent方法不会被调用（onClick事件是在onTouchEvent中调用）。所以三者优先级是onTouch->onTouchEvent->onClick
View 的onTouchEvent 方法默认都会消费掉事件（返回true），除非它是不可点击的（clickable和longClickable同时为false），View的longClickable默认为false，clickable需要区分情况，如Button的clickable默认为true，而TextView的clickable默认为false。
setOnLongClickListener和setOnClickListener是否只能执行一个？不是的，只要setOnLongClickListener中的onClick返回false，则两个都会执行；返回true则会只执行setOnLongClickListener

FloriztW

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
View的绘制、View的事件分发与传递

view的绘制流程View 绘制中主要流程分为measure，layout， draw 三个阶段。measure ：根据父 view 传递的 MeasureSpec 进行计算大小。layout ：根据 measure 子 View 所得到的布局大小和布局参数，将子View放在合适的位置上。draw ：把 View 对象绘制到屏幕上。发起绘制的入口那么发起绘制的入口在哪里呢？在介绍发起绘制的入口之前，我们需要先了解Window，ViewRootImpl，DecorView之间的联系。一个
复制链接

扫一扫