你的列表比巧克力还丝滑般柔顺的瓶颈在于哪里？

         前言：当你的列表迭代了一段时间后，业务是不是越来越复杂，滑动起来是不是一顿一顿的，你是不是也按着度娘的列表性能优化一步步操作过，但效果不太明显，病症一如当初，最近我们封面团队做列表相关优化，取得不错的效果，那么今天我们一起来探讨探讨60 FPS的帧率到底是被谁吃了？谁吃了？

       

        一般而言一个产品的页面结构，主要就是列表详情列表详情，产品也会不厌其烦的往列表里塞新的Cell样式，可横向滚动的卡片，数目不定的1图，3图，4图....9图，行数不定文字内容，关键字异色的标题，定制的行间距，可随时展开收起的卡片，到了这个时候你的列表FPS应该已经掉到了50甚至更低了。

        AutoLayout 是iOS6开始引入的，记得5年前刚做iOS开发事iPhone的分辨率还只有960X640，那时在公司里做个小游戏用了高版本的API iPhone 3gs 上跑不起来，当时带我的老大晚上加班帮我适配（再次感谢我的人生导师铭爷，好吧扯远了），纯frame布局，稍复杂一点的也就百分比布局。iPhone 5出了后屏幕长了，6出来屏幕大了，6p屏幕更大，这个时候明显frame布局对于复杂点的页面适配力不从心，自然而然开始使用AutoLayout，可是Apple爸爸出的原生布局API简直繁（没）杂（有）无（人）比（性），这个时候DeSandro带来了Masonry，以及后来的Snpkit讲iOS coder们从石器时代带入农耕时代。

       

       既然我花了一大段的时间说AutoLayout，那么卡顿一定会与他有关系，没错，tableview在绘制cell时会不知一次的调用高度绘制，不止一次的时候去调用，即使你只是简单的滚动列表也会调用用heightForRowAtIndexPath，

cellForRowAtIndexPath方法（微信公众号这个编辑器好蛋疼，空了研究），

如果是定高cell直接返回cell高度也是不错，可是需求大多数情况是不定高，每次滑动都会算高度，是不是就会卡了(FDTemplateLayoutCell 可以做cell高度缓存减少一部分卡顿)，另外注意不要在cellForRowAtIndexPath做约束设置相关的代码设置如make、update、remake，我们使用Instruments里的Animation可以直观的查看当前页面的帧率或者自己实现监测帧率的组件，使用Time Profile可以查看到底时哪里的代码是卡顿的瓶颈，这里直接出结论:无论是mas还是snp约束设置耗时依次是 remake>make>update，所以做好不要在列表滚动的时候做这些耗时的操作，可以的话使用frame布局或者autolayout，frame结合使用。

       离屏渲染这点很多列表优化里有讲不在多说，在我们团队列表优化的时候还发现富文本串AttributeString的绘制也很耗时，这是另一个重要的瓶颈，那么既然产品汪有需求，我们只能满足，但是性能会降，我们有什么方案可以提高FPS呢，你说的对异步绘制YYKit，Asyncdisplaykit，我们团队的大神觉得方案太重，读了源码后自己实现了CMAsyncLabel，效果很明显丝滑般。

       相信经过上边的优化你的列表已经很流畅了，这是目前团队列表优化过程中的一些心得，如有不妥之处望指正。