AsyncDisplayKit介绍（一）原理和思路

UITableView/UICollectionView的优化一直是iOS应用性能优化重要的一块。即便是iOS10+iPhone7这样的最新软硬件配置，在系统的信息app中滚动，仔细观察的话仍然能感到必定的掉帧现象。对于UI要求苛刻的苹果居然在如此简单的tableView上没法达到60fps的帧率，可见优化滚动性能的背后并不简单。

为何？

理想状态下，iOS的帧率应该保持在60fps。然而不少状况下用户操做时会感受到掉帧或者『不跟手』。缘由可能有不少，这里只简单列举几个，网上能够找到许多相应分析：

1. CPU(主要是主线程)/GPU负担太重或者不均衡（诸如mask/cornerRadius/drawRect/opaque带来offscreen
   rendering/blending等等）。因为全部的UIView都是由CALayer来负责显示，所以对Core
   Animation的了解就变得尤其重要。这里推荐Nick Lockwood的Core Animation: Advanced
   Techniques一书，其中有对Core Animation的性能有着很是详尽的梳理和剖析。
2. Autolayout布局性能瓶颈，约束计算时间会随着数量呈指数级增加，而且必须在主线程执行。具体分析能够参考这篇文章：floriankugler.com/2013/04/22/…。这也是为什么ASDK抛弃了Autolayout而设计了本身的布局系统的重要缘由之一(github.com/facebook/As…)。Autolayout在单个View开发时能带来不少便利，而在一些须要高性能的场景下须要谨慎使用。
3. 尽管从iPhone4S(A5)开始CPU已经采用多核，然而对于大多数app来讲，多线程协做并无被充分利用。换句话说，在app卡顿（主线程所占用的核心满负荷）时，每每CPU的其余核心几乎无事可作。通常状况下，因为主线程承担了绝大部分的工做，若是能把主线程的任务转移一部给其余线程进行异步处理，就能够立刻享受到并发带来的性能提高。这应该也是AsyncDisplayKit得名的缘由之一。

UIKit的单线程设计也有必定的历史缘由。早在十年前iOS SDK刚问世的时候，mobile
SDK仍是一个很是新的概念，更没有移动多核CPU的存在，所以当时的重点是简单可靠，大多数API都没有支持相对复杂的异步操做。时至今日，若是要彻底重构UIKit使之支持异步绘制和布局，对于兼容已有海量的app，难度可想而知。在iOS10中虽然对UICollectionView/UITableView作了必定的预加载优化（WWDC2016
Session219），然而并无从根本上解决主线程布局和渲染的问题。

优化思路

咱们知道，当用户开始滚动或点击一个View，全部的事件都会被送到主线程等待处理。此时主线程可否抽出足够充裕的时间来处理变得极为重要，尤为是在连续操做（如UIGestureRecognizer）时，每次touchMoved事件处理都会占用主线程必定的时间（如新的UIImageView进入视图，主线程开始处理布局或者图片解码，而这些须要连续占用大量CPU时间）。若是一个操做耗时超过16ms(1000ms/60fps)，那就意味着下一帧没法及时获得处理，引发丢帧。

图片截取自wwdc2016 session219

如何能将主线程的压力尽量减轻成为优化的首要目标。

对列表滚动卡顿的经常使用解决方案有(推荐Yaoyuan的博客，有比较深刻的介绍:
blog.ibireme.com/2015/11/12/…)：

1. 针对Autolayout性能优化：提早计算并缓存cell的layout:
   github.com/forkingdog/…
2. 省去中间滑动过程当中的计算，直接计算目标区域cell:
   github.com/johnil/VVeb…
3. 弃用Autolayout，采用手动布局计算。这样虽然能够换来最高的性能，可是代价是编写和维护的不便，对于常常改动或者性能要求不高的场景并不必定值得。
4. 自行异步渲染Layer，如：github.com/ibireme/YYA…
5. iOS10列表的prefetch API，只是并无解决Autolayout的性能，同时也受到系统版本限制。

ASDK的基本思路：异步

对于通常的开发者，本身从新实现一整套异步布局和渲染机制是很是困难的。幸运的是，ASDK作到了。

AsyncDisplayKit(ASDK)是2012年由Facebook开始着手开发，并于2014年出品的高性能显示类库，主要做者是Scott
Goodson。Scott(github:
appleguy)曾经参与了多个iOS版本系统的开发，包括UIKit以及一些系统原生app，后来加入Facebook并参与了ASDK的开发并应用到Paper，所以该库有机会从相对底层的角度来进行一系列的优化。

