Reputation: 18204
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.
Upvotes: 34
Views: 35158
Reputation: 2388
The purpose of dequeueReusableCellWithIdentifier
is to use less memory. if we use 100 cells in a tableView then need to create 100 cells every time.It reduce the app functionality and may cause crash.
For that dequeueReusableCellWithIdentifier
initialise the particular number of cells that we created and the cells will use again for further processing.
-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *TableIdentifier = @"YourCellIdentifier";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:TableIdentifier];
if (cell == nil) {
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:TableIdentifier];
}
ExternalClassTableViewCell *myCell = [[ExternalClassTableViewCell alloc]init];
myCell.MyCellText.text = [tableData objectAtIndex:indexPath.row];
myCell.MyCellImage.backgroundColor = [UIColor blueColor];
return cell;
}
Upvotes: 2
Reputation: 5403
dequeueReusableCellWithIdentifier:
only returns a cell
if it has been marked as ready for reuse. This is why in almost every cellForRowAtIndexPath:
method you will see something like
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (nil == cell) {
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault
reuseIdentifier:CellIdentifier];
}
// Do something to cell
return cell;
In effect, enough rows will be allocated to fill the visible part of the tableview
(plus one or two more). As cells scroll
off screen, they are removed from the table
and marked as ready for reuse
. As the queue of "available cells" grows, your line that asks for a dequeued cell
will start obtaining a cell
to use, at which point you will not have to allocate anymore.
Upvotes: 44
Reputation: 34945
The code for deqeueueReusableCellsWithIdentifier:
will look something like this:
(Taken from one of my own projects where I do something similar with views/pages in a paged scroll view)
- (UIView*) dequeueReusablePage
{
UIView* page = [reusablePages_ anyObject];
if (page != nil) {
[[page retain] autorelease];
[reusablePages_ removeObject: page];
}
return page;
}
So it keeps a simple NSMutableSet
with reusable objects.
When cells scroll off the screen and are not longer visible, they are put in this set.
So you start with an empty set and the set will only grow if you actually have more data to show then is visible on the screen.
Used cell scrolls off the top of the screen, is put in the set, then taken for the cell that appears at the bottom of the screen.
Upvotes: 13