UITableView性能优化

关于UITableView的性能优化，网络上也有一些总结。在这里就介绍下我们项目中遇到的问题以及对应的解决方法。相信我们遇到的问题也有一定的普适性，能够作为其他问题的优化方案。

Instruments

要对UITableView的性能进行优化，有一个工具肯定是不能少的，那就是Instruments，如果还不知道Instruments，建议先去看看相应的Apple Docoment。在开始着手优化你的UITableView的时候，不妨先用Instruments来看看你的UITableView看看你的代码的瓶颈究竟在哪里，不要轻易的对代码下判断，耗时不耗时。这里有个例子，当时我发现我们项目中有一个UITableView的滚动特别不顺畅，而这个UITableView的cell中的布局也确实很复杂，优化了一段时间后却发现滚动还是一样的不顺畅，打开Instruments工具Profile，立刻就发现了初始化Cell的代码占据了大量的运行时间，第一反应就是Reuse Identifier写错了。果不其然，查了一下xib和代码中的Identifier，哪位粗心程序猿同学没有两处的Identifier设为一致，导致每次都重新生成了一个Cell。

其实这是个非常简单的问题，但凡使用过UITableView的人都知道要对Cell进行重用。但是这却是在优化中特别容易被忽略的点，这个例子是为了说明使用Instruments的重要性，它能给我们的优化带来很大的方便。

将属性设置代码放在正确的位置

再来谈谈另一个容易被忽略的点。也是对我们的项目Profile的时候发现的问题。这可能与每个人的编码习惯以及编程经验有关。在我们的项目代码中，我发现CustomCell方法中的某些属性设置操作在CustomCell方法中占了很大一部分时间，比如利用layer设置圆角、设置阴影、设置遮罩、设置图片等操作。仔细阅读代码后发现，其实这部分代码完全可以提前到awakeFromNib或者是init方法中去，但是直接写到了CustomCell方法中了，这就等于每次CellForRowAtIndexPath:时就会运行这些方法，其实也可以归结到重用的问题中去。

异步加载

既然讲到了CustomCell方法，就继续说几个可以在这里面优化的地方。iOS 6之后在很多控件中，Apple给我们提供了attributedText方法，以前需要使用Core Text才能完成的工作现在使用attributedText方法就能简单的完成了，给我们提供了很大的便利。但是在优化的时候，发现attributedText方法的耗时是非常大的，如果设置了图片作为attachment，那么就更加耗时了。因为闭源的原因，也不清楚究竟是什么原因引起的。既然这么耗时，又无法避免，那就只能直面他了，刚正面！优化用到的方法也很简单，就是异步的去执行这些操作。开个异步队列（非主队列）去构建这个attributedString，然后回到主队列里来设置attributedText，因为在iOS中UI操作必须要在主线程中进行嘛，不然会造成不可预知的后果，这个不可预知的后果据我观察一般就是UI不会立马更新。那么这里又有一个常用的优化方法了，其实不只针对UITableView，其他场合也能适用——把耗时的操作异步的去处理，然后回到主线程中更新UI。在我们的项目中，某些CustomCell方法因为业务需求，需要访问Disk。显然，IO操作是耗时大户，滑动的时候有明显的卡顿，也是采用了异步方式来处理的。

容易忽视的stringWithFormat:

在优化中，还发现了一个很隐蔽的问题。如果你的CustomCell方法中有大量的stringWithFormat:操作的话，你可能需要在字符串的优化上下点力气。因为不幸的是stringWithFormat:操作也会造成不可忽视的开销，听起来很奇怪吧。当时我在Profile的时候也惊呆了，为啥这个操作会造成性能瓶颈。幸好我们有解决方案。我们可以用C Style的方式来构造我们的字符串！事实证明这能减少不小开销，如果你的CustomCell方法中有大量的stringWithFormat:方法，那么性能提升的效果应该非常明显。下面这段代码可以用来进行C和ObjC字符串的转换：

char cString[255];    // 这里要根据实际情况开辟大小

sprintf(string, "Click: %d", numberOfClick);

NSString *objCString = [[NNString alloc] initWithUTF8String:cString];

GIF

