andorid,把控件置于最顶端。bringToFront的意外发现

2018-01-23 02:22:17

 最近在项目终于到了View.bringToFront()方法,简单看了下其源码,在这儿总结一下。

  bringToFront方法在SDK中的说明是“Change the view's z order in the tree, so it's on top of other sibling views”,翻译过来就是改变view的z轴,使其处在他父view的顶端。关于bringToFront的实现,网上有很多资料介绍,大体来说就是将这个view从父view中移除,然后再加入父view的顶端。具体实现如何呢?

  bringToFront的具体实现要参看ViewGroup中的bringChildToFront方法。代码很简单,如下:

复制代码

  public void bringChildToFront(View child) {        int index = indexOfChild(child);        if (index >= 0) {
            removeFromArray(index);
            addInArray(child, mChildrenCount);
            child.mParent = this;
        }
    }

复制代码

  分两步,首先remove,然后add,实际上ViewGroup维持了一个View数组,addInArray方法会把这个child加入到数组最末端,在draw的时候,将依次画数组中的child,最后一个自然就放到了顶端。

  removeFromArray方法中有一段奇怪的代码:

if (!(mTransitioningViews != null && mTransitioningViews.contains(children[index]))) {
            children[index].mParent = null;
}

  mTransitioningViews官方解释如下:

  The set of views that are currently being transitioned. This list is used to track views being removed that should not actually be removed from the parent yet because they are being animated.

  正如上述,当某个child正在做动画的时候(这里指android.app.Fragment和android.animation.LayoutTransition移除view的动画),还不能删除这个child,应该等到动画结束,所以在ViewGroup中暂时保留这个child,直到动画真正结束后再真正删除。ViewGroup有两个成对出现的方法:startViewTransition和endViewTransition。在startViewTransition方法中将child加入mTransitioningViews中,在endViewTransition中最终执行view.dispatchDetachedFromWindow(),并在函数最后调用invalidate()。

  值得一提的是,在removeView的时候,如果当前child在mTransitioningViews中,ViewGroup并不会执行view.dispatchDetachedFromWindow(),也不会设置当前view的mParent为空。

  没想到分析bringToFront方法竟然还意外发现一个mTransitioningViews,由此可以看到一个潜在的问题,如果我们在执行LayoutTransition的DISAPPEARING动画同时removeView,这时子view还并未删除,如果直接将子view加入其它ViewGroup中则会报错“The specified child already has a parent. You must call removeView() on the child's parent first.” 因为此时这个view还未从上一个ViewGroup中删除。


  • 2019-05-21 12:43:26

    (重要)RecycleView的缓存机制

    RecycleView的四级缓存是由三个类共同作用完成的,Recycler、RecycledViewPool和ViewCacheExtension。Recycler用于管理已经废弃或者与RecyclerView分离的ViewHolder,这里面有两个重要的成员,为可以看见的屏幕的内部缓存成员mAttachedScrap、mChangedScrap和滑出屏幕外的外部缓存成员mCachedViews二者共同完成ViewHolder的缓存;RecycledViewPool类是用来缓存整体所有的ViewHolder,是对mCachedViews缓存的补充;ViewCacheExtension是扩展内的缓存对象,默认不加载,需实现方法getViewForPositionAndType(Recycler recycler, int position, int type)来实现自己的缓存。接下来对四级缓存一步步介绍。

  • 2019-05-21 12:44:31

    对嵌套RecyclerView的优化

    RecyclerView 是一个更高级的 ListView ,它可以重用view避免额外创建太多的view从而带来流畅的滚动性能。RecyclerView通过叫做 View pool 的东西持有不再可见的 view ,让它可被回收

  • 2019-05-25 14:54:50

    commit your changes or stash them before you can merge

    Your local changes to the following files would be overwritten by merge:         protected/config/main.php Please, commit your changes or stash them before you can merge. --------------------- 作者:陈小峰_iefreer 来源:CSDN 原文:https://blog.csdn.net/iefreer/article/details/7679631 版权声明:本文为博主原创文章,转载请附上博文链接!

  • 2019-05-27 10:43:34

    IntelliJ IDEA中C盘文件过大怎么办

    当我在D:\ 安装完IDEA9.0之后,建立了一个工程,发现C:\Users\Administrator\.IntelliJIdea90 竟然增大到了500+M,并且随着使用在逐渐增大,这样占用系统盘资源是非常让人不爽的,那么如何将其修改到其他路径呢?

  • 2019-05-28 13:33:20

    BRVAH+MTRVA,复杂?不存在的

    言归正传,这样的一个首页,我们需要做怎么样的基础工作呢?或者说,碰到以后更复杂的页面我们应该怎么做?这里小提示下,不要再用什么类似ScrollView的这种东西了,诶,好像说的有点绝对,尽量不要用,这不是谷歌想要看到的,5.0谷歌推出了RecyclerView,从它的整个设计架构来看,简直就是为这而生的。而RecyclerView的视图是通过Adapter来渲染的。原始的Adapter,让人很蛋疼,重复工作太多,我们应该要有封装的思想,把最需要的部分提供出来,其它不用管。

  • 2019-05-29 14:19:19

    解决Git中fatal: refusing to merge unrelated histories

    Git的报错 在使用Git的过程中有时会出现一些问题,那么在解决了每个问题的时候,都需要去总结记录下来,下次不再犯。 一、fatal: refusing to merge unrelated histories 今天在使用Git创建项目的时候,在两个分支合并的时候,出现了下面的这个错误。