我有一个带有自定义单元格子类UICollectionView的UICollectionViewCell。在代码中,我做了以下工作:
[self.collectionView_ registerClass:[AHPinterestCell class]
forCellWithReuseIdentifier:@"AHPinterestCell"];这就是我的cellForItem
AHPinterestCell *cell =
(AHPinterestCell *)[collectionView dequeueReusableCellWithReuseIdentifier:@"AHPinterestCell"
forIndexPath:indexPath];然而,它似乎没有重用细胞。在我的每个屏幕的集合视图中,它显示了大约9-10个单元格,但是当我无限滚动然后调用insertItemsAtIndexPath时,它会在我的自定义单元格上调用initWithFrame方法,而它可能会重用我已经拥有的单元格。为什么会这样呢?
编辑:
我正在添加一个示例演示项目来说明问题,可以找到到xcode项目的链接这里。它本质上是做一个无限滚动,当你到达底部,它只是附加更多的东西到它。但是当您这样做时,它将再次调用init方法。
发布于 2013-01-22 18:13:50
简而言之,您的代码运行良好。正如预期的那样,随着单元格在屏幕上滚动,它们最终会被标记为可重用。当您调用dequeueReusableCellWithReuseIdentifier时,如果有一个可以重用的单元,它就会这样做。如果不是,它会创建一个。
如果快速或持续滚动,您将看到大量的单元格正在创建的时间。但是,如果你做短的小卷轴,放手,暂停,让UI赶上并重复,那么你会看到很少的单元格正在创建。
我将此解释为iOS优先考虑UI和创建新单元而不是旧单元排队,从而允许它们重用。因此,如果您快速翻转,它将很难赶上并标记可重用的旧单元。这可能并不完全是坏事,因为这可能是使集合视图如此流畅的原因。标记旧单元以便重用是iOS在这里要做的不太重要的事情之一。但是很明显,如果记忆很紧,这可能是个问题。
顺便说一句,如果你也把一个NSLog放在dealloc里,你会发现当UI在集合视图中快速滚动之后终于赶上了,它显然有一些逻辑:“哎呀,我有比我真正需要的更多的备用单元格,我要去掉其中的一些。”实际上,这是一个非常聪明的实现。关注速度,但是在UI停止时会进行一些内存优化。
发布于 2013-04-17 14:44:47
同意,我也有同样的问题,但我想创建一个类别,如果可以的话,可以给我一个可见的单元格。
// 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而不是零,这是一个样式问题。(我需要这个来检索一个在给定单元格中带有给定标记的UITextField,使其成为becomeFIrstResponder,但是cellForRowAtIndexPath一直在重新分配我的单元格,非常令人沮丧。
发布于 2014-06-03 14:47:35
从设备设置中关闭可访问性。是个窃听器。我在我的iPad迷你版上也有同样的问题。
https://stackoverflow.com/questions/14453741
复制相似问题