因为业务需求，需要在某些Cell中添加GIF图片，Gif图片本来就比较吃资源，满屏的Cell每个都有一个GIF在动，想想就酸爽。一开始是使用FlAnimatedImage在每个Cell中添加一个GIF View，居然也没人发现有问题（应该是发现有问题，但是觉得问题不大），直到第一版本上架了也没人发现。某天我没事在优化的时候发现我的iPhone 5s已经烫的可以煎鸡蛋了，然后用Instruments一跑，不跑不知道，一跑吓一跳，停留在这个UITableView不操作的时候，FlAnimatedImage一直在创建线程，不烧CPU才怪呢。因为这个GIF还不算特别复杂，想了想可以自己画，然后用几个动画就能做出一样的效果，果断换了解决方案，换完之后简直顺畅。

不要忘记scrollViewDidScroll

我觉得这应该又是一个偷懒的结果。同样是在Instruments里发现的问题，scrollViewDidScroll:方法莫名其妙的占了很多运行时间。打开来一看，哦！原来是要记录每次用户滑动后停下的位置，显然放在scrollViewDidScroll:里是不合适的，因为随便滚动一下，scrollViewDidScroll:就调用了N次。果断转移代码，想了下丢到了scrollViewWillEndDragging:withVelocity:targetContentOffset:代理方法中去了，利用这个targetContentOffset就能解决啦。和CellForRowAtIndexPath:方法一样，这个方法调用的频率也很高，迫不得已不在在里面放耗时的代码。

图片！图片！

图片一直是吃资源的大户，网络图片的异步加载应该算是使用UITableViewCell的初级技术，所以这里讲的并不是图片的加载。圆角图片，相信都见过，四个角圆圆的那种矩形图片，看起来萌萌的。圆角的实现方式也有好多种：配合使用layer的cornerRadius和maskToBounds来实现、使用Core Graphics绘制（用UIBezierPath添加Clip）、使用图片遮罩等等。如果只有一个圆角图片，那么可能不会造成大的影响，但是如果每个Cell中都有圆角图片，那么建议是采用图片遮罩的形式来实现，因为这种方法效率更高。

图片加载还有个小技巧就是当图片在异步加载的时候，图片所在的Cell滚动出了屏幕，那么立马把这个下载的操作给Cancel掉，避免不必要的资源消耗。

[UIImage imageNamed:] 的数据会缓存在内存中，而[UIImage imageWithContentOfFile:]的数据则不会。如果你需要在Cell中频繁的设置几个图片，那么在Cell中使用一个UIImage对象来保存住这些Image，也会对性能有所提升。

以上是我在项目中遇到的一些UITableView优化的问题。其实网上还有很多经验，这里摘抄一些作为记录，来源都在最后的Reference中有给出。

减少Subview的个数和层级。使用一个UIView并override drawRect:方法来绘制所有内容能够提升UITableView的性能。主要是因为GPU负责来rendering和compositing，层级多了之后CPU需要做的合成工作变得复杂，所以可能还不如drawRect:使用CPU来绘制比较快，这其中的原因也很复杂，不是任何时候使用drawRect:都能提升性能的。而且一般并不推荐这么做，这里有非常详细的解答。
将Subview的opaque属性设置为YES（不透明了就告诉GPU不用再渲染此view下的图层了，GPU在UITableView``scroll的时候做了大量的工作）
将CALayer的ShouldRasterize设置为YES（ShouldRasterize告诉系统可以直接使用Cache的备份，如果View的内容不会改变，可以使用，否则会有副作用）
不要拉伸Cell中的图片。
如果是动态高度的Cell，可以想办法缓存Cell的高度，避免每次计算。
使用Instruments找到当前的瓶颈是在CPU还是GPU上。链接
如果Cell有阴影，尽量使用图片而不是操作layer来绘制。

除了以上技术上可以对UITableView的性能进行优化外，还可以从加载逻辑上对UITableView的性能进行优化。

这篇文章就从图片的加载逻辑上做了优化，达到提升性能的目的。主要思想是：用户在滑动UITableView时，不加载快速滑动过程中的图片，预先加载UITableView滚动停下位置的图片。