UITableView dequeueReusableCellWithIdentifier 理论 [英] UITableView dequeueReusableCellWithIdentifier Theory

问题描述

当苹果为第一部 iPhone 开发 UITableView 时，他们在滚动浏览时遇到了性能问题.后来一位聪明的工程师发现，造成这种情况的原因是对象的分配是有代价的，于是他想出了一种方法来重用单元格.

<块引用>

"对象分配有性能成本，特别是如果分配必须在短时间内重复发生——例如，当用户滚动表格视图.如果您重用单元格而不是分配新的，你大大提高了表视图的性能."

来源:iOS 参考库

要重复使用您使用的单元格:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

现在，我想知道的是，这里到底发生了什么?如果有一个具有该标识符的单元格，它是否会在 TableView 中查找并只返回该标识符?好吧，是的，但是如果它发送引用而不是分配，并且我有一个表视图，假设有 4 个具有相同标识符的单元格都可见.它如何在不分配的情况下将自身乘以四个实例?

我想知道这一点，因为我正在构建一个日历类型的组件，并且所有单元格都具有相同的结构，只有更改中的文本.因此，如果我能以某种方式重用我的单元而不是分配，我想我可能会获得更好的性能.

我自己的理论是它分配了四个单元格(仅仅是因为它也分配了).当一个单元格从屏幕上消失时，它将被放入 TableView 重用队列中.当需要一个新单元格时，它会在队列中查找具有相同标识符的单元格是否可用，它会在该单元格上调用 prepareForReuse 方法并将其从队列中移除.

解决方案

dequeueReusableCellWithIdentifier: 仅返回一个 cell 如果它已被标记为可以重用.这就是为什么在几乎每个 cellForRowAtIndexPath: 方法中你都会看到类似

<前><代码>UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];如果(零 == 单元格){cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault重用标识符:CellIdentifier];}//对单元格做一些事情返回单元格；

实际上，将分配足够的行来填充tableview 的可见部分(再加上一两个).当单元格滚动离开屏幕时，它们会从table中移除并标记为准备好reuse.随着可用单元格"队列的增长，您要求 出列单元格 的行将开始获取要使用的 cell ，此时您将不必再分配.

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.

解决方案

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.

这篇关于UITableView dequeueReusableCellWithIdentifier 理论的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！