android 判断子view的高度能不能再父view中完全展示判断view是否可见

转载

karen 2024-07-02 12:53:16

文章标签 自定义控件 invalidate 源码分析 requestLayout 视图状态 文章分类 Android 移动开发

使用View的时候会发现它是有状态的：

比如说按钮，普通状态下是一种效果，但是当手指按下的时候就会变成另外一种效果，这样才会给人产生一种点击了按钮的感觉。

它背后的实现原理应该是什么样的，今天就让我们来一起探究一下吧。

一、视图状态

视图状态的种类非常多，一共有十几种类型，不过多数情况下我们只会使用到其中的几种，因此这里我们也就只去分析最常用的几种视图状态。

1. enabled

表示当前视图是否可用。可以调用setEnable()方法来改变视图的可用状态，传入true表示可用，传入false表示不可用。

它们之间最大的区别在于，不可用的视图是无法响应onTouch事件的。

2. focused

表示当前视图是否获得到焦点。通常情况下有两种方法可以让视图获得焦点，即通过键盘的上下左右键切换视图，以及调用requestFocus()方法。而现在的Android手机几乎都没有键盘了，因此基本上只可以使用requestFocus()这个办法来让视图获得焦点了。而requestFocus()方法也不能保证一定可以让视图获得焦点，它会有一个布尔值的返回值，如果返回true说明获得焦点成功，返回false说明获得焦点失败。一般只有视图在focusable和focusable in touch mode同时成立的情况下才能成功获取焦点，比如说EditText。

3. window_focused

表示当前视图是否处于正在交互的窗口中，这个值由系统自动决定，应用程序不能进行改变。

4. selected

表示当前视图是否处于选中状态。一个界面当中可以有多个视图处于选中状态，调用setSelected()方法能够改变视图的选中状态，传入true表示选中，传入false表示未选中。

5. pressed

表示当前视图是否处于按下状态。可以调用setPressed()方法来对这一状态进行改变，传入true表示按下，传入false表示未按下。通常情况下这个状态都是由系统自动赋值的，但开发者也可以自己调用这个方法来进行改变。

我们可以在项目的drawable目录下创建一个selector文件，在这里配置每种状态下视图对应的背景图片。比如创建一个compose_bg.xml文件，在里面编写如下代码：

<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:drawable="@drawable/compose_pressed" android:state_pressed="true"></item>
    <item android:drawable="@drawable/compose_pressed" android:state_focused="true"></item>
    <item android:drawable="@drawable/compose_normal"></item>
</selector>

创建好了这个selector文件后，我们就可以在布局或代码中使用它了，比如将它设置为某个视图的背景图。

当手指按在视图上的时候，视图的状态就已经发生了变化，此时视图的pressed状态是true。

每当视图的状态有发生改变的时候，就会回调 View.drawableStateChanged() 方法，代码如下所示：

protected void drawableStateChanged() {
    Drawable d = mBGDrawable;//view的背景，即android:background属性值
    if (d != null && d.isStateful()) {
        d.setState(getDrawableState());//更新视图状态
    }
}

代码中的mBGDrawable是什么呢？观察

setBackgroundResource() 方法中的代码，如下所示：

public void setBackgroundResource(int resid) {
    if (resid != 0 && resid == mBackgroundResource) {
        return;
    }
    Drawable d= null;
    if (resid != 0) {
        d = mResources.getDrawable(resid);//将resid转换成了一个Drawable对象
    }
    setBackgroundDrawable(d);//将传入的Drawable对象赋值给mBGDrawable
    mBackgroundResource = resid;
}

可以看到，在第7行调用了

Resource.getDrawable() 方法将resid转换成了一个

Drawable对象，

然后调用了 setBackgroundDrawable() 方法并将这个Drawable对象传入，该方法会将传入的Drawable对象赋值给mBGDrawable。

而我们在布局文件中通过 android:background属性指定的selector文件，效果等同于调用setBackgroundResource()方法。也就是说drawableStateChanged()方法中的mBGDrawable对象其实就是我们指定的selector文件。

接下来在之前的

