When apple developed the UITableView
for the first iPhone they had a problem in performance when scrolling through it. Then one clever engineer discovered that the cause of this was that allocation of objects comes with a price, so he came up with a way to reuse cells.
"Object allocation has a performance cost, especially if the allocation has to happen repeatedly over a short period—say, when the
user scrolls a table view. If you reuse cells instead of allocating
new ones, you greatly enhance table-view performance."
Source: iOS Reference Library
To reuse a cell you use:
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
Now, what I am wondering is, what actually happens here? Does it look in the TableView if there is a cell with that identifier and just returns that one? Well yea duh, but if it sends a reference instead of allocating and I have a table view with let's say 4 cells with the same identifier all visible. How can it multiply itself into four instances without allocating?
I want to know this because I am building a calendar type component and all the cells have the same structure only the text within changes. So if I could somehow reuse my cells instead of allocating I think I might get a better performance.
My own theory is that it allocates the four cells (simply because it has too). When a cell disappears from the screen it will be put in the TableView reuse queue. When a new cell is needed it looks in the que if a cell with the same identifier is available, it invokes prepareForReuse
method on that cell and it removes itself from the queue.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…