recyclerview item点击无效-ag凯发k8国际
点击上方蓝字关注 ??
来源：肖邦kakahttps://www.jianshu.com/p/3e9aa4bdaefd前言
recyclerview这个控件几乎所有的android开发者都使用过(甚至不用加几乎)，它是真的很好用，完美取代了listview和gridview，而recyclerview之所以好用，得益于它优秀的缓存机制。关于recyclerview缓存机制，更是需要我们开发者来掌握的。本文就将先从整体流程看recyclerview的缓存，再带你从源码角度分析，跳过读源码的坑，最后用一个简单的demo的形式展示出来。在开始recyclerview的缓存机制之前我们先学习关于viewholder的知识。
recyclerview为什么强制我们实现viewholder模式？
关于这个问题，我们首先看一下listview。listview是不强制我们实现viewholder的，但是后来google建议我们实现viewholder模式。我们先分别看一下这两种不同的方式。
其实这里我已经用红框标出来了，listview使用viewholder的好处就在于可以避免每次getview都进行findviewbyid()操作，因为findviewbyid()利用的是dfs算法(深度优化搜索)，是非常耗性能的。而对于recyclerview来说，强制实现viewholder的其中一个原因就是避免多次进行findviewbyid()的处理，另一个原因就是因为itemview和viewholder的关系是一对一，也就是说一个viewholder对应一个itemview。这个viewholder当中持有对应的itemview的所有信息，比如说：position；view；width等等，拿到了viewholder基本就拿到了itemview的所有信息，而viewholder使用起来相比itemview更加方便。recyclerview缓存机制缓存的就是viewholder(listview缓存的是itemview)，这也是为什么recyclerview为什么强制我们实现viewholder的原因。
listview的缓存机制
在正式讲recyclerview的缓存机制之前还需要提一嘴listview的缓存机制，不多bb，先上图:
listview的缓存有两级，在listview里面有一个内部类 recyclebin，recyclebin有两个对象active view和scrap view来管理缓存，active view是第一级，scrap view是第二级。
active view：是缓存在屏幕内的itemview，当列表数据发生变化时，屏幕内的数据可以直接拿来复用，无须进行数据绑定。
scrap view：缓存屏幕外的itemview，这里所有的缓存的数据都是"脏的"，也就是数据需要重新绑定，也就是说屏幕外的所有数据在进入屏幕的时候都要走一遍getview()方法。再来一张图，看看listview的缓存流程
当active view和scrap view中都没有缓存的时候就会直接create view。
小结
listview的缓存机制相对比较好理解，它只有两级缓存，一级缓存active view是负责屏幕内的itemview快速复用，而scrap view是缓存屏幕外的数据，当该数据从屏幕外滑动到屏幕内的时候需要走一遍getview()方法。
recyclerview的缓存机制
先上图：
recyclerview的缓存分为四级
scrap
cache
viewcacheextension
recycledviewpool
scrap对应listview 的active view，就是屏幕内的缓存数据，就是相当于换了个名字，可以直接拿来复用。
cache 刚刚移出屏幕的缓存数据，默认大小是2个，当其容量被充满同时又有新的数据添加的时候，会根据fifo原则，把优先进入的缓存数据移出并放到下一级缓存中，然后再把新的数据添加进来。cache里面的数据是干净的，也就是携带了原来的viewholder的所有数据信息，数据可以直接来拿来复用。需要注意的是，cache是根据position来寻找数据的，这个postion是根据第一个或者最后一个可见的item的position以及用户操作行为(上拉还是下拉)。举个栗子：当前屏幕内第一个可见的item的position是1，用户进行了一个下拉操作，那么当前预测的position就相当于(1-1=0)，也就是position=0的那个item要被拉回到屏幕，此时recyclerview就从cache里面找position=0的数据，如果找到了就直接拿来复用。
viewcacheextension是google留给开发者自己来自定义缓存的，这个viewcacheextension我个人建议还是要慎用，因为我扒拉扒拉网上其他的博客，没有找到对应的使用场景，而且这个类的api设计的也有些奇怪，只有一个public abstract view getviewforpositionandtype(@nonnull recycler recycler, int position, int type);让开发者重写通过position和type拿到viewholder的方法，却没有提供如何产生viewholder或者管理viewholder的方法，给人一种只出不进的赶脚，还是那句话慎用。
recycledviewpool刚才说了cache默认的缓存数量是2个，当cache缓存满了以后会根据fifo(先进先出)的规则把cache先缓存进去的viewholder移出并缓存到recycledviewpool中，recycledviewpool默认的缓存数量是5个。recycledviewpool与cache相比不同的是，从cache里面移出的viewholder再存入recycledviewpool之前viewholder的数据会被全部重置，相当于一个新的viewholder，而且cache是根据position来获取viewholder，而recycledviewpool是根据itemtype获取的，如果没有重写getitemtype()方法，itemtype就是默认的。因为recycledviewpool缓存的viewholder是全新的，所以取出来的时候需要走onbindviewholder()方法。再来张图看看整体流程
这里大家先记住主要流程，并且记住各级缓存是根据什么拿到viewholder以及viewholder能否直接拿来复用，先有一个整体的认识，下面我会带着大家再简单分析一下recyclerview缓存机制的源码。
阅读recyclerview缓存机制源码
由于篇幅和内容的关系，我不可能带大家一行一行读，这里我只列出关键点，还有哪些需要重点看，哪些可以直接略过，避免大家陷入读源码一个劲儿钻进去出不来的误区。当recyclerview绘制的时候，会走到layoutmanager里面的next()方法，在next()里面是正式开始使用缓存机制，这里以linearlayoutmanager为例子
/**
* gets the view for the next element that we should layout.
* also updates current item index to the next item, based on {@link #mitemdirection}
*
* @return the next element that we should layout.
*/
view next(recyclerview.recycler recycler) {if (mscraplist != null) {return nextviewfromscraplist();
}final view view = recycler.getviewforposition(mcurrentposition);
mcurrentposition = mitemdirection;return view;
}
在next方法里传入了recycler对象，这个对象是recyclerview的内部类。我们先去看一眼这个类
public final class recycler {final arraylist mattachedscrap = new arraylist<>();
arraylist mchangedscrap = null;final arraylist mcachedviews = new arraylist();private final list
munmodifiableattachedscrap = collections.unmodifiablelist(mattachedscrap);private int mrequestedcachemax = default_cache_size;int mviewcachemax = default_cache_size;
recycledviewpool mrecyclerpool;private viewcacheextension mviewcacheextension;static final int default_cache_size = 2;
}
再看一眼recycledviewpool的源码
public static class recycledviewpool {private static final int default_max_scrap = 5;static class scrapdata {final arraylist mscrapheap = new arraylist<>();int mmaxscrap = default_max_scrap;long mcreaterunningaveragens = 0;long mbindrunningaveragens = 0;
}
sparsearray mscrap = new sparsearray<>();
其中mattachedscrap对应scrap；mcachedviews对应cache；mviewcacheextension对应viewcacheextension；mrecyclerpool对应recycledviewpool。注意：mattachedscrap、mcachedviews和recycledviewpool里面的mscrapheap都是arraylist，缓存被加入到这三个对象里面实际上就是调用的arraylist.add()方法，复用缓存呢，这里要注意一下不是调用的arraylist.get()而是arraylist.remove(),其实这里也很好理解，因为当缓存数据被取出来展示到了屏幕内，自然就应该被移除。我们现在回到刚才的next()方法里，recycler.getviewforposition(mcurrentposition); 直接去看getviewforposition这个方法，接着跟到了这里
view getviewforposition(int position, boolean dryrun) {return trygetviewholderforpositionbydeadline(position, dryrun, forever_ns).itemview;
}
接着跟进去
viewholder trygetviewholderforpositionbydeadline(int position,boolean dryrun, long deadlinens){if (position < 0 || position >= mstate.getitemcount()) {throw new indexoutofboundsexception("invalid item position " position
"(" position "). item count:" mstate.getitemcount()
exceptionlabel());
}boolean fromscraporhiddenorcache = false;
viewholder holder = null;// 0) if there is a changed scrap, try to find from thereif (mstate.isprelayout()) {
holder = getchangedscrapviewforposition(position);
fromscraporhiddenorcache = holder != null;
}// 1) find by position from scrap/hidden list/cacheif (holder == null) {
holder = getscraporhiddenorcachedholderforposition(position, dryrun);
}if (holder == null) {final int type = madapter.getitemviewtype(offsetposition);// 2) find from scrap/cache via stable ids, if existsif (madapter.hasstableids()) {
holder = getscraporcachedviewforid(madapter.getitemid(offsetposition),
type, dryrun);if (holder != null) {// update position
holder.mposition = offsetposition;
fromscraporhiddenorcache = true;
}
}if (holder == null && mviewcacheextension != null) {// we are not sending the offsetposition because layoutmanager does not// know it.final view view = mviewcacheextension
.getviewforpositionandtype(this, position, type);if (view != null) {
holder = getchildviewholder(view);
}
}if (holder == null) { // fallback to poolif (debug) {
log.d(tag, "trygetviewholderforpositionbydeadline("
position ") fetching from shared pool");
}
holder = getrecycledviewpool().getrecycledview(type);if (holder != null) {
holder.resetinternal();if (force_invalidate_display_list) {
invalidatedisplaylistint(holder);
}
}
}if (holder == null) {long start = getnanotime();if (deadlinens != forever_ns
&& !mrecyclerpool.willcreateintime(type, start, deadlinens)) {// abort - we have a deadline we can't meetreturn null;
}
holder = madapter.createviewholder(recyclerview.this, type);if (allow_thread_gap_work) {// only bother finding nested rv if prefetching
recyclerview innerview = findnestedrecyclerview(holder.itemview);if (innerview != null) {
holder.mnestedrecyclerview = new weakreference<>(innerview);
}
}
}
}boolean bound = false;if (mstate.isprelayout() && holder.isbound()) {// do not update unless we absolutely have to.
holder.mprelayoutposition = position;
} else if (!holder.isbound() || holder.needsupdate() || holder.isinvalid()) {if (debug && holder.isremoved()) {throw new illegalstateexception("removed holder should be bound and it should"
" come here only in pre-layout. holder: " holder
exceptionlabel());
}final int offsetposition = madapterhelper.findpositionoffset(position);
bound = trybindviewholderbydeadline(holder, offsetposition, position, deadlinens);
}return holder;
}
终于到了缓存机制最核心的地方，为了方便大家阅读，我对这部分源码进行了删减，直接从官方给的注释里面看。
// (0) if there is a changed scrap, try to find from thereif (mstate.isprelayout()) {
holder = getchangedscrapviewforposition(position);
fromscraporhiddenorcache = holder != null;
}
这里面只有设置动画以后才会为true，跟咱们讲的缓存也没有多大关系，直接略过。
// 1) find by position from scrap/hidden list/cacheif (holder == null) {
holder = getscraporhiddenorcachedholderforposition(position, dryrun);
}
这里就开始拿第一级和第二级缓存了getscraporhiddenorcachedholderforposition()这个方法可以深入去看以下，注意这里传的参数是position(dryrun这个参数不用管)，就跟我之前说的，scrap和cache是根据position拿到缓存。
if (holder == null && mviewcacheextension != null) {// we are not sending the offsetposition because layoutmanager does not// know it.
final view view = mviewcacheextension
.getviewforpositionandtype(this, position, type);if (view != null) {
holder = getchildviewholder(view);
}
}
这里开始拿第三级缓存了，这里我们不自定义viewcacheextension就不会进入判断条件，还是那句话慎用。
if (holder == null) { // fallback to poolif (debug) {
log.d(tag, "trygetviewholderforpositionbydeadline("
position ") fetching from shared pool");
}
holder = getrecycledviewpool().getrecycledview(type);if (holder != null) {
holder.resetinternal();if (force_invalidate_display_list) {
invalidatedisplaylistint(holder);
}
}
}
这里到了第四级缓存recycledviewpool，getrecycledviewpool().getrecycledview(type);通过type拿到viewholder，接着holder.resetinternal();重置viewholder，让其变成一个全新的viewholder
if (holder == null) {long start = getnanotime();if (deadlinens != forever_ns
&& !mrecyclerpool.willcreateintime(type, start, deadlinens)) {// abort - we have a deadline we can't meetreturn null;
}
holder = madapter.createviewholder(recyclerview.this, type);if (allow_thread_gap_work) {// only bother finding nested rv if prefetching
recyclerview innerview = findnestedrecyclerview(holder.itemview);if (innerview != null) {
holder.mnestedrecyclerview = new weakreference<>(innerview);
}
}
}
到这里如果viewholder还为null的话，就会create view了，创建一个新的viewholder
boolean bound = false;if (mstate.isprelayout() && holder.isbound()) {// do not update unless we absolutely have to.
holder.mprelayoutposition = position;
} else if (!holder.isbound() || holder.needsupdate() || holder.isinvalid()) {if (debug && holder.isremoved()) {
throw new illegalstateexception("removed holder should be bound and it should"
" come here only in pre-layout. holder: " holder
exceptionlabel());
}
final int offsetposition = madapterhelper.findpositionoffset(position);
bound = trybindviewholderbydeadline(holder, offsetposition, position, deadlinens);
}
这里else if (!holder.isbound() || holder.needsupdate() || holder.isinvalid())是判断这个viewholder是不是有效的，也就是可不可以复用，如果不可以复用就会进入trybindviewholderbydeadline(holder, offsetposition, position, deadlinens);这个方法，在这里面调用了bindviewholder()方法。点进去看一眼
private boolean trybindviewholderbydeadline(@nonnull viewholder holder, int offsetposition,
int position, long deadlinens) {
....................madapter.bindviewholder(holder, offsetposition);
....................return true;
}
在点进去就到了我们熟悉的onbindviewholder()
public final void bindviewholder(@nonnull vh holder, int position) {
.......................onbindviewholder(holder, position, holder.getunmodifiedpayloads());
.........................
}
至此，缓存机制的整体流程就全部分析完毕了。
小结
listview有两级缓存，分别是active view和scrap view，缓存的对象是itemview；而recyclerview有四级缓存，分别是scrap、cache、viewcacheextension和recycledviewpool，缓存的对象是viewholder。scrap和cache分别是通过position去找viewholder可以直接复用；viewcacheextension自定义缓存，目前来说应用场景比较少却需慎用；recycledviewpool通过type来获取viewholder，获取的viewholder是个全新，需要重新绑定数据。当你看到这里的时候，面试官再问recyclerview的性能比listview优化在哪里，我想你已经有答案。
通过demo理解
担心你看完上面的内容，倒头就忘，我们写个简单的demo通过打印log的方式来巩固一下学到的知识。简单说一下demo里面需要注意的代码，下面是对recyclerview的一个包装
public class recyclerviewwrapper extends recyclerview {private layoutlistener layoutlistener;public recyclerviewwrapper(@nonnull context context) {super(context);
}public recyclerviewwrapper(@nonnull context context, @nullable attributeset attrs) {super(context, attrs);
}public recyclerviewwrapper(@nonnull context context, @nullable attributeset attrs, int defstyle) {super(context, attrs, defstyle);
}public void setlayoutlistener(layoutlistener layoutlistener) {this.layoutlistener = layoutlistener;
}@overrideprotected void onlayout(boolean changed, int l, int t, int r, int b) {if (layoutlistener != null) {
layoutlistener.onbeforelayout();
}super.onlayout(changed, l, t, r, b);if (layoutlistener != null) {
layoutlistener.onafterlayout();
}
}public interface layoutlistener {void onbeforelayout();void onafterlayout();
}
}
其实很简单，在recyclerview执行onlayout()方法前后执行一下咱们打印缓存变化的方法
再看一眼打印缓存变化的方法，利用反射的技术
/**
* 利用java反射机制拿到recyclerview内的缓存并打印出来
* */private void showmessage(recyclerviewwrapper rv) {try {
field mrecycler =
class.forname("androidx.recyclerview.widget.recyclerview").getdeclaredfield("mrecycler");
mrecycler.setaccessible(true);
recyclerview.recycler recyclerinstance = (recyclerview.recycler) mrecycler.get(rv);
class> recyclerclass = class.forname(mrecycler.gettype().getname());
field mviewcachemax = recyclerclass.getdeclaredfield("mviewcachemax");
field mattachedscrap = recyclerclass.getdeclaredfield("mattachedscrap");
field mchangedscrap = recyclerclass.getdeclaredfield("mchangedscrap");
field mcachedviews = recyclerclass.getdeclaredfield("mcachedviews");
field mrecyclerpool = recyclerclass.getdeclaredfield("mrecyclerpool");
mviewcachemax.setaccessible(true);
mattachedscrap.setaccessible(true);
mchangedscrap.setaccessible(true);
mcachedviews.setaccessible(true);
mrecyclerpool.setaccessible(true);int mviewcachesize = (int) mviewcachemax.get(recyclerinstance);
arraylistwrapper mattached =
(arraylistwrapper) mattachedscrap.get(recyclerinstance);
arraylist mchanged =
(arraylist) mchangedscrap.get(recyclerinstance);
arraylist mcached =
(arraylist) mcachedviews.get(recyclerinstance);
recyclerview.recycledviewpool recycledviewpool =
(recyclerview.recycledviewpool) mrecyclerpool.get(recyclerinstance);
class> recyclerpoolclass = class.forname(mrecyclerpool.gettype().getname());
log.e(tag, "mattachedscrap(一缓) size is:" mattached.maxsize ", \n" "mcachedviews(二缓) max size is:" mviewcachesize ","
getmcachedviewsinfo(mcached) getrvpoolinfo(recyclerpoolclass, recycledviewpool));
} catch (exception e) {
e.printstacktrace();
}
}
核心的代码呢就这两块，文章的最后我会把我的demo上传到github上。注意：本文使用的recyclerview的版本是androidx，在调onattachedtowindow()方法的时候会进行版本判断，如果是5.0以及以上的系统(即大于等于21)，gapworker会把recyclerview自己加入到gapworker。在renderthread线程执行预取操作的时候会mprefetchmaxcountobserved = 1，这就会导致你使用5.0以及以上系统的手机打印缓存数量的时候会比你预想的多一个。这里为了不造成这种问题，本文使用4.4系统的android模拟器来演示demo。
demo演示效果截图
启动app，第一次加载的情况
初始化加载只有屏幕内的一级缓存7个
把position = 0 和position=1 两个item移除屏幕
看蓝色框出来的，position = 0 和position = 1的item被加入到了cache缓存中，cache的缓存数量我没有修改，默认2个，也就说现在已经满了
再把position = 2的item也移除屏幕
因为上一步cache里面的缓存已经慢了，此时position = 2又被加入缓存，根据fifo的原则，cache里面position = 0 被remove掉并加入到了四级缓存recycledview里面，此时recycledview也有了缓存并且该缓存没有任何有效数据信息。
再上一步的基础上下拉一下，把position = 2的item显示出来
此时position = 2的item将要被显示出来，会先从cache里面找，发现cache正好有position = 2的缓存就直接拿出来复用了，并且原来在屏幕里的position= 9 的item被移除了，就会加入到cache的缓存里。现在看一下oncreateviewholder()和onbindviewholder()的情况
还是启动app，第一次加载后，再把position = 0和position =1的item移除屏幕再移回来
onbindviewholder()方法没有被重复执行(静态图显示的效果不是很好，gif录制的质量太差了，还是建议下载demo自己尝试一下)
最后留一个问题给大家
为什么在第10次oncreateviewholder()执行以后就再也没有执行过oncreateviewholder()方法了？
总结
关于recyclerview的缓存分为四级，scrap、cache、viewcacheextension和recycledviewpool。scrap是屏幕内的缓存一般我们不怎么需要特别注意；cache可直接拿来复用的缓存，性能高效；viewcacheextension需要开发者自定义的缓存，api设计比较奇怪，慎用；recycledviewpool四级缓存，可以避免用户调用oncreateviewholder()方法，提高性能，在viewpager recyclerview的应用场景下可以大有作为。以上就是关于recyclerview缓存的所有内容，另外要备注一下，就是文章的图片上有些单词打错了，实在是懒得重画了，以文本的内容为准，请大家见谅。
最后是github的地址:
https://github.com/kaka10xiaobang/recyclerviewcachedemo
—————end—————
总结
以上是ag凯发k8国际为你收集整理的recyclerview item点击无效_让你彻底掌握recyclerview的缓存机制的全部内容，希望文章能够帮你解决所遇到的问题。
- 上一篇：
- 下一篇： js对文字批注_实现spreadjs的自