我在xib中有自定义UICollectionViewCell。
当ViewController加载 - awakeFromNib()在单元子类中调用6次（屏幕最初放置6个单元格，确定），但是当我开始滚动时，awakeFromNib()被称为6时间更长，造成滞后。但在此之后＆＃34;重新加载＆＃34;滚动开始顺利进行。这仅在滚动开始时第一次发生。显然，dequeueReusableCell被使用。
使用UITableView而不是收集，情况类似。
感觉下一个6个单元格再次从xib加载（仅在100多个单元格的集合中），忽略重用。
那可能是什么问题？
为清楚起见：
UIColectionView具有垂直滚动方向，两个单元格在一条直线上。当ViewController加载时，我在屏幕上看到6个单元格，在控制台中看到6个awakeFromNib个调用。
我开始向下滚动到7-8个单元格，在它们出现在屏幕上之前我看到滞后和2个awakeFromNib方法的调用。
同样适用于以下两对细胞。
此滚动开始后工作正常，直到单元格99-100 +，并且永远不会调用awakeFromNib。
加了： 好的，这是我发现的：
我在collectionView中有一个subView（像UITableView中的标题），因此，collectionViewLayout设置sectionInsets top =标题的高度。如果我删除标题，并制作顶部插图，例如：-180（关于排除NavigationBar的高度，所以屏幕最初适合12个单元格，滚动滞后消失。
即，系统需要从xib加载所有将在屏幕上一次性可见的单元格，并在将来重复使用它们。 （但为什么不一次加载xib并立即重新用于所有其他最初的单元？）
现在问题是 - 如何解决它？
Added.2
工作解决方案 - 在ViewController的viewDidAppear方法中添加标题，但这......嗯..不好。
答案 0 :(得分：0)
这实际上是UICollectionView＆amp; amp;的一个已知的副作用（或有目的的设计？）。 UITableView的。这是一个相关的问题（谈论NSTableView，但概念/问题是相同的）：
awakeFromNib method called multiple times
您的收藏视图最初会显示六个单元格，但听起来iOS正在分配另外六个单元格以允许向左和向右滚动。对。因此，内存中至少有12个（可重复使用的）单元。
如果你在awakeFromNib做了很多工作（这是造成延迟的原因），你可能想要尝试确定如何优化事物。
您还可以在此相关问题中找到一些其他有用的提示：