我们项目单个页面比较复杂，内容比较多，对渲染的性能要求也比较高，之前也出现过几个性能问题，所以就去翻了下AsyncDisplayKit的源码，看看是否可以接入项目来优化性能。
AsyncDisplayKit的基本原理很简单，异步绘制图片，然后直接通过layer的contents直接传递给GPU绘制。的确这样永远不会卡在主线程，也不会卡在GPU的性能上，但是这么做也带来了一些不好的影响。
并没有实质性的优化性能。他只是把原本会阻塞主线程的内容，转移到了子线程，或者会阻塞GPU的内容，转移到了CPU中完成。这样做只是表面上帧率达到了很高，但是某些东西移到CPU后，反而不能更好的利用GPU，同时内存在CPU和GPU之间拷贝也会损耗部分性能，所以很多情况下是得不偿失的，界面会呈现空白一小段时间。
内存问题，在reuse view中，Node部分并不会发生重用，所以如果你在Node里面占用了很多内存的话，很容易导致内存上涨加快。
控制复杂，依赖程序员能力。AsyncDisplayKit很大程度是依靠图层的合并来做的，并且需要程序员自己来判断哪些需要合并，这就非常的依赖个人能力以及对AsyncDisplayKit的了解了。
在reuse view里面的表现并不好。在快速滑动时，确实不会有卡顿现象了，但是在快速的reuse过程中，绘制队列可能会进入一个产生小于消费的过程，这时候会导致界面的闪烁（新的库
Texture表现好一点）。同时这也会导致空白时间的延长。
所以在绝大部分场景，我们都不应该依赖AsyncDisplayKit来解决我们的卡顿问题。事实上，我们项目经过几次的优化已经拥有了非常良好的体验，也没有使用如此庞大的一个系统，可以说目前的设备性能能够满足我们几户所有的视觉要求。
但是AsyncDisplayKit也有我们可以借鉴的地方。
内存释放。AsyncDisplayKit专门创建了一个子线程去释放内存，这可以给我们一个思路，在需要大量释放非UI内存的时候，完全可以抛给子线程做，这样就不会导致一次性大量释放内存带来的卡顿。参考下Java可怜的GC，一旦发生GC，整个程序都被暂停了。
异步绘制。的确有部分内容需要我们去异步绘制，控制好各个视图的合并和更新重绘能够提升性能。
布局。AsyncDisplayKit嫌弃苹果的AutoLayout太慢，直接自己搞了一套Flex布局，来提升性能。同样我们也可以尝试减少AutoLayout给我们带来的性能损耗，在一些常用控件和复杂场景使用手动布局的方式。
或许我们可以在非常小的范围使用它，但是在我看来，几乎没有需要引入整个开源库的必要，几乎没有那么复杂的视图需要我们如此去绘制。
ps.
Texture 发展比较快，可以继续观察下他做了哪些优化。