dequeueReusableCellWithIdentifier不重复使用单元格
我有一个UICollectionView与自定义单元格的子类UICollectionViewCell 。 在代码中，我做了以下几件事：
[self.collectionView_ registerClass:[AHPinterestCell class] forCellWithReuseIdentifier:@"AHPinterestCell"];
这是在我的cellForItem
AHPinterestCell *cell = (AHPinterestCell *)[collectionView dequeueReusableCellWithReuseIdentifier:@"AHPinterestCell" forIndexPath:indexPath];
不过，它似乎并没有重用这个单元格。 在我的每个屏幕收集视图显示约9-10单元格，但是当我做无限滚动然后我调用insertItemsAtIndexPath它调用我的自定义单元格上的initWithFrame方法，而它应该可能重用我已经有的单元格。 为什么是这样？
编辑：
我添加了一个示例演示项目来说明问题，可以在这里find到xcode项目的链接。 当你到达底部的时候，它本质上是做一个无限的滚动，它只是附加更多的东西。 但是当你这样做，它会再次调用init方法。
总之，你的代码工作正常。 正如所料，随着单元格从屏幕上滚动，它们最终被标记为可重用。 而当你调用dequeueReusableCellWithReuseIdentifier ，如果有一个单元格可供重用，它会这样做。 如果没有，就创build一个。
你会看到很多单元格的创build时间，如果你快速滚动或不断。 但是，如果你做的是短小的卷轴，放手，暂停，让用户界面赶上并重复，那么你会看到很less的单元格被创build。
我认为这意味着iOS优先考虑用户界面和新单元的创build，而不是使旧单元出列，从而允许重用。 所以，如果你快速翻转，就会遇到麻烦，无法将旧的单元格重新使用。 这可能并不是很糟糕，因为这可能是收集意见如此stream畅的原因。 标记旧的单元格以供重用是iOS所要做的不太重要的事情之一。 但是，如果记忆力很紧，这可能是一个问题。
顺便说一句，如果你把NSLog放在dealloc ，你会注意到当UI在集合视图中快速滚动之后终于赶上时，显然有一些逻辑表示“gee，我有更多的备用电池比我真正需要的，我要去掉其中的一些。“ 实际上这是一个相当聪明的实现。 关注速度，但是一旦UI平静下来就会发生一些内存优化。
同意，我有同样的问题，但我想创build一个类别给我的可见单元格，如果可用的话。
// Header file UITableView+VisibleCell.h" @interface UITableView (VisibleCell) - (UITableViewCell*) visibleCellForRowAtIndexPath:(NSIndexPath *)indexPath; @end // Implementation file UITableView+VisibleCell.m #import "UITableView+VisibleCell.h" @implementation UITableView (VisibleCell) - (UITableViewCell*) visibleCellForRowAtIndexPath:(NSIndexPath *)indexPath { for( UITableViewCell* currentVisibleCell in self.visibleCells ) { NSIndexPath* currentPath = [self indexPathForCell: currentVisibleCell ]; if( [currentPath isEqual:(id) indexPath] ) { return currentVisibleCell; } } return nil; } @end
你也可以从获取可见单元格开始，然后返回cellForRowAtIndexPath而不是nil，这是一个样式问题。 （我需要这个来检索给定单元格中的给定标签的UITextField，使其成为FIRSTResponder，但cellForRowAtIndexPath不断重新分配我的单元格，非常令人沮丧。
closures设备设置的辅助function。 它是一个错误。 我在iPad mini上遇到了同样的问题。