遇到个难题，怎么修改子View绘制顺序？

最新推荐文章于 2024-04-16 17:02:26 发布

转载最新推荐文章于 2024-04-16 17:02:26 发布 · 787 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

原文链接：https://mp.weixin.qq.com/s/nEvBqMPrdmirADo-Y6ihYg

recycleView 专栏收录该内容

60 篇文章

订阅专栏

本文围绕RecycleView中某一项放大效果被遮挡的问题展开。先写Demo复现问题，分析原因是绘制顺序导致。通过研究View的draw方法，得出修改ViewGroup子View绘制顺序的基本方法。RecycleView提供了API简化操作。此外，还发现事件分发中遍历子View顺序和绘制顺序获取机制相同。

前言

周一的早上，由于项目的开发做的差不多了，正在等待测试结果的我就开始发呆，思考端午节的去处～

“理塘？稻城？还是...解决bug？”

不行不行，可不能让BUG耽误了我的假期，于是我打开公司的项目管理工具，看看测试有没有反馈问题。果然，出现了一个BUG。

大概就是一个RecycleView，需要把其中某一项做放大效果，类似焦点放大的效果。

但是现在的APP中显示效果是会被下一个View遮挡住，我简单写了个Demo说明：

正常的效果应该是Item4的View做放大效果，处在item3和item5的上一层。

但是现在的效果是Item4在Item3的上面，Item5又在Item4的上面，所以放大的Item4被遮挡住了。

这是什么问题呢？

写个Demo

首先，我们写个Demo复制下BUG出现的页面：

//初始化RecycleView
var adapter = TestAdapter()
rv.layoutManager = LinearLayoutManager(this)
rv.adapter = adapter

//修改数据源
var list = mutableListOf<String>()
for (number in 0..10) {
   list.add("item$number")
}
adapter.addData(list)

//Adapter类
class TestAdapter() : RecyclerView.Adapter<TestAdapter.ViewHolder>(){
    var dataList = mutableListOf<String>()

    class ViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView){
        var tvName = itemView.findViewById<TextView>(R.id.item_name)

        fun bind(str: String,position: Int){
            tvName.text=str

            if (position==4){
                //Item4放大两倍
                itemView.scaleX=2f
                itemView.scaleY=2f
                itemView.setBackgroundColor(Color.RED)
            }else{
                itemView.scaleX=1f
                itemView.scaleY=1f
                itemView.setBackgroundColor(Color.GREEN)
            }
        }
    }

思考原因

把放假的事情放到一边，我慢慢理清了头绪：

由于RecycleView是一个ViewGroup，所以也会按顺序一个个绘制子View，也就是按照顺序调用childView的draw方法。

所以在这个案例中，正常的绘制顺序就是：

Item0 -> Item1 ..Item3 -> Item4 -> Item5 ...

所以被放大的Item4自然也就处在Item3的上层，但会被Item5遮挡。

那怎么解决呢？

“如果能修改RecycleView的子View绘制顺序就好了～” 脑中突然浮现出这样的一句话。

对哦，如果能修改子View绘制顺序，让Item4在Item3和Item5之后进行绘制，那么就不会被遮挡了。

但是，真的能修改吗？

再看draw方法

这个问题本质上还是涉及到ViewGroup的子View 绘制问题，所以我们再次回顾View的draw方法：

//View.java
public void draw(Canvas canvas) {
    final int privateFlags = mPrivateFlags;
    mPrivateFlags = (privateFlags & ~PFLAG_DIRTY_MASK) | PFLAG_DRAWN;

    // Step 1, draw the background, if needed
    drawBackground(canvas);

    // Step 2, save the canvas' layers
    canvas.saveUnclippedLayer..

    // Step 3, draw the content
    onDraw(canvas);

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

    // Step 5, draw the fade effect and restore layers
    canvas.drawRect..

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

}

其中第三步大家都很熟悉，就是绘制View本身的onDraw方法，而在此之后，就是dispatchDraw方法，根据注释我们得知，这个方法就是用来绘制子View的。

//View.java
protected void dispatchDraw(Canvas canvas) {

}

在View中是一个空实现，既然是绘制子View，那么肯定会发生在ViewGroup中，所以我们大胆的猜测，在ViewGroup中应该对这个方法进行了重写：

//ViewGroup.java
@Override
protected void dispatchDraw(Canvas canvas) {
    //1、是否使用渲染节点
    boolean usingRenderNodeProperties = canvas.isRecordingFor(mRenderNode);
    final int childrenCount = mChildrenCount;
    final View[] children = mChildren;
    //2、预排序列表
    final ArrayList<View> preorderedList = usingRenderNodeProperties
            ? null : buildOrderedChildList();
    //3、是否自定义顺序
    final boolean customOrder = preorderedList == null
            && isChildrenDrawingOrderEnabled();
    //4、遍历子View
    for (int i = 0; i < childrenCount; i++) {
        //5、获取当前需要绘制的View序号
        final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);
        //根据序号获取View
        final View child = getAndVerifyPreorderedView(preorderedList, children, childIndex);
        if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) {
            //6、绘制子view
            more |= drawChild(canvas, child, drawingTime);
        }
    }
}

protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
    return child.draw(canvas, this, drawingTime);
}

代码进行了精简，我们一步步来看：

1、这里有一个属性叫做usingRenderNodeProperties，我们暂且不用管它是什么，只知道默认为true即可。

2、初始化preorderedList，这个我们今天也用不到，由于usingRenderNodeProperties为ture，所以这个列表为null。

3、这个属性就很重要了，customOrder——是否自定义顺序，看似和我们的需求对应上了。它的值由两者决定：preorderedList == null 并且 isChildrenDrawingOrderEnabled。前者我们知道为true，所以后者isChildrenDrawingOrderEnabled就是我们待会需要关注的。

4、开始遍历子View，注意这里的i还是正常的顺序，会从0一直遍历到childrenCount-1。

5、获取View对应的序号，所以获取子View并没有直接用遍历中的i，而是通过getAndVerifyPreorderedIndex方法再次获取子View的Index，然后再获取子View。

6、最后获取子View后，就开始调用drawChild也就是child.draw方法进行子View的绘

制，这样绘制就传递到子View了。

通过上面的讲解，我们知道了重点就在于获取当前需要绘制View的对应Index方法中，也就是方法getAndVerifyPreorderedIndex：

//获取子View的序号Index
private int getAndVerifyPreorderedIndex(int childrenCount, int i, boolean customOrder) {
    final int childIndex;
    if (customOrder) {
        final int childIndex1 = getChildDrawingOrder(childrenCount, i);
        childIndex = childIndex1;
    } else {
        childIndex = i;
    }
    return childIndex;
}

protected int getChildDrawingOrder(int childCount, int drawingPosition) {
    return drawingPosition;
}

//根据子View的序号Index获取子View
private static View getAndVerifyPreorderedView(ArrayList<View> preorderedList, View[] children,
        int childIndex) {
    final View child;
    if (preorderedList != null) {
        child = preorderedList.get(childIndex);
    } else {
        child = children[childIndex];
    }
    return child;
}

getAndVerifyPreorderedIndex方法负责返回子View的序号。

getAndVerifyPreorderedView方法按照序号childIndex，从children中取出序号对应的View。

当customOrder为true的时候，返回的view序号会被设置为getChildDrawingOrder方法的结果，否则就是按照正常的顺序序号，也就是i作为返回结果。

而getChildDrawingOrder方法默认情况下也是返回的参数drawingPosition，也就是正常顺序序号i。

但是，我们可以通过重写改变getChildDrawingOrder方法的返回结果，比如说：

当传入的正常View顺序是0，然后我们重写返回View序号为childCount-1。
当传入的正常View顺序是childCount-1，然后我们重写返回View序号为0。
其他情况正常返回

这样就能让原本在第一个绘制的View和最后一个绘制的View进行了顺序调换。

当然，getChildDrawingOrder方法能运行的前提是customOrder为true，而customOrder为true的前提是isChildrenDrawingOrderEnabled方法返回true。

final boolean customOrder = isChildrenDrawingOrderEnabled();

protected boolean isChildrenDrawingOrderEnabled() {
    return (mGroupFlags & FLAG_USE_CHILD_DRAWING_ORDER) == FLAG_USE_CHILD_DRAWING_ORDER;
}

所以，我们就能得出修改ViewGroup子View绘制顺序的基本方法了，主要有两步：

1、重写isChildrenDrawingOrderEnabled方法，返回true。（可以直接通过调用setChildrenDrawingOrderEnabled(true)方法来完成）

2、重写getChildDrawingOrder方法，返回当前顺序下需要进行绘制的View序号。

setChildrenDrawingOrderEnabled(true)

override fun getChildDrawingOrder(childCount: Int, drawingPosition: Int): Int {
    if (drawingPosition == 0) {
        return childCount - 1
    } else if (drawingPosition == childCount - 1) {
        return 0
    } else {
        return drawingPosition
    }
}

RecycleView 中的优化？

回到我们的需求，根据上述的分析，我们是不是需要自定义一个RecycleView，然后重写isChildrenDrawingOrderEnabled 和 getChildDrawingOrder 两个方法呢？

并不需要，RecycleView已经为我们提供了API，那就是setChildDrawingOrderCallback方法：

public void setChildDrawingOrderCallback(@Nullable ChildDrawingOrderCallback childDrawingOrderCallback) {
    mChildDrawingOrderCallback = childDrawingOrderCallback;
    setChildrenDrawingOrderEnabled(mChildDrawingOrderCallback != null);
}

public interface ChildDrawingOrderCallback {
    int onGetChildDrawingOrder(int childCount, int i);
}

可以看到，如果我们调用setChildDrawingOrderCallback方法，并且传入一个不为空的ChildDrawingOrderCallback，那么就会调用setChildrenDrawingOrderEnabled(true)来完成修改绘制顺序的第一步了，也就是保证customOrder为true。

那么getChildDrawingOrder方法是怎么和ChildDrawingOrderCallback回调方法产生联系的呢？

