推荐：http://code4app.com/ios/VVeboTableView/565d75a3594b90bf268b49ff
1: heightForRowAtIndexPath方法小做文章
原因：tableview继承自scrollview，当tableview加载时需要将contentSize计算出来。所以第一次加载时会频繁调用此方法，如：table有100行，则此方法调用100次，将每次得出的结果相加得到contentSize。就像每次使用scrollview滚动时都要设置contentSize这个属性一样。
小做文章1:如果table每一个cell的高度固定，使用_tableView.rowHeight ＝ 200；
小做文章2:如果cell高度可变，不要在heightForRowAtIndexPath中调用cellForRowAtIndexPath来计算。取而代之的是，cell的工厂方法。如：
小做文章3:在获取数据的时候就将高度计算好并存储到数据中，heightForRowAtIndexPath方法则直接使用该数据。如：
总结：尽可能使用第三种方法，分析如下
第二种方法时间分析如下：
第三种方法时间分析如下：
两种方法本质上都是遍历数据获取相应高度，计算高度的代码完全相同。但是第二种方法中heightForRowAtIndexPath的运行时间占比很大，并且随着table滚动而不断增加，证明每次用户滚动table时，计算高度的方法都执行一次，如果计算高度的方法用时比较多，如我当前用的
每次计算的时间都在330个单位上下，那么如果数据量大，滚动很快时，这简直就是灾难。
第三种方法计算高度的代码则是在获取数据后，table加载之前执行，并且只执行一次。210ms的时间不随着table的滚动儿增加。而我们的heightForRowAtIndexPath的方法，执行时间已经降到了1ms，几乎可以忽略不计了。
当然，在一个只有table的demo中，这点优化基本看不出有什么作用。
2:添加不如画：cellForRowAtIndexPath方法大费周折
平时使用cellForRowAtIndexPath时最常用的方法就是在cell的init方法中addSubview如
这个是添加子视图的方法将数据灌在cell中。
画的方法则是在最开始推荐的demo中的方法，感谢作者。
像这样：
画的代码很多，基本属于CoreGraphics框架的东东，说大费周折，基本都在这了。
添加子视图的方法时间分析如下：
画的方法时间分析如下：
实话实说呀，这画的方法代码执行的时间真心是吓了我一跳了，画cell的线程真心是-_-#
但是呢，用户滚动table是感觉不到地，因为所有画的线程都是子线程，而主线程占比只有区区的2%，就是setimage的方法。
反过来，添加子视图的方法cellForRowAtIndexPath则几乎全部都在主线程执行，子线程只有查找缓存图片的方法。这个办法真心卡卡卡的呀。
真机跑一下，明显感觉画的方法要比添加子视图的方法顺畅的多。
ps:只分析代码执行时间，不分析内存占用量。