在iOS App中，UITableView应该是使用率最高的。同一时候也是最为复杂的视图。 
差点儿全部自带的应用中都能看到它的身影，可见它的重要性。

　　在使用UITableView时，会常常遇到性能上的问题，普遍表如今滚动时比較卡。特别是table 
cell中包括图片的情况时。
实际上仅仅要针对性地优化一下，这样的问题就不会有了。有兴趣的能够看看LazyTableImages这个官方的样例程序，尽管也要从网上下载图片并显示。但滚动时丝毫不卡。

　　首先说下UITableView的原理。有兴趣的能够看看《About Table Views in iOS-Based 
Applications》。
UITableView是UIScrollView的子类，因此它能够自己主动响应滚动事件（一般为上下滚动）。
它内部包括0到多个UITableViewCell对象，每一个table 
cell展示各自的内容。
当新cell须要被显示时，就会调用tableView:cellForRowAtIndexPath:方法来获取或创建一个cell。而不可视时，它又会被释放。由此可见，同一时间事实上仅仅须要存在一屏幕的cell对象就可以，不须要为每一行创建一个cell。


　　此外。UITableView还能够分为多个sections，每一个区段都能够有自己的head、foot和cells。而在定位一个cell时，就须要2个字段了：在哪个section，以及在这个section的第几行。这在iOS 
SDK中是用NSIndexPath来表述的，UIKit为其加入了indexPathForRow:inSection:这个创建方法。
其它诸如编辑之类的就不提了。由于和本文无关。介绍完原理，接下来就開始优化吧。

使用不透明视图。
不透明的视图能够极大地提高渲染的速度。因此如非必要。能够将table 
cell及其子视图的opaque属性设为YES（默认值）。
当中的特例包括背景色，它的alpha值应该为1（比如不要使用clearColor）；图像的alpha值也应该为1。或者在绘图时设为不透明。

不要反复创建不必要的table 
cell。
前面说了，UITableView仅仅须要一屏幕的UITableViewCell对象就可以。
因此在cell不可见时。能够将其缓存起来，而在须要时继续使用它就可以。
而UITableView也提供了这样的机制，仅仅须要简单地设置一个identifier就可以：

static NSString *CellIdentifier = @"xxx";
UITableViewCell *cell = 
[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == 
nil) {
    cell = [[[UITableViewCell alloc] 
initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] 
autorelease];
}
　　值得一提的是，cell被重用时，它内部绘制的内容并不会被自己主动清除，因此你可能须要调用setNeedsDisplayInRect:或setNeedsDisplay方法。


　　降低视图的数目。
UITableViewCell 也能够私人定制。 
每一个Cell 
中可包括Label、ImageView等多个子View。你还能够自己定义一些视图放在它的contentView里。这里须要指出的是。view是非常大的对象。创建它会消耗非常多内存。而且也影响渲染的效果。
假设你的table 
cell包括图片，且数目较多。使用默认的UITableViewCell会非常影响性能。
奇怪的是，使用自己定义的view，而非提前定义的view，明显会快些。
当然，最佳的解决的方法还是继承UITableViewCell，并在其drawRect:中自行绘制：

- (void)drawRect:(CGRect)rect {    
    if (image) {
        
[image drawAtPoint:imagePoint];
        self.image = nil;
    } else 
{
        [placeHolder drawAtPoint:imagePoint];
    } 

[text drawInRect:textRect withFont:font 
lineBreakMode:UILineBreakModeTailTruncation];
}

　　只是这样一来，你会发现选中一行后，这个cell就变蓝了。当中的内容就被挡住了。最简单的方法就是将cell的selectionStyle属性设为UITableViewCellSelectionStyleNone。这样就不会被高亮了。


　　此外还能够创建CALayer。将内容绘制到layer上，然后对cell的contentView.layer调用addSublayer:方法。这个样例中，layer并不会显著影响性能，但假设layer透明，或者有圆角、变形等效果，就会影响到绘制速度了。解决的方法可參见后面的预渲染图像。
不要做多余的绘制工作。

　　在实现drawRect:的时候，它的rect參数就是须要绘制的区域。这个区域之外的不须要进行绘制。
比如上例中，就能够用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect推断是否须要绘制image和text。然后再调用绘制方法。

　　预渲染图像。
你会发现即使做到了上述几点，当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在bitmap 
context里先将其画一遍，导出成UIImage对象，然后再绘制到屏幕。具体做法可见《利用预渲染加速iOS设备的图像显示》。
不要堵塞主线程。

　　做到前几点后。你的table 
view滚动时应该足够流畅了。只是你仍可能让用户感到不爽。常见的现象就是在更新数据时，整个界面卡住不动，全然不响应用户请求。

出现这样的现象的原因就是主线程运行了耗时非常长的函数或方法，在其运行完毕前。无法绘制屏幕和响应用户请求。当中最常见的就是网络请求了，它通常都须要花费数秒的时间，而你不应该让用户等待那么久。

　　解决的方法就是使用多线程，让子线程去运行这些函数或方法。
这里面另一个学问，当下载线程数超过2时。会显著影响主线程的性能。因此在使用ASIHTTPRequest时，能够用一个NSOperationQueue来维护下载请求，并将其maxConcurrentOperationCount设为2。而NSURLRequest则能够配合GCD来实现，或者使用NSURLConnection的setDelegateQueue:方法。
当然，在不须要响应用户请求时。也能够添加下载线程数，以加快下载速度：

- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView 
willDecelerate:(BOOL)decelerate {
    if (!decelerate) {
        
queue.maxConcurrentOperationCount = 5;
    }
}

- 
(void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView {
    
queue.maxConcurrentOperationCount = 5;
}

- 
(void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
    
queue.maxConcurrentOperationCount = 2;
}

　　此外，自己主动加载更新数据对用户来说也非常友好，这降低了用户等待下载的时间。比如每次加载50条信息，那就能够在滚动到倒数第10条以内时，加载很多其它信息：

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
    if (count - indexPath.row < 10 && !updating) {
        updating = YES;
        [self update];
    }
}
// update方法获取到结果后，设置updating为NO

　　另一点要注意的就是当图片下载完毕后，假设cell是可见的，还须要更新图像：

NSArray *indexPaths = [self.tableView indexPathsForVisibleRows];for (NSIndexPath *visibleIndexPath in indexPaths) {  if (indexPath == visibleIndexPath)   {   MyTableViewCell *cell = (MyTableViewCell *)[self.tableView cellForRowAtIndexPath:indexPath];   cell.image = image;   [cell setNeedsDisplayInRect:imageRect];    break;  }}// 也可不遍历。直接与头尾相比較。看是否在中间就可以。


最后还是前面所说过的insertRowsAtIndexPaths:withRowAnimation:方法，插入新行须要在主线程运行，而一次插入非常多行的话（比如50行），会长时间堵塞主线程。而换成reloadData方法的话，瞬间就处理完了。
转载仅供參考。版权属于原作者。