很明显，RecycleView肯定是重写了getChildDrawingOrder方法：

@Override
protected int getChildDrawingOrder(int childCount, int i) {
    if (mChildDrawingOrderCallback == null) {
        return super.getChildDrawingOrder(childCount, i);
    } else {
        return mChildDrawingOrderCallback.onGetChildDrawingOrder(childCount, i);
    }
}

所以getChildDrawingOrder方法的结果就等于回调方法ChildDrawingOrderCallback.onGetChildDrawingOrder。

至此，修改子View绘制顺序的两步都完成了，通过RecycleView的setChildDrawingOrderCallback即可完成。

验证时刻

终于，一切可以尘埃落定了，接下来就是见证我们分析结果的时刻，来修改Demo：

rv.setChildDrawingOrderCallback(object : RecyclerView.ChildDrawingOrderCallback {
    override fun onGetChildDrawingOrder(childCount: Int, i: Int): Int {
        if (i < 4) {
            return i
        } else if (i < childCount - 1) {
            return i + 1
        } else {
            //最后绘制Item4
            return 4
        }
    }
})

运行：

结束了？并没有

到此，我们的BUG是解决了，但是，关于绘制顺序的知识点我们可以再做下延伸。

在搜索getAndVerifyPreorderedIndex方法的过程中，我发现了另外一处也用到了getAndVerifyPreorderedIndex方法：

@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
    if (!canceled && !intercepted) {
        if (actionMasked == MotionEvent.ACTION_DOWN
            || (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
             || actionMasked == MotionEvent.ACTION_HOVER_MOVE) {

            //和绘制顺序几乎一样的代码，获取子View的index，然后获取子View
            final ArrayList<View> preorderedList = buildTouchDispatchChildList();
            final boolean customOrder = preorderedList == null
                            && isChildrenDrawingOrderEnabled();
            final View[] children = mChildren;
            //遍历子View
            for (int i = childrenCount - 1; i >= 0; i--) {
                final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);
                final View child = getAndVerifyPreorderedView(
                        preorderedList, children, childIndex);
                //事件向下传递给子View        
                if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
                    break;
                }
            }
        }
    }
}

惊不惊喜，意不意外，在负责事件分发的dispatchTouchEvent方法中，我们找到了和绘制子View几乎一样的代码。

同样的通过getAndVerifyPreorderedIndex方法获取子View的序号，然后获取序号对应的子View。

有的朋友可能会疑惑，这里的preorderedList好像不为null了呢？直接赋值的buildTouchDispatchChildList方法？那我们就进去看看这个方法：

public ArrayList<View> buildTouchDispatchChildList() {
    return buildOrderedChildList();
}

ArrayList<View> buildOrderedChildList() {
    final int childrenCount = mChildrenCount;
    if (childrenCount <= 1 || !hasChildWithZ()) return null;

    final boolean customOrder = isChildrenDrawingOrderEnabled();
    for (int i = 0; i < childrenCount; i++) {
        // add next child (in child order) to end of list
        final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);
        final View nextChild = mChildren[childIndex];
        final float currentZ = nextChild.getZ();

        // insert ahead of any Views with greater Z
        int insertIndex = i;
        while (insertIndex > 0 && mPreSortedChildren.get(insertIndex - 1).getZ() > currentZ) {
            insertIndex--;
        }
        mPreSortedChildren.add(insertIndex, nextChild);
    }
    return mPreSortedChildren;
}

可以看到，第二句有一个判断：

if (childrenCount <= 1 || !hasChildWithZ()) return null;

private boolean hasChildWithZ() {
    for (int i = 0; i < mChildrenCount; i++) {
        if (mChildren[i].getZ() != 0) return true;
    }
    return false;
}

childrenCount <= 1 肯定是不成立的。

!hasChildWithZ() 这个一般情况下都是为true的，因为一般View是没有Z轴位置的（需要setZ方法设置z轴坐标）。

所以在事件分发的子View遍历中，preorderedList还是为null，所以和上述的子View绘制逻辑是一模一样的，还是靠isChildrenDrawingOrderEnabled方法和getChildDrawingOrder方法来完成修改事件分发的子View遍历顺序。

总结

1、ViewGroup可以通过调用setChildrenDrawingOrderEnabled(true)方法，以及重写getChildDrawingOrder方法修改子View绘制顺序。

2、RecycleView中将两者进行了封装，只需要调用setChildDrawingOrderCallback方法即可完成修改子View绘制顺序的需求。

3、事件分发的过程中，遍历子View的顺序和绘制子View的顺序获取机制是相同的。

（这里要注意，只是两者的顺序获取机制是相同的，都是通过getChildDrawingOrder方法获取，但是两者顺序并不是完全相同的。因为事件分发中遍历子View是倒序的，也就是从最后一个View开始遍历。而绘制子View的顺序是正序，也就是从第一个View开始遍历）

4、所以在我们修改子View绘制顺序的同时，其实也修改了事件分发的子View遍历顺序。

参考

https://www.wanandroid.com/wenda/show/8852

转自：https://mp.weixin.qq.com/s/nEvBqMPrdmirADo-Y6ihYg