android - RecyclerView 挂起主线程有很多元素

Question

我有一个 RecyclerView 和一个基于项目的 List 的适配器。当我在适配器中有大约 400 个元素时，当我通知适配器我已设置新数据时，我看到主线程挂起大约 1-2 秒。

我已经对它进行了方法跟踪，它正忙于 View 层次结构的深处(从 ViewRootImpl.performTraversal() 开始)。这没有意义，因为我预计它只会渲染实际可见的 10 个元素，应该快如闪电。

我是否遗漏了 RecyclerView 的某些方面？

编辑

它为列表中的每个元素调用 onBindViewHolder()。这似乎不正确。

编辑

如果我给 RecyclerView 一个静态高度，它就解决了问题。本身不是解决方案，但希望指明方向。

Answer 1

我看到了一些问题，我会不分先后地指出它们；虽然我还没有看到任何可能导致您的问题的具体情况，但在我写这个答案时，我可能会发现一些东西，所以让我们分析您的代码。

缺少什么？

您没有包含更多代码，所以我不知道您如何使用此适配器，或者您的 recyclerview 布局如何(它包含在另一个 ScrollView 或嵌套 ScrollView 中吗？)这些都是重要的问题，因为它可能会影响 Android 渲染/布局引擎的工作方式。

布局

您正在使用带权重的 LinearLayout(这里有点不需要)。除非你有非常正当的理由，否则不推荐这些；计算小部件的大小和不计算小部件的大小是昂贵的，当涉及图像和位图时更是如此。

我建议您切换到 ConstraintLayout 并做正确的事。您会感谢自己，您的布局可能会表现得更好(据我所知，对于 ConstraintLayout，您当前的布局中没有什么是不可能的)。

适配器

• 这很奇怪:

    @Override
    public void onClick(View v) {
      Listener l;
      if ((l = listener) != null) {
        mainHandler.post(() -> l.onItemClick(devices.get(getAdapterPosition())));
      }
    }

点击应该总是发生在主线程上，您不需要发布任何内容。我会这样写:

if (listener instanceof Listener) { //already fails if L is null anyway) 
     listener.onItemClick(...)
}

• 在您的onBind 中执行大量查找，如果您缓存这些，则可以节省周期。例如:

Picasso.with(context).load(SetupAppUtils.getDeviceImageUrl(context, device)).into(image);

我不知道你的 SsetupAppUtils.getDeviceImageUrl 方法做了什么，但它可能很昂贵，如果需要你可以将它保存在本地 map 中(查找 URL 一次，重复使用)(只是一个想法，不看代码就无法分辨)

• 您的 onBind 方法中似乎嵌入了很多业务逻辑(很多 if 语句，通常是一个危险信号。您的适配器根本不关心这个，它只是“适应”模型中的数据 -> View ，如果可以避免，不应该做出决定和执行转换。在这种情况下，我看到你传递了一个 Device... 似乎没问题，但你似乎要进行大量检查和转换，请记住，一旦绑定(bind)所有项目，就会发生这种情况......，每次用户滚动并且需要绑定(bind)新项目时，你都会再次执行所有这些工作，当您只想“重新绑定(bind)”viewholder 时。

• 您正在通知一个完整的更改，这意味着对于 recyclerview 来说有很多(所有都必须重新测量并重新布局)，因为您实际上是在告诉适配器:所有数据都已更改。

  void setDevices(List<Device> devices) {
    this.devices.clear();
    this.devices.addAll(devices);
    notifyDataSetChanged();
  }

使用 DiffUtil 非常简单(包含在框架中!)并且完全推荐。

• 您覆盖了一个方法，但所有项目都具有相同的 id:

  @Override
  public long getItemId(int i) {
    return 0;
  }

如果您不能提供合适的 ID，则不要覆盖它。我会返回 item[i].something() (之前检查 null/空列表!)。同时将 i 重命名为 position 因为它就是这样。

还有什么吗？

除此之外，我看不出有什么特别奇怪的。我会做一个简单的测试:删除你在那里的所有绑定(bind)代码(onBind 中的所有代码)并只放入 name.SetText(...) 看看你是否仍然看到“滞后” ”。如果您不这样做，那么您就会知道其中一些操作比其他操作花费的时间更长。

尝试使用较少的项目，看看会发生什么； recyclerview 应该只绑定(bind)可见的 View +/- 几个向上/向下，而不是一次 400 个项目。我能想到的唯一原因是，如果您的 RecyclerView 在 NestedScrollView 或类似的内部。