我已经在这这个最好的移动开发平台上开发很多年了 - iOS,在这区间我已经了解很多iOS apps和很多移动开发人员。

我们周围有很多优秀的开发者，但是我发现很多开发者都无法充分利用这个最优秀平台的性能，从而开发出最优秀的平滑应用。

现在，我从我的角度来说明下开发工程如何使<code>UITableViews</code>更加快和平滑

文章的深度和难度会随文章的推进越来越提升，所以开始我会用一些大家容易理解的，文章最后会涉及到iOS的Core Graphics 和UIKit更加深层次的内容。

内置方法

相信大部分人都知道这些方法，甚至使用过，但是相信大部分人都没有正确的使用这些方法。

首先，我们需要重用单个<code>cell/header/footer</code>实例，或者显示更多，最好的方式就是我们优化<code>UIScrollView</code>(UITableView的父类)，它是苹果公司提供的，为了正确的使用它，我们应该只使用<code>cell/header/footer</code>，一次性初始化它并且返回给<code>UITableView</code>
苹果文档已经已经对cell的重用已经很好的描述了，这里就不赘述了。

这里最重要的就是方法<code> tableView:cellForRowAtIndexPath:</code>,这个方法必须在<code>UITableView</code>的代理方法里实现，需要为每个<code>Cell</code>调用一次，它应该快速执行，所以你应该尽可能的快返回重用的 <code>Cell</code>

这里不要执行数据绑定，因为现在<code>Cell</code>还没有显示到屏幕上面，数据绑定的动作可以在 tableView:willDisplayCell:forRowAtIndexPath:方法里进行，这个方法在代理里面实现，并且在<code>Cell</code>显示的时候掉用

第二点也不难理解，但是有一点需要说明的
这点对于固定高度的<code>UITableView</code>没有意义，但是对于动态高度的却非常有用

我们都知道，<code>UITableView</code>是<code>UIScrollView</code>的子类，<code>UIScrollView</code>可以使用户交互的区域比可视区域更加宽广，任何<code>UIScrollView</code>的实例都会有contentSize, contentOffset以及一些其它属性，来正确显示区域呈现给用户。

但是<code>UITableView</code>的问题出现在哪呢？正如我们说的那样，<code>UITablView</code>不会维护所有<code>Cell</code>实例，只为维护显示给用户能看见的<code>Cell</code>

那么<code>UITableView</code>怎么知道它的<code>contentSize</code>呢？它只是计算每个Cell高度的和。

方法 tableView: heightForRowAtIndexPath:为<code>UITableView</code>的代理方法，每个<code>cell</code>都会调用该方法返回高度，即使这个<code>cell</code>还没有显示，所以您返回高度的时候要尽可能的快

大部分人都犯了一个错误，通过AutoLayout实例化一个<code>Cell</code>,并通过绑定数据来获取其高度。如果你想优化滑动性能就不该采用这种方法来计算<code>Cell</code>高度。这么操作会是流畅度为60FPS骤降到15-20FPS，严重影响滑动性能。

如果你没有<code>Cell</code>实例，怎么更好的返回一个<code>Cell</code>的高度呢，下面有一个例子，基于一个类方法返回高度，通过传入宽度和数据

可以不看.png

从iOS8开始，我们可以使用<code>automatic height</code>计算，通过食用自动布局和设置<code>rowHeight</code>为<code>UITableViewAutomaticDimension</code>,更多详细信息你可以通过 StackOverflow发现。

尽管可以使用这些方法，我强烈建议你不要，还有，我也建议不要使用复杂的数学计算在计算<code>Cell</code>高度的时候，如果可以的话，最好只使用加、减、乘、除。

但是关于<code>AutoLayout</code>?它真的如我讲的那么慢吗？可能你很惊讶，但是那是事实。如果你想让你的app在所有设备上都能完美的滑动，你会发现使用<code>AutoLayout</code>反推高度，难于置信的慢。子视图越多，AutoLayout效率越低。

