dequeueReusableCellWithIdentifier 不重用单元格 [英] dequeueReusableCellWithIdentifier not reusing cells

查看:25
本文介绍了dequeueReusableCellWithIdentifier 不重用单元格的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 UICollectionView,其中包含自定义单元格子类 UICollectionViewCell.在代码中我做了以下事情:

I have a UICollectionView with a custom cell subclassing UICollectionViewCell. And in the code I have done the following:

 [self.collectionView_ registerClass:[AHPinterestCell class]
        forCellWithReuseIdentifier:@"AHPinterestCell"];

这就是我的 cellForItem

  AHPinterestCell *cell =
                (AHPinterestCell *)[collectionView dequeueReusableCellWithReuseIdentifier:@"AHPinterestCell"
                                                                             forIndexPath:indexPath];

但是,它似乎没有重复使用单元格.在每个屏幕的集合视图中,它显示大约 9-10 个单元格,但是当我进行无限滚动然后调用 insertItemsAtIndexPath 时,它会在我的自定义单元格上调用 initWithFrame 方法,虽然它可能应该重用我已经拥有的单元格.这是为什么呢?

however, it seems that it's not reusing the cell. In my collection view per screen it is showing about 9-10 cells, however when I do infinite scroll and then I call insertItemsAtIndexPath it calls the initWithFrame method on my custom cell, while it should probably reuse the cells I already have. Why is this?

我正在添加一个示例演示项目来说明问题,可以找到指向 xcode 项目的链接 这里.当您到达底部时,它实际上是在进行无限滚动,它只是在其中添加了更多内容.但是当你这样做时,它会再次调用 init 方法.

I am adding a sample demo project that illustrates the problem, the link to the xcode project can be found here. It's essentially doing an infinite scroll when you reach to the bottom, it just appends more stuff into it. But when you do so it's going to call the init method again.

推荐答案

简而言之,您的代码运行良好.正如预期的那样,当单元格从屏幕上滚出时,它们最终会被标记为可重复使用.而当你调用 dequeueReusableCellWithReuseIdentifier 时,如果有一个单元格可供重用,它就会这样做.如果没有,它会创建一个.

In short, your code works fine. As expected, as cells scroll off the screen, they are eventually flagged as being available for reuse. And when you call dequeueReusableCellWithReuseIdentifier, if there is a cell available for reuse, it will do so. If not, it creates one.

如果您快速或连续滚动,您会看到创建大量单元格的时间.但是如果你做短小的滚动,放开,暂停,让 UI 跟上并重复,那么你会看到创建的单元格非常少.

The time that you'll see a lot of cells being created is if you scroll fast or continually. But if you do short little scrolls, let go, pause, let the UI catch up and repeat, then you'll see very few cells being created.

我将此解释为 iOS 优先考虑 UI 和新单元格的创建,而不是旧单元格的出列,从而允许它们重用.因此,如果您快速翻转,它很难赶上旧单元并将其标记为可重复使用.这可能并不完全是坏事,因为这可能是集合视图如此流畅的原因.标记旧单元以供重用是 iOS 在这里要做的不太重要的事情之一.但显然,如果内存紧张,这可能是个问题.

I interpret this as meaning that iOS prioritizes the UI and the creation of new cells over the dequeuing of old cells, allowing their reuse. So if you flip quickly, it has trouble catching up and flagging old cells as available for reuse. This is probably not altogether bad, as this is probably what gives collection views such smooth flow. Flagging old cells for reuse is one of the less important things for iOS to do here. But clearly if memory is tight, this might be a problem.

顺便说一句,如果你在 dealloc 中也放一个 NSLog,你会注意到当 UI 在快速滚动浏览集合视图,它显然有一些逻辑说天哪,我有比我真正需要的更多的备用单元,我要摆脱其中的一些."实际上,这是一个非常聪明的实现.专注于速度,但会在 UI 安静下来后进行一些内存优化.

By the way, if you put a NSLog in dealloc, too, you'll notice that when the UI finally catches up after doing a really fast scroll through the collection view, it clearly has some logic that says "gee, I've got more spare cells than I really need, I'm going to get rid of some of these." It's a pretty clever implementation, actually. A focus on speed, but with some memory optimizations that take place once the UI quiets down.

这篇关于dequeueReusableCellWithIdentifier 不重用单元格的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