本文轉載自longxdragon
一、UITableView的簡單認識
UITableView最核心的思想就是UITableViewCell的重用機制。
簡單的理解就是：UITableView只會創建一屏幕（或一屏幕多一點）的UITableViewCell，其他都是重用這些的（除非你沒有使用reuse機制）。每當Cell滑出屏幕時，就會放入到一個集合（或數組）中（這裏就相當於一個重用池），當要顯示某一位置的Cell時，會先去集合（或數組）中取，如果有，就直接拿來顯示；如果沒有，纔會創建。這樣做的好處可想而知，極大的減少了內存的開銷。
知道UITableViewCell的重用原理後，我們來看看UITableView的回調方法。UITableView最主要的兩個回調方法是tableView:cellForRowAtIndexPath:和tableView:heightForRowAtIndexPath:。那麼問題來了，UITableView會先調用前者，還是先調用後者？按照我們創建控件的思路，先調用前者創建它，再調用後者設置它的佈局。但實際上卻並非如此，我們都知道，UITableView是繼承自UIScrollView的，需要先確定它的contentSize及每個Cell的位置，然後纔會把重用的Cell放置到對應的位置。所以事實上，UITableView的回調順序是先多次調用tableView:heightForRowAtIndexPath:以確定contentSize及Cell的位置，然後纔會調用tableView:cellForRowAtIndexPath:，從而來顯示在當前屏幕的Cell。
舉個例子來說：如果現在要顯示100個Cell，當前屏幕顯示5個。那麼刷新（reload）UITableView時，UITableView會先調用100次tableView:heightForRowAtIndexPath:方法，然後調用5次tableView:cellForRowAtIndexPath:方法；滾動屏幕時，每當Cell滾入屏幕，都會調用一次tableView:heightForRowAtIndexPath:、tableView:cellForRowAtIndexPath:方法。
看到這裏，想必大夥也都能隱約察覺到，UITableView優化的首要任務是要優化上面兩個回調方法。事實也確實如此，下面按照我探討進階的過程，來研究如何優化：
優化探索，項目拿到手時代碼是這樣：
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
ContacterTableCell *cell = [tableView dequeueReusableCellWithIdentifier:@"ContacterTableCell"];
if (!cell) {
cell = (ContacterTableCell *)[[[NSBundle mainBundle] loadNibNamed:@"ContacterTableCell" owner:self options:nil] lastObject];
}
NSDictionary *dict = self.dataList[indexPath.row];
[cell setContentInfo:dict];
return cell;
}
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath];
return cell.frame.size.height;
}
看到這段代碼，看起來沒什麼不對，覺得還是蠻巧妙的，但巧歸巧，當Cell非常複雜的時候，直接卡出翔了。。。特別是在我的Touch4上，有設備的可以試試？！好吧，依據上面UITableView原理的分析，我們先來分析它爲什麼卡？
這樣寫，在Cell賦值內容的時候，會根據內容設置佈局，當然也就可以知道Cell的高度，想想如果1000行，那就會調用1000+頁面Cell個數次tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath方法，而我們對Cell的處理操作，都是在這個方法裏的！什麼賦值、佈局等等。開銷自然很大，這種方案Pass。。。改進代碼。
改進代碼後：
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
NSDictionary *dict = self.dataList[indexPath.row];
return [ContacterTableCell cellHeightOfInfo:dict];
}思路是把賦值和計算佈局分離。這樣讓tableView:cellForRowAtIndexPath:方法只負責賦值，tableView:heightForRowAtIndexPath:方法只負責計算高度。注意：兩個方法儘可能的各司其職，不要重疊代碼！兩者都需要儘可能的簡單易算。Run一下，會發現UITableView滾動流暢了很多。。。
基於上面的實現思路，我們可以在獲得數據後，直接先根據數據源計算出對應的佈局，並緩存到數據源中，這樣在tableView:heightForRowAtIndexPath:方法中就直接返回高度，而不需要每次都計算了。
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
NSDictionary *dict = self.dataList[indexPath.row];
CGRect rect = [dict[@"frame"] CGRectValue];
return rect.frame.height;
}其實上面的改進方法並不是最佳方案，但基本能滿足簡單的界面！記得開頭我的任務嗎？像朋友圈那樣的圖文混排，這種方案還是扛不住的！我們需要進入更深層次的探究：自定義Cell的繪製。
我們在Cell上添加系統控件的時候，實質上系統都需要調用底層的接口進行繪製，當我們大量添加控件時，對資源的開銷也會很大，所以我們可以索性直接繪製，提高效率。是不是說的很抽象？廢話不多說，直接上代碼：
首先需要給自定義的Cell添加draw方法，（當然也可以重寫drawRect）然後在方法體中實現：
//異步繪製
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
CGRect rect = [_data[@"frame"] CGRectValue];
UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0);
CGContextRef context = UIGraphicsGetCurrentContext();
//整個內容的背景
[[UIColor colorWithRed:250/255.0 green:250/255.0 blue:250/255.0 alpha:1] set];
CGContextFillRect(context, rect);
//轉發內容的背景
if ([_data valueForKey:@"subData"]) {
[[UIColor colorWithRed:243/255.0 green:243/255.0 blue:243/255.0 alpha:1] set];
CGRect subFrame = [_data[@"subData"][@"frame"] CGRectValue];
CGContextFillRect(context, subFrame);
[[UIColor colorWithRed:200/255.0 green:200/255.0 blue:200/255.0 alpha:1] set];
CGContextFillRect(context, CGRectMake(0, subFrame.origin.y, rect.size.width, .5));
}
{
//名字
float leftX = SIZE_GAP_LEFT+SIZE_AVATAR+SIZE_GAP_BIG;
float x = leftX;
float y = (SIZE_AVATAR-(SIZE_FONT_NAME+SIZE_FONT_SUBTITLE+6))/2-2+SIZE_GAP_TOP+SIZE_GAP_SMALL-5;
[_data[@"name"] drawInContext:context withPosition:CGPointMake(x, y) andFont:FontWithSize(SIZE_FONT_NAME)
andTextColor:[UIColor colorWithRed:106/255.0 green:140/255.0 blue:181/255.0 alpha:1]
andHeight:rect.size.height];
//時間+設備
y += SIZE_FONT_NAME+5;
float fromX = leftX;
float size = [UIScreen screenWidth]-leftX;
NSString *from = [NSString stringWithFormat:@"%@ %@", _data[@"time"], _data[@"from"]];
[from drawInContext:context withPosition:CGPointMake(fromX, y) andFont:FontWithSize(SIZE_FONT_SUBTITLE)
andTextColor:[UIColor colorWithRed:178/255.0 green:178/255.0 blue:178/255.0 alpha:1]
andHeight:rect.size.height andWidth:size];
}
//將繪製的內容以圖片的形式返回，並調主線程顯示
UIImage *temp = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
dispatch_async(dispatch_get_main_queue(), ^{
if (flag==drawColorFlag) {
postBGView.frame = rect;
postBGView.image = nil;
postBGView.image = temp;
}
}
//內容如果是圖文混排，就添加View，用CoreText繪製
[self drawText];
}}上述代碼只貼出來部分功能，但大體的思路都是一樣的，各個信息都是根據之前算好的佈局進行繪製的。這裏是需要異步繪製，但如果在重寫drawRect方法就不需要用GCD異步線程了，因爲drawRect本來就是異步繪製的。對於圖文混排的繪製，可以移步Google，研究下CoreText，這塊內容太多了，不便展開。
好了，至此，我們又讓UITableView的效率提高了一個等級！但我們的步伐還遠遠不止這些，下面我們還可以從UIScrollView的角度出發，再次找到突破口。
滑動UITableView時，按需加載對應的內容
直接上代碼：
//按需加載 - 如果目標行與當前行相差超過指定行數，只在目標滾動範圍的前後指定3行加載。
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset{
NSIndexPath *ip = [self indexPathForRowAtPoint:CGPointMake(0, targetContentOffset->y)];
NSIndexPath *cip = [[self indexPathsForVisibleRows] firstObject];
NSInteger skipCount = 8;
if (labs(cip.row-ip.row)>skipCount) {
NSArray *temp = [self indexPathsForRowsInRect:CGRectMake(0, targetContentOffset->y, self.width, self.height)];
NSMutableArray *arr = [NSMutableArray arrayWithArray:temp];
if (velocity.y<0) {
NSIndexPath *indexPath = [temp lastObject];
if (indexPath.row+3<datas.count) {
[arr addObject:[NSIndexPath indexPathForRow:indexPath.row+1 inSection:0]];
[arr addObject:[NSIndexPath indexPathForRow:indexPath.row+2 inSection:0]];
[arr addObject:[NSIndexPath indexPathForRow:indexPath.row+3 inSection:0]];
}
} else {
NSIndexPath *indexPath = [temp firstObject];
if (indexPath.row>3) {
[arr addObject:[NSIndexPath indexPathForRow:indexPath.row-3 inSection:0]];
[arr addObject:[NSIndexPath indexPathForRow:indexPath.row-2 inSection:0]];
[arr addObject:[NSIndexPath indexPathForRow:indexPath.row-1 inSection:0]];
}
}
[needLoadArr addObjectsFromArray:arr];
}
}
記得在tableView:cellForRowAtIndexPath:方法中加入判斷：
if (needLoadArr.count>0&&[needLoadArr indexOfObject:indexPath]==NSNotFound) {
[cell clear];
return;
}滾動很快時，只加載目標範圍內的Cell，這樣按需加載，極大的提高流暢度。
寫了這麼多，也差不多該來個總結了！UITableView的優化主要從三個方面入手：
- 提前計算並緩存好高度（佈局），因爲heightForRowAtIndexPath:是調用最頻繁的方法；
- 異步繪製，遇到複雜界面，遇到性能瓶頸時，可能就是突破口；
- 滑動時按需加載，這個在大量圖片展示，網絡加載的時候很管用！（SDWebImage已經實現異步加載，配合這條性能槓槓的）。
除了上面最主要的三個方面外，還有很多幾乎大夥都很熟知的優化點：
- 正確使用reuseIdentifier來重用Cells
- 儘量使所有的view opaque，包括Cell自身
- 儘量少用或不用透明圖層
- 如果Cell內現實的內容來自web，使用異步加載，緩存請求結果
- 減少subviews的數量
- 在heightForRowAtIndexPath:中儘量不使用cellForRowAtIndexPath:，如果你需要用到它，只用一次然後緩存結果
- 儘量少用addView給Cell動態添加View，可以初始化時就添加，然後通過hide來控制是否顯示
尾巴
肯定很多人會非常好奇，爲什麼我都是手動用代碼創建Cell的？現在主流不都是Xib、Storyboard什麼的嘛？我的回答是：要想提高效率，還是手動寫有用！拋開Xib、Storyboard需要系統自動轉碼，給系統多加了一層負擔不談，自定義Cell的繪製更是無從下手，所以，在我看來，複雜的需要高效的界面，還是手動寫代碼吧！！！
最後如果你們的項目都是用的Xib、Storyboard，並需要優化UITableView的話，sunnyxx大神提出了好的方案：http://blog.sunnyxx.com/2015/05/17/cell-height-calculation/ 大夥可以自行研究研究。
歡迎留言交流。
註明：本篇的分析源碼來源於開源項目VVeboTableViewDemo
CSDN下載地址
