UITableViewCell - prepareForReuse 和 dequeueReusableCellWithIdentifier答案

【问题标题】：UITableViewCell - prepareForReuse and dequeueReusableCellWithIdentifierUITableViewCell - prepareForReuse 和 dequeueReusableCellWithIdentifier
【发布时间】：2012-09-12 15:08:27
【问题描述】：

检查GitHub project 以获取此article。自定义单元格（JKCallbacksTableViewCell 类）的prepareForReuse 方法向tableViewCellIsPreparingForReuse 方法观察到的表（RootViewController 类）发送通知。此方法重置关联键和单元格的 imageview。

那么，为什么作者在从表的 dequeueReusableCellWithIdentifier 方法获得非零单元格后，更喜欢通过通知发送而不是重置它们？

根据documentation of UITableViewCell，prepareForReuse 在 dequeueReusableCellWithIdentifier 之前被调用。

如果一个 UITableViewCell 对象是可重用的——也就是说，它有一个重用标识符——这个方法在对象从 UITableView 方法返回之前被调用 dequeueReusableCellWithIdentifier:。

我已经测试过，当 dequeueReusableCellWithIdentifier 返回一个非空值时，它与对 prepareForReuse 的调用相结合。

作者在 JKCallbacksTableViewCell.h 中评论了应用程序逻辑分离，但我认为这是一种矫枉过正；通过异步调度优化性能，但发送那些缓慢的通知来重置某些属性......或者我错过了关于 GCD 的一些东西？

【问题讨论】：

你有没有试过直接问他？他似乎在文章的评论部分很活跃......他可能比其他任何人都更清楚他为什么选择这种方法:) 甚至可以给他发送这个问题的链接，他可能会来回答，你不觉得吗？
好吧，我考虑过这一点，但 cmets 已关闭。反正我会想办法联系他的。
评论没有关闭，它们是经过审核的。一会儿我会在这里回答。

标签： objective-c ios uitableview grand-central-dispatch

【解决方案1】：

大多数编程问题都有近乎无限的解决方案。我没有任何特别的理由选择通知，除了它们是松散耦合的。

关于您对通知速度的评论：使应用变慢的原因是加载图像，因此我们正在尝试优化。通知的速度不足以影响应用程序的使用，因此出于纯粹的性能原因使用其他东西在这里是没有根据的。

也就是说，它在 GitHub 中，所以请随意发送不使用通知的拉取请求。如果我更喜欢它，我会使用它。

【讨论】：

感谢您的回答。无论如何，忘记性能考虑。我实际上想知道我是否会在从 deque..cell 方法返回的非空单元格之后调用 tableViewCellIsPreparingForReuse 来做错事（尤其是用 GCD 打破 smth）。
不，这不会破坏任何东西。