本篇所涉及的性能问题我都将根据滑动的流畅性来评判, 包括掉帧状况和一些实际体验html
ASDK 已经更名为 Texture, 我习惯称做 ASDKios
编译环境: MacOS 10.13.3, Xcode 9.2git
参与测试机型: iPhone 6 10.3.3, iPhone 7 11.2.1, iPhone X 11.2.5, 默认 iPhone 6github
TableView / TableNode 包含的 TableViewCell / CellNode: 默认复杂程度通常, 包含 1~2 张图片和 2~4 条文本展现, 图片有圆角segmentfault
大牛们把缘由都说的很清楚了, 致使的结果就是 16ms 不足以渲染一帧, 产生掉帧卡顿缓存
下面是尝试过的一些优化:安全
老生长谈了, 除 UITableView-FDTemplateLayoutCell 以外, QMUI 中也有提供一套缓存行高方案性能优化
具体是在 JSON 转 Model 后把文本转为富文本, 处理一些弱逻辑等, 以后赋值就能够直接展现了网络
咳咳, 这个感受不到什么效果并发
例如处理图片遮罩或固定的图标, 通常是直接使用多层视图实现
我曾尝试把三张小图绘制到一张大图上再进行展现, 因而乎, 异步复用问题除外, 内存炸了, 最终仍是老老实实用多个视图实现
一般咱们认为 UIKit 是不能渲染于非主线程的, 一旦你这么作, 就可能会致使崩溃, 没法正常显示等问题, 而 ASDK 为何能够呢, 由于 ASDisplayNode 是线程安全的, Node 建立时, 不会当即在其内部新建 UIView 和 CALayer, 直到主线程第一次访问时才会生成对应的对象, 除此以外, 还经过图层预合成和基于 Runloop 的异步并发, 使其拥有更好的性能 ASAsyncTransactionGroup
这个特色带来的相关实际体验就是: 安心的进行异步绘图, 如圆角裁剪, 增长遮罩等, 这在 UIKit 中是足以毁灭人生的, 内存暴涨, 异步复用, 性能极差
不太低性能设备下仍是会出现明显空白
首先来一张 Gif 体验一下, 实际上使用 ASDK 开发完成后对比也是如此, 有种网速变快了的错觉
ASDK 中的 ASRangeController, ASTableView, ASCollectionView 相对于 UIKit 原生控件的特色是可用于监控视图的可见区域, 维护工做区域, 在合适的时机触发网络请求以及绘制, 单元格的异步布局
这里推荐阅读: 预加载与智能预加载(iOS)
意思是某个 List 展现的样式只有一种, TableView 只须要注册一个 Cell
这种状况下, 若是常规的一些优化得当, 滚动的流畅性仍是能够接受的(与 ASDK 差距微小, 但仍然肉眼可分辨)
此时的差距主要体如今列表某项数据第一次展现, 以及 TableView 在分页加载时产生的等待较长, 固然, 这两点也是能够继续优化和解决的
相反的, 也就是来回滑动已经展现过的数据, 二者的差距就很是小了, 大概是 59.7 - 59.9 和 59.9 的区别 (我瞎扯的)
综上, 优化得当的状况下, 单一的 Cell 状况下 UIKit 与 ASDK 的差距不明显
表示某 List 中有多种不一样的样式, TableView 必需要经过注册 N 个 Cell 来实现
这种状况下, 假设有 5 种 Cell, 屏幕可同时展现 6 条 Cell, 此时若第一屏幕恰好展现的就包含所有 5 种 Cell , 那么后续的滑动状况将与单一的 Cell表现一致, 若第一屏幕展现的内容只包含一种, 其余 4 种没有在屏幕上出现过, 那么当某一种首次出如今屏幕上时, 便会出现明显的卡顿; 我尝试过解决这个问题, 提早建立全部的 Cell 实例对象, 缓存和复用相同的子视图, 异步预绘制为一张图片并缓存(坑), 都收效渐微
因 ASDK 支持预渲染, 与处理单种 Cell 没有区别, 依旧 59.9
TableView 的复用机制我是既爱又恨的, 方便之处在于直接与数据绑定后, 能够方便的更新和修改, 只需保证 setModel 简洁就 OK, 只是当业务绑定较多时就比较麻烦了
下面重点说说 TableNode, TableNode 的复用机制就是没有复用, 只有缓存, 每一个 CellNode 都是全新的, 所以会有一些特殊的地方:
CellNode 与数据源没有绑定关系: 建立后就算把数据源删除, TableNode 依然能够正常展现
数据直接决定要建立一个怎样的 CellNode: 这一点很重要, TableViewCell 的展现大体为: 添加空假数据子视图 -> 数据填充 -> 刷新, 涉及布局或图文时会更复杂
CellNode 只有一步: 添加真数据的子视图; 所以能够直接根据业务逻辑对控件和布局作出处理, 而不用一次或屡次刷新
Demo: 此处需求为每组一个大图 + N个小图, 每组 3 或 5 个
解决思路: TableView 的方式是建立 5 个, 根据数量显隐下面两个, 或者两种 Cell, 把 3 和 5 的状况分别对应, 除此以外, 最重要的是: 祈祷数据正常, 每组数据个数仅为 3 或 5
此时若使用 TableNode 就灵活多了, 能够根据须要(数据个数), 加入须要的子视图, 个人思路是把顶部的大图固定, 剩下的两个为一行进行添加, 就算总数为偶数也是没有任何额外消耗的, 具体参见 ASDKDemo
ASDK 使用的是 Flex 布局, 且面向对象
偷一张图
具体对比: iOS 上的 FlexBox 布局
简单来讲, 缺点只有一个, 就是学习曲线相对 Frame AutoLayout 更陡峭, 而优势是 性能与 Frame 至关, 上手后比 AutoLayout 还简单, 若是你已经开始尝试, 请坚持下去
使用 AutoLayout 时我内心想的无外乎:
缺点是视图之间的依赖性太强, 可读性维护性较差(更差的是 Frame), 例如排列数个距离不等控件, 就会很厌烦, 而后 cv 重复代码; 处理多个多行文本垂直排列时很恶心, 想要处理好最终须要去计算文字行高, 外加入自定行间距; ...
例如 Demo 中的
<img src="https://img.didee.cn/imgs/201...; width="300"/>
我作的事情是:
postImageRatioSpec
titleInsetSpec
titleInsetSpec
的位置是垂直方向下的最尾部; titleRelativeSpec
titleRelativeSpec
是覆盖到 postImageRatioSpec
上: titleOverlaySpec
此时大图和文字布局完成
接下来是用户栏:
leftStackSpec
rightStackSpec
leftStackSpec
和 rightStackSpec
水平排列, 等间距排列填充(实际是为 left 和 rightStack 进行填充), 距离 8, 对齐方式填充(无实际做用, 因为子视图同为 Stack 且都是水平方向); userStackSpec
最后:
titleOverlaySpec
和 userStackSpec
垂直排列, 自上而下, 对齐方式填充(同理于userStackSpec
, 此处影响的是 userStackSpec
); videoStackSpec
videoStackSpec
的内边距: Inset(16, 16, 0, 16); videoInsetSpec
特别注意 userStackSpec
和 videoStackSpec
, StackSpec 多层叠加后, 父子间是存在影响的, 我在使用中也感受比较奇怪, 具体须要自行尝试体会..
具体实现代码: VideoCellNode.m , UserNode.m
AsyncDisplayKit 系列教程 —— 为何要使用 AsyncDisplayKit
AsyncDisplayKit State of the Code (WWDC 2016)
包含无限滚动和不定子视图的 Demo ASDKDemo
官方示例 Texture Examples
线上项目 AppStore 耐飞视频