iOS开发之多种Cell高度自适应实现方案的UI流畅度分析

转载至 http://www.cnblogs.com/ludashi/p/5895725.html

本篇博客的主题是关于UI操作流畅度优化的一篇博客，我们以TableView中填充多个根据内容自适应高度的Cell来作为本篇博客的使用场景。当然Cell高度的自适应网上的解决方案是铺天盖地呢，今天我们的重点不是如何讨论Cell高度的自适应，而是给出几种Cell高度自适应的解决方案，然后对比起UI流畅度，从而得出一些UI优化的一些常规做法。今天博客中主要用涉及的第三方库是YYKit和AsyncDisplayKit。

关于YYKit和AsyncDisplayKit这两个库，本篇博客只是简单的涉及到一些基本用法，主要是针对我们本篇博客的Demo来使用的，其中好多功能并未使用。因为之前在项目中没怎么使用过这两个框架，所以本篇博客就不着重介绍着两个第三方框架了，如果你对其感兴趣，Github上有你想要的内容，请自行搜索。废话少说，进入今天的主题。

一、总述

本篇博客主要给出了5种Cell自适应高度的解决方案，并对比了每种实现方案的流畅度。也可以说是从UI最不流畅的一种我们慢慢优化，从而实现了这5种解决方案。当然我们是观察屏幕的FPS来判断屏幕在操作时是否卡顿。关于对FPS的实时监测，我参考了YYKit-Demo中的做法，并将其单独提取了一个组件，便于我们项目的使用，关于这个提取的FPS组件，下方使用时会具体介绍。当然本篇博客所涉及的所有代码，依然会分享到Github上，文章后方会给出相应的链接，有需要的小伙伴请自行clone。

下方这个截图是我们今天demo的菜单列表页面，点击每个Cell都会跳转左边这个内容列表页面。不过每个Cell所对应的内容页面的Cell自适应高度的实现方式不同，我们在对其滑动操作时，可以根据下方这个FPS组件来观察屏幕的流畅度。当然，每个内容列表页的布局和显示内容都是相同的，不过不同的Cell自适应解决方案所对应的UI流畅度也是不同的。下面我们先大体的聊一下每种Cell自适应的实现方案。

Autolayout + AutomaticDimension: 该解决方案对应着，下方第一个Cell, 点击该Cell进入的页面完全由AutoLayout进行布局，Cell自适应的高度也不用我们自己计算，而是使用系统提供的解决方案UITableViewAutomaticDimension来解决。当然，使用UITableViewAutomaticDimension要依赖于你添加的约束，稍后会介绍到。这种实现方案用起来简单，不过UI流畅度方面不太理想。当TableView快速滑动时，就会出现掉帧，卡的不要不要的。

Autolayout + CountHeight: 这种解决方案依然是采用AutoLayout的方式来对Cell的内容进行布局，不过Cell的高度我们是自己计算的，当然我们这个计算Cell高度的过程是放在子线程中进行的，所以这种实现方式要优于第一种实现方式，稍后会详细介绍。

FrameLayout + CountHeight: 为了进一步提高流畅度，我们采用了纯Frame布局，之前好像在哪儿看过，说Autolayout最终也是会被转换成Frame进行布局的，所以我们索性就使用Frame对整个Cell中的元素进行布局。当然Cell高度已经Cell中可变内容的高度都是在子线程中进行计算的，这也是优化很重要的一步。这种实现方式还是比较流畅的，可以作为折中的方案。

YYKit + CountHeight: 这种解决方案用到了YYKit中的控件，并且使用Frame布局与Cell高度的计算。这种方式要由于上面的解决方案，比较YYKit中的一些控件做了优化。

AsyncDisplayKit + CountHeight: 则是使用了AsyncDisplayKit中提供的相关Note代替系统的原生控件，这种实现方式是这5种实现方式中最为流畅的。稍后会详细介绍。