前言
AsyncDisplayKit 是 Facebook 在 2014 年开源的一个异步界面渲染库，她是构筑于 UIKit 之上的一个封装库，与 UIView 是平级的关系（同时提供 UIView bridge 接口）。
AsyncDisplayKit 在开源社区历经一年多时间的琢磨，已经逐趋成熟，完全可以用于生产环境，但目前将 AsyncDisplayKit 用于生产环境的应用寥寥无几，究其原因，不外乎以下几点：
- 不支持 IB，不支持 Autolayout，也不支持 Autoresizing，一切布局都需要手动计算完成；
- 接口并非与 UIView 完全一致，对入门使用者来说，有一定的学习成本；
- AsyncDisplayKit 并不是非用不可，她所追求的是极限用户体验。
为此， 我们可以引申出问题，** 为什么要使用AsyncDisplayKit **？
什么情况下应该使用 AsyncDisplayKit
- 复杂的界面
- 存在滑动性能问题的界面，同时使用各种方法优化无效的界面
- 频繁更新的TableView（比如聊天界面）
什么情况下不应该使用 AsyncDisplayKit
- 不存在性能问题的界面，没有必要使用 AsyncDisplayKit
性能问题的探讨
当我们谈论性能问题的时候，我们只是关注UI性能问题，那些逻辑、网络的性能问题并不是我们要关注的重点。
作为iOS开发者而言，务必需要了解到，有什么因素会影响UI性能。
就一般应用而言，需要关注的性能的UI控件可能就只有 UITableView 和 UICollectionView，其它类型的UI，性能问题在可以容忍的范围内。 这也是** 什么情况下应该使用 AsyncDisplayKit ** 的关注点。
但是，我们仍然有必要去列出一些影响流畅性的关键点。
网络请求，大部分网络请求都应该使用后台线程完成，如果你使用的是 AFNetworking、 SDWebImage 这些开源缓存库，那么切换到后台去请求网络资源的操作都已经默认完成。
本地数据读写和计算，当你需要从闪存中读取文件的时候，这些操作都应该使用GCD或者NSThread切换至后台线程中完成。
图像的处理，尽量使用合适的UIImage给予UIImageView使用，何谓合适？已经提前剪裁、缩放好的图片是最佳的，否则当UIImage赋予UIImageView.image的时候，iOS会有不必要的计算开销，而这些开销却是可以提前手动缓存起来的。
Layer 属性的谨慎选择，不合理的 Layer 特效（阴影、圆角）都会使流畅的滑动变成卡顿（非常重要）。
少用 UIView.backgroundColor = UIColor.clearColor()，透明的背景会加剧卡顿。
文字的渲染，你可能不知道，文字的渲染也是需要开销的。一般来说，文字渲染的开销非常小，甚至不能察觉到。但是，当一个UILabel被赋予大段富文本文字后，开销就会非常大。
图像的渲染，一个任何开发者、几乎所有库（包括SDWebImage）都无法解决的问题，图像在UIImageView中的渲染开销，并且图像的渲染只能在主线程中执行。
前五点都是可以在 UIView 的基础上解决的，如果前五点均优化完成后，仍然无法解决卡顿问题，则应该使用 AsyncDisplayKit。
AsyncDisplayKit 有对应的方案，着力解决文字渲染、图像渲染两个难题。