drawableStateChanged() 的第4行调用了 getDrawableState() 来获取视图状态，代码如下所示：

public final int[] getDrawableState() {
    // 判断当前视图的状态是否发生了改变
    if ((mDrawableState != null) && ((mPrivateFlags & DRAWABLE_STATE_DIRTY) == 0)) {
        return mDrawableState;//没变，就返回当前状态
    } else {//变了，就用onCreateDrawableState()获取最新状态并返回
        mDrawableState = onCreateDrawableState(0);
        mPrivateFlags &= ~DRAWABLE_STATE_DIRTY;
        return mDrawableState;
    }
}

如果发生了改变就调用

onCreateDrawableState() 方法来获取最新的视图状态。视图的所有状态会以一个整型数组的形式返回。

得到了视图状态的数组之后，就会在之前的drawableStateChanged()中调用Drawable.setState()

public boolean setState(final int[] stateSet) {
    if (!Arrays.equals(mStateSet, stateSet)) {//判断视图状态的数组是否发生了变化
        mStateSet = stateSet;//更新状态
        return onStateChange(stateSet);//将背景设置为当前状态对应的那张图片
    }
    return false;
}

DrawableonStateChange() 中其实就只是简单返回了一个false，并没有任何的逻辑处理，这是为什么呢？

这主要是因为mBGDrawable对象是通过一个selector文件创建出来的，而通过这种文件创建出来的Drawable对象其实都是一个StateListDrawable实例，因此这里调用的onStateChange()方法实际上调用的是StateListDrawable.onStateChange() ，那么我们赶快看一下吧：

@Override
protected boolean onStateChange(int[] stateSet) {
    int idx = mStateListState.indexOfStateSet(stateSet);//找到当前视图状态对应的Drawable资源下标
    if (DEBUG) android.util.Log.i(TAG, "onStateChange " + this + " states "
            + Arrays.toString(stateSet) + " found " + idx);
    if (idx < 0) {
        idx = mStateListState.indexOfStateSet(StateSet.WILD_CARD);
    }
    if (selectDrawable(idx)) { //将视图的背景设置为当前视图状态所对应的那张图片
        return true;
    }
    return super.onStateChange(stateSet);
}

这里会先调用

indexOfStateSet() 找到当前视图状态所对应的Drawable资源下标，

然后在第9行调用 selectDrawable()将下标传入，该方法就会将视图的背景设置为当前视图状态所对应的那张图片了。

任何一个视图的显示都要经过绘制流程的；很显然，背景图的绘制是在draw()方法中完成的，那么为什么 selectDrawable() 能够控制背景图的改变呢？这就要研究一下视图重绘的流程了。

二、视图重绘

虽然视图会在Activity加载完成之后自动绘制到屏幕上，但有时我们在与Activity进行交互的时候要求动态更新视图，比如改变视图的状态、以及显示或隐藏某个控件等。此时，之前绘制出的视图其实就已经过期了，此时我们就应该对视图进行重绘。

调用视图的setVisibility()、setEnabled()、setSelected()等都会导致视图重绘，如果想要手动地强制让视图进行重绘，可以调用invalidate() 来实现。

当然了，setVisibility()、setEnabled()、setSelected()等方法的内部其实也是通过调用invalidate()方法来实现的。

View的源码中会有数个invalidate()方法的重载和一个invalidateDrawable()方法，它们的原理都是相同的，因此我们只分析其中一种，代码如下所示：

