我使用带有相对“重”的自定义表格 View 单元格的表格 View - 假设单个单元格中有大约 100 个 subview (完整的层次结构)。尽管如此，我已经能够实现非常平滑的滚动 - 使用标准实践，例如仅使用不透明 View 、隐藏未使用的 subview (甚至从 View 层次结构中删除)、预加载单元格高度等。
问题是创建单个单元实例的成本仍然相对较高。由于标准 UITableView 的单元格重用逻辑的工作原理，此问题仅在特定条件下才会明显。
通常，当加载 TableView (并显示初始内容)时，它会创建几乎所有必需的单元格实例 - 因此，当您开始滚动时，它很少需要创建更多可重用的单元格。但是，如果由于某种原因它只在开始时显示几个单元格，那么在启动滚动时显然需要创建更多单元格。就我而言，如果有较宽的 TableView 标题或第一个单元格足够大，则这一点会很明显。当您开始滚动时发生这种情况时，会出现一段明显的滞后，这显然是由创建的新单元格实例引起的。没有什么真正丑陋的，但仍然引人注目，特别是与之后绝对平滑的滚动相比。
现在，显而易见的解决方案是让单元格变得“更轻”——比如将它们分成不同的更具体的类型，这样每个类型都可以包含更少的 subview 。但由于我的内容组织方式，这将是一个非常复杂的解决方案。
所以我的问题是 - 有没有什么好方法来“欺骗” TableView 逻辑以立即强制加载和缓存特定数量的可重用单元格实例 - 尽管实际可见的单元格数量有多少？
我一直在考虑的选项之一是拥有自己的显式单元格缓存，并在需要时用单元格预先填充它(例如在 -viewDidLoad 中)。我使用这种方法的问题是你必须事先知道你需要的细胞的确切类型 - 对我来说效果不好。改进之处在于在加载初始数据时构建缓存(因此至少知道内容的确切类型)，但我一直想知道是否有任何简单的选项。
最佳答案
您可以通过将自己的“二级缓存”层添加到数据源来实现这一点。
初始化数据源时，根据需要预先创建尽可能多的单元格，并将它们放入数组中。当您的 dequeueReusableCellWithIdentifier 失败时，首先查找该数组，然后从那里取出一个单元格。一旦数组耗尽，就开始创建新的单元格(如果您预先创建了足够的单元格，则不需要动态创建新的单元格:当您有足够的单元格进出可见性时，出队最终将停止失败)。
关于ios - 强制 UITableView 缓存可重用单元格，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10918697/