The question is raised:
Sometimes we often need to customize the TableView cell, and when the layout in the cell is more complex, it tends to discard the pure code and use the Xib way to customize it. When we layout the cell in a pure code way, we tend to layout it in the cell's Initwithstyle:reuseidentifier: method, and then we write it in the Cellforrowatindexpath method of the external VC, Assuming that the custom cell is a cell, inherit from UITableViewCell:
Static NSString *cellidentifier@ "Cell"; dequeuereusablecellwithidentifier: cellidentifier]; if (!cell) { reuseidentifier:cellidentifier] autorelease]; } Cell.titleLabel.text = [Self.datalist objectAtIndex:indexPath.row]; return cell;
There is no problem with this writing, as textbooks are written in various tutorials, and the code above is reused for cells. But what if we want to use xib to lay it out now? See a lot of code is written like this:
StaticNSString *Cellidentifier = @"Cell ";Cell *cell = (Cell *) [TableViewDequeuereusablecellwithidentifier:Cellidentifier];if (!cell) {cell = [[nsbundle Mainbundle] Loadnibnamed:nsstringfromclass ([cell class] ) owner:self options:nil] span class= "symbol" >objectatindex:0]; //cell = [[cell alloc] Initwithstyle:uitableviewcellstyledefault reuseidentifier:cellidentifier] autorelease]; } cell.titleLabel.text = [self.datalist objectatindex:indexpath.row];< span class= "keyword" >return cell;
The only difference is the location of the red: the cell initialization is no longer through the Initwithstyle function, because we are now using the Xib layout, all the control information is inside the xib, so we load xib according to the xib name of the cell to create the cell. But did you notice that the red part of the second method does not contain any reuse information, that is, each time you drag TableView, a different cell is created, and the memory problem is revealed when there is a lot of cells to display.
To solve this problem, let's switch to another better way.
Directly put the optimized code, the Uinib class can not look at first, does not affect the understanding of the code:
@ "Cell"; BOOL nibsregistered = NO; if (!nibsregistered) { class]) Bundle:nil]; [TableView registernib:nib forcellreuseidentifier:cellidentifier]; nibsregistered = YES; } Cell *cell = (cell *) [TableView dequeuereusablecellwithidentifier:cellidentifier]; Cell.titleLabel.text = [Self.datalist objectAtIndex:indexPath.row]; return cell;
We can see that the red part is a good fit for our needs: both the nib loading and the cell reuse. The code is explained below:
1.UINib is a IOS4.0 class, similar to the Nsnib class on Mac, which accelerates the loading of frequently used nib files. When the nib is loaded for the first time from the hard disk, it caches the nib file object in memory. The nib file is then loaded from a memory copy to avoid slower hard drive access. Apple claims to provide a twice-fold speed boost when the nib file is loaded. The most obvious place to use uinib is in the uitableviewcontrollers where the cell is loaded from the nib file each time a new cell is created. The advantage of uinib is that performance improvements are achieved without a lot of code changes. In fact, simply put, the use of caching mechanism to avoid the frequent loading of xib files from the hard disk, which is particularly useful when the volume of large data.
2. In addition to the above code, you will need to do the following in the Xib file: Set the identifier in the Cell.xib inspector window, where identifier is consistent with Cellforrowatindexpath.
These are the considerations and solutions for loading custom UITableViewCell from Xib, and many people use the second approach, which seems to be fine, but when memory is tight, the problem is revealed!
The previous code is the 2nd kind of writing, did not carefully consider this problem, today, a whim, think of this problem, Baidu, only to find that there are problems.
Considerations for customizing UITableViewCell with Xib--reuse problems