First of all, you are not calling [super prepareForReuse]
like you should.
And the documentation is pretty clear, you should be setting the image in tableView:cellForRowAtIndexPath:
because it's content.
If you set the image in tableView:cellForRowAtIndexPath:
there is no point to set it to nil in prepareForReuse
.
Imagine the following flow.
- You scroll down, cell 0 is put onto the queue.
prepareForReuse
sets imageView.image to nil
tableView:cellForRowAtIndexPath:
dequeues the cell and sets imageView.image to image1
You are setting imageView.image twice.
If you use nil there might be no measurable performance impact at all. But you might come to the idea to actually set a placeHolder image. So the cell is queued and prepared for reuse, you set the placeholder image; later the cell is dequeued and the placeholder image is replaced by a real image before the placeholder image was even visible.
I would remove the prepareForReuse
method completely. You don't need it if you set the image in tableView:cellForRowAtIndexPath:
from the documentation:
If a UITableViewCell object is reusable—that is, it has a reuse identifier—this method is invoked just before the object is returned from the UITableView method dequeueReusableCellWithIdentifier:. For performance reasons, you should only reset attributes of the cell that are not related to content, for example, alpha, editing, and selection state. The table view's delegate in tableView:cellForRowAtIndexPath: should always reset all content when reusing a cell. If the cell object does not have an associated reuse identifier, this method is not called. If you override this method, you must be sure to invoke the superclass implementation.