即刻技术团队

2,396 人关注

iOS 开发

{"database":{"Post":{"25371361":{"title":"AsyncDisplayKit介绍（一）原理和思路","author":"ji-ke-ji-shu-tuan-dui-36","content":"\u003Cul\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F25371361\"\u003EAsyncDisplayKit系列之一：原理和思路\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F26283742\"\u003EAsyncDisplayKit系列之二：布局系统\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F29537687\"\u003EAsyncDisplayKit系列之三：深度优化列表性能\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E对于iOS开发而言，UITableView\u002FUICollectionView的优化一直是iOS应用性能优化重要的一块。即使是iOS10+iPhone7这样的最新软硬件配置，在系统的信息app中滚动，仔细观察的话仍然能感到一定的掉帧现象。对于UI要求苛刻的苹果，竟然在如此简单的tableView上无法达到60fps的帧率，可见优化滚动性能的背后并不简单。\u003C\u002Fp\u003E\u003Ch2\u003E为什么？\u003C\u002Fh2\u003E\u003Cp\u003E理想状态下，iOS的帧率应该保持在60fps。然而很多情况下用户操作时会感觉到掉帧或者『不跟手』。原因可能有很多，这里只简单列举几个，网上可以找到许多相应分析：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E\u003Cb\u003ECPU(主要是主线程)\u002FGPU负担过重或者不均衡\u003C\u002Fb\u003E（诸如mask\u002FcornerRadius\u002FdrawRect\u002Fopaque带来offscreen rendering\u002Fblending等等）。由于所有的UIView都是由CALayer来负责显示，因此对Core Animation的了解就变得尤为重要。这里推荐Nick Lockwood的*Core Animation: Advanced Techniques*一书，其中有对Core Animation的性能有着非常详尽的梳理和剖析。\u003C\u002Fli\u003E\u003Cli\u003E\u003Cb\u003EAutolayout布局性能瓶颈\u003C\u002Fb\u003E，约束计算时间会随着数量呈指数级增长，并且必须在主线程执行。具体分析可以参考这篇文章：\u003Ca href=\"http:\u002F\u002Ffloriankugler.com\u002F2013\u002F04\u002F22\u002Fauto-layout-performance-on-ios\u002F\"\u003EAuto Layout Performance on iOS\u003C\u002Fa\u003E。这也是为何ASDK抛弃了Autolayout而设计了自己的布局系统的重要原因之一(\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffacebook\u002FAsyncDisplayKit\u002Fissues\u002F196\"\u003Eauto layout · Issue #196 · facebook\u002FAsyncDisplayKit · GitHub\u003C\u002Fa\u003E)。Autolayout在单个View开发时能带来很多便利，而在一些需要高性能的场景下需要谨慎使用。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E尽管从iPhone4S(A5)开始CPU已经采用多核，然而\u003Cb\u003E对于大多数app来说，多线程协作并没有被充分利用。\u003C\u002Fb\u003E换句话说，在app卡顿（主线程所占用的核心满负荷）时，往往CPU的其他核心几乎无事可做。一般情况下，由于主线程承担了绝大部分的工作，如果能把主线程的任务转移一部给其他线程进行异步处理，就可以马上享受到并发带来的性能提升。这应该也是AsyncDisplayKit得名的原因之一。\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003EUIKit的单线程设计也有一定的历史原因。早在十年前iOS SDK刚问世的时候，mobile SDK还是一个非常新的概念，更没有移动多核CPU的存在，因此当时的重点是简单可靠，大多数API都没有支持相对复杂的异步操作。时至今日，如果要完全重构UIKit使之支持异步绘制和布局，对于兼容已有海量的app，难度可想而知。在iOS10中虽然对UICollectionView\u002FUITableView做了一定的预加载优化（WWDC2016 Session219），然而并没有从根本上解决主线程布局和渲染的问题。\u003C\u002Fp\u003E\u003Ch2\u003E优化思路\u003C\u002Fh2\u003E\u003Cp\u003E我们知道，当用户开始滚动或点击一个View，所有的事件都会被送到主线程等待处理。此时主线程能否抽出足够充裕的时间来处理变得极为重要，尤其是在连续操作（如UIGestureRecognizer）时，每次touchMoved事件处理都会占用主线程一定的时间（如新的UIImageView进入视图，主线程开始处理布局或者图片解码，而这些需要连续占用大量CPU时间）。如果一个操作耗时超过16ms(1000ms\u002F60fps)，那就意味着下一帧无法及时得到处理，引起丢帧。\u003C\u002Fp\u003E\u003Cimg src=\"v2-862d7be56d8270fd772e8f983f9cd51b.png\" data-rawwidth=\"1542\" data-rawheight=\"852\"\u003E\u003Cp\u003E（图片截取自WWDC2016 session219）\u003C\u002Fp\u003E\u003Cp\u003E因此如何能将主线程的压力尽可能减轻成为优化的首要目标。\u003C\u002Fp\u003E\u003Cp\u003E对列表滚动卡顿的常用解决方案有：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E针对Autolayout性能优化：提前计算并缓存cell的layout: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fforkingdog\u002FUITableView-FDTemplateLayoutCell\"\u003Eforkingdog\u002FUITableView-FDTemplateLayoutCell: Template auto layout cell for automatically UITableViewCell height calculating\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E省去中间滑动过程中的计算，直接计算目标区域cell: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fjohnil\u002FVVeboTableViewDemo\"\u003EVVebo剥离的TableView绘制\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E弃用Autolayout，采用手动布局计算。这样虽然可以换来最高的性能，但是代价是编写和维护的不便，对于经常改动或者性能要求不高的场景并不一定值得。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E自行异步渲染Layer，如：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fibireme\u002FYYAsyncLayer\"\u003Eibireme\u002FYYAsyncLayer: iOS utility classes for asynchronous rendering and display.\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003EiOS10列表的prefetch API，只是并没有解决Autolayout的性能问题，同时也受到系统版本限制。\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E推荐Yaoyuan的博客，也有比较深入的介绍: \u003Ca href=\"http:\u002F\u002Fblog.ibireme.com\u002F2015\u002F11\u002F12\u002Fsmooth_user_interfaces_for_ios\u002F\"\u003EiOS 保持界面流畅的技巧 | Garan no dou\u003C\u002Fa\u003E \u003C\u002Fp\u003E\u003Ch2\u003EASDK的基本思路：异步\u003C\u002Fh2\u003E\u003Cp\u003E对于一般的开发者，自己重新实现一整套异步布局和渲染机制是非常困难的。幸运的是，ASDK做到了。\u003C\u002Fp\u003E\u003Cp\u003EAsyncDisplayKit(ASDK)是2012年由Facebook开始着手开发，并于2014年出品的高性能显示类库，主要作者是Scott Goodson。Scott(github: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fappleguy\"\u003Eappleguy · GitHub\u003C\u002Fa\u003E)曾经参与了多个iOS版本系统的开发，包括UIKit以及一些系统原生app，后来加入Facebook并参与了ASDK的开发并应用到Paper，因此该库有机会从相对底层的角度来进行一系列的优化。\u003C\u002Fp\u003E\u003Cp\u003E现在最新的版本是2.0，除了拥有1.0系列版本核心的异步布局渲染功能，还增加了类似ComponentKit的基于flexbox的布局功能。源文件一共近300个，3万多行代码，是一个非常庞大而精密的显示和布局系统。使用上\u003Cb\u003E如果不考虑工程成本，完全可以在一定程度上代替UIKit的大部分功能。\u003C\u002Fb\u003E同时由于和Instagram同处于FB家族，因此也迅速在最近的更新中加入了IGListKit的支持。\u003C\u002Fp\u003E\u003Cp\u003E在Scott介绍ASDK的视频中，总结了一下三点占用大量CPU时间的『元凶』（虽然仍然可能有以上提到的其他原因，但ASDK最主要集中于这三点进行优化）：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E\u003Cb\u003E渲染\u003C\u002Fb\u003E，对于大量图片，或者大量文字（尤其是CJK字符）混合在一起时。而文字区域的大小和布局，恰恰依赖着渲染的结果。ASDK尽可能后台线程进行渲染，完成后再同步回主线程相应的UIView。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E\u003Cb\u003E布局\u003C\u002Fb\u003E。ASDK完全弃用了Autolayout，另辟蹊径实现了自己的布局和缓存机制。关于布局的问题会在下一篇讲到。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E系统objects的\u003Cb\u003E创建与销毁\u003C\u002Fb\u003E。由于UIKit封装了CALayer以支持触摸等显示以外的操作，耗时也相应增加。而这些同样也需要在主线程上操作。ASDK基于Node的设计，突破了UIKit线程的限制。\u003Cbr\u003E\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E既然同步就意味着阻塞，那就异步放到其他线程去做，在需要主线程时再同步回来。\u003C\u002Fp\u003E\u003Cimg src=\"v2-56b49c627fd8693a8cb990044c360ff9.png\" data-rawwidth=\"1370\" data-rawheight=\"914\"\u003E\u003Cp\u003E我们知道对于一般UIView和CALayer来说，因为他们不是线程安全的，任何相关操作都需要在主线程进行。正如UIView可以弥补CALayer无法处理用户事件的不足一样，ASDK引入了Node的概念来解决UIView\u002FCALayer只能在主线程上操作的限制（不由让人想起『Abstract layer can solve many problems, except problem of having too many abstract layers.』）。\u003C\u002Fp\u003E\u003Ch2\u003EASDisplayNode主要特点：\u003C\u002Fh2\u003E\u003Col\u003E\u003Cli\u003E每个Node对应相应的UIView或者CALayer，从开发者的角度而言，只需要将初始化UIView的代码稍作修改，替换为创建ASDisplayNode即可。在不需要接受用户操作的Node上可以开启isLayerBacked，直接使用CALayer进一步降低开销。根据Scott的研究UIView的开销大约是CALayer的5倍。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003ENode\u003Cb\u003E默认是异步布局\u002F渲染\u003C\u002Fb\u003E，只有在需要将frame\u002Fcontents等同步到UIView上才会回到主线程，使其空出更多的时间处理其他事件。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003EASDK只有在认为需要的时候才会异步地为Node加载相应的View，因此创建Node的开销变得非常低。同时Node是\u003Cb\u003E线程安全\u003C\u002Fb\u003E的，可以在任意queue上创建和设置属性。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003EASDK不仅有与UIView对应的大部分控件（如ASButtonNode、ASTextNode、ASImageNode、ASTableNode等等），同时也bridge了大多数UIView的方法和属性，可以非常方便的操作frame\u002FbackgroundColor\u002FaddSubnode等，因此一般情况下只要对Node进行操作，ASDK就会在适当的时候同步到其View。如果需要的话，当相应的View加载之后（或访问node.view手动触发加载），也可以通过node.view的方式直接访问，回到我们熟悉的UIKit。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E当实现自定义View的时候，ASDisplayNode提供了一个初始化方法initWithViewBlock\u002FinitWithLayerBlock，就可以将任意UIView\u002FCALayer用Node包裹起来（被包裹的view可以使用autolayout），从而与ASDK的其他组件相结合。虽然这样创建的Node与一般view在布局和渲染上的差异不大，但是由于Node管理着何时何地加载view，我们仍然能得到一定的性能提升。\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E举例来说，当使用UIKit创建一个UIImageView：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E _imageView = [[UIImageView alloc] init];\n    _imageView.image = [UIImage imageNamed:@\"hello\"];\n    _imageView.frame = CGRectMake(10.0f, 10.0f, 40.0f, 40.0f);\n    [self.view addSubview:_imageView];\u003C\u002Fcode\u003E\u003Cp\u003E使用ASDK后只要稍加改动：\u003C\u002Fp\u003E\u003Ccode lang=\"objective-c\"\u003E _imageNode = [[ASImageNode alloc] init];\n    _imageNode.image = [UIImage imageNamed:@\"hello\"];\n    _imageNode.frame = CGRectMake(10.0f, 10.0f, 40.0f, 40.0f);\n    [self.view addSubview:_imageNode.view];\u003C\u002Fcode\u003E\u003Cp\u003E虽然只是简单的把View替换成了Node，然而和UIImageView不同的是，此时ASDK已经在悄悄使用另一个线程进行图片解码，从而大大降低新的用户操作到来时主线程被阻塞的概率，使每一个回调都能得到及时的处理。实践中将会有更加复杂的情况，有兴趣的话可以参考项目中的Example目录，有20多个不同场景下的示例项目。\u003C\u002Fp\u003E\u003Ch2\u003E一些细节\u003C\u002Fh2\u003E\u003Col\u003E\u003Cli\u003E在ASDisplayNode.h中有相当多的注释，其中displaysAsynchronously属性大致描述了异步渲染的步骤：\u003Cbr\u003E\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E&gt; * Asynchronous rendering proceeds as follows:\n&gt; * When the view is initially added to the hierarchy, it has -needsDisplay true.\n&gt; * After layout, Core Animation will call -display on the _ASDisplayLayer\n&gt; * -display enqueues a rendering operation on the displayQueue\n&gt; * When the render block executes, it calls the delegate display method\n&gt; (-drawRect:… or -display)\n&gt; * The delegate provides contents via this method and an operation is added to\n&gt; the asyncdisplaykit_async_transaction\n&gt; * Once all rendering is complete for the current\n&gt; asyncdisplaykit_async_transaction,\n&gt; * the completion for the block sets the contents on all of the layers in the\n&gt; same frame\u003C\u002Fcode\u003E\u003Cp\u003E从中我们可以看到，所有异步渲染操作是先被同一加入asyncdisplaykit_async_transaction，然后一起提交的。在_ASAsyncTransactionGroup.m源文件中，可以看到ASDK是在主线程的runloop（关于runloop可以参考Yaoyuan的 \u003Ca href=\"http:\u002F\u002Fblog.ibireme.com\u002F2015\u002F05\u002F18\u002Frunloop\u002F\"\u003E深入理解RunLoop | Garan no dou\u003C\u002Fa\u003E和sunny的 \u003Ca href=\"http:\u002F\u002Fv.youku.com\u002Fv_show\u002Fid_XODgxODkzODI0.html\"\u003EiOS线下分享《RunLoop》by 孙源@sunnyxx\u003C\u002Fa\u003E）中注册了observer，在kCFRunLoopBeforeWaiting和kCFRunLoopExit两个activity的回调中将之前异步完成的工作同步到主线程中去。\u003C\u002Fp\u003E\u003Cp\u003E2. ASDisplayNode还有一个属性shouldRasterizeDescendants。\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E&gt; \u002F**\n&gt; * @abstract Whether to draw all descendant nodes’ layers\u002Fviews into this node’s\n&gt; layer\u002Fview’s backing store.\n&gt; * @discussion\n&gt; * When set to YES, causes all descendant nodes’ layers\u002Fviews to be drawn\n&gt; directly into this node’s layer\u002Fview’s backing\n&gt; * store. Defaults to NO.\n&gt; * If a node’s descendants are static (never animated or never change attributes\n&gt; after creation) then that node is a\n&gt; * good candidate for rasterization. Rasterizing descendants has two main\n&gt; benefits:\n&gt; * 1) Backing stores for descendant layers are not created. Instead the layers\n&gt; are drawn directly into the rasterized\n&gt; * container. This can save a great deal of memory.\n&gt; * 2) Since the entire subtree is drawn into one backing store, compositing and\n&gt; blending are eliminated in that subtree\n&gt; * which can help improve animation\u002Fscrolling\u002Fetc performance.\n&gt; * Rasterization does not currently support descendants with transform,\n&gt; sublayerTransform, or alpha. Those properties\n&gt; * will be ignored when rasterizing descendants.\n&gt; * Note: this has nothing to do with -[CALayer shouldRasterize], which doesn’t\n&gt; work with ASDisplayNode’s asynchronous\n&gt; * rendering model.\n&gt; *\u002F\u003C\u002Fcode\u003E\u003Cp\u003E当我们不需要分别关注单个CALayer，也不需要对他们进行操作时，就可以将所有的子node都合并到父node的backing store一并绘制，从而达到节省内存和提高性能的目的。 \u003C\u002Fp\u003E\u003Ch2\u003E注意事项\u003C\u002Fh2\u003E\u003Col\u003E\u003Cli\u003EASDK不支持Storyboard和Autolayout，但是可以与使用Autolayout的view兼容共存。同样React native和Component Kit等其他Facebook出品的iOS库也不支持Storyboard。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E由于Node的异步渲染，很有可能在其View到达屏幕之后，内容仍然在渲染过程中。此时需要额外考虑每个Node的placeholder状态，使用户不至于看到一片空白。\u003Cbr\u003E\u003C\u002Fli\u003E\u003Cli\u003E在使用ASDisplayNode初始化initWithViewBlock时，由于Node需要在适当的时候调用该block来创建view，因此并不会立即调用block（block可能capture其他变量，例如self），而是存在一个ivar当中。如果该view始终没被创建，而此时拥有该node的父元素被销毁，容易造成retain cycle导致memory leak。\u003Cbr\u003E\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Ch2\u003EBest Practice\u003C\u002Fh2\u003E\u003Cp\u003E由于ASDK的基本理念是在需要创建UIView时替换成对应的Node来获取性能提升，因此对于现有代码改动较大，侵入性较高，同时由于大量原本熟悉的操作变成了异步的，对于一个团队来说学习曲线也较为陡峭。\u003C\u002Fp\u003E\u003Cp\u003E从我们在实际项目中的经验，结合Scott的建议来看，不需要也不可能将所有UIView都替换成其Node版本。将注意力集中在可能造成主线程阻塞的地方，如tableView\u002FcollectionView、复杂布局的View、使用连续手势的操作等等。找到合适的切入点将一部分性能需求较高的代码替换成ASDK，会是一个较好的选择。\u003C\u002Fp\u003E\u003Cp\u003E对于优化以后的效果，可以尝试我们的应用：\u003Ca href=\"http:\u002F\u002Fjike.ruguoapp.com\u002F\"\u003E即刻 - 期待每一次推送\u003C\u002Fa\u003E，其中消息盒子部分应用了ASDK进行了大量调优工作，从而在拥有大量图片和gif\u002F不定长度文字共存的情况下，仍然能达到60fps的流畅体验。在我们将近两年的实践中，尽管也碰到过一些坑，但是带来的提升也是非常明显的，使在构建更复杂的界面同时保持高性能成为可能。\u003C\u002Fp\u003E\u003Ch2\u003E推荐阅读\u003C\u002Fh2\u003E\u003Cp\u003E\u003Ca href=\"http:\u002F\u002Fasyncdisplaykit.org\u002Fguide\u002F\"\u003EAsyncDisplayKit Getting Started\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"http:\u002F\u002Fwww.raywenderlich.com\u002F107310\u002Fasyncdisplaykit-tutorial-node-hierarchies\"\u003EAsyncDisplayKit Tutorial: Node Hierarchies\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=-IPMNWqA638\"\u003ENSLondon — Scott Goodson — Behind  AsyncDisplayKit\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=ZPL4Nse76oY\"\u003EMCE 2015 — Scott Goodson — Effortless Responsiveness with  AsyncDisplayKit\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=RY_X7l1g79Q\"\u003EAsyncDisplayKit 2.0: Intelligent User Interfaces — NSSpain  2015\u003C\u002Fa\u003E\u003C\u002Fp\u003E","updated":new Date("2017-02-22T09:00:40.000Z"),"canComment":false,"commentPermission":"anyone","commentCount":6,"likeCount":81,"state":"published","isLiked":false,"slug":"25371361","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-02-22T17:00:40+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F25371361\u002Fcomments"},"url":"\u002Fp\u002F25371361","titleImage":"https:\u002F\u002Fpic1.zhimg.com\u002Fv2-851252a02130f911ef00a2ead1cf90d1_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F25371361","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":6,"likesCount":81},"26283742":{"title":"AsyncDisplayKit介绍（二）布局系统","author":"ji-ke-ji-shu-tuan-dui-36","content":"\u003Cul\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F25371361\"\u003EAsyncDisplayKit系列之一：原理和思路\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F26283742\"\u003EAsyncDisplayKit系列之二：布局系统\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F29537687\"\u003EAsyncDisplayKit系列之三：深度优化列表性能\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E在上一篇介绍中我们曾经讨论过Autolayout的性能问题。然而在iOS中，除了Autolayout，能选择的只有autoresizingMask，或者纯手动布局。在写了无数view.frame = CGRect(…)之后，我们才发现，一个在HTML中非常简单的流式布局，到iOS9才有相应的UIStackView予以支持（如果用UICollectionView则需要将view包装成CollectionViewCell）。尽管你可以使用\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fforkingdog\u002FFDStackView\"\u003EFDStackView\u003C\u002Fa\u003E将系统要求降低到iOS6，对于复杂的布局仍然需要多层View嵌套来实现——其实对于实现stack布局的时候，并不需要一个真正的UIView实例来承载所有的元素，而只是需要它的布局功能而已（就好比UICollectionViewFlowLayout，只负责控制若干个元素的布局规则而不真正负责布局）。\u003C\u002Fp\u003E\u003Cp\u003E做过Web开发的朋友已经习惯了高效的css布局：声明式、易于调试，boxModel结构化清晰等等优点，特别是使用自动化工具之后，只需要保存文件就可以立即在浏览器中看到更新后的效果；而这一切在iOS中就变得遥不可及：命令式赋值、编译后（Objc速度尚可，而swift编译速度较慢）才能看到结果、Autolayout闭源、视图调试复杂、xcode经常crash等等。如果要实现一个高性能的tableView\u002FcollectionView，手写布局几乎是唯一选择。\u003C\u002Fp\u003E\u003Ch2\u003ELayout的本质\u003C\u002Fh2\u003E\u003Cp\u003E在决定使用哪种布局方式之前，先看看设计师是怎么思考布局的：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E每个元素的大小（size）\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E兄弟元素之间的位置关系：对齐（alignment）和间距（spacing）；父子元素之间的容纳关系：子元素的边距（insets）\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E设计师确定的，是一个布局规则。\u003C\u002Fp\u003E\u003Cp\u003E设计稿到了工程师这边以后，我们绝大多数时间都在做以下两件事：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E确定UIView自身的大小（覆盖sizeThatFits方法），与parent view无关\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E根据规则，将subview放在父parent内的指定位置（对应layoutSubviews），由parent view决定\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E这样自底向上层层递归，最终完成整个屏幕内所有子元素的布局。工程师完成的，是一个基于布局规则的具体实现，关注的对象是单个view或者是两个相邻view之间的关系。\u003C\u002Fp\u003E\u003Cp\u003E也就是说，\u003Cb\u003E手动布局或者通过约束（Autolayout）其实是在『实现』布局规则，而不是『声明』布局规则\u003C\u002Fb\u003E。抽象层级下降了，随之而来的是多到令人头疼的frame、size、origin计算，可读性、可维护性都非常差。那能不能提高抽象层级，用一个数据结构来表示布局规则，从而摆脱繁重又容易出错的数值计算，让布局系统根据规则自动地、异步地计算呢？\u003C\u002Fp\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Ch2\u003EAsyncDisplayKit的三种布局方式\u003C\u002Fh2\u003E\u003Cp\u003E\u003Cb\u003E1. 手动布局\u003C\u002Fb\u003E\u003C\u002Fp\u003E\u003Cp\u003E这是最基础的一种布局方式。在ASDK中的手动布局与UIKit的手动布局类似，只是方法名从sizeThatFits变成了calculatedSizeThatFits，layoutSubviews方法变成了layout方法。略微不同的是ASDK会将布局结果预先在后台线程进行计算，并缓存下来以提升性能，这点对于tableView滚动流畅性有非常大的帮助。\u003C\u002Fp\u003E\u003Cp\u003E然而，跟普通手动布局类似，最大的缺点是可读性和可维护性差。由于自身的大小常常和子元素的布局相关联，这两个方法中的代码容易重复；同时由于布局针对自身subView，很难将其代码与其他View进行复用。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cb\u003E2. Unified layout\u003C\u002Fb\u003E\u003C\u002Fp\u003E\u003Cp\u003E这也是在ASDK中新出现的概念。先介绍一下ASLayout：\u003C\u002Fp\u003E\u003Cimg src=\"v2-fe3cd3d79a64071512f8fa6d6c9ccc4a.png\" data-rawwidth=\"1340\" data-rawheight=\"1000\"\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E一个ASLayout对象包含以下元素：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E它所代表的布局元素\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E元素的尺寸\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E元素的位置\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E它所包含的sublayouts\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E可以看出，当一个node具备了确定的ASLayout对象时，它自身的布局也就随之确定了。为了生成ASLayout，ASDisplayNode为subclass提供了如下覆盖点：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E- (ASLayout *)calculateLayoutThatFits:(ASSizeRange)constrainedSize\n\u003C\u002Fcode\u003E\u003Cp\u003E只要Node能够计算出自己的ASLayout，父元素就可以完成对其的布局。这种方法将sizeThatFits和layoutSubviews结合在一起，一定程度上避免了相似代码的尴尬，但是计算上仍然是手动布局，不够简便。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cb\u003E3. Automatic Layout(不是系统的Autolayout)\u003C\u002Fb\u003E\u003C\u002Fp\u003E\u003Cp\u003E有了ASLayout这一层抽象，如何通过声明规则而不是通过计算得到它，是问题的核心。\u003C\u002Fp\u003E\u003Cp\u003EFacebook将React的概念延伸到native，同时也把声明式的语法带到了iOS，产生了\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffacebook\u002Fcomponentkit\"\u003EComponentKit\u003C\u002Fa\u003E框架。早在ASDK1.0的年代大家纷纷表示希望能将其与ComponentKit相融合，幸运的是，在2.0版本中实现了。我选用了作者Scott Goodson在NSSpain的\u003Ca href=\"https:\u002F\u002Fgithub-cloud.s3.amazonaws.com\u002Fassets\u002Frepositories\u002F21265042\u002F15788?X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ\u002F20160204\u002Fus-east-1\u002Fs3\u002Faws4_request&amp;X-Amz-Date=20160204T100616Z&amp;X-Amz-Expires=300&amp;X-Amz-Signature=50d624c30b9b31a059b1bf299a615bd72418c420e35d3730cc0017e0b3bfcf73&amp;X-Amz-SignedHeaders=host&amp;actor_id=3334458&amp;response-content-disposition=attachment;filename=AsyncDisplayKit.2.0.Beta.-.October.2015.Slides.pdf&amp;response-content-type=application\u002Fpdf\"\u003E演讲pdf\u003C\u002Fa\u003E作为插图，方便大家了解新的布局系统。\u003C\u002Fp\u003E\u003Cp\u003EAutomatic Layout是ASDK最推荐也是最为高效的布局方式。它引入了ASLayoutSpec的概念，来描述抽象的布局规则（并不需要创建对应node或者view来装载子元素）。一旦确定布局规则，它就能依照规则对其负责的子元素进行布局计算，得到每个布局元素的ASLayout对象。\u003C\u002Fp\u003E\u003Cp\u003E我们先来看一下它们之间的关系：\u003C\u002Fp\u003E\u003Cimg src=\"v2-7cc4780a65e481894d1563e3808d2843.png\" data-rawwidth=\"1336\" data-rawheight=\"1001\"\u003E\u003Cp\u003E可以看到ASLayoutSpec和ASDisplayNode都实现了ASLayoutable接口，因此他们都具备生成ASLayout的能力，这样就能唯一确定自身的大小。\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E对于以上提到的Unified布局，当我们实现了calculateLayoutThatFits，ASDK会在布局过程中调用measureWithSizeRange(如果没有缓存过再调用calculateLayoutThatFits)来算出ASLayout。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E如果ASDisplayNode选择实现layoutSpecThatFits，由更为抽象的ASLayoutSpec来负责指定布局规则，由于ASLayoutSpec也实现了ASLayoutable接口，同样也可以通过调用measureWithSizeRange来获得ASLayout。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E由于\u003Cb\u003EASLayoutSpec只负责指定布局规则，而不关心其布局的ASLayoutable具体是Node还是其他ASLayoutSpec\u003C\u002Fb\u003E，我们可以轻松地将ASLayoutSpec生成逻辑独立出来，达到复用的目的。\u003C\u002Fp\u003E\u003Ch2\u003E挑大梁的ASStackLayoutSpec\u003C\u002Fh2\u003E\u003Cp\u003EASLayoutSpec主要有以下几种：\u003C\u002Fp\u003E\u003Cimg src=\"v2-0c71f153552795c642c6dcfe729a0fd2.png\" data-rawwidth=\"1336\" data-rawheight=\"988\"\u003E\u003Cp\u003E通过它们的命名就可以了解其大致作用。其中用途最广泛的无疑是ASStackLayoutSpec，与UIStackView有异曲同工之妙。\u003C\u002Fp\u003E\u003Cp\u003EASStackLayoutSpec大量借鉴了CSS的flexbox概念，写过Web代码的同学应该能一眼认出许多熟悉的属性：justifyContent\u002FflexDirection\u002FalignSelf\u002FalignItems\u002FflexBasis等等。不熟悉的朋友也可以通过一个有趣的游戏来学习flexbox：\u003Ca href=\"http:\u002F\u002Fflexboxfroggy.com\u002F\"\u003EFlexbox Froggy\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Ch2\u003E示例\u003C\u002Fh2\u003E\u003Cp\u003E(图中的Huy Nguyen也是ASDK布局的主要贡献者之一)\u003C\u002Fp\u003E\u003Cimg src=\"v2-50e16b5af99156b2e6882648941512c4.png\" data-rawwidth=\"1350\" data-rawheight=\"1003\"\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E图中左边是一个imageNode，右边是由两个textNode组成的一个vertical\u003C\u002Fp\u003E\u003Cp\u003Estack，再和imageNode组合成一个横向的stack，最后加上边缘inset完成整个布局。\u003C\u002Fp\u003E\u003Cp\u003E事实上，与css类似，绝大多数的布局都可以通过stack和inset的组合来完成；而和UIStackView不同的是，layout spec只是一个存在于内存之中的数据结构，并不需要额外创建view容器来承载子元素，大大节约了复杂布局带来的开销；同时因为它的轻量级和独立性，因此能够将布局规则放到后台线程独立计算，并缓存在node之中，对于大量tableView\u002FcollectionView的CellNode快速布局有相当大的帮助。\u003C\u002Fp\u003E\u003Cp\u003EHuy Nguyen也为ASLayoutSpec写了一个寓教于乐的\u003Ca href=\"http:\u002F\u002Fnguyenhuy.github.io\u002Ffroggy-asdk-layout\u002F\"\u003E小游戏\u003C\u002Fa\u003E，只是将上面提到的的针对css的小游戏版本改成了Objc，方便大家快速学习。\u003C\u002Fp\u003E\u003Cp\u003E在最近的版本中，ASDK也同时支持 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffacebook\u002Fyoga\"\u003EYoga\u003C\u002Fa\u003E （一个跨平台的flexbox引擎，使用C语言实现）来计算基于flexbox的布局，与ASDK本身实现的flexbox概念类似。\u003C\u002Fp\u003E\u003Ch2\u003E即刻的实践\u003C\u002Fh2\u003E\u003Cp\u003E即刻在多个消息页面使用了ASDK新的布局系统，例如：\u003C\u002Fp\u003E\u003Cimg src=\"v2-4087a894b3c8190d3f98fa273c9e68c5.png\" data-rawwidth=\"766\" data-rawheight=\"896\"\u003E\u003Cp\u003E从我们的实践经验来看有以下优缺点：\u003C\u002Fp\u003E\u003Ch2\u003E优点\u003C\u002Fh2\u003E\u003Cul\u003E\u003Cli\u003E实现一个layout的视角从专注view之间的距离和约束，转变成划分和制定不同view子区域的布局规则，抽象层级变高，可读性、可维护性大大增强。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E由于ASDisplayNode的显示是异步的，因此无论布局是否依赖于显示结果，都可以在主线程以外进行，并且有缓存，性能有很大提升。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E借用CSS成熟的flexbox布局模型，有大量现成资料和案例来学习，避免了新造轮子的尴尬。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E由于ASDK是开源的，调试难度大大降低。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E布局规则可以脱离实际布局对象进行独立声明，容易复用。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Ch2\u003E缺点\u003C\u002Fh2\u003E\u003Cul\u003E\u003Cli\u003E由于与iOS原生布局方式完全不同，学习适应需要一定时间（如果将来flexbox渐渐成为前端标准，花一些时间了解也是完全值得的。）\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E对于ASDK依赖非常重。如果你想对已有的view改造成用flexbox进行布局，需要重新使用ASDisplayNode来实现该view。如果不方便重新写，只能选用类似Yoga的独立框架来实现功能。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E虽然是声明式布局，然而相对css而言仍较为繁琐。去年参加WWDC时我曾经到Pinterest与Scott有过一些当面交流，也尝试说服他们做一些DSL来简化布局声明。他们的回答是，由于ASDK的复杂性和基础性（类似UIKit），他们仍然将大部分时间放在优化异步渲染和布局性能，并没有太多精力在layout的语法上做出进一步突破。可能当布局系统生长成为独立框架以后分开来做比较合适。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E尽管即刻没有在整个项目都采用新的的布局方式，然而ASDK带来的启发是深远的：声明式、异步布局、flexbox、缓存等等。我们也看到有一些其他布局库做了许多声明式的尝试，如\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fwayfair\u002Fbrickkit-ios\"\u003EBrickkit\u003C\u002Fa\u003E, \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Flinkedin\u002FLayoutKit\"\u003ELayoutkit\u003C\u002Fa\u003E等等，从而加快我们平时的开发和维护效率。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003EPS: 即刻正在招聘，如果你是一个追求极致又富有探索精神的iOS工程师，同时也热爱我们的产品，那么欢迎加入我们，一起参加WWDC（公司cover全部费用），持续打造更棒的即刻！联系我们：\u003Ca href=\"mailto:hr@ruguoapp.com\"\u003Ehr@ruguoapp.com\u003C\u002Fa\u003E\u003C\u002Fp\u003E","updated":new Date("2017-04-11T07:01:42.000Z"),"canComment":false,"commentPermission":"anyone","commentCount":14,"likeCount":23,"state":"published","isLiked":false,"slug":"26283742","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-04-11T15:01:42+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F26283742\u002Fcomments"},"url":"\u002Fp\u002F26283742","titleImage":"https:\u002F\u002Fpic2.zhimg.com\u002Fv2-c8592079fb1afb0cfcf537d0c4a489e4_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F26283742","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":14,"likesCount":23},"29537687":{"title":"AsyncDisplayKit介绍（三）深度优化列表性能","author":"ji-ke-ji-shu-tuan-dui-36","content":"\u003Cp\u003E（ASDK已改名Texture）\u003C\u002Fp\u003E\u003Cp\u003E说到视图性能，不能不提到UITableView，对于它的滚动性能的讨论和优化从未停止。在我们的探索过程中，尝试过以下一些措施：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003Ecell reuse，Apple原生支持，每个人都会用到\u003C\u002Fli\u003E\u003Cli\u003Eestimated cell height，iOS8开始原生支持\u003C\u002Fli\u003E\u003Cli\u003E手动将计算完成的height缓存(或使用FDTemplateLayoutCell等框架自动计算)\u003C\u002Fli\u003E\u003Cli\u003Eprefetch API，iOS10开始原生支持\u003C\u002Fli\u003E\u003Cli\u003E异步加载cell内容，文字图片等\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E还有一些诸如圆角、opaque等普通UIView可能遇到的性能瓶颈已经在\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fyxztj\u002FTechBlogs\u002Fblob\u002Fmaster\u002Fasdk-1.md\"\u003E第一篇\u003C\u002Fa\u003E中讨论了一些，这里不再赘述。\u003C\u002Fp\u003E\u003Cp\u003E然而我们会想，cell的异步布局、图片和文字渲染是否还可以优化，预加载是否可以更完善更智能？仍然有许多问题等待被解决。\u003C\u002Fp\u003E\u003Ch2\u003EUITableView加载Cell的过程\u003C\u002Fh2\u003E\u003Cp\u003E我们先看一下一般UITableView加载Cell的过程：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003EcellForRowAtIndexPath，读取model\u003C\u002Fli\u003E\u003Cli\u003E从reuse池中dequeue一个cell，调用prepareForReuse重置其状态\u003C\u002Fli\u003E\u003Cli\u003E将model装配到UITableViewCell当中去\u003C\u002Fli\u003E\u003Cli\u003E布局（耗时且无法缓存的Autolayout），渲染（文字和图片都很耗时），显示\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E这些操作都在cell将要进入屏幕的一刹那发生，不难理解，在短短的16ms里（60fps）是很难完成这些任务的，尤其是当用户快速滚动的时候，大量任务堆积在主线程runloop，情况变得雪上加霜。如果将滚动中的CPU占用情况用图表显示出来，大概是这样的（WWDC16 session 219）：\u003C\u002Fp\u003E\u003Cimg src=\"v2-875671b73f28f6084f9ae6517ff0d010.jpg\" data-rawwidth=\"2646\" data-rawheight=\"630\"\u003E\u003Cp\u003E这其中每当一个cell将要进入屏幕，一个尖峰就会产生。而在其他相对空闲的时候，cpu的负载相当的低。\u003C\u002Fp\u003E\u003Cp\u003E自然我们会想到，如果把任务平均分配到一个时间段内，而不是集中在某一个点，是否就可以避免这样的情况发生？如果我们能够\u003Cb\u003E预测\u003C\u002Fb\u003E一个cell很快将要进入屏幕，而此时cpu空闲，是否可以未雨绸缪，提前做一些布局和渲染的工作？那样一来，在cell真正需要显示的时候，由于布局和渲染结果backing store已经是现成的了，只需要将它送给真正负责显示的view就可以，也就可以避免产生剧烈的性能波动。\u003C\u002Fp\u003E\u003Ch2\u003EASTableNode\u002FASCollectionNode开辟的新航路\u003C\u002Fh2\u003E\u003Cp\u003E首先的好消息是，作为ASDK的一员，ASTableNode以及其cellNode已经具备了异步布局和异步渲染的能力，即使没有做额外优化，仅仅利用ASDK通用的异步机制将耗时操作延后，相对于一般UITableView已经有了显著的提升。虽然性能锯齿仍然存在，但是将其转移到了后台线程以后，用户感受到的卡顿就已经不会那么明显了。\u003C\u002Fp\u003E\u003Cp\u003E然而这些似乎还不够，在进入屏幕之后才开始渲染，会有短暂的白屏现象（等待渲染完成）再显示内容。\u003Cb\u003E既然渲染工作可以在显示之后再进行，那么类似的，也可以在显示之前的一段时间，把布局和渲染的工作预先完成\u003C\u002Fb\u003E。\u003C\u002Fp\u003E\u003Cp\u003E要达到这些目的，首先介绍一些相关的类：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003EASTableNode\u002FASCollectionNode，可以认为是UITableView\u002FUICollectionView的异步版本，内部包装了原来的UIKit的对应版本，并扩展了一系列功能使他们能够实现异步布局及渲染。\u003C\u002Fli\u003E\u003Cli\u003EASInterfaceState，表示一个node不同的显示状态。其实每个ASDisplayNode都具备interfaceState属性，它主要的用武之地还是在tableNode\u002FcollectionNode之中。对于一个UITableViewCell来说，布局和渲染一般都是在cellForRowAtIndexpath同时完成，然而当需要精细处理任务时就需要把每一个不同的状态分开，降低某一瞬间由于CPU负载高导致卡顿的可能性。ASInterfaceState递进地分为5种状态:\u003C\u002Fli\u003E\u003Cli\u003ENone，该node在一段时间内不会进入屏幕\u003C\u002Fli\u003E\u003Cli\u003EMeasureLayout，可能会在一段时间后进入屏幕，应该准备layout和size计算\u003C\u002Fli\u003E\u003Cli\u003EPreload，加载所需要的数据，如下载图片，缓存读取等等\u003C\u002Fli\u003E\u003Cli\u003EDisplay，马上将要进入屏幕，开始进行渲染操作，显示包含的文字或者图片\u003C\u002Fli\u003E\u003Cli\u003EVisible，该node（所对应的view）至少有1个像素已经在屏幕内，正在显示\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E对于每一个cell而言，原本需要在同一时间点进行的所有初始化\u002F加载\u002F布局\u002F渲染等工作，现在被均匀分配到了不同的状态进行预处理。随着用户滚动列表，根据cell离屏幕的距离不同，设置相应的interfaceState并触发不同阶段的工作，达到均匀分配的目的。同时，由于不需要在主线程上进行，多个cell的工作可以通过共享后台线程来大幅提高并行效率。\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003EASDataController，与ASTableNode一一对应，负责代替ASTableNode管理delegate和dataSource的一系列方法，诸如初始化，插入，删除和一些代理方法等。\u003C\u002Fli\u003E\u003Cli\u003EASRangeController，同样与ASTableNode一一对应，并且可以根据设备性能自定义布局、加载、渲染的工作indexPath区间，在滚动时动态高效地调整各cell的interfaceState来层层触发不同显示阶段的工作，对于流畅滚动起到了至关重要的作用。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cimg src=\"v2-689a24cb8cec86452a6bc8777f273c18.jpg\" data-rawwidth=\"497\" data-rawheight=\"719\"\u003E\u003Cul\u003E\u003Cli\u003EASScrollDirection，定义了列表滚动的方向（上下左右）。在ASRangeController调整各阶段的工作区间时，一般在用户滚动的方向上需要多加载一些，而滚出屏幕的cell在一定时间内回到屏幕的概率较低，因此其分配到的资源也就相应少一些。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E在ASDK1.x的时代，由于彼时还没有ASRangeController的存在，cell的渲染只会在进入屏幕以后进行，也就是说，虽然性能能够达到60fps，但是滚动较快时，渲染跟不上，『白屏』现象就出现了。到了2.x有了ASRangeController之后，虽然在滚动极快的情况下仍然会因为资源不足而产生白屏现象，但是在一般情况下，因为资源分配更加合理，这个问题得到了显著的改善。\u003C\u002Fp\u003E\u003Ch2\u003E一些细节\u003C\u002Fh2\u003E\u003Ch2\u003E多线程\u003C\u002Fh2\u003E\u003Cp\u003E当同时layout多个node时，如何均匀分配工作到各个线程，同时单次不占用过多cpu时间？\u003C\u002Fp\u003E\u003Cp\u003EASDK是这么做的：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E获取当前设备上cpu的数量，并乘以每个cpu的工作量，如4 * 5 = 20，即同一批最多对20个node进行布局。（尽管没有找到严格的文档来说明这样的计算方式会带来最高的效率，但是应该要比不分批次处理更优，使占用的cpu时间片可控）\u003C\u002Fli\u003E\u003Cli\u003E调用dispatch_apply，对同一批次20个node进行并行布局计算\u003C\u002Fli\u003E\u003Cli\u003E每一批处理20个，直到所有都处理完\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Ch2\u003E监听状态变化\u003C\u002Fh2\u003E\u003Cp\u003E不光ASDisplayNode本身会根据不同的state进行相应的工作，它同时也提供了一系列的方法供子类override，如didEnterPreloadState\u002FdidExitVisibleState等等。在实际应用中，由于子类通常会持有一些自己管理的资源（如图片），需要控制在显示\u002F离开屏幕之际进行资源的分配\u002F回收。由于每个时间点分的比较细，只要将工作均匀、合理地分配到相应的方法中，就可以实现非常精确高效的资源调度。\u003C\u002Fp\u003E\u003Ch2\u003E内存管理\u003C\u002Fh2\u003E\u003Cp\u003EASRangeController经常需要管理屏幕外的node（可能同时有好几屏的内容同时进行布局计算和显示），通过预处理来减轻将来的工作量，是一个典型的『空间换时间』的办法，对于内存的压力自然就会上升。\u003C\u002Fp\u003E\u003Cp\u003E为此，ASRangeController提供了一些参数，让开发者可以自行决定每个stage所囊括的范围，达到控制内存的：\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003EASLayoutRangeModeFull，此时用到的资源较多，同时用户体验也是最好的\u003C\u002Fli\u003E\u003Cli\u003EASLayoutRangeMinimum，比上一种类型节省一些资源\u003C\u002Fli\u003E\u003Cli\u003EASLayoutRangeModeVisibleOnly，在app退到后台的时候自动设置，将屏幕外的node所占用的资源释放，降低app在系统中被杀的概率\u003C\u002Fli\u003E\u003Cli\u003EASLayoutRangeModeLowMemory，比上一种更省内存，对于app退到后台，并且目前没有在屏幕上（可能在navigation stack里）的rangeController适用，最大程度释放资源\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E我们可以通过调用setTuningParameters的方式，对于每一种mode中的每一种layoutRangeType做出精细调整。同时，ASDK会自动根据此时node在屏幕上的情况，自动在以上几种mode中来回切换，并根据指定的参数范围来加载\u002F释放资源，达到资源和性能的平衡。\u003C\u002Fp\u003E\u003Cp\u003EASDK中还自带了一个显示rangeController工作情况的小工具：\u003C\u002Fp\u003E\u003Cimg src=\"v2-7a149af7b4e8708916f80ca7ff3a00cd.jpg\" data-rawwidth=\"748\" data-rawheight=\"1338\"\u003E\u003Cp\u003E即刻在热门页面有4个tab，相应的右下角的debug view显示的分别是4个页面不同的working range。箭头表示当前的滚动方向，由于我们配置了在滚动方向上加载的距离比反方向要更长，因此可以看到在滚动方向上的色块会更长一些。\u003C\u002Fp\u003E\u003Ch2\u003E即刻的实践\u003C\u002Fh2\u003E\u003Cp\u003E即刻iOS在最初时也曾苦苦找寻列表性能优化方案。在阅读了Ray Wenderlich的\u003Ca href=\"https:\u002F\u002Fwww.raywenderlich.com\u002F124311\u002Fasyncdisplaykit-2-0-tutorial-getting-started\"\u003E一篇文章\u003C\u002Fa\u003E之后，惊艳其出色的性能，开始接触ASDK。最开始尝试在消息页面使用，后来在长期实践中，发现其确实能够解决tableView的行高计算和性能问题，才渐渐在其他页面使用。\u003C\u002Fp\u003E\u003Cp\u003E就如同在本系列第一篇提到的，对于先进的框架虽然不能重度依赖，我们也愿意勇于拥抱其先进之处。站在ASDK的角度看UITableView，就能有更大的空间来重新审视列表滚动的本质，将性能和资源分配效率提升到一个新的高度；即使将来脱离ASDK，仍然有一些想法值得我们进一步思考。\u003C\u002Fp\u003E\u003Cp\u003E想体验即刻的朋友可以下载看一下，最近又增加了不少新玩法 :)\u003C\u002Fp\u003E\u003Cp\u003EPS: 我们在招Android、爬虫、后端的职位，链接：http:\u002F\u002Fjike.ruguoapp.com\u002Fcareers \u003C\u002Fp\u003E","updated":new Date("2017-09-21T05:55:38.000Z"),"canComment":false,"commentPermission":"anyone","commentCount":5,"likeCount":24,"state":"published","isLiked":false,"slug":"29537687","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-09-21T13:55:38+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F29537687\u002Fcomments"},"url":"\u002Fp\u002F29537687","titleImage":"https:\u002F\u002Fpic4.zhimg.com\u002Fv2-7ddfdd02a5550889026fbc56d1588f33_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F29537687","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":5,"likesCount":24}},"User":{"ji-ke-ji-shu-tuan-dui-36":{"isFollowed":false,"name":"即刻技术团队","headline":"信息过载的今天，获取有效资讯正变得越来越累。不妨换一种轻盈、高效、省心的方式，与你感兴趣的信息相遇。","avatarUrl":"https:\u002F\u002Fpic1.zhimg.com\u002Fv2-65f1b5e0e6ab110cb5e7a288c82eae11_s.jpg","isFollowing":false,"type":"org","slug":"ji-ke-ji-shu-tuan-dui-36","bio":"就想看点好东西","hash":"efdfe1842f00d1b722d6b4062df61031","uid":815926420399358000,"isOrg":true,"description":"信息过载的今天，获取有效资讯正变得越来越累。不妨换一种轻盈、高效、省心的方式，与你感兴趣的信息相遇。","profileUrl":"https:\u002F\u002Fwww.zhihu.com\u002Forg\u002Fji-ke-ji-shu-tuan-dui-36","avatar":{"id":"v2-65f1b5e0e6ab110cb5e7a288c82eae11","template":"https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg"},"isOrgWhiteList":false,"isBanned":false}},"Comment":{},"favlists":{}},"me":{},"global":{"experimentFeatures":{"ge3":"ge3_9","ge2":"ge2_1","androidPassThroughPush":"all","sEI":"c","nwebQAGrowth":"experiment","qawebRelatedReadingsContentControl":"close","liveStore":"ls_a2_b2_c1_f2","nwebSearch":"nweb_search_heifetz","newSignBg":"new","rt":"y","isOffice":"false","enableTtsPlay":"post","newLiveFeedMediacard":"new","newMobileAppHeader":"true","growthSearch":"s2","hybridZhmoreVideo":"yes","nwebGrowthPeople":"default","nwebSearchSuggest":"default","qrcodeLogin":"qrcode","enableVoteDownReasonMenu":"enable","isShowUnicomFreeEntry":"unicom_free_entry_off","growthBanner":"default","newMobileColumnAppheader":"new_header","androidDbRecommendAction":"open","zcmLighting":"zcm","androidDbFeedHashTagStyle":"button","appStoreRateDialog":"close","mobileFeedGuide":"block","default":"None","isNewNotiPanel":"no","adR":"b","wechatShareModal":"wechat_share_modal_show","uRe":"1","androidProfilePanel":"panel_b"}},"columns":{"next":{},"jikeapp":{"followersCount":2396,"creator":{"bio":"就想看点好东西","isFollowing":false,"hash":"efdfe1842f00d1b722d6b4062df61031","uid":815926420399358000,"isOrg":true,"slug":"ji-ke-ji-shu-tuan-dui-36","isFollowed":false,"description":"信息过载的今天，获取有效资讯正变得越来越累。不妨换一种轻盈、高效、省心的方式，与你感兴趣的信息相遇。","name":"即刻技术团队","profileUrl":"https:\u002F\u002Fwww.zhihu.com\u002Forg\u002Fji-ke-ji-shu-tuan-dui-36","avatar":{"id":"v2-65f1b5e0e6ab110cb5e7a288c82eae11","template":"https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg"},"isOrgWhiteList":false,"isBanned":false},"topics":[{"url":"https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F19555404","id":"19555404","name":"iOS 开发"},{"url":"https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F19555634","id":"19555634","name":"Android 开发"},{"url":"https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F19550547","id":"19550547","name":"移动互联网"}],"activateState":"activated","href":"\u002Fapi\u002Fcolumns\u002Fjikeapp","acceptSubmission":true,"firstTime":false,"postTopics":[{"postsCount":3,"id":1724,"name":"iOS 开发"},{"postsCount":2,"id":77,"name":"iOS"},{"postsCount":1,"id":1800,"name":"Android 开发"},{"postsCount":1,"id":3527,"name":"MongoDB"},{"postsCount":1,"id":4656,"name":"敏捷开发"},{"postsCount":1,"id":5869,"name":"Scrum"},{"postsCount":1,"id":6231,"name":"推送 (Push)"},{"postsCount":1,"id":6445,"name":"Node.js"},{"postsCount":1,"id":10100,"name":"布局"},{"postsCount":1,"id":169732,"name":"Swift 编程"},{"postsCount":1,"id":21366,"name":"类型系统"},{"postsCount":1,"id":21961,"name":"容器"},{"postsCount":1,"id":72175,"name":"TypeScript"},{"postsCount":1,"id":84652,"name":"Android 消息推送"},{"postsCount":1,"id":118508,"name":"Elasticsearch"},{"postsCount":1,"id":135680,"name":"Docker"},{"postsCount":1,"id":158144,"name":"Kubernetes"},{"postsCount":1,"id":15950,"name":"ETL"}],"pendingName":"","avatar":{"id":"v2-f0fd84a936ce1297fe603f9033a6138a","template":"https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg"},"canManage":false,"description":"","pendingTopics":[],"nameCanEditUntil":0,"reason":"","banUntil":0,"slug":"jikeapp","name":"即刻技术团队","url":"\u002Fjikeapp","intro":"","topicsCanEditUntil":0,"activateAuthorRequested":"none","commentPermission":"anyone","following":false,"postsCount":9,"canPost":false,"FULLINFO":true,"pins":[]}},"columnPosts":{"jikeapp":{"entity":["29537687","25371361","26283742"],"topic":"iOS 开发"}},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldSetPoster":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"updating":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"edition":{"baidu":false,"yidianzixun":false,"qqnews":false},"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false,"userAgent":{"ua":"CCBot\u002F2.0 (http:\u002F\u002Fcommoncrawl.org\u002Ffaq\u002F)","browser":{},"engine":{},"os":{},"device":{},"cpu":{}}},"message":{"newCount":0},"pushNotification":{"newCount":0}}