在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; }}// 也可不遍历，直接与头尾相比拟，看是不是在中间便可。
在iOS App中，UITableView应当是应用率最高的，同时也是最为庞杂的视图。
几近所有
阅读背景：
如何优化UITableView的性能
来源：互联网
分享到：
