tableView流畅度优化
- 异步渲染内容到图片
- 按照滑动速度按需加载内容
- 重写处理网络图片加载
实际上做完前两点就可以很流畅了。
预排版
当获取到JSON数据后，把每个cell需要的数据都在后台线程计算，并封装成为一个布局对象cellLayout，cellLayout包含了cell内部每个控件的高度，cell的整体高度。每个cellLayout占用的内存并不多，所以当生成后，可以全部缓存到内存，以供稍后使用。这样tableView在请求各个高度函数时，不会消耗任何多余的计算量。当把cellLayout设置到cell内部时，cell内部也不用再计算布局了。
预渲染
对于TableView来说，cell内容的离屏渲染会带来较大的GPU消耗，在cell中用到了不少的layer的圆角属性，如果在低性能的设备（比如iPad3）上快速滑动tableView，能感受到虽然列表并没有较大的卡顿，但是整体的平均帧数降了下来，用Instument查看时能够看到GPU已经满负荷运转，而CPU却比较清闲，为了避免离屏渲染，应当尽量避免layer的border、corner、shadow、mask等技术，而尽量在后台线程预先绘制好对应的内容。
异步绘制
当tableView快速滑动时，会有大量的异步绘制任务提交到后台去执行，但有时候滑动速度过快时，绘制任务还没有完成就可能已经取消了，如果这时仍然继续绘制，就会造成大量的CPU资源浪费，甚至阻塞线程并造成后续的绘制任务迟迟无法完成。所以应当尽量快速、提前判断当前绘制任务是否已经被取消；在绘制每一行的文本前都判断当前任务是否被取消，取消的任务及时推出，不至于影响后续操作，
目前有些第三方的微博客户端（VVebo、墨客），使用了一种方式来避免高速滑动时cell的绘制过程，相关实现：VVedoTableViewDemo.它的原理是，当滑动时，松开手指后，立刻计算出滑动停止时cell的位置，并预先绘制那个位置附近的几个cell，而忽略当前滑动中的cell，这个方法比较有技巧性，并且对于滑动性能来说提升也很大，唯一的缺点就是快速滑动中会出现大量的空白内容。
全局并发控制
大量的任务提交到后台队列时，某些任务会因为某些原因被锁住，导致线程休眠或者被阻塞，concurrent queue随后会创建新的线程来执行其他任务，当这种情况变多时，或者app中使用了大量concurrent queue来执行较多任务时，app在同一时刻就会存在几十个线程同时运行、创建、销毁。CPU是用时间轮转来实现线程并发的，尽管concurrent queue能控制线程的优先级，但当大量的线程同事创建运行销毁时，这些操作仍然会占掉主线程的CPU资源。
使用concurrent queue时，可不避免会遇到这种问题，但使用serial queue又不能充分利用多核CPU的资源。有一个简单的工具 YYDispatchQueuePool，为不同优先级创建和CPU数量相同的serial queue，每次从pool中获取queue时，就会轮询返回其中一个。把App内所有的异步操作，包括图像解码、对象释放、异步绘制，都按优先级不同放入了全局的serial queue中执行，这样避免了过多的线程导致的性能问题。
更加高效的异步图片加载
SDWebImage 在这个demo里仍然会产生少量的性能问题，并且有些地方不能满足需求，比如在显示单张图片的时候，利用UIView.layer.contents就足够了，没必要使用UIImageView带来额外的消耗，可以在CALayer上添加setImageWithURL等方法。
其他可以改进的地方
- tableView中有不少视觉元素并不需要触摸事件，这些元素可以用ASDK的图层混合技术预先绘制为一张图。
- 在进一步减少每个cell内图层的数量，用CALayer替换到UIView。
每个cell类型都是相同的，但是显示的内容却各不一样，有的cell有图片，有的没有图片，可以把cell进一步划分，进一步减少cell不必要的视图对象操作。 - 把需要放到主线程执行的任务划分为足够小的块，并通过RunLoop来进行调度，在每个Loop里判断下一次的VSync的时间(绘制完当前帧，重新绘制下一帧)，并在下次VSync到来前，把当前未执行完的任务延迟到下一个Loop去。
最后要提一下 “过早的优化是万恶之源”，在需求稳定，性能问题不明显时，没必要尝试做优化，而要尽量正确的实现功能，做性能优化时，也最好修改代码，这样一个流程，有限解决最值得优化的地方。
如果需要一个明确的FPS指示器，可以尝试一下KMCGeigerCounter，对于GOU带来的卡顿，它用了一个1x1的SKView来进行监视，这个项目目前有两个小问题，SKView虽然能监视到GPU的卡顿，但引入SKVView本身就会对CPU/GPU带来额外的资源消耗，另外就是与新的系统的兼容问题。
最后，用Instuments的GPU Driver预设，能够实时查看到CPU/GPU的资源消耗。在这个预设内，能够查看到几乎所有与显示有关的数据，比如texture数量、CA提交的频率、GPU消耗等，在定位界面卡顿问题时，这是最好的工具.
。
。
。
。
。
。
。
。
。
。