如今最新的版本是2.0，除了拥有1.0系列版本核心的异步布局渲染功能，还增长了相似ComponentKit的基于flexbox的布局功能。源文件一共近300个，3万多行代码，是一个很是庞大而精密的显示和布局系统。使用上若是不考虑工程成本，彻底能够在必定程度上代替UIKit的大部分功能。同时因为和Instagram同处于FB家族，所以也迅速在最近的更新中加入了IGListKit的支持。

在Scott介绍ASDK的视频中，总结了一下三点占用大量CPU时间的『元凶』（虽然仍然可能有以上提到的其余缘由，但ASDK最主要集中于这三点进行优化）：

1. 渲染，对于大量图片，或者大量文字（尤为是CJK字符）混合在一块儿时。而文字区域的大小和布局，偏偏依赖着渲染的结果。ASDK尽量后台线程进行渲染，完成后再同步回主线程相应的UIView。
2. 布局。ASDK彻底弃用了Autolayout，另辟蹊径实现了本身的布局和缓存机制。关于布局的问题会在下一篇讲到。
3. 系统objects的建立与销毁。因为UIKit封装了CALayer以支持触摸等显示之外的操做，耗时也相应增长。而这些一样也须要在主线程上操做。ASDK基于Node的设计，突破了UIKit线程的限制。

既然同步就意味着阻塞，那就异步放到其余线程去作，在须要主线程时再同步回来。

咱们知道对于通常UIView和CALayer来讲，由于不是线程安全的，任何相关操做都须要在主线程进行。正如UIView能够弥补CALayer没法处理用户事件的不足同样，ASDK引入了Node的概念来解决UIView/CALayer只能在主线程上操做的限制（不禁让人想起『Abstract layer can solve many problems, except problem of having too many abstract layers.』）。

主要特色以下：

1. 每一个Node对应相应的UIView或者CALayer，从开发者的角度而言，只须要将初始化UIView的代码稍做修改，替换为建立ASDisplayNode便可。在不须要接受用户操做的Node上能够开启isLayerBacked，直接使用CALayer进一步下降开销。根据Scott的研究UIView的开销大约是CALayer的5倍。
2. Node默认是异步布局/渲染，只有在须要将frame/contents等同步到UIView上才会回到主线程，使其空出更多的时间处理其余事件。
3. ASDK只有在认为须要的时候才会异步地为Node加载相应的View，所以建立Node的开销变得很是低。同时Node是线程安全的，能够在任意queue上建立和设置属性。
4. ASDK不只有与UIView对应的大部分控件（如ASButtonNode、ASTextNode、ASImageNode、ASTableNode等等），同时也bridge了大多数UIView的方法和属性，能够很是方便的操做frame/backgroundColor/addSubnode等，所以通常状况下只要对Node进行操做，ASDK就会在适当的时候同步到其View。若是须要的话，当相应的View加载以后（或访问node.view手动触发加载），也能够经过node.view的方式直接访问，回到咱们熟悉的UIKit。
5. 当实现自定义View的时候，ASDisplayNode提供了一个初始化方法initWithViewBlock/initWithLayerBlock，就能够将任意UIView/CALayer用Node包裹起来（被包裹的view可使用autolayout），从而与ASDK的其余组件相结合。虽然这样建立的Node与通常view在布局和渲染上的差别不大，可是因为Node管理着什么时候何地加载view，咱们仍然能获得必定的性能提高。

举例来讲，当使用UIKit建立一个UIImageView：

_imageView = [[UIImageView alloc] init];
_imageView.image = [UIImage imageNamed:@"hello"];
_imageView.frame = CGRectMake(10.0f, 10.0f, 40.0f, 40.0f);
[self.view addSubview:_imageView];复制代码

使用ASDK后只要稍加改动：

_imageNode = [[ASImageNode alloc] init];
_imageNode.image = [UIImage imageNamed:@"hello"];
_imageNode.frame = CGRectMake(10.0f, 10.0f, 40.0f, 40.0f);
[self.view addSubview:_imageNode.view];复制代码

虽然只是简单的把View替换成了Node，然而和UIImageView不一样的是，此时ASDK已经在悄悄使用另外一个线程进行图片解码，从而大大下降新的用户操做到来时主线程被阻塞的几率，使每个回调都能获得及时的处理。实践中将会有更加复杂的状况，有兴趣的话能够参考项目中的Example目录，有20多个不一样场景下的示例项目。

一些细节

1. 在ASDisplayNode.h中有至关多的注释，其中displaysAsynchronously属性大体描述了异步渲染的步骤：

• Asynchronous rendering proceeds as follows:

• When the view is initially added to the hierarchy, it has -needsDisplay true.

