我有一个有趣的情况,我的适配器有2种视图类型-HEADER
和ITEM
。标题视图始终位于位置0。更新数据时,我使用DiffUtil
来获取数据的差异。要分发更新并重新绑定,我使用ListUpdateCallback
:
private void dispatchUpdates(
@NonNull final RecyclerView.Adapter adapter,
@NonNull DiffUtil.DiffResult result) {
result.dispatchUpdatesTo(new ListUpdateCallback() {
@Override
public void onInserted(int position, int count) {
adapter.notifyItemRangeInserted(position + getItemOffset(), count);
}
....
因此我可以将偏移量(即始终存在标头的1个原因)添加到
DiffUtil
计算的位置,以更新正确的元素。这很好。当我还需要更新标题时,就会发生问题。我手动计算标题diff并通知适配器。与
DiffUtil
一起,代码如下所示: DiffUtil.DiffResult diffResult = DiffUtil
.calculateDiff(new ItemDiffUtil(getItems(), newData));
Bundle headerDiff = getDiffPayload(newData);
dispatchUpdates(this, diffResult);
if (!isNullOrEmpty(headerDiff.keySet())) {
notifyItemChanged(0, headerDiff);
}
这是拒绝打得很好。通过将多个更新分派给适配器(例如,插入3个项目),它变得很混乱,并且我可以在网格中看到重复的项目(只是通过Picasso加载的缩略图)。如果我注释掉
notifyItemChanged(0, headerDiff);
,则标题显然不会更新,但是其他所有东西都可以正常工作。我的问题是是否有可能以更有意义的方式将这些更新排队,以便我仍然可以使用
DiffUtil
但我的标头也会被更新?编辑:有趣的是,如果我使用AirBnb的
Epoxy
而不是我自己的RecyclerView
适配器,则相同的问题仍然存在 最佳答案
我仍然不确定为什么会这样,但是我认为是罪魁祸首是Picasso
。我注意到日志中的一些内容:
问题出现时,Picasso
永远不会完成请求:
D/Picasso: Main created [R14655] Request{content://com.app.myapp.contentprovider/thumb/20170705173259427 resize(534,534) centerCrop}
D/Picasso: Dispatcher enqueued [R14655]+0ms
D/Picasso: Hunter executing [R14655]+0ms
D/Picasso: Hunter removed [R14655]+4ms from
D/Picasso: Dispatcher canceled [R14655]+4ms
当
Picasso
进入一个无限循环,为网格中的每个元素创建请求时,也发生了一些奇怪的事情:D/Picasso: Main created [R14424] Request{content://com.app.myapp.contentprovider/thumb/20170705173054794 resize(534,534) centerCrop}
D/Picasso: Main completed [R14424] from MEMORY
<...> // repeated for each ViewHolder forever in an endless loop
无论如何,据我所知,转向Glide已解决了该问题。
关于android - 当手动并通过DiffUtil通知更改时,RecyclerView会感到困惑,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/44905859/