Feed流应该是每个App和游戏开发者都避免不了的话题。特别是App开发，绝大多数App的内容呈现都是以Feed流来实现的。其实讲Feed流性能优化的文章已经有很多了，而且很大文章都给出了具体的代码实现。所以我没必要再写一篇很详细的文章，只是当自己做的总结了。
1.优化feed高度计算。
我觉得这是一个最简单却又收效很明显的一个方法。具体做法如下：
a.使用推测（预估）高度方法
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath NS_AVAILABLE_IOS(7_0);
我们都知道，tableView在初次加载的时候，如果有100个cell那么就会调用100次heightForRowAtIndexPath方法，苹果在iOS7上新增了estimatedHeightForRowAtIndexPath方法后，如果实现了这个方法，初次加载的时候就会调用100次estimatedHeightForRowAtIndexPath来替代heightForRowAtIndexPath方法。
重点是estimatedHeightForRowAtIndexPath方法可以给一个预估值，而不是具体值。也就是说你可以给一个接近于平均cell高度的值。比如直接return 80.0f;
这样以来就大大节省了初次加载的高度计算时间。当然，当你滑动以显示更多cell的时候还是会调用heightForRowAtIndexPath方法。
b.缓存cell高度
这是一个优化滑动卡顿很好的方法，因为每次滑动的时候，需要绘制新的cell或者重用旧的cell，就会调用对应cell的heightForRowAtIndexPath方法。如果能做到根据数据就能计算cell显示高度的话最好不过了。这样就可以在拿到数据的时候计算一次高度，然后缓存起来，一劳永逸。
具体做法是，比如根据后端下发的数据，计算高度放一个数组里。然后在heightForRowAtIndexPath取出对应的高度值。这样不用每次计算，但是会引出一个问题，就是需要维护这个数组。当数据发生改变的时候，数组必须作出对应的改变。
2.异步加载／绘制，甚至不绘制。
其实异步加载都不用说了，现在大多数项目中都使用SDWebImage之类的库，实现了网络图片的异步加载了。在滑动的时候，图片的加载并不会影响滑动流畅度。
这里要重点说的是“不绘制”，监测tableview的滑动速度，如果速度快到一定程度，那么这时候需要显示的cell就延时绘制，用户看到的可能只是一些和真实cell等高的，但是内容是空白或者默认图案／文案的cell。微博客户端就有一套这种机制。这个实现起来稍微复杂，而且依赖于高度缓存。如果有机会我会写一个Demo来说明。
