关于《RecyclerView的item添加悬浮层的效果》的问题反馈

本文主要是介绍关于《RecyclerView的item添加悬浮层的效果》的问题反馈，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

如果你还没看过自定义View：实现RecyclerView的item添加悬浮层的效果，可以先阅读上一篇。

上一周向郭神的微信公众号投稿《RecyclerView的item添加悬浮层的效果》，看到有那么多的朋友阅读和留言评论，心情十分激动，文章已将近过去一周，阅读的高峰期应该已经过去了，这里针对评论反馈的问题，来写一个解答篇。

正文

ListView版本已发布

之前说会做一个ListView的版本，现在已经完成并发布到github上了。实现的思路和RecyclerView基本相同，只是在判断child是否移除有一些不同，因为在ListView中没有

addOnChildAttachStateChangeListener

监听，所以我们换一种思路：

// 判断显示浮层的child是否已经划出屏幕
if (needFloatChild != null) {if (needFloatInScreen(firstVisibleItem, visibleItemCount)) {clearFloatChild();}
}private boolean needFloatInScreen(int firstVisibleItem, int visibleItemCount) {// 别忘了visibleItemCount包含了第一个可见的item，所以要减一return needFloatChildPosition < firstVisibleItem || needFloatChildPosition > firstVisibleItem + visibleItemCount - 1;
}

我们在onScroll中判断当前屏幕中显示浮层的child是否在第一个可见和最后一个可见之中。其他的实现无太大变化，欢迎大家使用。

问题一：方案二中滑动停止添加浮层的性能问题

这个方案是我当时临时想出来的方案，因为本人不是特别喜欢频繁的添加或删除View的操作，所以简单思考后，就放弃了这种想法，但是没想到很多朋友对于方案二非常的支持。于是我又仔细的研究了方案二和方案三，从实现思路上看，方案二和方案三基本相同：只是在得到显示浮层的Child时，是执行addView，还是显示浮层，其余无变化。这次再重新做一次对比：

嵌套层级

方案二减少了嵌套的层级。可以直接继承RecyclerView，通过重写onScoll等相关方法实现此效果（内部实现）。而方案三需要在RecyclerView外部嵌套一个FramLayout，通过设置OnScrollListener实现（外部实现）。

开发成本

方案二减少了部分代码量。直接调用addView，比方案三中计算浮层位置更简单。

对Adapter的入侵

方案二中，child中需要显示浮层的根布局受到了限制，只能使用类似FramLayout或者RelativeLayout这种布局，才能覆盖掉child的内容。而方案三对Adapter无入侵。

扩展性

方案二中，浮层的大小和位置都受到了child的限制，而方案三浮层的可显示区域是整个RecyclerView的大小，相比之下，方案三的扩展性要稍强一些，例如，变态的需求举例：浮层比child要大，或者显示在child以外的位置。

滑动性能的对比

因为方案二中添加addView操作是在滑动静止状态，所以对于用户是没有感知的，除了那种极其变态的操作下，滑动性能几乎是没有影响。方案三是控制浮层的显示和隐藏，也是同样的道理，但是如果硬要抠，显示的效率，肯定显示和隐藏的效果更高一些。

耦合性的对比

有一个朋友提到了手势重写的问题：如果嵌套在ViewPager中需要重写手势怎么办，方案三相对于方案二的耦合性太高。

我几经思考还是没有想到该如何回答这个问题，因为方案二和方案三的操作都需要重写手势监听，并且更新浮层的位置。如果需求和实现出现了冲突，无论哪一种方案都避免不了对View进行定制化。

所以在常见的应用场景中，方案二发挥的也是很棒的，也是值得推荐的一种方案。