在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方法的话，瞬间就处理完了。
转载仅供參考。版权属于原作者。