From the official documentation:
The reuse identifier is associated with a UITableViewCell object that the table-view’s delegate creates with the intent to reuse it as the basis (for performance reasons) for multiple rows of a table view. It is assigned to the cell object in initWithFrame:reuseIdentifier: and cannot be changed thereafter. A UITableView object maintains a queue (or list) of the currently reusable cells, each with its own reuse identifier, and makes them available to the delegate in the dequeueReusableCellWithIdentifier: method.
I don't understand this. Well, I understand the basic idea, I think, that you create UITableViewCells, and try to reuse as many as you can instead of making new ones (or something like that). But what exactly decides whether or not a cell is reusable? If I've got two identical (visually) cells, but with different texts (well I suppose they aren't entirely identical), can they both have the same identifier? Or should they have different ones? Or in what situation are you supposed to use different identifiers?
Can anyone clarify or link to a place where it is?
Ok, this is how I believe it works:
Using dequeueReusableCellWithIdentifier for the tableView, you can greatly speed things up. Instead of instantiating a lot of cells, you just instantiate as many as needed, i.e. as many that are visible (this is handled automatically). If scrolling to an area in the list where there are "cells" that haven't got their visual representation yet, instead of instantiating new ones, you reuse already existing ones.
You can try this yourself by doing this:
static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil)
{
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
NSLog(@"new one");
}
else
{
NSLog(@"old one");
}
Remember, you only want dequeueReusableCellWithIdentifier to return a cell if it is applicable. So if a cell is going to be reused, make sure it is correct for the situation. That's what reuseIdentifiers are for. Usually, you will only need one. But there might be a list that uses several different kinds of cells, and in that case, you'd have to keep them separate by providing different reuseIdentifiers. Otherwise you might end up getting a cell that you treat as some other kind of cell (for example, UITableView cell instead of the custom one you wanted).
So basically, as I understand it, use different reuseIdentifiers for different kinds of cells, where kind means class. If you only use standard cells, you probably only need one reuseIdentifier.
This design pattern is known as object pooling.
Just to add some things to quano's otherwise very good answer: (I tried to add this as a comment, but it was too long!)
Even reuse identifiers can be omitted in developing, although this must be done in very specific circumstances. If you have a table view of 6-7 cells, and each one is different, you may find that creating a new cell with nil as the identifier may be preferable.
Having a reusable cell means that in each time the cellForRowAtIndexPath is called, you must check the cell, initialize it if there is no reusable cell, and outside of the init scope you must explicitly iterate through all possible indexpaths and set the values for each label explicitly depending on what kind of cell you have! So, in a table view with 10 dinstinct cells, you will have to take care of creating the cell if nil, and filling it up depending on what you created.
Therefore, in this case, it's preferable in terms of code maintenance to initialize each cell with nil identifier (since it's not going to be reused anyway) and fill each cell's info appropriately without worrying about reusing it.
UITableView is like having a cell pool for each reuseIdentifier, so that it recycle the cell
I like this video from http://oleb.net/blog/2014/05/scrollviews-inside-scrollviews/
来源：https://stackoverflow.com/questions/2152180/iphone-what-are-reuseidentifiers-uitableviewcell