void invalidate(boolean invalidateCache) {
    if (ViewDebug.TRACE_HIERARCHY) {
        ViewDebug.trace(this, ViewDebug.HierarchyTraceType.INVALIDATE);
    }
    if (skipInvalidate()) { //判断当前View是否需要重绘
        return;
    }
    if ((mPrivateFlags & (DRAWN | HAS_BOUNDS)) == (DRAWN | HAS_BOUNDS) ||
            (invalidateCache && (mPrivateFlags & DRAWING_CACHE_VALID) == DRAWING_CACHE_VALID) ||
            (mPrivateFlags & INVALIDATED) != INVALIDATED || isOpaque() != mLastIsOpaque) {
        mLastIsOpaque = isOpaque();
        mPrivateFlags &= ~DRAWN;
        mPrivateFlags |= DIRTY;
        if (invalidateCache) {
            mPrivateFlags |= INVALIDATED;
            mPrivateFlags &= ~DRAWING_CACHE_VALID;
        }
        final AttachInfo ai = mAttachInfo;
        final ViewParent p = mParent;
        if (!HardwareRenderer.RENDER_DIRTY_REGIONS) {
            if (p != null && ai != null && ai.mHardwareAccelerated) {
                p.invalidateChild(this, null);
                return;
            }
        }
        if (p != null && ai != null) {
            final Rect r = ai.mTmpInvalRect;
            r.set(0, 0, mRight - mLeft, mBottom - mTop);
            p.invalidateChild(this, r);
        }
    }
}

首先会调用

skipInvalidate() 来判断当前View是否需要重绘，判断的逻辑比较简单，如果View是不可见的且没有执行任何动画，就认为不需要重绘了。

之后会进行透明度的判断，并给View添加一些标记位，然后在第22和29行调用 ViewParent的invalidateChild()，这里的ViewParent其实就是当前视图的父视图，因此会调用到ViewGroup.invalidateChild()，代码如下所示：

public final void invalidateChild(View child, final Rect dirty) {
    ViewParent parent = this;
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        final boolean drawAnimation = (child.mPrivateFlags & DRAW_ANIMATION) == DRAW_ANIMATION;
        if (dirty == null) {
            ......
        } else {
            ......
            do { //循环获取当前布局的父布局
                View view = null;
                if (parent instanceof View) {
                    view = (View) parent;
                    if (view.mLayerType != LAYER_TYPE_NONE &&
                            view.getParent() instanceof View) {
                        final View grandParent = (View) view.getParent();
                        grandParent.mPrivateFlags |= INVALIDATED;
                        grandParent.mPrivateFlags &= ~DRAWING_CACHE_VALID;
                    }
                }
                if (drawAnimation) {
                    if (view != null) {
                        view.mPrivateFlags |= DRAW_ANIMATION;
                    } else if (parent instanceof ViewRootImpl) {
                        ((ViewRootImpl) parent).mIsAnimating = true;
                    }
                }
                if (view != null) {
                    if ((view.mViewFlags & FADING_EDGE_MASK) != 0 &&
                            view.getSolidColor() == 0) {
                        opaqueFlag = DIRTY;
                    }
                    if ((view.mPrivateFlags & DIRTY_MASK) != DIRTY) {
                        view.mPrivateFlags = (view.mPrivateFlags & ~DIRTY_MASK) | opaqueFlag;
                    }
                }
                parent = parent.invalidateChildInParent(location, dirty);
                if (view != null) {
                    Matrix m = view.getMatrix();
                    if (!m.isIdentity()) {
                        RectF boundingRect = attachInfo.mTmpTransformRect;
                        boundingRect.set(dirty);
                        m.mapRect(boundingRect);
                        dirty.set((int) boundingRect.left, (int) boundingRect.top,
                                (int) (boundingRect.right + 0.5f),
                                (int) (boundingRect.bottom + 0.5f));
                    }
                }
            } while (parent != null);
        }
    }
}

在第10行进入了一个while循环，当ViewParent不等于空的时候就会一直循环下去。

在这个while循环当中会不断地获取当前布局的父布局，并调用ViewGroup.invalidateChildInParent()，主要是来计算需要重绘的矩形区域，这里我们先不管它，当循环到最外层的根布局后，就会调用ViewRoot.invalidateChildInParent()，代码如下所示：

public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
    invalidateChild(null, dirty);
    return null;
}

这里的代码非常简单，仅仅是去调用了invalidateChild()方法而已，那我们再跟进去瞧一瞧吧：

public void invalidateChild(View child, Rect dirty) {
    checkThread();
    if (LOCAL_LOGV) Log.v(TAG, "Invalidate child: " + dirty);
    mDirty.union(dirty);
    if (!mWillDrawSoon) {
        scheduleTraversals();
    }
}