• After layout, Core Animation will call -display on the _ASDisplayLayer

• -display enqueues a rendering operation on the displayQueue

• When the render block executes, it calls the delegate display method
  (-drawRect:… or -display)

• The delegate provides contents via this method and an operation is added to
  the asyncdisplaykit_async_transaction

• Once all rendering is complete for the current
  asyncdisplaykit_async_transaction,

• the completion for the block sets the contents on all of the layers in the
  same frame

从中咱们能够看到，全部异步渲染操做是先被同一加入asyncdisplaykit_async_transaction，而后一块儿提交的。在_ASAsyncTransactionGroup.m源文件中，能够看到ASDK是在主线程的runloop（关于runloop能够参考Yaoyuan的文章和sunny的视频）中注册了observer，在kCFRunLoopBeforeWaiting和kCFRunLoopExit两个activity的回调中将以前异步完成的工做同步到主线程中去。

1. ASDisplayNode还有一个属性shouldRasterizeDescendants。

/**

• @abstract Whether to draw all descendant nodes’ layers/views into this node’s
  layer/view’s backing store.

• @discussion

• When set to YES, causes all descendant nodes’ layers/views to be drawn
  directly into this node’s layer/view’s backing

• store. Defaults to NO.

• If a node’s descendants are static (never animated or never change attributes
  after creation) then that node is a

• good candidate for rasterization. Rasterizing descendants has two main
  benefits:

• 1) Backing stores for descendant layers are not created. Instead the layers
  are drawn directly into the rasterized

• container. This can save a great deal of memory.

• 2) Since the entire subtree is drawn into one backing store, compositing and
  blending are eliminated in that subtree

• which can help improve animation/scrolling/etc performance.

• Rasterization does not currently support descendants with transform,
  sublayerTransform, or alpha. Those properties

• will be ignored when rasterizing descendants.

• Note: this has nothing to do with -[CALayer shouldRasterize], which doesn’t
  work with ASDisplayNode’s asynchronous

• rendering model.

*/

当咱们不须要分别关注单个CALayer，也不须要对他们进行操做时，就能够将全部的子node都合并到父node的backing
store一并绘制，从而达到节省内存和提升性能的目的。

注意事项

1. ASDK不支持Storyboard和Autolayout，可是能够与使用Autolayout的view兼容共存。一样React native和Component
   Kit等其余Facebook出品的iOS库也不支持Storyboard。
2. 因为Node的异步渲染，颇有可能在其View到达屏幕以后，内容仍然在渲染过程当中。此时须要额外考虑每一个Node的placeholder状态，使用户不至于看到一片空白。
3. 在使用ASDisplayNode初始化initWithViewBlock时，因为Node须要在适当的时候调用该block来建立view，所以并不会当即调用block（block可能capture其余变量，例如self），而是存在一个ivar当中。若是该view始终没被建立，而此时拥有该node的父元素被销毁，容易形成retain
   cycle致使memory leak。

Best Practice

因为ASDK的基本理念是在须要建立UIView时替换成对应的Node来获取性能提高，所以对于现有代码改动较大，侵入性较高，同时因为大量本来熟悉的操做变成了异步的，对于一个团队来讲学习曲线也较为陡峭。

从咱们在实际项目中的经验，结合Scott的建议来看，不须要也不可能将全部UIView都替换成其Node版本。将注意力集中在可能形成主线程阻塞的地方，如tableView/collectionView、复杂布局的View、使用连续手势的操做等等。找到合适的切入点将一部分性能需求较高的代码替换成ASDK，会是一个较好的选择。

对于优化之后的效果，能够尝试咱们的应用：即刻，其中消息盒子部分应用了ASDK进行了大量调优工做，从而在拥有大量图片和gif/不定长度文字共存的状况下，仍然能达到60fps的流畅体验。在咱们将近两年的实践中，尽管也碰到过一些坑，可是带来的提高也是很是明显的，使在构建更复杂的界面同时保持高性能成为可能。

推荐阅读

AsyncDisplayKit Getting Started

AsyncDisplayKit Tutorial: Node
Hierarchies

NSLondon — Scott Goodson — Behind
AsyncDisplayKit

MCE 2015 — Scott Goodson — Effortless Responsiveness with
AsyncDisplayKit

AsyncDisplayKit 2.0: Intelligent User Interfaces — NSSpain
2015

PS: 即刻正在招聘，若是你是一个追求极致又富有探索精神的iOS工程师，同时也热爱咱们的产品，那么欢迎加入咱们，一块儿参加WWDC（公司cover所有费用），持续打造更棒的即刻！联系咱们：hr@ruguoapp.com