1、Autolayout + AutomaticDimension
使用这种方式来是Cell高度的自适应比较简单，但不高效。
下方就是我们添加完约束后要做的事情，需要给我们的tableView设置一个预估值（estimatedRowHeight）, 然后在TableViewDelegate的heightForRowAtIndexPath方法中返回UITableViewAutomaticDimension该属性即可。这样Cell就可以根据可变的文字高度来自适应了。当然该方法在iOS8以上的系统上才可以使用
卡顿还是比较明显的，掉帧比较严重，在Cell高度自适应时最好不要采用此方法。
填写内容的Cell上是可以使用这种方法进行预估的，也就是说，当根据用户输入的内容来实时改变Cell的高度，是可以使用该方法的。
2、Autolayout +CountHeight
对上述的效果进行优化，不使用TableView的预估值了，而是直接使用我们在子线程中计算的文本高度。当然依然是使用AutoLayout的方式，将上述返回高度的方法heightForRowAtIndexPath中的内容进行替换，直接返回当前Model中Cell的高度，如下所示：
经过上面这么一修改，我们就可以将之前Cell高度计算的内容移到子线程中了，上述的卡顿问题会得到些微的解决。下方是该方式的运行效果，可以看出来比上述的实现方式稍微好一些，不过还是有些掉帧，掉帧也是比较严重的。
3、FrameLayout + CountHeight
上述结果仍然不理想，我们接着优化。我们不使用AutoLayout布局，我们直接使用Frame来布局，这样就减少了由AutoLayout转换到FrameLayout的时间。本部分我们就使用纯代码的方式，以Autolayout进行布局。在给Cell配置数据的时候我们根据Model中计算的高度来修改可变文字内容的高度，如下所示：
下方是使用这种方式最终的运行效果，从该效果中可以看出，效果还是蛮OK的。虽然有些掉帧，但是还是非常流畅的，这种流畅度是可以接受的。如果你不想使用第三方库的话，这种方式还是一个比较好的解决方案的。
4、YYKit + CountHeight
接下来我们进一步进行优化，引入第三方UI组件YYKit。将Cell上的组件替换成YYKit所提供的组件。然后使用Frame进行布局，当然也是在子线程中对Cell的高度进行计算了。
看来将进行系统的基础控件换成了YYKit中的控件，下方是此解决方案的运行效果。单从效果上来看，还是比较流畅的，但是为达到完全不掉帧的效果。不过整体看来还是比较流畅的。
5、AsyncDisplayKit + CountHeight
接下来我们要用Facebook提供的第三方库来进行基础组件的替换，将我们使用到的组件替换成AsyncDisplayKit相应的Note，如下所示。这些Note是对系统组件的重组，对组件的显示进行了优化，让其渲染更为流畅。
下方就是使用AsyncDisplayKit重构后运行的效果。从下方的效果上来看，几乎不掉帧，那个流畅呢。如果你对UI流畅度要求比较高的话，那么AsyncDisplayKit是一个比较好的选择。不过会严重依赖AsyncDisplayKit，如果AsyncDisplayKit停止维护了，后期对AsyncDisplayKit进行替换的话，工作量还是比较大的。因为这种布局框架不像网络框架，我们可以对网络框架的调用进行提取，网络层统一对外接口，很方便切换到其他网络请求库。但是像AsyncDisplayKit这种框架会散布于UI层的各个角落，封装提取不易，更不用说轻而易举的替换了。所以像这种页面的实现，个人还是偏向于Framelayout + CountHeight的方式来实现。
网友评论