iOS开辟肯定要实验的 Texture(ASDK)

开辟技能 2019/5/18

媒介

本篇所触及的功能题目我都将依据滑动的流利性来评判, 包罗失帧状况和一些实践体验

编译情况: MacOS 10.13.3, Xcode 9.2

到场测试机型: iPhone 6 10.3.3, iPhone 7 11.2.1, iPhone X 11.2.5, 默许 iPhone 6

TableView / TableNode 包括的 TableViewCell / CellNode: 默许庞大水平一样平常, 包括 1~2 张图片和 2~4 条文本展示, 图片有圆角

列表滑动卡顿的缘故原由及优化

大牛们把缘故原由都说的很明白了, 招致的后果便是 16ms 不敷以渲染一帧, 发生失帧卡顿

上面是实验过的一些优化:

圆角

利用一张圆角图片掩盖, 经典文章 Corner Rounding(http://texturegroup.org/docs/corner-rounding.html), HYBImageCliped(http://texturegroup.org/docs/corner-rounding.html )也是这么做的

iOS开辟肯定要实验的 Texture(ASDK)

异步裁剪图片: 经过 UIGraphics 对图片举行裁剪, 大概形成内存暴跌

数据预加工

详细是在 JSON 转 Model 后把文本转为富文本, 处置一些弱逻辑等, 之后赋值就可以间接展示了

咳咳, 这个觉得不到什么结果

图形预加工

比方处置图片遮罩或牢固的图标, 一样平常是间接利用多层视图完成

我曾实验把三张小图绘制到一张大图上再举行展示, 于是乎, 异步复用题目除外, 内存炸了, 终极照旧老诚实适用多个视图完成

为什么要利用 ASDK

图形异步渲染

通常j9九游以为 UIKit 是不克不及渲染于非主线程的, 一旦你这么做, 就大概会招致瓦解, 无法正常表现等题目, 而 ASDK 为什么可以呢, 由于 ASDisplayNode 是线程宁静的, Node 创立时, 不会立刻在其外部新建 UIView 和 CALayer, 直到主线程第一次拜访时才会天生对应的工具, 除此之外, 还经过图层预分解和基于 Runloop 的异步并发, 使其拥有更好的功能 ASAsyncTransactionGroup(https://github.com/TextureGroup/Texture/blob/b7cd0b16567a9eb10e58f4cc0886a145dc5273b8/Source/Details/Transactions/_ASAsyncTransactionGroup.m)

这个特点带来的相干实践体验便是: 放心的举行异步画图, 如圆角裁剪, 增长遮罩等, 这在 UIKit 中是足以扑灭人生的, 内存暴跌, 异步复用, 功能极差

不外低功能设置装备摆设下照旧会呈现分明空缺

iOS开辟肯定要实验的 Texture(ASDK)

预加载数据和工具

起首来一张 Gif 体验一下, 实践上利用 ASDK 开辟完成后比拟也是云云, 有种网速变快了的错觉

ASDK 中的 ASRangeController, ASTableView, ASCollectionView 绝对于 UIKit 原生控件的特点是可用于监控视图的可见地区, 维护事情地区, 在符合的机遇触发网络哀求以及绘制, 单位格的异步结构

iOS开辟肯定要实验的 Texture(ASDK)

异于原生控件的复用机制

单一的 Cell

意思是某个 List 展示的款式只要一种, TableView 只必要注册一个 Cell

这种状况下, 假如惯例的一些优化妥当, 转动的流利性照旧可以承受的(与 ASDK 差距巨大, 但仍旧肉眼可辨别)

此时的差距次要表现在列表某项数据第一次展示, 以及 TableView 在分页加载时发生的等候较长, 固然, 这两点也是可以持续优化息争决的

相反的, 也便是来来回回滑动曾经展示过的数据, 两者的差距就十分小了, 大约是 59.7 - 59.9 和 59.9 的区别 (我瞎说的)

综上, 优化妥当的状况下, 单一的 Cell 状况下 UIKit 与 ASDK 的差距不分明

iOS开辟肯定要实验的 Texture(ASDK)

多种 Cell

表现某 List 中有多种差别的款式, TableView 必需要经过注册 N 个 Cell 来完成

这种状况下, 假定有 5 种 Cell, 屏幕可同时展示 6 条 Cell, 此时若第一屏幕恰好展示的就包括所有 5 种 Cell , 那么后续的滑动状况将与单一的 Cell体现分歧, 若第一屏幕展示的内容只包括一种, 其他 4 种没有在屏幕上呈现过, 那么当某一种初次呈现在屏幕上时, 便会呈现分明的卡顿; 我实验过办理这个题目, 提早创立一切的 Cell 实例工具, 缓存和复用相反的子视图, 异步预绘制为一张图片并缓存(坑), 都见效渐微

ASDK 不必说了, 仍旧 59.9

复用的差异

TableView 的复用机制我是既爱又恨的, 利便之处在于间接与数据绑定后, 可以利便的更新和修正, 只需包管 setModel 简便就 OK, 只是当商业绑定较多时就比力贫苦了

上面重点说说 TableNode, TableNode 的复用机制便是没有复用, 只要缓存, 每个 CellNode 都是全新的, 因而会有一些特别的地方:

CellNode 与数据源没有绑定干系: 创立后就算把数据源删除, TableNode 仍然可以正常展示

数据间接决议要创立一个怎样的 CellNode: 这一点很紧张, TableViewCell 的展示大抵为: 添加空假数据子视图 -> 数据添补 -> 革新, 触及结构或图文时会更庞大

CellNode 只要一步: 添加真数据的子视图; 因而可以间接依据商业逻辑对控件和结构做来由理, 而不必一次或屡次革新

Demo: 此处需求为每组一个大图 + N个小图, 每组 3 或 5 个

iOS开辟肯定要实验的 Texture(ASDK)

办理思绪: TableView 的方法是创立 5 个, 依据数目显隐上面两个, 大概两种 Cell, 把 3 和 5 的状况辨别对应, 除此之外, 最紧张的是: 祷告数据正常, 每组数据个数仅为 3 或 5

此时若利用 TableNode 就机动多了, 可以依据必要(数据个数), 参加必要的子视图, 我的思绪是把顶部的大图牢固, 剩下的两个为一行举行添加, 就算总数为偶数也是没有任何分外斲丧的, 详细拜见 ASDKDemo(https://github.com/didez/ASDK-Demo/tree/master/ASDKDemo)

iOS开辟肯定要实验的 Texture(ASDK)

Flex 结构

ASDK 利用的是 Flex 结构, 且面向工具

偷一张图

iOS开辟肯定要实验的 Texture(ASDK)

复杂来说, 缺陷只要一个, 便是学习曲线绝对 Frame AutoLayout 更峻峭, 而好处是 功能与 Frame 相称, 上手后比 AutoLayout 还复杂。