<code>AutoLayout</code>相对低效的原因，是来自底层的一个名叫“Cassowary”的约束求解系统，子视图越多，就将花费更多的时间来返回<code>Cell</code>

哪个更快呢：执行少量的基本数学运算呢，还是大量线性等式或不等式呢？现在想象一下，用户想要快速滑动，每个<code>Cell AutoLayout</code>执行着疯狂的计算。

使用内置方法最正确的方案如下：

• 重用<code>Cell</code>实例：对于特殊的<code>Cell</code>类型，你应该只返回一个实例，不能更多了
• 不要在cellForRowAtIndexPath:中绑定数据，因为这个时候<code>Cell</code>还没有要显示，替代方法tableView:willDisplayCell:forRowAtIndexPath:里面进行数据绑定。
• 快速计算<code>Cell</code>高度，这对于工程师来说是常规工作。但是也会为你的耐心提高复杂<code>Cell</code>流畅度的时候获得嘉奖。

我们需要深入

当然，上面提到的不足于让我们实现真正的平滑滚动，特别是你要实现一些复杂的<code>Cell</code>的时候，这些<code>Cell</code>中包含了一些渐变、视图、交互元素、装饰元素以及更多。

在这种情况下，<code>UITableView</code>很容易变得卡顿，即使你已经做了上面所有得优化，子视图越多，FBS越低，滑动的时候。但是现在已经手动布局和最优化的高度计算了，问题就不在布局了，那么就在渲染了。

让我们把关注点切换到UIView的 “opaque”上来，文档说这个是帮主绘画系统定义<code>UIView</code>是否透明的，如果不透明，绘画系统将做一些优化在渲染的时候以提高性能。

我们需要新能，或者不要？用户可能非常密集的滑动或者直接使用 scrollsToTop特性，他们可能没有最新的<code>iPhone</code>，然而<code>Cell</code>必须渲染更快，比一般的视图更快的渲染。

渲染中最慢的就是混合渲染，它由GPU来执行完成，这个硬件本来就是用来做这个的（当然不仅仅是处理混合渲染）。

调试这里就不原文翻译了，直接使用Instruments调试即可发现，哪里使用了混合渲染。

Paste_Image.png

绿色的地方表示没有使用混合渲染，红色的地方表示使用了混合渲染。

正如你所见，这里至少2个地方出现了混合渲染，但是你可能看不出有什么不同（这个混合操作不是必须的）

不同的场景下，我们有不同的方式来处理混合渲染，这里我们只需要设置<code>backGroundColor</code>就可以处理掉混合渲染。

warning：插一句，设置背景色其实本质就是设置不透明。

但是有时候可能更复杂，我们有一个渐变，没有混合

Paste_Image.png

这确实发生了，因为我们混合了2个层的内容：UILabel 的CATextLayer和CAGraidentLayer.

如何能正确的使用GPU和CPU，使其能负载均衡，保证FPS在60.就像下面这样：

Paste_Image.png

问题是，当执行很多混合操作的时候，GPU满载了，而CPU还没怎么使用

在2010年夏季末尾的时候大部分工程师都面临着这个问题，在发布了iPhone4后，苹果发布了革命性的Retina屏和很普通的GPU，通常它还是可以处理一般情况的，但是上面的情况变的更加复杂。

你可以在当前运行iOS 7系统的iPhone 4上看到这一现象：所有的应用都变得很慢，即使是最简单的应用。不过，应用这篇文章中的介绍的方法，即使是在这种情况下，你的应用也能达到60 FPS，尽管会有些困难。

所以，需要怎么做呢？事实上，解决方案是：使用CPU来渲染！这将不会加载GPU，这样就无法执行混合操作。例如，在执行动画的CALayer上

我们可以使用CPU渲染，使用Core Graphics操作DrawRect:方法。如下：

![Uploading Paste_Image_995558.png . . .]
这段代码很