追梦

胜利不是最后的结局,失败也不是最终的宿命,重要的是勇气。

AsyncDisplayKit 系列教程 —— 为什么要使用 AsyncDisplayKit

前言

AsyncDisplayKit 是 Facebook 在 2014 年开源的一个异步界面渲染库,她是构筑于 UIKit 之上的一个封装库,与 UIView 是平级的关系(同时提供 UIView bridge 接口)。

AsyncDisplayKit 在开源社区历经一年多时间的琢磨,已经逐趋成熟,完全可以用于生产环境,但目前将 AsyncDisplayKit 用于生产环境的应用寥寥无几,究其原因,不外乎以下几点:

  • 不支持 IB,不支持 Autolayout,也不支持 Autoresizing,一切布局都需要手动计算完成;
  • 接口并非与 UIView 完全一致,对入门使用者来说,有一定的学习成本;
  • AsyncDisplayKit 并不是非用不可,她所追求的是极限用户体验。

为此, 我们可以引申出问题, 为什么要使用AsyncDisplayKit 

什么情况下应该使用 AsyncDisplayKit

  • 复杂的界面
  • 存在滑动性能问题的界面,同时使用各种方法优化无效的界面
  • 频繁更新的TableView(比如聊天界面)

什么情况下不应该使用 AsyncDisplayKit

  • 不存在性能问题的界面,没有必要使用 AsyncDisplayKit

性能问题的探讨

当我们谈论性能问题的时候,我们只是关注UI性能问题,那些逻辑、网络的性能问题并不是我们要关注的重点。

作为iOS开发者而言,务必需要了解到,有什么因素会影响UI性能。

就一般应用而言,需要关注的性能的UI控件可能就只有 UITableView 和 UICollectionView,其它类型的UI,性能问题在可以容忍的范围内。 这也是 什么情况下应该使用 AsyncDisplayKit 的关注点。

但是,我们仍然有必要去列出一些影响流畅性的关键点。

  • 网络请求,大部分网络请求都应该使用后台线程完成,如果你使用的是 AFNetworking、 SDWebImage 这些开源缓存库,那么切换到后台去请求网络资源的操作都已经默认完成。

  • 本地数据读写和计算,当你需要从闪存中读取文件的时候,这些操作都应该使用GCD或者NSThread切换至后台线程中完成。

  • 图像的处理,尽量使用合适的UIImage给予UIImageView使用,何谓合适?已经提前剪裁、缩放好的图片是最佳的,否则当UIImage赋予UIImageView.image的时候,iOS会有不必要的计算开销,而这些开销却是可以提前手动缓存起来的。

  • Layer 属性的谨慎选择,不合理的 Layer 特效(阴影、圆角)都会使流畅的滑动变成卡顿(非常重要)。

  • 少用 UIView.backgroundColor = UIColor.clearColor(),透明的背景会加剧卡顿。

  • 文字的渲染,你可能不知道,文字的渲染也是需要开销的。一般来说,文字渲染的开销非常小,甚至不能察觉到。但是,当一个UILabel被赋予大段富文本文字后,开销就会非常大。

  • 图像的渲染,一个任何开发者、几乎所有库(包括SDWebImage)都无法解决的问题,图像在UIImageView中的渲染开销,并且图像的渲染只能在主线程中执行。

前五点都是可以在 UIView 的基础上解决的,如果前五点均优化完成后,仍然无法解决卡顿问题,则应该使用 AsyncDisplayKit。

AsyncDisplayKit 有对应的方案,着力解决文字渲染、图像渲染两个难题。

下一篇教程,将指引你集成 AsyncDisplayKit 并编写一个简单的 Demo 界面。

转:http://www.jianshu.com/p/9e517e985145

阅读更多
个人分类: iOS
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

AsyncDisplayKit 系列教程 —— 为什么要使用 AsyncDisplayKit

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