这个方法也不长，它在第6行又调用了scheduleTraversals()这个方法，那么我们继续跟进：

public void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        sendEmptyMessage(DO_TRAVERSAL);
    }
}

可以看到，这里调用了

sendEmptyMessage()，并传入了一个DO_TRAVERSAL参数。

如果你看一下ViewRoot的类定义就会发现，它是继承自Handler的，也就是说会在ViewRoot的handleMessage()中接收到该消息。那么赶快看一下handleMessage()方法的代码吧，如下所示：

public void handleMessage(Message msg) {
    switch (msg.what) {
    case DO_TRAVERSAL:
        if (mProfile) {
            Debug.startMethodTracing("ViewRoot");
        }
        performTraversals();//进入视图绘制的入口
        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
        break;
    ......
}

这里在第7行调用了

performTraversals()，这不就是我们在前面一篇文章中学到的视图绘制的入口吗？

经过一番辗转，调用视图的invalidate()最终会走到performTraversals()方法中，然后重新执行绘制流程。

回答前一节最后提到的问题：为什么 selectDrawable() 能够控制背景图的改变？
来看它的源码：

public boolean selectDrawable(int idx) {
    if (idx == mCurIndex) {
        return false;
    }
    ........

    invalidateSelf();
    return true;
}

前面一堆代码可以忽略，最后调用了

invalidateSelf()，这个方法中的代码如下所示：

public void invalidateSelf() {
    final Callback callback = getCallback();
    if (callback != null) {
        callback.invalidateDrawable(this);
    }
}

可以看到，这里会先调用getCallback()方法获取Callback接口的回调实例，然后再去调用回调实例的

invalidateDrawable()。那么这里的回调实例又是什么呢？观察一下View的类定义其实你就知道了，如下所示：

public class View implements Drawable.Callback, Drawable.Callback2, KeyEvent.Callback,
AccessibilityEventSource {
    ......
}

View类正是实现了

Callback接口，所以刚才其实调用的就是View中的invalidateDrawable()，之后就会按照我们前面分析的流程执行重绘逻辑，所以视图的背景图才能够得到改变的。

另外需要注意的是，invalidate()方法虽然最终会调用到performTraversals()方法中，但这时measure和layout流程是不会重新执行的，因为视图没有强制重新测量的标志位，而且大小也没有发生过变化，所以这时只有draw流程可以得到执行。如果你希望视图的绘制流程可以完完整整地重新走一遍，就不能使用invalidate()方法，而应该调用 requestLayout()了。

两个方法的区别（如下图）：

android 判断子view的高度能不能再父view中完全展示判断view是否可见_源码分析

invalidate()
请求重绘 View 树，即 draw 过程，假如视图发生大小没有变化就不会调用layout()过程，并且只绘制那些调用了invalidate()方法的 View。
Android中实现view的更新有两个方法，一是invalidate，二是postInvalidate，其中前者是在UI线程自身中使用，而后者在非UI线程中使用。
requestLayout()
当布局变化的时候(view的LayoutParams发生改变)，比如方向变化，尺寸的变化，会调用该方法，在自定义的视图中，如果某些情况下希望重新测量尺寸大小，应该手动去调用该方法，会触发 measure()和 layout()过程。而draw()的触发是有条件，如果view是透明的（即不自带背景也不给它设置背景），或者view的大小为0，那么无论什么时候都不会触发它的draw（例如1个ViewGroup包含了多个子view，但你没给这ViewGroup设置背景，那它自己的draw和onDraw不会被执行）。换句话说，自定义View的时候，如果你想View的onDraw被调用，那么你的这个View不能是透明的，也不能大小为0。当然，如果view的LayoutParams没改变的话，requestLayout同样不会触发draw()，而不同的是，invalidate()必能触发draw()。

那有些同学要问，如果需要局部刷新怎么办？
使用 requestFocus()方法，他只刷新你要刷新的地方。他是让我们的某一部分获取焦点，获取焦点的会导致view的重绘。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。