Go The reuse mechanism of UITableViewCell

Transferred from: http://www.2cto.com/kf/201207/144337.html

Today, when I look at the iphone development cheats, encountered this problem, carefully in-depth, through the test, to obtain some self-thought is also good conclusions, I hope that you have encountered in cell reuse some of the problems will be helpful.

This article only describes the principle, for if the cell interface, not in-depth talk. Given my limited ability to express myself, there may be a place where I am clear, but I am not clear, if you have any questions, leave me a message.

UITableView in the interface programming very much, the iphone development is more than March, each time to use the Cellforrowatindexpath of the commissioning method, are directly copy code, their own slightly some changes in the interface, The identifier for the cell is static nsstring* identifier = @ "Cell", then the Dequeuereusablecellwithidentifier method is called to get the cell, if the cell is empty, then [[[ The Uitableviewcellalloc]initwithstyle method creates a new one, without even thinking about something deeper. In order to explain clearly, now put on a piece of code, code copy from the iphone development cheats, I have to explain, slightly modified. All of the explanations below are based on this code, so if you want a thorough understanding of the cell's reuse mechanism, it is recommended to actually run the following, and then explain the effect. The code has only TableView delegate methods, so you need to create your own project and add these delegate methods.

There are four delegate methods above, indicating that TableView a section with 32 rows, The height is 58. About the height of the TableView the return height value of the delegate method, it is recommended that you run the program yourself to see the following, eventually reaching a page of the interface to display 8 cells, the 8th cell displays half of the rows, but not 9 and 7 cells can be displayed. I am 58 here because (480-44)/58 is 7.5, 44 is Navigationbar, and 480 is the height of the screen. In summary, the desired effect is to display 7 + cells on a page. And that Icon.png needs to be prepared, to show it. Isn't that a lot of trouble? No way, who let us in the acquisition of knowledge, knowledge always need a bit of effort.

[CPP]
-(Nsinteger) Numberofsectionsintableview: (UITableView *) Atableview
{
return 1;
}

-(Nsinteger) TableView: (UITableView *) Atableview numberofrowsinsection: (nsinteger) Section
{
return 32;
}
-(CGFloat) TableView: (UITableView *) TableView Heightforrowatindexpath: (Nsindexpath *) Indexpath
{
return 58;
}
-(UITableViewCell *) TableView: (UITableView *) TView Cellforrowatindexpath: (Nsindexpath *) Indexpath
{
Uitableviewcellstyle style;
NSString *celltype;

Switch (indexpath.row% 4)
{
Case 0:
style = Uitableviewcellstyledefault;
Celltype = @ "Default Style";
There is no text in the title (No details). Optional picture
Break
Case 1:
style = Uitableviewcellstylesubtitle;
Celltype = @ "Subtitle Style";
Headings and body styles, arranged up and down. Optional picture
Break
Case 2:
style = UITableViewCellStyleValue1;
Celltype = @ "Value1 Style";
The left text is left aligned and the right text is right-aligned. Optional picture
Break
Case 3:
style = UITableViewCellStyleValue2;
Celltype = @ "Value2 Style";
Left text right aligned, blue, right text left aligned, black. No pictures
Break

}
static int i = 0;
UITableViewCell *cell = [TView dequeuereusablecellwithidentifier:celltype];
if (!cell)
{
cell = [[[UITableViewCell alloc] Initwithstyle:style Reuseidentifier:celltype] autorelease];
++i;
NSLog (@ "cell created%d times", I);
}

if (Indexpath.row > 3)
Cell.imageView.image = [UIImage imagenamed:@ "Icon.png"];

Cell.textLabel.text = Celltype;
Cell.detailTextLabel.text = @ "Subtitle text";
return cell;
}

Let's start by explaining the multiplexing queue:

The elements of the multiplexing queue increase: This cell is added to the multiplexing queue only when the cell is slid out of the interface. Each time the cell is created, the program first calls the Dequeuereusablecellwithidentifier:celltype method to the multiplexing queue to find the cell with the identifier "Celltype", and if it cannot find it, returns NIL, Then the program goes to create the identifier "Autorelease" by calling [[[[[] [[[[] UITableViewCell alloc] Initwithstyle:style Reuseidentifier:celltype] Celltype] The cell.

Run the program first, do not slide the cell, view the print log, there will be printed "cell create 1 times",,, "cell create 8 times", a total of 8 logs, indicating that the cell was created 8 time, This log print is printed when the cell is created in Cellforrowatindexpath. Then slowly downward (meaning, in fact, the hand is sliding upward, so that the interface shows the next cell, upward and opposite) slide the cell, to display the Nineth cell, you will see a log "cell create 9 times", and then continue to slide slowly, there will be "cell Create times "until after the cell has been created 12 after it has been slid to the 12th cell, the cell will not be created. In other words, the TableView to complete the work, altogether created 12 cells.

Start explaining the reason:

The first page of the interface needs to show 8 cells, so the cell needs to be created 8 times, each cell responsible for their own data display. After this 8 is created, the multiplexing queue remains empty (since you have not yet slid the cell, the elements of the multiplexing queue will not increase). Then the Cellforrowatindexpath method is called when the 9th cell is shown down, and in this method it is first found in the reusable queue, because the queue is empty, it creates a cell, prints the log, and when the 1th cell slips out of the interface , the first cell enters the multiplexing queue, and there is an element in the queue that has the @ "Default Style" as its identifier. Then continue to slide the cell, start to display the 10th cell, it is also in the multiplex queue to find, the 10th cell identifier is @ "Subtitle style", but the queue is the only cell identifier @ "Default style", based on the identifier search, Not found, so create a new cell again, and slide the 2nd cell out of the interface into the multiplexing queue. At this time the multiplexing queue has two elements, the identifier is @ "Default style" @ "Subtitle style". Similarly, when sliding to the 11th cell, the 3rd cell is enqueued, and the 12th cell is in the queue with the 4th cell. The number of elements in the multiplexed queue is four, with the following identifiers: @ "Default style" @ "Subtitle style" @ "Value1 style" @ "Value2 style". Then continue to slide the cell, When sliding to the 13th cell, its identifier is @ "Default Style", which is found in the multiplexing queue. Therefore, this cell will not be created, in the same way, once again, the following cells can find the corresponding cell according to the identifier, will not be created. As you swipe down, the cell that slides out is queued, but only the cell that was created is queued, which means there will be 12 cells in the final queue. For each element that takes the corresponding identifier, which one is taken? What strategy is used? I don't know, I'm looking through the print. In the process of sliding down, always follow the queue, the queue is a circular queue. When you swipe up, you look up against the queue, and because it's a circular queue, you keep spinning.

If you look closely, you will find that the first cell has no picture, why a row to slide down again (if the distance is far away, a fix, if the sliding distance close, more and more swipe up and down several times) come up with pictures? This is a thought: the first cell is taken from the multiplexing queue when it is in the slide-out interface and into the interface. The multiplexing queue has 12 elements, and the first cell of the 1,5,9 has the same identifier, the 1th has no picture, and the 5th and 9th have a picture. When the user re-use the first cell, it is no picture, when the user re-use the 5th, 9 cells, it is a picture. So, when you swipe up and down to see the first cell, you'll see that it has a picture, and no pictures. This is related to the queue lookup rule at multiplexing time.

Practical article:

It's all about the principle of saying so much. Now, say something practical. If you want to add a button to all cells, should you add it in the if, or should you add it outside of the IF? There is no doubt that if you are adding outside of if you are in the IF, it will cause you to move down the cell, and the cells that you have taken are already with the button, and you are still addsubview, with more and more buttons. Or you can add it outside of if the cell is removed from all its child views at the first time. This is too CPU-intensive, trouble. What do you do if you want a row with buttons and no buttons across the line? Think about it a bit, this is a two-style cell, so when you slide out of the interface to reuse it, they should belong to different identifiers. So when you create the cell, you should specify two identifiers and create two cells. Of course, maybe you're smart, if I can remove all of the cell's sub-views first, and then according to row% 2 = = 0 or! = is the Addsubview:button? The answer, of course, is yes, but this is the same problem, which consumes CPU too much. Normally we add a button to each cell, and we'll definitely add the event. Respond to different events for different buttons? So do I do this by setting its tag tag (for example, Button.tag = Indexpath.row) in the IF statement to the button? Haha, you should be smart enough, of course not. You can think of this, if statement is used to create, it is only executed (such as the above example: 12 times), but you may have hundreds of rows of cell, of course, your tag is only 12, obviously does not correspond. Like this, how should we deal with it? The answer is: put it outside the IF. You set the tag tag outside the IF, of course, at a specific point in time, there are still only 12 marks, but the 12 tags are variable, such as the current interface display 第100-111号 cell, then the button will be the tag of 100-111, is still 12 buttons, but they will be based on the user's swipe, a different tag switch, the equivalent of having a lot of buttons. If you are not dizzy by what I say, and your head is clear enough, you should be able to draw the following conclusion: for the customization of the interface, it is better to place it in the IF, only once in a cell, and for data customization, it is better to be outside if, for different cells, to represent different content. Although there are only 12 cells, I can map any data stored in the cell. If you come to this conclusion, if you add Textfield,label and so on, you should be able to handle it easily. Not onlyOnly on the surface, more importantly, you understand the principle, mastered the mechanism, million change are not afraid, even if there is a new demand, the brain think, or take this article to see, hope to give you some enlightenment.

[Reuse mechanism of]uitableviewcell