• AsyncDisplayKit

    一个第三方库能做到像新产品一样，值得大家去写写使用体会的，并不多见，AsyncDisplayKit却完全可以，因为AsyncDisplayKit不仅仅是一个工具，它更像一个系统UI框架，改变整个编码体验。也正是这种极强的侵入性，导致不少听过、star过，甚至下过demo跑过AsyncDisplayKit的你我，望而却步，驻足观望。但列表界面稍微复杂时，烦人的高度计算，因为性能不得不放弃Autolayout而选择上古时代的frame layout，令人精疲力尽，这时AsyncDisplayKit总会不自然浮现眼前，让你跃跃欲试。

    去年10月份，我们入坑了。

    当时还只是拿简单的列表页试水，基本上手后，去年底在稍微空闲的时候用AsyncDisplayKit重构了帖子详情，今年三月份，又借着公司聊天增加群聊的契机，用AsyncDisplayKit重构整个聊天。林林总总，从简单到复杂，踩过的坑大大小小，将近一年的时光转眼飞逝，可以写写总结了。

    学习曲线

    先说说学习曲线，这是大家都比较关心的问题。

    跟大多人一样，一开始我以为AsyncDisplayKit会像Rxswift等MVVM框架一样，有着陡峭的学习曲线。但事实上，AsyncDisplayKit的学习曲线还算平滑。

    主要是因为AsyncDisplayKit只是对UIKit的再一次封装，基本沿用了UIKit的API设计，大部分情况下，只是将view改成node，UI前缀改为AS，写着写着，恍惚间，你以为自己还是在写UIKit呢。

    比如ASDisplayNode与UIView：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    		 
    let nodeA = ASDisplayNode()
    let nodeB = ASDisplayNode()
    let nodeC = ASDisplayNode()
    nodeA.addSubnode(nodeB)
    nodeA.addSubnode(nodeC)
    nodeA.backgroundColor = .red
    nodeA.frame = CGRect(x: 0, y: 0,  100, height: 100)
    nodeC.removeFromSupernode()

    let viewA = UIView()
    let viewB = UIView()
    let viewC = UIView()
    viewA.addSubview(viewB)
    viewA.addSubview(viewC)
    viewA.backgroundColor = .red
    viewA.frame = CGRect(x: 0, y: 0,  100, height: 100)
    viewC.removeFromSuperview()

    相信你看两眼也就摸出门道了，大部分API一模一样。

    真正发生翻天覆地变化的是布局方式，AsyncDisplayKit用的是flexbox布局，UIView使用的是Autolayout。用AsyncDisplayKit的flexbox布局替代Autolayout布局，完全不亚于用Autolayout替换frame布局的蜕变，需要比较大的观念转变。

    但flexbox布局被提出已久，且其本身直观简单，较容易上手，学习曲线只是略陡峭。

    这里有一个学习AsyncDisplayKit布局的小游戏，简单有趣，可以一玩。

    整体上两天即可上手，无须担心学习曲线问题。

    体会

    当过了上手的艰难阶段后，才是真正开始体会AsyncDisplayKit的时候。用了将近一年，有几点AsyncDisplayKit的优势相当明显：

    1）cell中再也不用算高度和位置等frame信息了
    这是非常非常非常非常诱人的，当cell中有动态文本时，文本的高度计算很费神，计算完，还得缓存，如果再加上其他动态内容，比如有时候没图片，那frame算起来，简直让人想哭，而如果用AsyncDisplayKit，所有的height、frame计算都烟消云散，甚至都不知道frame这个东西存在过，很酸爽。

    2）一帧不掉
    平时界面稍微动态点，元素稍微多点，Autolayout的性能就不堪重用，而上古时代的frame布局在高效缓存的基础上确实可以做到高性能，但frame缓存的维护和计算都不是一般的复杂，而AsyncDisplayKit却能在保持简介布局的同时，做到一帧不掉，这是多么的让人感动！

    3）更优雅的架构设计
    前两点好处是用AsyncDisplayKit最直接最容易被感受到的，其实，当深入使用时，你会发现，AsyncDisplayKit还会给程序架构设计带来一些改变，会使原本复杂的架构变得更简单，更优雅，更灵活，更容易维护，更容易扩展，也会使整个代码更容易理解，而这个影响是深远的，毕竟代码是写给别人看的。

    但AsyncDisplayKit有一个极其著名的问题，闪烁。

    当我们开始试水使用AsyncDisplayKit时，只要简单reload一下TableNode，那闪烁，眼睛都瞎了。后来查了官方的issue，才发现很多人都提了这个问题，但官方也没给出什么优雅的解决方案。要知道，闪烁是非常影响用户体验的。如果非要在不闪烁和带闪烁的AsyncDisplayKit中选择，我会毫不犹豫的选择不闪烁，而放弃使用AsyncDisplayKit。但现在已经不存在这个选择了，因为经过AsyncDisplayKit的多次迭代努力加上一些小技巧，AsyncDisplayKit的异步闪烁已经被优雅的解决了。

    但AsyncDisplayKit不宜广泛使用，那些高度固定、UI简单用UIKit更好一些，毕竟AsyncDisplayKit并不像UIKit，人人都会，如果内容和高度复杂又很动态，强烈推荐AsyncDisplayKit，它会简化太多东西。

    疑难点

    一年的AsyncDisplayKit使用经验，踩过了不少坑，遇到了不少值得注意的问题，一并列在这里，以供参考。

    ASNetworkImageNode的缓存

    ASNetworkImageNode是对UIImageView需要从网络加载图片这一使用场景的封装，省去了YYWebImage或者SDWebImage等第三方库的引入，只需要设置URL即可实现网络图片的自动加载。

    1
    2
    3
    4
    		 
    import AsyncDisplayKit

    let avatarImageNode = ASNetworkImageNode()
    avatarImageNode.url = URL(string: "http://shellhue.github.io/images/log.png")

    这非常省事便捷，但ASNetworkImageNode默认用的缓存机制和图片下载器是PinRemoteImage，为了使用我们自己的缓存机制和图片下载器，需要实现ASImageCacheProtocol图片缓存协议和 ASImageDownloaderProtocol图片下载器协议两个协议，然后初始化时，用ASNetworkImageNode的init(cache: ASImageCacheProtocol, downloader: ASImageDownloaderProtocol)初始化方法，传入对应的类，方便其间，一般会自定义一个初始化静态方法。我们公司缓存机制和图片下载器都是用的YYWebImage，桥接代码如下。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    		 
    import YYWebImage
    import AsyncDisplayKit

    extension ASNetworkImageNode {
      static func imageNode() -> ASNetworkImageNode {
        let manager = YYWebImageManager.shared()
        return ASNetworkImageNode(cache: manager, downloader: manager)
      }
    }

    extension YYWebImageManager: ASImageCacheProtocol, ASImageDownloaderProtocol {
      public func downloadImage(with URL: URL,
                                callbackQueue: DispatchQueue,
                                downloadProgress: AsyncDisplayKit.ASImageDownloaderProgress?,
                                completion: @escaping AsyncDisplayKit.ASImageDownloaderCompletion) -> Any? {
        weak var operation: YYWebImageOperation?
        operation = requestImage(with: URL,
                                 options: .setImageWithFadeAnimation,
                                 progress: { (received, expected) -> Void in
                                  callbackQueue.async(execute: {
                                    let progress = expected == 0 ? 0 : received / expected
                                    downloadProgress?(CGFloat(progress))
                                  })
        }, transform: nil, completion: { (image, url, from, state, error) in
          completion(image, error, operation)
        })
        
        return operation
      }
      
      public func cancelImageDownload(forIdentifier downloadIdentifier: Any) {
        guard let operation = downloadIdentifier as? YYWebImageOperation else {
          return
        }
        operation.cancel()
      }
      
      public func cachedImage(with URL: URL, callbackQueue: DispatchQueue, completion: @escaping AsyncDisplayKit.ASImageCacherCompletion) {
        cache?.getImageForKey(cacheKey(for: URL), with: .all, with: { (image, cacheType) in
          callbackQueue.async {
            completion(image)
          }
        })
      }
    }

    闪烁

    初次使用AsyncDisplayKit，当享受其一帧不掉如丝般柔滑的手感时，ASTableNode和ASCollectionNode刷新时的闪烁一定让你几度崩溃，到AsyncDisplayKit的github上搜索闪烁相关issue，会出来100多个问题。闪烁是AsyncDisplayKit与生俱来的问题，闻名遐迩，而闪烁的体验非常糟糕。幸运的是，几经探索，AsyncDisplayKit的闪烁问题已经完美解决，这个完美指的是一帧不掉的同时没有任何闪烁，同时也没增加代码的复杂度。

    闪烁可以分为四类，

    1）ASNetworkImageNode reload时的闪烁

    当ASCellNode中包含ASNetworkImageNode，则这个cell reload时，ASNetworkImageNode会异步从本地缓存或者网络请求图片，请求到图片后再设置ASNetworkImageNode展示图片，但在异步过程中，ASNetworkImageNode会先展示PlaceholderImage，从PlaceholderImage—>fetched image的展示替换导致闪烁发生，即使整个cell的数据没有任何变化，只是简单的reload，ASNetworkImageNode的图片加载逻辑依然不变，因此仍然会闪烁，这显著区别于UIImageView，因为YYWebImage或者SDWebImage对UIImageView的image设置逻辑是，先同步检查有无内存缓存，有的话直接显示，没有的话再先显示PlaceholderImage，等待加载完成后再显示加载的图片，也即逻辑是memory cached image—>PlaceholderImage—>fetched image的逻辑，刷新当前cell时，如果数据没有变化memory cached image一般都会有，因此不会闪烁。

    AsyncDisplayKit官方给的修复思路是：

    1
    2
    3
    4
    5
    		 
    import AsyncDisplayKit

    let node = ASNetworkImageNode()
    node.placeholderColor = UIColor.red
    node.placeholderFadeDuration = 3

    这样修改后，确实没有闪烁了，但这只是将PlaceholderImage—>fetched image图片替换导致的闪烁拉长到3秒而已，自欺欺人，并没有修复。

    既然闪烁是reload时，没有事先同步检查有无缓存导致的，继承一个ASNetworkImageNode的子类，复写url设置逻辑：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    		 
    import AsyncDisplayKit

    class NetworkImageNode: ASNetworkImageNode {
      override var url: URL? {
        didSet {
          if let u = url,
            let image = UIImage.cachedImage(with: u) else {
            self.image = image
            placeholderEnabled = false
          }
        }
      }
    }

    按道理不会闪烁了，但事实上仍然会，只要是个ASNetworkImageNode，无论怎么设置，都会闪，这与官方的API说明严重不符，很无语。迫不得已之下，当有缓存时，直接用ASImageNode替换ASNetworkImageNode。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    		 
    import AsyncDisplayKit

    class NetworkImageNode: ASDisplayNode {
      private var networkImageNode = ASNetworkImageNode.imageNode()
      private var imageNode = ASImageNode()
      
      var placeholderColor: UIColor? {
        didSet {
          networkImageNode.placeholderColor = placeholderColor
        }
      }
      
      var image: UIImage? {
        didSet {
          networkImageNode.image = image
        }
      }
      
      override var placeholderFadeDuration: TimeInterval {
        didSet {
          networkImageNode.placeholderFadeDuration = placeholderFadeDuration
        }
      }
      
      var url: URL? {
        didSet {
          guard let u = url,
            let image = UIImage.cachedImage(with: u) else {
              networkImageNode.url = url
              return
          }
          
          imageNode.image = image
        }
      }
      
      override init() {
        super.init()
        addSubnode(networkImageNode)
        addSubnode(imageNode)
      }
      
      override func layoutSpecThatFits(_ constrainedSize: ASSizeRange) -> ASLayoutSpec {
        return ASInsetLayoutSpec(insets: .zero,
                                 child: networkImageNode.url == nil ? imageNode : networkImageNode)
      }
      
      func addTarget(_ target: Any?, action: Selector, forControlEvents controlEvents: ASControlNodeEvent) {
        networkImageNode.addTarget(target, action: action, forControlEvents: controlEvents)
        imageNode.addTarget(target, action: action, forControlEvents: controlEvents)
      }
    }

    使用时将NetworkImageNode当成ASNetworkImageNode使用即可。

    2）reload 单个cell时的闪烁

    当reload ASTableNode或者ASCollectionNode的某个indexPath的cell时，也会闪烁。原因和ASNetworkImageNode很像，都是异步惹的祸。当异步计算cell的布局时，cell使用placeholder占位（通常是白图），布局完成时，才用渲染好的内容填充cell，placeholder到渲染好的内容切换引起闪烁。UITableViewCell因为都是同步，不存在占位图的情况，因此也就不会闪。

    先看官方的修改方案，

    1
    2
    3
    4
    5
    6
    7
    8
    		 
    func tableNode(_ tableNode: ASTableNode, nodeForRowAt indexPath: IndexPath) -> ASCellNode {
      let cell = ASCellNode()
      ... // 其他代码
        
      cell.neverShowPlaceholders = true
      
      return cell
    }

    这个方案非常有效，因为设置cell.neverShowPlaceholders = true，会让cell从异步状态衰退回同步状态，若reload某个indexPath的cell，在渲染完成之前，主线程是卡死的，这与UITableView的机制一样，但速度会比UITableView快很多，因为UITableView的布局计算、资源解压、视图合成等都是在主线程进行，而ASTableNode则是多个线程并发进行，何况布局等还有缓存。所以，一般也没有问题，贝聊的聊天界面只是简单这样设置后，就不闪了，而且一帧不掉。但当页面布局较为复杂时，滑动时的卡顿掉帧就变的肉眼可见。

    这时，可以设置ASTableNode的leadingScreensForBatching减缓卡顿

    1
    2
    3
    4
    5
    6
    		 
    override func viewDidLoad() {
      super.viewDidLoad()
      ... // 其他代码
        
      tableNode.leadingScreensForBatching = 4
    }

    一般设置tableNode.leadingScreensForBatching = 4即提前计算四个屏幕的内容时，掉帧就很不明显了，典型的空间换时间。但仍不完美，仍然会掉帧，而我们期望的是一帧不掉，如丝般顺滑。这不难，基于上面不闪的方案，刷点小聪明就能解决。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    		 
    class ViewController: ASViewController {
      ... // 其他代码
      private var indexPathesToBeReloaded: [IndexPath] = []
      
      func tableNode(_ tableNode: ASTableNode, nodeForRowAt indexPath: IndexPath) -> ASCellNode {
        let cell = ASCellNode()
        ... // 其他代码
          
        cell.neverShowPlaceholders = false
        if indexPathesToBeReloaded.contains(indexPath) {
          let oldCellNode = tableNode.nodeForRow(at: indexPath)
          cell.neverShowPlaceholders = true
          oldCellNode?.neverShowPlaceholders = true
          DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, execute: {
            cell.neverShowPlaceholders = false
            if let indexP = self.indexPathesToBeReloaded.index(of: indexPath) {
              self.indexPathesToBeReloaded.remove(at: indexP)
            }
          })
        }
        return cell
      }
      
      func reloadActionHappensHere() {
        ... // 其他代码
        
        let indexPath = ... // 需要roload的indexPath
          indexPathesToBeReloaded.append(indexPath)
        tableNode.reloadRows(at: [indexPath], with: .none)
      }
    }

    关键代码是，

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    		 
    if indexPathesToBeReloaded.contains(indexPath) {
      let oldCellNode = tableNode.nodeForRow(at: indexPath)
      cell.neverShowPlaceholders = true
      oldCellNode?.neverShowPlaceholders = true
      DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, execute: {
        cell.neverShowPlaceholders = false
        if let indexP = self.indexPathesToBeReloaded.index(of: indexPath) {
          self.indexPathesToBeReloaded.remove(at: indexP)
        }
      })
    }

    即，检查当前的indexPath是否被标记，如果是，则先设置cell.neverShowPlaceholders = true，等待reload完成（一帧是1/60秒，这里等待0.5秒，足够渲染了），将cell.neverShowPlaceholders = false。这样reload时既不会闪烁，也不会影响滑动时的异步绘制，因此一帧不掉。

    这完全是耍小聪明的做法，但确实非常有效。

    3）reloadData时的闪烁

    在下拉刷新后，列表经常需要重新刷新，即调用ASTableNode或者ASCollectionNode的reloadData方法，但会闪，而且很明显。有了单个cell reload时闪烁的解决方案后，此类闪烁解决起来，就很简单了。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    		 
    func reloadDataActionHappensHere() {
      ... // 其他代码
      
      let count = tableNode.dataSource?.tableNode?(tableNode, numberOfRowsInSection: 0) ?? 0
      if count > 2 {
        // 将肉眼可见的cell添加进indexPathesToBeReloaded中
        indexPathesToBeReloaded.append(IndexPath(row: 0, section: 0))
        indexPathesToBeReloaded.append(IndexPath(row: 1, section: 0))
        indexPathesToBeReloaded.append(IndexPath(row: 2, section: 0))
      }
      tableNode.reloadData()
        
      ... // 其他代码
    }

    将肉眼可见的cell添加进indexPathesToBeReloaded中即可。

    4）insertItems时更改ASCollectionNode的contentOffset引起的闪烁

    我们公司的聊天界面是用AsyncDisplayKit写的，当下拉加载更多新消息时，为保持加载后当前消息的位置不变，需要在collectionNode.insertItems(at: indexPaths)完成后，复原collectionNode.view.contentOffset，代码如下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    		 
    func insertMessagesToTop(indexPathes: [IndexPath]) {
      let originalContentSizeHeight = collectionNode.view.contentSize.height
      let originalContentOffsetY = collectionNode.view.contentOffset.y
      let heightFromOriginToContentBottom = originalContentSizeHeight - originalContentOffsetY
      let heightFromOriginToContentTop = originalContentOffsetY
      collectionNode.performBatch(animated: false, updates: {
        self.collectionNode.insertItems(at: indexPaths)
      }) { (finished) in
        let contentSizeHeight = self.collectionNode.view.contentSize.height
        self.collectionNode.view.contentOffset = CGPointMake(0, isLoadingMore ? (contentSizeHeight - heightFromOriginToContentBottom) : heightFromOriginToContentTop)
      }
    }

    遗憾的是，会闪烁。起初以为是AsyncDisplayKit异步绘制导致的闪烁，一度还想放弃AsyncDisplayKit，用UITableView重写一遍，幸运的是，当时项目工期太紧，没有时间重写，也没时间仔细排查，直接带问题上线了。

    最近闲暇，经仔细排查，方知不是AsyncDisplayKit的锅，但也比较难修，有一定的参考价值，因此一并列在这里。

    闪烁的原因是，collectionNode insertItems成功后会先绘制contentOffset为CGPoint(x: 0, y: 0)时的一帧画面，无动画时这一帧画面立即显示，然后调用成功回调，回调中复原了collectionNode.view.contentOffset，下一帧就显示复原了位置的画面，前后有变化因此闪烁。这是做消息类APP一并会遇到的bug，google一下，主要有两种解决方案，

    第一种，通过仿射变换倒置ASCollectionNode，这样下拉加载更多，就变成正常列表的上拉加载更多，也就无需移动contentOffset。ASCollectionNode还特意设置了个属性inverted，方便大家开发。然而这种方案换汤不换药，当收到新消息，同时正在查看历史消息，依然需要插入新消息并复原contentOffset，闪烁依然在其他情形下发生。

    第二种，集成一个UICollectionViewFlowLayout，重写prepare()方法，做相应处理即可。这个方案完美，简介优雅。子类化的CollectionFlowLayout如下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    		 
    class CollectionFlowLayout: UICollectionViewFlowLayout {
      var isInsertingToTop = false
      override func prepare() {
        super.prepare()
        guard let collectionView = collectionView else {
          return
        }
        if !isInsertingToTop {
          return
        }
        let oldSize = collectionView.contentSize
        let newSize = collectionViewContentSize
        let contentOffsetY = collectionView.contentOffset.y + newSize.height - oldSize.height
        collectionView.setContentOffset(CGPoint(x: collectionView.contentOffset.x, y: contentOffsetY), animated: false)
      }
    }

    当需要insertItems并且保持位置时，将CollectionFlowLayout的isInsertingToTop设置为true即可，完成后再设置为false。如下，

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    		 
    class MessagesViewController: ASViewController {
      ... // 其他代码
      var collectionNode: ASCollectionNode!
      var flowLayout: CollectionFlowLayout!
      override func viewDidLoad() {
        super.viewDidLoad()
        flowLayout = CollectionFlowLayout()
        collectionNode = ASCollectionNode(collectionViewLayout: flowLayout)
        ... // 其他代码
      }
      
      ... // 其他代码
      
      func insertMessagesToTop(indexPathes: [IndexPath]) {
        flowLayout.isInsertingToTop = true
        collectionNode.performBatch(animated: false, updates: {
          self.collectionNode.insertItems(at: indexPaths)
        }) { (finished) in
          self.flowLayout.isInsertingToTop = false
        }
      }
      
      ... // 其他代码
    }

    布局

    AsyncDisplayKit采用的是flexbox的布局思想，非常高效直观简洁，但毕竟迥异于AutoLayout和frame layout的布局风格，咋一上手，很不习惯，有些小技巧还是需要慢慢积累，有些概念也需要逐渐熟悉深入，下面列举几个笔者觉得比较重要的概念

    1）设置任意间距

    AutoLayout实现任意间距，比较容易直观，因为AutoLayout的约束，本来就是我的边离你的边有多远的概念，而AsyncDisplayKit并没有，AsyncDisplayKit里面的概念是，我自己的前面有多少空白距离，我自己的后面有多少空白距离，更强调自己。假如有三个元素，怎么约束它们之间的间距？

    AutoLayout是这样的：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    		 
    import Masonry
    class SomeView: UIView {
      override init() {
        super.init()
        let viewA = UIView()
        let viewB = UIView()
        let viewC = UIView()
        addSubview(viewA)
        addSubview(viewB)
        addSubview(viewC)
        
        viewB.snp.makeConstraints { (make) in
          make.left.equalTo(viewA.snp.right).offset(15)
        }
        
        viewC.snp.makeConstraints { (make) in
          make.left.equalTo(viewB.snp.right).offset(5)
        }
      }
    }

    而AsyncDisplayKit是这样的：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    		 
    import AsyncDisplayKit
    class SomeNode: ASDisplayNode {
      let nodeA = ASDisplayNode()
      let nodeB = ASDisplayNode()
      let nodeC = ASDisplayNode()
      override init() {
        super.init()
        addSubnode(nodeA)
        addSubnode(nodeB)
        addSubnode(nodeC)
      }
      override func layoutSpecThatFits(_ constrainedSize: ASSizeRange) -> ASLayoutSpec {
        nodeB.style.spaceBefore = 15
        nodeC.stlye.spaceBefore = 5
        
        return ASStackLayoutSpec(direction: .horizontal, spacing: 0, justifyContent: .start, alignItems: .start, children: [nodeA, nodeB, nodeC])
      }
    }

    如果是拿ASStackLayoutSpec布局，元素之间的任意间距一般是通过元素自己的spaceBefore或者spaceBefore style实现，这是自我包裹性，更容易理解，如果不是拿ASStackLayoutSpec布局，可以将某个元素包裹成ASInsetsLayoutSpec，再设置UIEdgesInsets，保持自己的四周任意边距。

    能任意设置间距是自由布局的基础。

    2）flexGrow和flexShrink

    flexGrow和flexShrink是相当重要的概念，flexGrow是指当有多余空间时，拉伸谁以及相应的拉伸比例（当有多个元素设置了flexGrow时），flexShrink相反，是指当空间不够时，压缩谁及相应的压缩比例（当有多个元素设置了flexShrink时）。
    灵活使用flexGrow和spacer(占位ASLayoutSpec)可以实现很多效果，比如等间距，

    实现代码如下，

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    		 
    import AsyncDisplayKit
    class ContainerNode: ASDisplayNode {
      let nodeA = ASDisplayNode()
      let nodeB = ASDisplayNode()
      override init() {
        super.init()
        addSubnode(nodeA)
        addSubnode(nodeB)
      }
      override func layoutSpecThatFits(_ constrainedSize: ASSizeRange) -> ASLayoutSpec {
        let spacer1 = ASLayoutSpec()
        let spacer2 = ASLayoutSpec()
        let spacer3 = ASLayoutSpec()
        spacer1.stlye.flexGrow = 1
        spacer2.stlye.flexGrow = 1
        spacer3.stlye.flexGrow = 1
        
        return ASStackLayoutSpec(direction: .horizontal, spacing: 0, justifyContent: .start, alignItems: .start, children: [spacer1, nodeA,spacer2, nodeB, spacer3])
      }
    }

    如果spacer的flexGrow不同就可以实现指定比例的布局，再结合width样式，轻松实现以下布局

    布局代码如下，

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    		 
    override func layoutSpecThatFits(_ constrainedSize: ASSizeRange) -> ASLayoutSpec {
      let spacer1 = ASLayoutSpec()
      let spacer2 = ASLayoutSpec()
      let spacer3 = ASLayoutSpec()
      spacer1.stlye.flexGrow = 2
      spacer2.stlye.width = ASDimensionMake(100)
      spacer3.stlye.flexGrow = 1
      
      return ASStackLayoutSpec(direction: .horizontal, spacing: 0, justifyContent: .start, alignItems: .start, children: [spacer1, nodeA,spacer2, nodeB, spacer3])
    }

    相同的布局如果用Autolayout，麻烦去了。

    3）constrainedSize的理解

    constrainedSize是指某个node的大小取值范围，有minSize和maxSize两个属性。比如下图的布局：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    		 
    import AsyncDisplayKit
    class ContainerNode: ASDisplayNode {
      let nodeA = ASDisplayNode()
      let nodeB = ASDisplayNode()
      override init() {
        super.init()
        addSubnode(nodeA)
        addSubnode(nodeB)
        nodeA.style.preferredSize = CGSize( 100, height: 100)
      }

      override func layoutSpecThatFits(_ constrainedSize: ASSizeRange) -> ASLayoutSpec {
        nodeB.style.flexShrink = 1
        nodeB.style.flexGrow = 1
        let stack = ASStackLayoutSpec(direction: .horizontal, spacing: e, justifyContent: .start, alignItems: .start, children: [nodeA, nodeB])
        return ASInsetLayoutSpec(insets: UIEdgeInsetsMake(a, b, c, d), child: stack)
      }
    }

    其中方法override func layoutSpecThatFits(_ constrainedSize: ASSizeRange) -> ASLayoutSpec中的constrainedSize所指是ContainerNode自身大小的取值范围。给定constrainedSize，AsyncDisplayKit会根据ContainerNode在layoutSpecThatFits(_:)中施加在nodeA、nodeB的布局规则和nodeA、nodeB自身属性计算nodeA、nodeB的constrainedSize。

    假如constrainedSize的minSize是CGSize( 0, height: 0)，maxSize为CGSize( 375, height: Inf+)(Inf+为正无限大)，则：

    1）根据布局规则和nodeA自身样式属性maxWidth、minWidth、width、height、preferredSize，可计算出nodeA的constrainedSize的minSize和maxSize均为其preferredSize即CGSize( 100, height: 100)，因为布局规则为水平向的ASStackLayout，当空间富余或者空间不足时，nodeA即不压缩又不拉伸，所以会取其指定的preferredSize。

    2）根据布局规则和nodeB自身样式属性maxWidth、minWidth、width、height、preferredSize，可以计算出其constrainedSize的minSize是CGSize( 0, height: 0)，maxSize为CGSize( 375 - 100 - b - e - d, height: Inf+)，因为nodeB的flexShrink和flexGrow均为1，也即当空间富余或者空间不足时，nodeB添满富余空间或压缩至空间够为止。

    如果不指定nodeB的flexShrink和flexGrow，那么当空间富余或者空间不足时，AsyncDisplayKit就不知道压缩和拉伸哪一个布局元素，则nodeB的constrainedSize的maxSize就变为CGSize( Inf+, height: Inf+)，即完全无大小限制，可想而知，nodeB的子node的布局将完全不对。这也说明另外一个问题，node的constrainedSize并不是一定大于其子node的constrainedSize。

    理解constrainedSize的计算，才能熟练利用node的样式maxWidth、minWidth、width、height、preferredSize、flexShrink和flexGrow进行布局。如果发现布局结果不对，而对应node的布局代码确是正确无误，一般极有可能是因为此node的父布局元素不正确。

    动画

    因为AsyncDisplayKit的布局方式有两种，frame布局和flexbox式的布局，相应的动画方式也有两种

    1）frame布局

    如果采用的是frame布局，动画跟普通的UIView相同

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    		 
    class ViewController: ASViewController {
      let nodeA = ASDisplayNode()
      override func viewDidLoad() {
        super.viewDidLoad()
        nodeA.frame = CGRect(x: 0, y: 0,  100, height: 100)
        ... // 其他代码
      }

      ... // 其他代码
      func animateNodeA() {
        UIView.animate(withDuration: 0.5) { 
          let newFrame = ... // 新的frame
          nodeA.frame = newFrame
        }
      }
    }

    不要觉得用了AsyncDisplayKit就告别了frame布局，ViewController中主要元素个数很少，布局简单，因此，一般也还是采用frame layout，如果只是做一些简单的动画，直接采用UIView的动画API即可

    2）flexbox式的布局

    这种布局方式，是在某个子node中常用的，如果node内部布局发生了变化，又需要做动画时，就需要复写AsyncDisplayKit的动画API，并基于提供的动画上下文类context，做动画：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    		 
    class SomeNode: ASDisplayNode {
      let nodeA = ASDisplayNode()

      override func animateLayoutTransition(_ context: ASContextTransitioning) {
        // 利用context可以获取animate前后布局信息

        UIView.animate(withDuration: 0.5) { 
          // 不使用系统默认的fade动画，采用自定义动画
          let newFrame = ... // 新的frame
          nodeA.frame = newFrame
        }
      }
    }

    系统默认的动画是渐隐渐显，可以获取animate前后布局信息，比如某个子node两种布局中的frame，然后再自定义动画类型。如果想触发动画，主动调用SomeNode的触发方法transitionLayout(withAnimation:shouldMeasureAsync:measurementCompletion:)即可。

    内存泄漏

    为了方便将一个UIView或者CALayer转化为一个ASDisplayNode，系统提供了用block初始化ASDisplayNode的简便方法：

    1
    2
    3
    4
    		 
    public convenience init(viewBlock: @escaping AsyncDisplayKit.ASDisplayNodeViewBlock)
    public convenience init(viewBlock: @escaping AsyncDisplayKit.ASDisplayNodeViewBlock, didLoad didLoadBlock: AsyncDisplayKit.ASDisplayNodeDidLoadBlock? = nil)
    public convenience init(layerBlock: @escaping AsyncDisplayKit.ASDisplayNodeLayerBlock)
    public convenience init(layerBlock: @escaping AsyncDisplayKit.ASDisplayNodeLayerBlock, didLoad didLoadBlock: AsyncDisplayKit.ASDisplayNodeDidLoadBlock? = nil)

    需要注意的是所传入的block会被要创建的node持有。如果block中反过来持有了这个node的持有者，则会产生循环引用，导致内存泄漏：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    		 
    class SomeNode {
      var nodeA: ASDisplayNode!
      let color = UIColor.red
      override init() {
        super.init()
        nodeA = ASDisplayNode {
          let view = UIView()
          view.backgroundColor = self.color // 内存泄漏
          return view
        }
      }
    }

    子线程崩溃

    AsyncDisplayKit的性能优势来源于异步绘制，异步的意思是有时候node会在子线程创建，如果继承了一个ASDisplayNode，一不小心在初始化时调用了UIKit的相关方法，则会出现子线程崩溃。比如以下node，

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    		 
    class SomeNode {
      let iconImageNode: ASDisplayNode
      let color = UIColor.red
      override init() {
        iconImageNode = ASImageNode()
        iconImageNode.image = UIImage(named: "iconName") // 需注意SomeNode有时会在子线程初始化，而UIImage(named:)并不是线程安全

        super.init()

      }
    }

    但在node初始化时调用UIImage(named:)创建图片是不可避免的，用methodSwizzle将UIImage(named:)置换成安全的即可。

    其实在子线程初始化node并不多见，一般都在主线程。

    总结

    一年的实践下来，闪烁是AsyncDisplayKit遇到的最大的问题，修复起来也颇为费神。其他bug，有时虽然很让人头疼，但由于AsyncDisplayKit是对UIKit的再封装，实在不行，仍然可以越过AsyncDisplayKit用UIKit的方法修复。

    学习曲线也不算很陡峭。

    考虑到AsyncDisplayKit的种种好处，非常推荐AsyncDisplayKit，当然还是仅限于用在比较复杂和动态的页面中。

     

     http://qingmo.me/2017/07/21/asyndisplaykit/

    https://blog.csdn.net/weixin_35755389/article/details/54692401
  • 相关阅读:
    Convert Date between LocalDateTime
    Java 8 Date Time API Example Tutorial – LocalDate, Instant, LocalDateTime, Parse and Format
    Enable HTTPS in Spring Boot
    设定范围和步长的递增数验证器Validator
    Codeforces Round #392(div 2) 758D （贪心）
    机器学习：决策树算法（简单尝试）
    Codeforces Round #388 (Div. 2) 749E(巧妙的概率dp思想)
    Codeforces Round #364 (Div. 1) 700B(树)
    Codeforces Round #389 (Div. 2) 752F(树的权值重心)
    Codeforces Round #389 (Div. 2) 752E(二分答案)
  • 原文地址：https://www.cnblogs.com/saytome/p/9342219.html
Copyright © 2020-2023  润新知