即刻技术团队

iOS 开发

{"database":{"Post":{"25371361":{"title":"AsyncDisplayKit介绍（一）原理和思路","author":"ji-ke-ji-shu-tuan-dui-36","content":"<ul><li><a href=\"https://zhuanlan.zhihu.com/p/25371361\">AsyncDisplayKit系列之一：原理和思路</a></li><li><a href=\"https://zhuanlan.zhihu.com/p/26283742\">AsyncDisplayKit系列之二：布局系统</a></li><li><a href=\"https://zhuanlan.zhihu.com/p/29537687\">AsyncDisplayKit系列之三：深度优化列表性能</a></li></ul><p>对于iOS开发而言，UITableView/UICollectionView的优化一直是iOS应用性能优化重要的一块。即使是iOS10+iPhone7这样的最新软硬件配置，在系统的信息app中滚动，仔细观察的话仍然能感到一定的掉帧现象。对于UI要求苛刻的苹果，竟然在如此简单的tableView上无法达到60fps的帧率，可见优化滚动性能的背后并不简单。</p><h2>为什么？</h2><p>理想状态下，iOS的帧率应该保持在60fps。然而很多情况下用户操作时会感觉到掉帧或者『不跟手』。原因可能有很多，这里只简单列举几个，网上可以找到许多相应分析：</p><ol><li><b>CPU(主要是主线程)/GPU负担过重或者不均衡</b>（诸如mask/cornerRadius/drawRect/opaque带来offscreen rendering/blending等等）。由于所有的UIView都是由CALayer来负责显示，因此对Core Animation的了解就变得尤为重要。这里推荐Nick Lockwood的*Core Animation: Advanced Techniques*一书，其中有对Core Animation的性能有着非常详尽的梳理和剖析。</li><li><b>Autolayout布局性能瓶颈</b>，约束计算时间会随着数量呈指数级增长，并且必须在主线程执行。具体分析可以参考这篇文章：<a href=\"http://floriankugler.com/2013/04/22/auto-layout-performance-on-ios/\">Auto Layout Performance on iOS</a>。这也是为何ASDK抛弃了Autolayout而设计了自己的布局系统的重要原因之一(<a href=\"https://github.com/facebook/AsyncDisplayKit/issues/196\">auto layout · Issue #196 · facebook/AsyncDisplayKit · GitHub</a>)。Autolayout在单个View开发时能带来很多便利，而在一些需要高性能的场景下需要谨慎使用。<br></li><li>尽管从iPhone4S(A5)开始CPU已经采用多核，然而<b>对于大多数app来说，多线程协作并没有被充分利用。</b>换句话说，在app卡顿（主线程所占用的核心满负荷）时，往往CPU的其他核心几乎无事可做。一般情况下，由于主线程承担了绝大部分的工作，如果能把主线程的任务转移一部给其他线程进行异步处理，就可以马上享受到并发带来的性能提升。这应该也是AsyncDisplayKit得名的原因之一。</li></ol><p>UIKit的单线程设计也有一定的历史原因。早在十年前iOS SDK刚问世的时候，mobile SDK还是一个非常新的概念，更没有移动多核CPU的存在，因此当时的重点是简单可靠，大多数API都没有支持相对复杂的异步操作。时至今日，如果要完全重构UIKit使之支持异步绘制和布局，对于兼容已有海量的app，难度可想而知。在iOS10中虽然对UICollectionView/UITableView做了一定的预加载优化（WWDC2016 Session219），然而并没有从根本上解决主线程布局和渲染的问题。</p><h2>优化思路</h2><p>我们知道，当用户开始滚动或点击一个View，所有的事件都会被送到主线程等待处理。此时主线程能否抽出足够充裕的时间来处理变得极为重要，尤其是在连续操作（如UIGestureRecognizer）时，每次touchMoved事件处理都会占用主线程一定的时间（如新的UIImageView进入视图，主线程开始处理布局或者图片解码，而这些需要连续占用大量CPU时间）。如果一个操作耗时超过16ms(1000ms/60fps)，那就意味着下一帧无法及时得到处理，引起丢帧。</p><img src=\"v2-862d7be56d8270fd772e8f983f9cd51b.png\" data-rawwidth=\"1542\" data-rawheight=\"852\"><p>（图片截取自WWDC2016 session219）</p><p>因此如何能将主线程的压力尽可能减轻成为优化的首要目标。</p><p>对列表滚动卡顿的常用解决方案有：</p><ol><li>针对Autolayout性能优化：提前计算并缓存cell的layout: <a href=\"https://github.com/forkingdog/UITableView-FDTemplateLayoutCell\">forkingdog/UITableView-FDTemplateLayoutCell: Template auto layout cell for automatically UITableViewCell height calculating</a></li><li>省去中间滑动过程中的计算，直接计算目标区域cell: <a href=\"https://github.com/johnil/VVeboTableViewDemo\">VVebo剥离的TableView绘制</a></li><li>弃用Autolayout，采用手动布局计算。这样虽然可以换来最高的性能，但是代价是编写和维护的不便，对于经常改动或者性能要求不高的场景并不一定值得。<br></li><li>自行异步渲染Layer，如：<a href=\"https://github.com/ibireme/YYAsyncLayer\">ibireme/YYAsyncLayer: iOS utility classes for asynchronous rendering and display.</a></li><li>iOS10列表的prefetch API，只是并没有解决Autolayout的性能问题，同时也受到系统版本限制。</li></ol><p><br></p><p>推荐Yaoyuan的博客，也有比较深入的介绍: <a href=\"http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/\">iOS 保持界面流畅的技巧 | Garan no dou</a> </p><h2>ASDK的基本思路：异步</h2><p>对于一般的开发者，自己重新实现一整套异步布局和渲染机制是非常困难的。幸运的是，ASDK做到了。</p><p>AsyncDisplayKit(ASDK)是2012年由Facebook开始着手开发，并于2014年出品的高性能显示类库，主要作者是Scott Goodson。Scott(github: <a href=\"https://github.com/appleguy\">appleguy · GitHub</a>)曾经参与了多个iOS版本系统的开发，包括UIKit以及一些系统原生app，后来加入Facebook并参与了ASDK的开发并应用到Paper，因此该库有机会从相对底层的角度来进行一系列的优化。</p><p>现在最新的版本是2.0，除了拥有1.0系列版本核心的异步布局渲染功能，还增加了类似ComponentKit的基于flexbox的布局功能。源文件一共近300个，3万多行代码，是一个非常庞大而精密的显示和布局系统。使用上<b>如果不考虑工程成本，完全可以在一定程度上代替UIKit的大部分功能。</b>同时由于和Instagram同处于FB家族，因此也迅速在最近的更新中加入了IGListKit的支持。</p><p>在Scott介绍ASDK的视频中，总结了一下三点占用大量CPU时间的『元凶』（虽然仍然可能有以上提到的其他原因，但ASDK最主要集中于这三点进行优化）：</p><ol><li><b>渲染</b>，对于大量图片，或者大量文字（尤其是CJK字符）混合在一起时。而文字区域的大小和布局，恰恰依赖着渲染的结果。ASDK尽可能后台线程进行渲染，完成后再同步回主线程相应的UIView。<br></li><li><b>布局</b>。ASDK完全弃用了Autolayout，另辟蹊径实现了自己的布局和缓存机制。关于布局的问题会在下一篇讲到。<br></li><li>系统objects的<b>创建与销毁</b>。由于UIKit封装了CALayer以支持触摸等显示以外的操作，耗时也相应增加。而这些同样也需要在主线程上操作。ASDK基于Node的设计，突破了UIKit线程的限制。<br></li></ol><p><br></p><p>既然同步就意味着阻塞，那就异步放到其他线程去做，在需要主线程时再同步回来。</p><img src=\"v2-56b49c627fd8693a8cb990044c360ff9.png\" data-rawwidth=\"1370\" data-rawheight=\"914\"><p>我们知道对于一般UIView和CALayer来说，因为他们不是线程安全的，任何相关操作都需要在主线程进行。正如UIView可以弥补CALayer无法处理用户事件的不足一样，ASDK引入了Node的概念来解决UIView/CALayer只能在主线程上操作的限制（不由让人想起『Abstract layer can solve many problems, except problem of having too many abstract layers.』）。</p><h2>ASDisplayNode主要特点：</h2><ol><li>每个Node对应相应的UIView或者CALayer，从开发者的角度而言，只需要将初始化UIView的代码稍作修改，替换为创建ASDisplayNode即可。在不需要接受用户操作的Node上可以开启isLayerBacked，直接使用CALayer进一步降低开销。根据Scott的研究UIView的开销大约是CALayer的5倍。<br></li><li>Node<b>默认是异步布局/渲染</b>，只有在需要将frame/contents等同步到UIView上才会回到主线程，使其空出更多的时间处理其他事件。<br></li><li>ASDK只有在认为需要的时候才会异步地为Node加载相应的View，因此创建Node的开销变得非常低。同时Node是<b>线程安全</b>的，可以在任意queue上创建和设置属性。<br></li><li>ASDK不仅有与UIView对应的大部分控件（如ASButtonNode、ASTextNode、ASImageNode、ASTableNode等等），同时也bridge了大多数UIView的方法和属性，可以非常方便的操作frame/backgroundColor/addSubnode等，因此一般情况下只要对Node进行操作，ASDK就会在适当的时候同步到其View。如果需要的话，当相应的View加载之后（或访问node.view手动触发加载），也可以通过node.view的方式直接访问，回到我们熟悉的UIKit。<br></li><li>当实现自定义View的时候，ASDisplayNode提供了一个初始化方法initWithViewBlock/initWithLayerBlock，就可以将任意UIView/CALayer用Node包裹起来（被包裹的view可以使用autolayout），从而与ASDK的其他组件相结合。虽然这样创建的Node与一般view在布局和渲染上的差异不大，但是由于Node管理着何时何地加载view，我们仍然能得到一定的性能提升。</li></ol><p>举例来说，当使用UIKit创建一个UIImageView：</p><code lang=\"text\"> _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];</code><p>使用ASDK后只要稍加改动：</p><code lang=\"objective-c\"> _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];</code><p>虽然只是简单的把View替换成了Node，然而和UIImageView不同的是，此时ASDK已经在悄悄使用另一个线程进行图片解码，从而大大降低新的用户操作到来时主线程被阻塞的概率，使每一个回调都能得到及时的处理。实践中将会有更加复杂的情况，有兴趣的话可以参考项目中的Example目录，有20多个不同场景下的示例项目。</p><h2>一些细节</h2><ol><li>在ASDisplayNode.h中有相当多的注释，其中displaysAsynchronously属性大致描述了异步渲染的步骤：<br></li></ol><p><br></p><code lang=\"text\">&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</code><p>从中我们可以看到，所有异步渲染操作是先被同一加入asyncdisplaykit_async_transaction，然后一起提交的。在_ASAsyncTransactionGroup.m源文件中，可以看到ASDK是在主线程的runloop（关于runloop可以参考Yaoyuan的 <a href=\"http://blog.ibireme.com/2015/05/18/runloop/\">深入理解RunLoop | Garan no dou</a>和sunny的 <a href=\"http://v.youku.com/v_show/id_XODgxODkzODI0.html\">iOS线下分享《RunLoop》by 孙源@sunnyxx</a>）中注册了observer，在kCFRunLoopBeforeWaiting和kCFRunLoopExit两个activity的回调中将之前异步完成的工作同步到主线程中去。</p><p>2. ASDisplayNode还有一个属性shouldRasterizeDescendants。</p><code lang=\"text\">&gt; /**\n&gt; * @abstract Whether to draw all descendant nodes’ layers/views into this node’s\n&gt; layer/view’s backing store.\n&gt; * @discussion\n&gt; * When set to YES, causes all descendant nodes’ layers/views to be drawn\n&gt; directly into this node’s layer/view’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/scrolling/etc 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; */</code><p>当我们不需要分别关注单个CALayer，也不需要对他们进行操作时，就可以将所有的子node都合并到父node的backing store一并绘制，从而达到节省内存和提高性能的目的。 </p><h2>注意事项</h2><ol><li>ASDK不支持Storyboard和Autolayout，但是可以与使用Autolayout的view兼容共存。同样React native和Component Kit等其他Facebook出品的iOS库也不支持Storyboard。<br></li><li>由于Node的异步渲染，很有可能在其View到达屏幕之后，内容仍然在渲染过程中。此时需要额外考虑每个Node的placeholder状态，使用户不至于看到一片空白。<br></li><li>在使用ASDisplayNode初始化initWithViewBlock时，由于Node需要在适当的时候调用该block来创建view，因此并不会立即调用block（block可能capture其他变量，例如self），而是存在一个ivar当中。如果该view始终没被创建，而此时拥有该node的父元素被销毁，容易造成retain cycle导致memory leak。<br></li></ol><p><br></p><h2>Best Practice</h2><p>由于ASDK的基本理念是在需要创建UIView时替换成对应的Node来获取性能提升，因此对于现有代码改动较大，侵入性较高，同时由于大量原本熟悉的操作变成了异步的，对于一个团队来说学习曲线也较为陡峭。</p><p>从我们在实际项目中的经验，结合Scott的建议来看，不需要也不可能将所有UIView都替换成其Node版本。将注意力集中在可能造成主线程阻塞的地方，如tableView/collectionView、复杂布局的View、使用连续手势的操作等等。找到合适的切入点将一部分性能需求较高的代码替换成ASDK，会是一个较好的选择。</p><p>对于优化以后的效果，可以尝试我们的应用：<a href=\"http://jike.ruguoapp.com/\">即刻 - 期待每一次推送</a>，其中消息盒子部分应用了ASDK进行了大量调优工作，从而在拥有大量图片和gif/不定长度文字共存的情况下，仍然能达到60fps的流畅体验。在我们将近两年的实践中，尽管也碰到过一些坑，但是带来的提升也是非常明显的，使在构建更复杂的界面同时保持高性能成为可能。</p><h2>推荐阅读</h2><p><a href=\"http://asyncdisplaykit.org/guide/\">AsyncDisplayKit Getting Started</a></p><p><a href=\"http://www.raywenderlich.com/107310/asyncdisplaykit-tutorial-node-hierarchies\">AsyncDisplayKit Tutorial: Node Hierarchies</a></p><p><a href=\"https://www.youtube.com/watch?v=-IPMNWqA638\">NSLondon — Scott Goodson — Behind  AsyncDisplayKit</a></p><p><a href=\"https://www.youtube.com/watch?v=ZPL4Nse76oY\">MCE 2015 — Scott Goodson — Effortless Responsiveness with  AsyncDisplayKit</a></p><p><a href=\"https://www.youtube.com/watch?v=RY_X7l1g79Q\">AsyncDisplayKit 2.0: Intelligent User Interfaces — NSSpain  2015</a></p>","updated":"2017-02-22T09:00:40.000Z","canComment":false,"commentPermission":"anyone","commentCount":4,"likeCount":68,"state":"published","isLiked":false,"slug":"25371361","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-02-22T17:00:40+08:00","links":{"comments":"/api/posts/25371361/comments"},"url":"/p/25371361","titleImage":"https://pic2.zhimg.com/v2-851252a02130f911ef00a2ead1cf90d1_r.png","summary":"","href":"/api/posts/25371361","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":4,"likesCount":68},"26283742":{"title":"AsyncDisplayKit介绍（二）布局系统","author":"ji-ke-ji-shu-tuan-dui-36","content":"<ul><li><a href=\"https://zhuanlan.zhihu.com/p/25371361\">AsyncDisplayKit系列之一：原理和思路</a></li><li><a href=\"https://zhuanlan.zhihu.com/p/26283742\">AsyncDisplayKit系列之二：布局系统</a></li><li><a href=\"https://zhuanlan.zhihu.com/p/29537687\">AsyncDisplayKit系列之三：深度优化列表性能</a></li></ul><p>在上一篇介绍中我们曾经讨论过Autolayout的性能问题。然而在iOS中，除了Autolayout，能选择的只有autoresizingMask，或者纯手动布局。在写了无数view.frame = CGRect(…)之后，我们才发现，一个在HTML中非常简单的流式布局，到iOS9才有相应的UIStackView予以支持（如果用UICollectionView则需要将view包装成CollectionViewCell）。尽管你可以使用<a href=\"https://github.com/forkingdog/FDStackView\">FDStackView</a>将系统要求降低到iOS6，对于复杂的布局仍然需要多层View嵌套来实现——其实对于实现stack布局的时候，并不需要一个真正的UIView实例来承载所有的元素，而只是需要它的布局功能而已（就好比UICollectionViewFlowLayout，只负责控制若干个元素的布局规则而不真正负责布局）。</p><p>做过Web开发的朋友已经习惯了高效的css布局：声明式、易于调试，boxModel结构化清晰等等优点，特别是使用自动化工具之后，只需要保存文件就可以立即在浏览器中看到更新后的效果；而这一切在iOS中就变得遥不可及：命令式赋值、编译后（Objc速度尚可，而swift编译速度较慢）才能看到结果、Autolayout闭源、视图调试复杂、xcode经常crash等等。如果要实现一个高性能的tableView/collectionView，手写布局几乎是唯一选择。</p><h2>Layout的本质</h2><p>在决定使用哪种布局方式之前，先看看设计师是怎么思考布局的：</p><ol><li>每个元素的大小（size）</li></ol><p><br></p><ol><li>兄弟元素之间的位置关系：对齐（alignment）和间距（spacing）；父子元素之间的容纳关系：子元素的边距（insets）</li></ol><p><br></p><p>设计师确定的，是一个布局规则。</p><p>设计稿到了工程师这边以后，我们绝大多数时间都在做以下两件事：</p><ol><li>确定UIView自身的大小（覆盖sizeThatFits方法），与parent view无关</li></ol><p><br></p><ol><li>根据规则，将subview放在父parent内的指定位置（对应layoutSubviews），由parent view决定</li></ol><p><br></p><p>这样自底向上层层递归，最终完成整个屏幕内所有子元素的布局。工程师完成的，是一个基于布局规则的具体实现，关注的对象是单个view或者是两个相邻view之间的关系。</p><p>也就是说，<b>手动布局或者通过约束（Autolayout）其实是在『实现』布局规则，而不是『声明』布局规则</b>。抽象层级下降了，随之而来的是多到令人头疼的frame、size、origin计算，可读性、可维护性都非常差。那能不能提高抽象层级，用一个数据结构来表示布局规则，从而摆脱繁重又容易出错的数值计算，让布局系统根据规则自动地、异步地计算呢？</p><p><br></p><h2>AsyncDisplayKit的三种布局方式</h2><p><b>1. 手动布局</b></p><p>这是最基础的一种布局方式。在ASDK中的手动布局与UIKit的手动布局类似，只是方法名从sizeThatFits变成了calculatedSizeThatFits，layoutSubviews方法变成了layout方法。略微不同的是ASDK会将布局结果预先在后台线程进行计算，并缓存下来以提升性能，这点对于tableView滚动流畅性有非常大的帮助。</p><p>然而，跟普通手动布局类似，最大的缺点是可读性和可维护性差。由于自身的大小常常和子元素的布局相关联，这两个方法中的代码容易重复；同时由于布局针对自身subView，很难将其代码与其他View进行复用。</p><p><b>2. Unified layout</b></p><p>这也是在ASDK中新出现的概念。先介绍一下ASLayout：</p><img src=\"v2-fe3cd3d79a64071512f8fa6d6c9ccc4a.png\" data-rawwidth=\"1340\" data-rawheight=\"1000\"><p><br></p><p>一个ASLayout对象包含以下元素：</p><ul><li>它所代表的布局元素</li></ul><p><br></p><ul><li>元素的尺寸</li></ul><p><br></p><ul><li>元素的位置</li></ul><p><br></p><ul><li>它所包含的sublayouts</li></ul><p><br></p><p>可以看出，当一个node具备了确定的ASLayout对象时，它自身的布局也就随之确定了。为了生成ASLayout，ASDisplayNode为subclass提供了如下覆盖点：</p><code lang=\"text\">- (ASLayout *)calculateLayoutThatFits:(ASSizeRange)constrainedSize\n</code><p>只要Node能够计算出自己的ASLayout，父元素就可以完成对其的布局。这种方法将sizeThatFits和layoutSubviews结合在一起，一定程度上避免了相似代码的尴尬，但是计算上仍然是手动布局，不够简便。</p><p><b>3. Automatic Layout(不是系统的Autolayout)</b></p><p>有了ASLayout这一层抽象，如何通过声明规则而不是通过计算得到它，是问题的核心。</p><p>Facebook将React的概念延伸到native，同时也把声明式的语法带到了iOS，产生了<a href=\"https://github.com/facebook/componentkit\">ComponentKit</a>框架。早在ASDK1.0的年代大家纷纷表示希望能将其与ComponentKit相融合，幸运的是，在2.0版本中实现了。我选用了作者Scott Goodson在NSSpain的<a href=\"https://github-cloud.s3.amazonaws.com/assets/repositories/21265042/15788?X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ/20160204/us-east-1/s3/aws4_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/pdf\">演讲pdf</a>作为插图，方便大家了解新的布局系统。</p><p>Automatic Layout是ASDK最推荐也是最为高效的布局方式。它引入了ASLayoutSpec的概念，来描述抽象的布局规则（并不需要创建对应node或者view来装载子元素）。一旦确定布局规则，它就能依照规则对其负责的子元素进行布局计算，得到每个布局元素的ASLayout对象。</p><p>我们先来看一下它们之间的关系：</p><img src=\"v2-7cc4780a65e481894d1563e3808d2843.png\" data-rawwidth=\"1336\" data-rawheight=\"1001\"><p>可以看到ASLayoutSpec和ASDisplayNode都实现了ASLayoutable接口，因此他们都具备生成ASLayout的能力，这样就能唯一确定自身的大小。</p><ul><li>对于以上提到的Unified布局，当我们实现了calculateLayoutThatFits，ASDK会在布局过程中调用measureWithSizeRange(如果没有缓存过再调用calculateLayoutThatFits)来算出ASLayout。</li></ul><p><br></p><ul><li>如果ASDisplayNode选择实现layoutSpecThatFits，由更为抽象的ASLayoutSpec来负责指定布局规则，由于ASLayoutSpec也实现了ASLayoutable接口，同样也可以通过调用measureWithSizeRange来获得ASLayout。</li></ul><p><br></p><p>由于<b>ASLayoutSpec只负责指定布局规则，而不关心其布局的ASLayoutable具体是Node还是其他ASLayoutSpec</b>，我们可以轻松地将ASLayoutSpec生成逻辑独立出来，达到复用的目的。</p><h2>挑大梁的ASStackLayoutSpec</h2><p>ASLayoutSpec主要有以下几种：</p><img src=\"v2-0c71f153552795c642c6dcfe729a0fd2.png\" data-rawwidth=\"1336\" data-rawheight=\"988\"><p>通过它们的命名就可以了解其大致作用。其中用途最广泛的无疑是ASStackLayoutSpec，与UIStackView有异曲同工之妙。</p><p>ASStackLayoutSpec大量借鉴了CSS的flexbox概念，写过Web代码的同学应该能一眼认出许多熟悉的属性：justifyContent/flexDirection/alignSelf/alignItems/flexBasis等等。不熟悉的朋友也可以通过一个有趣的游戏来学习flexbox：<a href=\"http://flexboxfroggy.com/\">Flexbox Froggy</a></p><h2>示例</h2><p>(图中的Huy Nguyen也是ASDK布局的主要贡献者之一)</p><img src=\"v2-50e16b5af99156b2e6882648941512c4.png\" data-rawwidth=\"1350\" data-rawheight=\"1003\"><p><br></p><p>图中左边是一个imageNode，右边是由两个textNode组成的一个vertical</p><p>stack，再和imageNode组合成一个横向的stack，最后加上边缘inset完成整个布局。</p><p>事实上，与css类似，绝大多数的布局都可以通过stack和inset的组合来完成；而和UIStackView不同的是，layout spec只是一个存在于内存之中的数据结构，并不需要额外创建view容器来承载子元素，大大节约了复杂布局带来的开销；同时因为它的轻量级和独立性，因此能够将布局规则放到后台线程独立计算，并缓存在node之中，对于大量tableView/collectionView的CellNode快速布局有相当大的帮助。</p><p>Huy Nguyen也为ASLayoutSpec写了一个寓教于乐的<a href=\"http://nguyenhuy.github.io/froggy-asdk-layout/\">小游戏</a>，只是将上面提到的的针对css的小游戏版本改成了Objc，方便大家快速学习。</p><p>在最近的版本中，ASDK也同时支持 <a href=\"https://github.com/facebook/yoga\">Yoga</a> （一个跨平台的flexbox引擎，使用C语言实现）来计算基于flexbox的布局，与ASDK本身实现的flexbox概念类似。</p><h2>即刻的实践</h2><p>即刻在多个消息页面使用了ASDK新的布局系统，例如：</p><img src=\"v2-4087a894b3c8190d3f98fa273c9e68c5.png\" data-rawwidth=\"766\" data-rawheight=\"896\"><p>从我们的实践经验来看有以下优缺点：</p><h2>优点</h2><ul><li>实现一个layout的视角从专注view之间的距离和约束，转变成划分和制定不同view子区域的布局规则，抽象层级变高，可读性、可维护性大大增强。</li></ul><p><br></p><ul><li>由于ASDisplayNode的显示是异步的，因此无论布局是否依赖于显示结果，都可以在主线程以外进行，并且有缓存，性能有很大提升。</li></ul><p><br></p><ul><li>借用CSS成熟的flexbox布局模型，有大量现成资料和案例来学习，避免了新造轮子的尴尬。</li></ul><p><br></p><ul><li>由于ASDK是开源的，调试难度大大降低。</li></ul><p><br></p><ul><li>布局规则可以脱离实际布局对象进行独立声明，容易复用。</li></ul><p><br></p><h2>缺点</h2><ul><li>由于与iOS原生布局方式完全不同，学习适应需要一定时间（如果将来flexbox渐渐成为前端标准，花一些时间了解也是完全值得的。）</li></ul><p><br></p><ul><li>对于ASDK依赖非常重。如果你想对已有的view改造成用flexbox进行布局，需要重新使用ASDisplayNode来实现该view。如果不方便重新写，只能选用类似Yoga的独立框架来实现功能。</li></ul><p><br></p><ul><li>虽然是声明式布局，然而相对css而言仍较为繁琐。去年参加WWDC时我曾经到Pinterest与Scott有过一些当面交流，也尝试说服他们做一些DSL来简化布局声明。他们的回答是，由于ASDK的复杂性和基础性（类似UIKit），他们仍然将大部分时间放在优化异步渲染和布局性能，并没有太多精力在layout的语法上做出进一步突破。可能当布局系统生长成为独立框架以后分开来做比较合适。</li></ul><p><br></p><p>尽管即刻没有在整个项目都采用新的的布局方式，然而ASDK带来的启发是深远的：声明式、异步布局、flexbox、缓存等等。我们也看到有一些其他布局库做了许多声明式的尝试，如<a href=\"https://github.com/wayfair/brickkit-ios\">Brickkit</a>, <a href=\"https://github.com/linkedin/LayoutKit\">Layoutkit</a>等等，从而加快我们平时的开发和维护效率。</p><p><br></p><p>PS: 即刻正在招聘，如果你是一个追求极致又富有探索精神的iOS工程师，同时也热爱我们的产品，那么欢迎加入我们，一起参加WWDC（公司cover全部费用），持续打造更棒的即刻！联系我们：<a href=\"mailto:hr@ruguoapp.com\">hr@ruguoapp.com</a></p>","updated":"2017-04-11T07:01:42.000Z","canComment":false,"commentPermission":"anyone","commentCount":14,"likeCount":17,"state":"published","isLiked":false,"slug":"26283742","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-04-11T15:01:42+08:00","links":{"comments":"/api/posts/26283742/comments"},"url":"/p/26283742","titleImage":"https://pic1.zhimg.com/v2-c8592079fb1afb0cfcf537d0c4a489e4_r.png","summary":"","href":"/api/posts/26283742","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":14,"likesCount":17},"29537687":{"title":"AsyncDisplayKit介绍（三）深度优化列表性能","author":"ji-ke-ji-shu-tuan-dui-36","content":"<ul><li><a href=\"https://zhuanlan.zhihu.com/p/25371361\">AsyncDisplayKit系列之一：原理和思路</a></li><li><a href=\"https://zhuanlan.zhihu.com/p/26283742\">AsyncDisplayKit系列之二：布局系统</a></li><li><a href=\"https://zhuanlan.zhihu.com/p/29537687\">AsyncDisplayKit系列之三：深度优化列表性能</a></li></ul><p>（ASDK已改名Texture）</p><p>说到视图性能，不能不提到UITableView，对于它的滚动性能的讨论和优化从未停止。在我们的探索过程中，尝试过以下一些措施：</p><ul><li>cell reuse，Apple原生支持，每个人都会用到</li><li>estimated cell height，iOS8开始原生支持</li><li>手动将计算完成的height缓存(或使用FDTemplateLayoutCell等框架自动计算)</li><li>prefetch API，iOS10开始原生支持</li><li>异步加载cell内容，文字图片等</li></ul><p>还有一些诸如圆角、opaque等普通UIView可能遇到的性能瓶颈已经在<a href=\"https://github.com/yxztj/TechBlogs/blob/master/asdk-1.md\">第一篇</a>中讨论了一些，这里不再赘述。</p><p>然而我们会想，cell的异步布局、图片和文字渲染是否还可以优化，预加载是否可以更完善更智能？仍然有许多问题等待被解决。</p><h2>UITableView加载Cell的过程</h2><p>我们先看一下一般UITableView加载Cell的过程：</p><ol><li>cellForRowAtIndexPath，读取model</li><li>从reuse池中dequeue一个cell，调用prepareForReuse重置其状态</li><li>将model装配到UITableViewCell当中去</li><li>布局（耗时且无法缓存的Autolayout），渲染（文字和图片都很耗时），显示</li></ol><p>这些操作都在cell将要进入屏幕的一刹那发生，不难理解，在短短的16ms里（60fps）是很难完成这些任务的，尤其是当用户快速滚动的时候，大量任务堆积在主线程runloop，情况变得雪上加霜。如果将滚动中的CPU占用情况用图表显示出来，大概是这样的（WWDC16 session 219）：</p><img src=\"v2-875671b73f28f6084f9ae6517ff0d010.jpg\" data-rawwidth=\"2646\" data-rawheight=\"630\"><p>这其中每当一个cell将要进入屏幕，一个尖峰就会产生。而在其他相对空闲的时候，cpu的负载相当的低。</p><p>自然我们会想到，如果把任务平均分配到一个时间段内，而不是集中在某一个点，是否就可以避免这样的情况发生？如果我们能够<b>预测</b>一个cell很快将要进入屏幕，而此时cpu空闲，是否可以未雨绸缪，提前做一些布局和渲染的工作？那样一来，在cell真正需要显示的时候，由于布局和渲染结果backing store已经是现成的了，只需要将它送给真正负责显示的view就可以，也就可以避免产生剧烈的性能波动。</p><h2>ASTableNode/ASCollectionNode开辟的新航路</h2><p>首先的好消息是，作为ASDK的一员，ASTableNode以及其cellNode已经具备了异步布局和异步渲染的能力，即使没有做额外优化，仅仅利用ASDK通用的异步机制将耗时操作延后，相对于一般UITableView已经有了显著的提升。虽然性能锯齿仍然存在，但是将其转移到了后台线程以后，用户感受到的卡顿就已经不会那么明显了。</p><p>然而这些似乎还不够，在进入屏幕之后才开始渲染，会有短暂的白屏现象（等待渲染完成）再显示内容。<b>既然渲染工作可以在显示之后再进行，那么类似的，也可以在显示之前的一段时间，把布局和渲染的工作预先完成</b>。</p><p>要达到这些目的，首先介绍一些相关的类：</p><ul><li>ASTableNode/ASCollectionNode，可以认为是UITableView/UICollectionView的异步版本，内部包装了原来的UIKit的对应版本，并扩展了一系列功能使他们能够实现异步布局及渲染。</li><li>ASInterfaceState，表示一个node不同的显示状态。其实每个ASDisplayNode都具备interfaceState属性，它主要的用武之地还是在tableNode/collectionNode之中。对于一个UITableViewCell来说，布局和渲染一般都是在cellForRowAtIndexpath同时完成，然而当需要精细处理任务时就需要把每一个不同的状态分开，降低某一瞬间由于CPU负载高导致卡顿的可能性。ASInterfaceState递进地分为5种状态:</li><li>None，该node在一段时间内不会进入屏幕</li><li>MeasureLayout，可能会在一段时间后进入屏幕，应该准备layout和size计算</li><li>Preload，加载所需要的数据，如下载图片，缓存读取等等</li><li>Display，马上将要进入屏幕，开始进行渲染操作，显示包含的文字或者图片</li><li>Visible，该node（所对应的view）至少有1个像素已经在屏幕内，正在显示</li></ul><p>对于每一个cell而言，原本需要在同一时间点进行的所有初始化/加载/布局/渲染等工作，现在被均匀分配到了不同的状态进行预处理。随着用户滚动列表，根据cell离屏幕的距离不同，设置相应的interfaceState并触发不同阶段的工作，达到均匀分配的目的。同时，由于不需要在主线程上进行，多个cell的工作可以通过共享后台线程来大幅提高并行效率。</p><ul><li>ASDataController，与ASTableNode一一对应，负责代替ASTableNode管理delegate和dataSource的一系列方法，诸如初始化，插入，删除和一些代理方法等。</li><li>ASRangeController，同样与ASTableNode一一对应，并且可以根据设备性能自定义布局、加载、渲染的工作indexPath区间，在滚动时动态高效地调整各cell的interfaceState来层层触发不同显示阶段的工作，对于流畅滚动起到了至关重要的作用。</li></ul><img src=\"v2-689a24cb8cec86452a6bc8777f273c18.jpg\" data-rawwidth=\"497\" data-rawheight=\"719\"><ul><li>ASScrollDirection，定义了列表滚动的方向（上下左右）。在ASRangeController调整各阶段的工作区间时，一般在用户滚动的方向上需要多加载一些，而滚出屏幕的cell在一定时间内回到屏幕的概率较低，因此其分配到的资源也就相应少一些。</li></ul><p>在ASDK1.x的时代，由于彼时还没有ASRangeController的存在，cell的渲染只会在进入屏幕以后进行，也就是说，虽然性能能够达到60fps，但是滚动较快时，渲染跟不上，『白屏』现象就出现了。到了2.x有了ASRangeController之后，虽然在滚动极快的情况下仍然会因为资源不足而产生白屏现象，但是在一般情况下，因为资源分配更加合理，这个问题得到了显著的改善。</p><h2>一些细节</h2><h2>多线程</h2><p>当同时layout多个node时，如何均匀分配工作到各个线程，同时单次不占用过多cpu时间？</p><p>ASDK是这么做的：</p><ol><li>获取当前设备上cpu的数量，并乘以每个cpu的工作量，如4 * 5 = 20，即同一批最多对20个node进行布局。（尽管没有找到严格的文档来说明这样的计算方式会带来最高的效率，但是应该要比不分批次处理更优，使占用的cpu时间片可控）</li><li>调用dispatch_apply，对同一批次20个node进行并行布局计算</li><li>每一批处理20个，直到所有都处理完</li></ol><h2>监听状态变化</h2><p>不光ASDisplayNode本身会根据不同的state进行相应的工作，它同时也提供了一系列的方法供子类override，如didEnterPreloadState/didExitVisibleState等等。在实际应用中，由于子类通常会持有一些自己管理的资源（如图片），需要控制在显示/离开屏幕之际进行资源的分配/回收。由于每个时间点分的比较细，只要将工作均匀、合理地分配到相应的方法中，就可以实现非常精确高效的资源调度。</p><h2>内存管理</h2><p>ASRangeController经常需要管理屏幕外的node（可能同时有好几屏的内容同时进行布局计算和显示），通过预处理来减轻将来的工作量，是一个典型的『空间换时间』的办法，对于内存的压力自然就会上升。</p><p>为此，ASRangeController提供了一些参数，让开发者可以自行决定每个stage所囊括的范围，达到控制内存的：</p><ul><li>ASLayoutRangeModeFull，此时用到的资源较多，同时用户体验也是最好的</li><li>ASLayoutRangeMinimum，比上一种类型节省一些资源</li><li>ASLayoutRangeModeVisibleOnly，在app退到后台的时候自动设置，将屏幕外的node所占用的资源释放，降低app在系统中被杀的概率</li><li>ASLayoutRangeModeLowMemory，比上一种更省内存，对于app退到后台，并且目前没有在屏幕上（可能在navigation stack里）的rangeController适用，最大程度释放资源</li></ul><p>我们可以通过调用setTuningParameters的方式，对于每一种mode中的每一种layoutRangeType做出精细调整。同时，ASDK会自动根据此时node在屏幕上的情况，自动在以上几种mode中来回切换，并根据指定的参数范围来加载/释放资源，达到资源和性能的平衡。</p><p>ASDK中还自带了一个显示rangeController工作情况的小工具：</p><img src=\"v2-7a149af7b4e8708916f80ca7ff3a00cd.jpg\" data-rawwidth=\"748\" data-rawheight=\"1338\"><p>即刻在热门页面有4个tab，相应的右下角的debug view显示的分别是4个页面不同的working range。箭头表示当前的滚动方向，由于我们配置了在滚动方向上加载的距离比反方向要更长，因此可以看到在滚动方向上的色块会更长一些。</p><h2>即刻的实践</h2><p>即刻iOS在最初时也曾苦苦找寻列表性能优化方案。在阅读了Ray Wenderlich的<a href=\"https://www.raywenderlich.com/124311/asyncdisplaykit-2-0-tutorial-getting-started\">一篇文章</a>之后，惊艳其出色的性能，开始接触ASDK。最开始尝试在消息页面使用，后来在长期实践中，发现其确实能够解决tableView的行高计算和性能问题，才渐渐在其他页面使用。</p><p>就如同在本系列第一篇提到的，对于先进的框架虽然不能重度依赖，我们也愿意勇于拥抱其先进之处。站在ASDK的角度看UITableView，就能有更大的空间来重新审视列表滚动的本质，将性能和资源分配效率提升到一个新的高度；即使将来脱离ASDK，仍然有一些想法值得我们进一步思考。</p><p>想体验即刻的朋友可以下载看一下，最近又增加了不少新玩法 :)</p>","updated":"2017-09-21T05:55:38.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"likeCount":4,"state":"published","isLiked":false,"slug":"29537687","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-09-21T13:55:38+08:00","links":{"comments":"/api/posts/29537687/comments"},"url":"/p/29537687","titleImage":"https://pic4.zhimg.com/v2-7ddfdd02a5550889026fbc56d1588f33_r.png","summary":"","href":"/api/posts/29537687","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":1,"likesCount":4}},"User":{"ji-ke-ji-shu-tuan-dui-36":{"isFollowed":false,"name":"即刻技术团队","headline":"信息过载的今天，获取有效资讯正变得越来越累。不妨换一种轻盈、高效、省心的方式，与你感兴趣的信息相遇。","avatarUrl":"https://pic2.zhimg.com/v2-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://www.zhihu.com/org/ji-ke-ji-shu-tuan-dui-36","avatar":{"id":"v2-65f1b5e0e6ab110cb5e7a288c82eae11","template":"https://pic2.zhimg.com/{id}_{size}.jpg"},"isOrgWhiteList":false}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"next":{},"jikeapp":{"pins":[],"followersCount":1702,"creator":{"bio":"就想看点好东西","isFollowing":false,"hash":"efdfe1842f00d1b722d6b4062df61031","uid":815926420399358000,"isOrg":true,"slug":"ji-ke-ji-shu-tuan-dui-36","isFollowed":false,"description":"信息过载的今天，获取有效资讯正变得越来越累。不妨换一种轻盈、高效、省心的方式，与你感兴趣的信息相遇。","name":"即刻技术团队","profileUrl":"https://www.zhihu.com/org/ji-ke-ji-shu-tuan-dui-36","avatar":{"id":"v2-65f1b5e0e6ab110cb5e7a288c82eae11","template":"https://pic2.zhimg.com/{id}_{size}.jpg"},"isOrgWhiteList":false},"topics":[{"url":"https://www.zhihu.com/topic/19555404","id":"19555404","name":"iOS 开发"},{"url":"https://www.zhihu.com/topic/19555634","id":"19555634","name":"Android 开发"},{"url":"https://www.zhihu.com/topic/19550547","id":"19550547","name":"移动互联网"}],"activateState":"activated","href":"/api/columns/jikeapp","acceptSubmission":true,"firstTime":false,"postTopics":[{"postsCount":3,"id":1724,"name":"iOS 开发"},{"postsCount":1,"id":15950,"name":"ETL"},{"postsCount":1,"id":1800,"name":"Android 开发"},{"postsCount":1,"id":3527,"name":"MongoDB"},{"postsCount":1,"id":6231,"name":"推送 (Push)"},{"postsCount":1,"id":10100,"name":"布局"},{"postsCount":1,"id":77,"name":"iOS"},{"postsCount":1,"id":21961,"name":"容器"},{"postsCount":1,"id":84652,"name":"Android 消息推送"},{"postsCount":1,"id":118508,"name":"Elasticsearch"},{"postsCount":1,"id":135680,"name":"Docker"},{"postsCount":1,"id":158144,"name":"Kubernetes"}],"pendingName":"","avatar":{"id":"v2-f0fd84a936ce1297fe603f9033a6138a","template":"https://pic3.zhimg.com/{id}_{size}.jpg"},"canManage":false,"description":"","pendingTopics":[],"nameCanEditUntil":0,"reason":"","banUntil":0,"slug":"jikeapp","name":"即刻技术团队","url":"/jikeapp","intro":"","topicsCanEditUntil":0,"activateAuthorRequested":"none","commentPermission":"anyone","following":false,"postsCount":6,"canPost":false,"FULLINFO":true}},"columnPosts":{"jikeapp":{"entity":["25371361","26283742","29537687"],"topic":"iOS 开发"}},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"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},"sys":{}}