滚动视图内回收器视图的滞后问题 [英] Lagging issue of Recycler View inside Scroll View

问题描述

ScrollView 和 RecyclerView 中的多个 RecyclerView 一直滞后，有时会冻结.需要指导吗?我错过了或者应该是这个设计的改进.

Multiple RecyclerView inside a ScrollView and RecyclerView has been lagging and sometimes freezing. Need guidance for it? What I missed or should be the improvement of this design.

 <Scrollview>
           <LinearLayout> 
                       <Recyclerview>  
                     
                       <Recyclerview>
        
           </LinearLayout>
    </Scrollview>

推荐答案

通常，当 RecyclerView 出现滚动性能问题时，是因为

Usually, when a RecyclerView has scrolling performance issues, it's because

a) 您在 onBindView 中做了太多工作，每次屏幕上出现新项目时都会调用它.b) 您正在显示使用大量内存(如大图像)的参考对象的视图，因此 Android 垃圾收集器 (GC) 必须做大量工作来释放内存.衡量 (a) 的一种快速而肮脏的方法类似于:

a) You're doing too much work in onBindView, which is called every time a new item comes on screen. b) The views you're displaying reference objects which use lots of memory (like large images), so the Android Garbage Collector (GC) has to do lots of work to free up memory. A quick and dirty way to measure (a) is something like:

void onBindView(RecyclerView.ViewHolder holder, int position) {
    long startTime = System.currentTimeMillis();

    //..bind view stuff

    Log.i(TAG, "bindView time: " + (System.currentTimeMillis() - startTime));
}

这将使您大致了解 bindView 需要多长时间.如果是 ~10ms 就可以了.如果超过 10 毫秒，那就不好了.如果超过 50 毫秒，那真的很糟糕.

This will give you a rough idea of how long bindView is taking. If it's ~10ms it's OK. If it's >10ms it's not good. If it's >50ms it's really bad.

对于 (b)，这实际上取决于您加载数据/图像的方式.如果你使用的是像 Picasso 或 Glide 这样的东西，很多这样的东西都是为你处理的.您可以将 onViewRecycled 侦听器附加到您的 RecyclerView，然后如果您使用 Glide/Picasso，请不要忘记调用 recycle() 方法(或任何调用的方法).

For (b), it really depends on how you're loading your data/images. If you're using something like Picasso or Glide, a lot of this stuff is handled for you. You can attach an onViewRecycled listener to your RecyclerView, and then if you are using Glide/Picasso, don't' forget to call the recycle() method (or whatever it's called).

如果您在此处手动加载图像，那么在回收视图时可能只需调用 ImageView.setImage(null).此外，请确保您仅以您需要的大小加载图片，并且如果您正在执行任何加载/降采样图片的处理，请确保它发生在后台.

If you're manually loading images here, then maybe just call ImageView.setImage(null) when the view is recycled. Also, make sure you're loading images at only the size you need, and if you are doing any processing to load/downsample images, make sure it's happening in the background.

如果您使用自定义字体，请确保使用某种缓存机制.加载字体可能很昂贵.

If you're using custom fonts, make sure you use some sort of caching mechanism. Loading fonts can be expensive.

无论如何，(a) 应该为您提供有关问题发生位置的线索.您可以在 onBindView() 中记录特定调用以缩小范围.

Anyway, (a) should give you clues as to where the issue is occurring. You can log specific calls inside onBindView() to narrow it down.

这篇关于滚动视图内回收器视图的滞后问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！