即刻技术团队

iOS 开发

{"database":{"Post":{"25371361":{"title":"AsyncDisplayKit介绍（一）原理和思路","author":"ji-ke-ji-shu-tuan-dui-36","content":"对于iOS开发而言，UITableView/UICollectionView的优化一直是iOS应用性能优化重要的一块。即使是iOS10+iPhone7这样的最新软硬件配置，在系统的信息app中滚动，仔细观察的话仍然能感到一定的掉帧现象。对于UI要求苛刻的苹果，竟然在如此简单的tableView上无法达到60fps的帧率，可见优化滚动性能的背后并不简单。<h2>为什么？</h2>理想状态下，iOS的帧率应该保持在60fps。然而很多情况下用户操作时会感觉到掉帧或者『不跟手』。原因可能有很多，这里只简单列举几个，网上可以找到许多相应分析：<ol><li>CPU(主要是主线程)/GPU负担过重或者不均衡（诸如mask/cornerRadius/drawRect/opaque带来offscreen rendering/blending等等）。由于所有的UIView都是由CALayer来负责显示，因此对Core Animation的了解就变得尤为重要。这里推荐Nick Lockwood的*Core Animation: Advanced Techniques*一书，其中有对Core Animation的性能有着非常详尽的梳理和剖析。</li><li>Autolayout布局性能瓶颈，约束计算时间会随着数量呈指数级增长，并且必须在主线程执行。具体分析可以参考这篇文章：<a href=\"http://floriankugler.com/2013/04/22/auto-layout-performance-on-ios/\" data-editable=\"true\" data-title=\"Auto Layout Performance on iOS\" class=\"\">Auto Layout Performance on iOS</a>。这也是为何ASDK抛弃了Autolayout而设计了自己的布局系统的重要原因之一(<a href=\"https://github.com/facebook/AsyncDisplayKit/issues/196\" data-editable=\"true\" data-title=\"auto layout · Issue #196 · facebook/AsyncDisplayKit · GitHub\" class=\"\">auto layout · Issue #196 · facebook/AsyncDisplayKit · GitHub</a>)。Autolayout在单个View开发时能带来很多便利，而在一些需要高性能的场景下需要谨慎使用。 </li><li>尽管从iPhone4S(A5)开始CPU已经采用多核，然而对于大多数app来说，多线程协作并没有被充分利用。换句话说，在app卡顿（主线程所占用的核心满负荷）时，往往CPU的其他核心几乎无事可做。一般情况下，由于主线程承担了绝大部分的工作，如果能把主线程的任务转移一部给其他线程进行异步处理，就可以马上享受到并发带来的性能提升。这应该也是AsyncDisplayKit得名的原因之一。</li></ol>UIKit的单线程设计也有一定的历史原因。早在十年前iOS SDK刚问世的时候，mobile SDK还是一个非常新的概念，更没有移动多核CPU的存在，因此当时的重点是简单可靠，大多数API都没有支持相对复杂的异步操作。时至今日，如果要完全重构UIKit使之支持异步绘制和布局，对于兼容已有海量的app，难度可想而知。在iOS10中虽然对UICollectionView/UITableView做了一定的预加载优化（WWDC2016 Session219），然而并没有从根本上解决主线程布局和渲染的问题。<h2>优化思路</h2>我们知道，当用户开始滚动或点击一个View，所有的事件都会被送到主线程等待处理。此时主线程能否抽出足够充裕的时间来处理变得极为重要，尤其是在连续操作（如UIGestureRecognizer）时，每次touchMoved事件处理都会占用主线程一定的时间（如新的UIImageView进入视图，主线程开始处理布局或者图片解码，而这些需要连续占用大量CPU时间）。如果一个操作耗时超过16ms(1000ms/60fps)，那就意味着下一帧无法及时得到处理，引起丢帧。<img src=\"v2-862d7be56d8270fd772e8f983f9cd51b.png\" data-rawwidth=\"1542\" data-rawheight=\"852\">（图片截取自WWDC2016 session219）因此如何能将主线程的压力尽可能减轻成为优化的首要目标。对列表滚动卡顿的常用解决方案有：<ol><li>针对Autolayout性能优化：提前计算并缓存cell的layout: <a href=\"https://github.com/forkingdog/UITableView-FDTemplateLayoutCell\" data-editable=\"true\" data-title=\"forkingdog/UITableView-FDTemplateLayoutCell: Template auto layout cell for automatically UITableViewCell height calculating\" class=\"\">forkingdog/UITableView-FDTemplateLayoutCell: Template auto layout cell for automatically UITableViewCell height calculating</a></li><li>省去中间滑动过程中的计算，直接计算目标区域cell: <a href=\"https://github.com/johnil/VVeboTableViewDemo\" data-editable=\"true\" data-title=\"VVebo剥离的TableView绘制\" class=\"\">VVebo剥离的TableView绘制</a></li><li>弃用Autolayout，采用手动布局计算。这样虽然可以换来最高的性能，但是代价是编写和维护的不便，对于经常改动或者性能要求不高的场景并不一定值得。 </li><li>自行异步渲染Layer，如：<a href=\"https://github.com/ibireme/YYAsyncLayer\" data-editable=\"true\" data-title=\"ibireme/YYAsyncLayer: iOS utility classes for asynchronous rendering and display.\" class=\"\">ibireme/YYAsyncLayer: iOS utility classes for asynchronous rendering and display.</a></li><li>iOS10列表的prefetch API，只是并没有解决Autolayout的性能问题，同时也受到系统版本限制。</li></ol> 推荐Yaoyuan的博客，也有比较深入的介绍: <a href=\"http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/\" data-editable=\"true\" data-title=\"iOS 保持界面流畅的技巧 | Garan no dou\" class=\"\">iOS 保持界面流畅的技巧 | Garan no dou</a> <h2>ASDK的基本思路：异步</h2>对于一般的开发者，自己重新实现一整套异步布局和渲染机制是非常困难的。幸运的是，ASDK做到了。AsyncDisplayKit(ASDK)是2012年由Facebook开始着手开发，并于2014年出品的高性能显示类库，主要作者是Scott Goodson。Scott(github: <a href=\"https://github.com/appleguy\" data-editable=\"true\" data-title=\"appleguy · GitHub\" class=\"\">appleguy · GitHub</a>)曾经参与了多个iOS版本系统的开发，包括UIKit以及一些系统原生app，后来加入Facebook并参与了ASDK的开发并应用到Paper，因此该库有机会从相对底层的角度来进行一系列的优化。现在最新的版本是2.0，除了拥有1.0系列版本核心的异步布局渲染功能，还增加了类似ComponentKit的基于flexbox的布局功能。源文件一共近300个，3万多行代码，是一个非常庞大而精密的显示和布局系统。使用上如果不考虑工程成本，完全可以在一定程度上代替UIKit的大部分功能。同时由于和Instagram同处于FB家族，因此也迅速在最近的更新中加入了IGListKit的支持。在Scott介绍ASDK的视频中，总结了一下三点占用大量CPU时间的『元凶』（虽然仍然可能有以上提到的其他原因，但ASDK最主要集中于这三点进行优化）：<ol><li>渲染，对于大量图片，或者大量文字（尤其是CJK字符）混合在一起时。而文字区域的大小和布局，恰恰依赖着渲染的结果。ASDK尽可能后台线程进行渲染，完成后再同步回主线程相应的UIView。 </li><li>布局。ASDK完全弃用了Autolayout，另辟蹊径实现了自己的布局和缓存机制。关于布局的问题会在下一篇讲到。 </li><li>系统objects的创建与销毁。由于UIKit封装了CALayer以支持触摸等显示以外的操作，耗时也相应增加。而这些同样也需要在主线程上操作。ASDK基于Node的设计，突破了UIKit线程的限制。 </li></ol> 既然同步就意味着阻塞，那就异步放到其他线程去做，在需要主线程时再同步回来。<img src=\"v2-56b49c627fd8693a8cb990044c360ff9.png\" data-rawwidth=\"1370\" data-rawheight=\"914\">我们知道对于一般UIView和CALayer来说，因为他们不是线程安全的，任何相关操作都需要在主线程进行。正如UIView可以弥补CALayer无法处理用户事件的不足一样，ASDK引入了Node的概念来解决UIView/CALayer只能在主线程上操作的限制（不由让人想起『Abstract layer can solve many problems, except problem of having too many abstract layers.』）。<h2>ASDisplayNode主要特点：</h2><ol><li>每个Node对应相应的UIView或者CALayer，从开发者的角度而言，只需要将初始化UIView的代码稍作修改，替换为创建ASDisplayNode即可。在不需要接受用户操作的Node上可以开启isLayerBacked，直接使用CALayer进一步降低开销。根据Scott的研究UIView的开销大约是CALayer的5倍。 </li><li>Node默认是异步布局/渲染，只有在需要将frame/contents等同步到UIView上才会回到主线程，使其空出更多的时间处理其他事件。 </li><li>ASDK只有在认为需要的时候才会异步地为Node加载相应的View，因此创建Node的开销变得非常低。同时Node是线程安全的，可以在任意queue上创建和设置属性。 </li><li>ASDK不仅有与UIView对应的大部分控件（如ASButtonNode、ASTextNode、ASImageNode、ASTableNode等等），同时也bridge了大多数UIView的方法和属性，可以非常方便的操作frame/backgroundColor/addSubnode等，因此一般情况下只要对Node进行操作，ASDK就会在适当的时候同步到其View。如果需要的话，当相应的View加载之后（或访问node.view手动触发加载），也可以通过node.view的方式直接访问，回到我们熟悉的UIKit。 </li><li>当实现自定义View的时候，ASDisplayNode提供了一个初始化方法initWithViewBlock/initWithLayerBlock，就可以将任意UIView/CALayer用Node包裹起来（被包裹的view可以使用autolayout），从而与ASDK的其他组件相结合。虽然这样创建的Node与一般view在布局和渲染上的差异不大，但是由于Node管理着何时何地加载view，我们仍然能得到一定的性能提升。</li></ol>举例来说，当使用UIKit创建一个UIImageView：<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>使用ASDK后只要稍加改动：<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>虽然只是简单的把View替换成了Node，然而和UIImageView不同的是，此时ASDK已经在悄悄使用另一个线程进行图片解码，从而大大降低新的用户操作到来时主线程被阻塞的概率，使每一个回调都能得到及时的处理。实践中将会有更加复杂的情况，有兴趣的话可以参考项目中的Example目录，有20多个不同场景下的示例项目。<h2>一些细节</h2><ol><li>在ASDisplayNode.h中有相当多的注释，其中displaysAsynchronously属性大致描述了异步渲染的步骤： </li></ol> <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>从中我们可以看到，所有异步渲染操作是先被同一加入asyncdisplaykit_async_transaction，然后一起提交的。在_ASAsyncTransactionGroup.m源文件中，可以看到ASDK是在主线程的runloop（关于runloop可以参考Yaoyuan的 <a href=\"http://blog.ibireme.com/2015/05/18/runloop/\" data-editable=\"true\" data-title=\"深入理解RunLoop | Garan no dou\" class=\"\">深入理解RunLoop | Garan no dou</a>和sunny的 <a href=\"http://v.youku.com/v_show/id_XODgxODkzODI0.html\" data-editable=\"true\" data-title=\"iOS线下分享《RunLoop》by 孙源@sunnyxx\" class=\"\">iOS线下分享《RunLoop》by 孙源@sunnyxx</a>）中注册了observer，在kCFRunLoopBeforeWaiting和kCFRunLoopExit两个activity的回调中将之前异步完成的工作同步到主线程中去。2. ASDisplayNode还有一个属性shouldRasterizeDescendants。<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>当我们不需要分别关注单个CALayer，也不需要对他们进行操作时，就可以将所有的子node都合并到父node的backing store一并绘制，从而达到节省内存和提高性能的目的。 <h2>注意事项</h2><ol><li>ASDK不支持Storyboard和Autolayout，但是可以与使用Autolayout的view兼容共存。同样React native和Component Kit等其他Facebook出品的iOS库也不支持Storyboard。 </li><li>由于Node的异步渲染，很有可能在其View到达屏幕之后，内容仍然在渲染过程中。此时需要额外考虑每个Node的placeholder状态，使用户不至于看到一片空白。 </li><li>在使用ASDisplayNode初始化initWithViewBlock时，由于Node需要在适当的时候调用该block来创建view，因此并不会立即调用block（block可能capture其他变量，例如self），而是存在一个ivar当中。如果该view始终没被创建，而此时拥有该node的父元素被销毁，容易造成retain cycle导致memory leak。 </li></ol> <h2>Best Practice</h2>由于ASDK的基本理念是在需要创建UIView时替换成对应的Node来获取性能提升，因此对于现有代码改动较大，侵入性较高，同时由于大量原本熟悉的操作变成了异步的，对于一个团队来说学习曲线也较为陡峭。从我们在实际项目中的经验，结合Scott的建议来看，不需要也不可能将所有UIView都替换成其Node版本。将注意力集中在可能造成主线程阻塞的地方，如tableView/collectionView、复杂布局的View、使用连续手势的操作等等。找到合适的切入点将一部分性能需求较高的代码替换成ASDK，会是一个较好的选择。对于优化以后的效果，可以尝试我们的应用：<a href=\"http://jike.ruguoapp.com/\" data-editable=\"true\" data-title=\"即刻 - 期待每一次推送\" class=\"\">即刻 - 期待每一次推送</a>，其中消息盒子部分应用了ASDK进行了大量调优工作，从而在拥有大量图片和gif/不定长度文字共存的情况下，仍然能达到60fps的流畅体验。在我们将近两年的实践中，尽管也碰到过一些坑，但是带来的提升也是非常明显的，使在构建更复杂的界面同时保持高性能成为可能。<h2>推荐阅读</h2><a href=\"http://asyncdisplaykit.org/guide/\" class=\"\" data-title=\"AsyncDisplayKit Getting Started\">AsyncDisplayKit Getting Started</a><a href=\"http://www.raywenderlich.com/107310/asyncdisplaykit-tutorial-node-hierarchies\" data-editable=\"true\" data-title=\"AsyncDisplayKit Tutorial: Node Hierarchies\" class=\"\">AsyncDisplayKit Tutorial: Node Hierarchies</a><a href=\"https://www.youtube.com/watch?v=-IPMNWqA638\" data-editable=\"true\" data-title=\"NSLondon — Scott Goodson — Behind AsyncDisplayKit\" class=\"\">NSLondon — Scott Goodson — Behind AsyncDisplayKit</a><a href=\"https://www.youtube.com/watch?v=ZPL4Nse76oY\" data-editable=\"true\" data-title=\"MCE 2015 — Scott Goodson — Effortless Responsiveness with AsyncDisplayKit\" class=\"\">MCE 2015 — Scott Goodson — Effortless Responsiveness with AsyncDisplayKit</a><a href=\"https://www.youtube.com/watch?v=RY_X7l1g79Q\" data-editable=\"true\" data-title=\"AsyncDisplayKit 2.0: Intelligent User Interfaces — NSSpain 2015\" class=\"\">AsyncDisplayKit 2.0: Intelligent User Interfaces — NSSpain 2015</a>","updated":"2017-02-22T09:00:40.000Z","canComment":false,"commentPermission":"anyone","commentCount":4,"likeCount":66,"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":66},"26283742":{"title":"AsyncDisplayKit介绍（二）布局系统","author":"ji-ke-ji-shu-tuan-dui-36","content":"在上一篇介绍中我们曾经讨论过Autolayout的性能问题。然而在iOS中，除了Autolayout，能选择的只有autoresizingMask，或者纯手动布局。在写了无数view.frame = CGRect(…)之后，我们才发现，一个在HTML中非常简单的流式布局，到iOS9才有相应的UIStackView予以支持（如果用UICollectionView则需要将view包装成CollectionViewCell）。尽管你可以使用<a href=\"https://github.com/forkingdog/FDStackView\" data-editable=\"true\" data-title=\"FDStackView\" class=\"\">FDStackView</a>将系统要求降低到iOS6，对于复杂的布局仍然需要多层View嵌套来实现——其实对于实现stack布局的时候，并不需要一个真正的UIView实例来承载所有的元素，而只是需要它的布局功能而已（就好比UICollectionViewFlowLayout，只负责控制若干个元素的布局规则而不真正负责布局）。\n做过Web开发的朋友已经习惯了高效的css布局：声明式、易于调试，boxModel结构化清晰等等优点，特别是使用自动化工具之后，只需要保存文件就可以立即在浏览器中看到更新后的效果；而这一切在iOS中就变得遥不可及：命令式赋值、编译后（Objc速度尚可，而swift编译速度较慢）才能看到结果、Autolayout闭源、视图调试复杂、xcode经常crash等等。如果要实现一个高性能的tableView/collectionView，手写布局几乎是唯一选择。\n<h2>Layout的本质</h2>\n在决定使用哪种布局方式之前，先看看设计师是怎么思考布局的：\n<ol><li>每个元素的大小（size）\n</li>\n<li>兄弟元素之间的位置关系：对齐（alignment）和间距（spacing）；父子元素之间的容纳关系：子元素的边距（insets）\n</li>\n</ol>设计师确定的，是一个布局规则。\n设计稿到了工程师这边以后，我们绝大多数时间都在做以下两件事：\n<ol><li>确定UIView自身的大小（覆盖sizeThatFits方法），与parent view无关\n</li>\n<li>根据规则，将subview放在父parent内的指定位置（对应layoutSubviews），由parent view决定\n</li>\n</ol>这样自底向上层层递归，最终完成整个屏幕内所有子元素的布局。工程师完成的，是一个基于布局规则的具体实现，关注的对象是单个view或者是两个相邻view之间的关系。\n也就是说，手动布局或者通过约束（Autolayout）其实是在『实现』布局规则，而不是『声明』布局规则。抽象层级下降了，随之而来的是多到令人头疼的frame、size、origin计算，可读性、可维护性都非常差。那能不能提高抽象层级，用一个数据结构来表示布局规则，从而摆脱繁重又容易出错的数值计算，让布局系统根据规则自动地、异步地计算呢？ <h2>AsyncDisplayKit的三种布局方式</h2>\n1. 手动布局\n这是最基础的一种布局方式。在ASDK中的手动布局与UIKit的手动布局类似，只是方法名从sizeThatFits变成了calculatedSizeThatFits，layoutSubviews方法变成了layout方法。略微不同的是ASDK会将布局结果预先在后台线程进行计算，并缓存下来以提升性能，这点对于tableView滚动流畅性有非常大的帮助。\n然而，跟普通手动布局类似，最大的缺点是可读性和可维护性差。由于自身的大小常常和子元素的布局相关联，这两个方法中的代码容易重复；同时由于布局针对自身subView，很难将其代码与其他View进行复用。\n2. Unified layout\n这也是在ASDK中新出现的概念。先介绍一下ASLayout：<img src=\"v2-fe3cd3d79a64071512f8fa6d6c9ccc4a.png\" data-rawwidth=\"1340\" data-rawheight=\"1000\"> 一个ASLayout对象包含以下元素：\n<ul><li>它所代表的布局元素\n</li>\n<li>元素的尺寸\n</li>\n<li>元素的位置\n</li>\n<li>它所包含的sublayouts\n</li>\n</ul>可以看出，当一个node具备了确定的ASLayout对象时，它自身的布局也就随之确定了。为了生成ASLayout，ASDisplayNode为subclass提供了如下覆盖点：\n<code lang=\"text\">- (ASLayout *)calculateLayoutThatFits:(ASSizeRange)constrainedSize\n</code>只要Node能够计算出自己的ASLayout，父元素就可以完成对其的布局。这种方法将sizeThatFits和layoutSubviews结合在一起，一定程度上避免了相似代码的尴尬，但是计算上仍然是手动布局，不够简便。\n3. Automatic Layout(不是系统的Autolayout)\n有了ASLayout这一层抽象，如何通过声明规则而不是通过计算得到它，是问题的核心。\nFacebook将React的概念延伸到native，同时也把声明式的语法带到了iOS，产生了<a href=\"https://github.com/facebook/componentkit\" data-editable=\"true\" data-title=\"ComponentKit\" class=\"\">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\" data-editable=\"true\" data-title=\"演讲pdf\" class=\"\">演讲pdf</a>作为插图，方便大家了解新的布局系统。\nAutomatic Layout是ASDK最推荐也是最为高效的布局方式。它引入了ASLayoutSpec的概念，来描述抽象的布局规则（并不需要创建对应node或者view来装载子元素）。一旦确定布局规则，它就能依照规则对其负责的子元素进行布局计算，得到每个布局元素的ASLayout对象。\n我们先来看一下它们之间的关系：\n<img src=\"v2-7cc4780a65e481894d1563e3808d2843.png\" data-rawwidth=\"1336\" data-rawheight=\"1001\">可以看到ASLayoutSpec和ASDisplayNode都实现了ASLayoutable接口，因此他们都具备生成ASLayout的能力，这样就能唯一确定自身的大小。\n<ul><li>对于以上提到的Unified布局，当我们实现了calculateLayoutThatFits，ASDK会在布局过程中调用measureWithSizeRange(如果没有缓存过再调用calculateLayoutThatFits)来算出ASLayout。\n</li>\n<li>如果ASDisplayNode选择实现layoutSpecThatFits，由更为抽象的ASLayoutSpec来负责指定布局规则，由于ASLayoutSpec也实现了ASLayoutable接口，同样也可以通过调用measureWithSizeRange来获得ASLayout。\n</li>\n</ul>由于ASLayoutSpec只负责指定布局规则，而不关心其布局的ASLayoutable具体是Node还是其他ASLayoutSpec，我们可以轻松地将ASLayoutSpec生成逻辑独立出来，达到复用的目的。\n<h4>挑大梁的ASStackLayoutSpec</h4>\nASLayoutSpec主要有以下几种：<img src=\"v2-0c71f153552795c642c6dcfe729a0fd2.png\" data-rawwidth=\"1336\" data-rawheight=\"988\">通过它们的命名就可以了解其大致作用。其中用途最广泛的无疑是ASStackLayoutSpec，与UIStackView有异曲同工之妙。\nASStackLayoutSpec大量借鉴了CSS的flexbox概念，写过Web代码的同学应该能一眼认出许多熟悉的属性：justifyContent/flexDirection/alignSelf/alignItems/flexBasis等等。不熟悉的朋友也可以通过一个有趣的游戏来学习flexbox：<a href=\"http://flexboxfroggy.com/\" data-editable=\"true\" data-title=\"Flexbox Froggy\" class=\"\">Flexbox Froggy</a>\n<h3>示例</h3>\n(图中的Huy Nguyen也是ASDK布局的主要贡献者之一)<img src=\"v2-50e16b5af99156b2e6882648941512c4.png\" data-rawwidth=\"1350\" data-rawheight=\"1003\"> 图中左边是一个imageNode，右边是由两个textNode组成的一个vertical\nstack，再和imageNode组合成一个横向的stack，最后加上边缘inset完成整个布局。\n事实上，与css类似，绝大多数的布局都可以通过stack和inset的组合来完成；而和UIStackView不同的是，layout spec只是一个存在于内存之中的数据结构，并不需要额外创建view容器来承载子元素，大大节约了复杂布局带来的开销；同时因为它的轻量级和独立性，因此能够将布局规则放到后台线程独立计算，并缓存在node之中，对于大量tableView/collectionView的CellNode快速布局有相当大的帮助。\nHuy Nguyen也为ASLayoutSpec写了一个寓教于乐的<a href=\"http://nguyenhuy.github.io/froggy-asdk-layout/\" data-editable=\"true\" data-title=\"小游戏\" class=\"\">小游戏</a>，只是将上面提到的的针对css的小游戏版本改成了Objc，方便大家快速学习。\n在最近的版本中，ASDK也同时支持 <a href=\"https://github.com/facebook/yoga\" data-editable=\"true\" data-title=\"Yoga\" class=\"\">Yoga</a> （一个跨平台的flexbox引擎，使用C语言实现）来计算基于flexbox的布局，与ASDK本身实现的flexbox概念类似。\n<h3>即刻的实践</h3>\n即刻在多个消息页面使用了ASDK新的布局系统，例如：\n<img src=\"v2-4087a894b3c8190d3f98fa273c9e68c5.png\" data-rawwidth=\"766\" data-rawheight=\"896\">从我们的实践经验来看有以下优缺点：\n<h4>优点</h4>\n<ul><li>实现一个layout的视角从专注view之间的距离和约束，转变成划分和制定不同view子区域的布局规则，抽象层级变高，可读性、可维护性大大增强。\n</li>\n<li>由于ASDisplayNode的显示是异步的，因此无论布局是否依赖于显示结果，都可以在主线程以外进行，并且有缓存，性能有很大提升。\n</li>\n<li>借用CSS成熟的flexbox布局模型，有大量现成资料和案例来学习，避免了新造轮子的尴尬。\n</li>\n<li>由于ASDK是开源的，调试难度大大降低。\n</li>\n<li>布局规则可以脱离实际布局对象进行独立声明，容易复用。\n</li>\n</ul><h4>缺点</h4>\n<ul><li>由于与iOS原生布局方式完全不同，学习适应需要一定时间（如果将来flexbox渐渐成为前端标准，花一些时间了解也是完全值得的。）\n</li>\n<li>对于ASDK依赖非常重。如果你想对已有的view改造成用flexbox进行布局，需要重新使用ASDisplayNode来实现该view。如果不方便重新写，只能选用类似Yoga的独立框架来实现功能。\n</li>\n<li>虽然是声明式布局，然而相对css而言仍较为繁琐。去年参加WWDC时我曾经到Pinterest与Scott有过一些当面交流，也尝试说服他们做一些DSL来简化布局声明。他们的回答是，由于ASDK的复杂性和基础性（类似UIKit），他们仍然将大部分时间放在优化异步渲染和布局性能，并没有太多精力在layout的语法上做出进一步突破。可能当布局系统生长成为独立框架以后分开来做比较合适。\n</li>\n</ul>尽管即刻没有在整个项目都采用新的的布局方式，然而ASDK带来的启发是深远的：声明式、异步布局、flexbox、缓存等等。我们也看到有一些其他布局库做了许多声明式的尝试，如<a href=\"https://github.com/wayfair/brickkit-ios\" data-editable=\"true\" data-title=\"Brickkit\" class=\"\">Brickkit</a>, <a href=\"https://github.com/linkedin/LayoutKit\" data-editable=\"true\" data-title=\"Layoutkit\" class=\"\">Layoutkit</a>等等，从而加快我们平时的开发和维护效率。 PS: 即刻正在招聘，如果你是一个追求极致又富有探索精神的iOS工程师，同时也热爱我们的产品，那么欢迎加入我们，一起参加WWDC（公司cover全部费用），持续打造更棒的即刻！联系我们：<a href=\"mailto:hr@ruguoapp.com\" data-editable=\"true\" data-title=\"hr@ruguoapp.com\" class=\"\">hr@ruguoapp.com</a>","updated":"2017-04-11T07:01:42.000Z","canComment":false,"commentPermission":"anyone","commentCount":13,"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":13,"likesCount":17}},"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":{"jikeapp":{"pins":[],"followersCount":1583,"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":2,"id":1724,"name":"iOS 开发"},{"postsCount":1,"id":158144,"name":"Kubernetes"},{"postsCount":1,"id":3527,"name":"MongoDB"},{"postsCount":1,"id":6231,"name":"推送（Push）"},{"postsCount":1,"id":10100,"name":"布局"},{"postsCount":1,"id":1800,"name":"Android 开发"},{"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":15950,"name":"ETL"}],"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":5,"canPost":false,"FULLINFO":true}},"columnPosts":{"jikeapp":{"entity":["26283742","25371361"],"topic":"iOS 开发"}},"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":[]},"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":{}}