texture iOS 开发一定要尝试的 Texture

前言

我会根据滑动的流畅度来判断本文涉及的性能问题，包括掉框和一些实践经验

ASDK已更名为纹理(https://github。我以前称之为ASDK。

编译环境:MacOS 10.13.3，Xcode 9.2

测试机型:iPhone 6 10.3.3，iphone7 11.2.1，iPhone 11 . 2 . 5，默认iPhone 6

TableViewCell/CellNode包含在TableView/TableNode中:默认复杂度为平均，包括1~2张图片和2~4个文字显示，图片有圆角

列表滑动堵塞的原因及优化

大牛们已经把原因说的很清楚了，结果就是16ms不够渲染一帧，导致丢帧

下面是一些已经尝试过的优化:

里脊肉

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

异步裁剪图片: 通过 UIGraphics 对图片进行裁剪, 可能造成内存暴涨

行高缓存

我已经说了很久了。除了UITableView-FDTemplateOutlell(https://github。QMUI(https://github.com/QMUI/QMUI_iOS)还提供了一套缓存行高度方案

数据预处理

具体来说，JSON转换成Model后，文本就变成了富文本，再处理一些弱逻辑，就可以直接显示赋值了

咳咳，这个感觉没什么效果

图形预处理

例如，处理图片蒙版或固定图标，一般直接使用多层视图来实现

我试着在一幅大图上画三幅小图，然后展示出来。结果除了异步复用，内存爆炸，最后老老实实用多视图实现

为什么要用ASDK

图形的异步渲染

一般来说，我们认为UIKit不能渲染到非主线程。一旦这样做，可能会造成死机、显示异常等问题。为什么ASDK可以？因为ASDisplayNode是线程安全的，所以当创建节点时，它不会立即在其中创建新的UIView和CALayer。直到主线程第一次访问它，才会生成相应的对象。此外，通过图层预合成和基于Runloop的异步并发，使其具有更好的asasynctransactiongroup性能(https://github . com/texture group/texture/blob/B7 CD 0b 16567 a9 EB 10e 58 F4 cc 0886 a 145 DC 5273 b 8/source/details/transactions/_ asasynctransactiongroup . m)

这个特性带来的相关实践经验是:安心异步绘图，比如偷工减料，加蒙版，足以破坏UIKit中的生命，内存暴涨，异步复用，性能差

但是在低性能设备下还是会有明显的空白色

预加载数据和对象

首先，我们来看一个Gif体验。事实上，ASDK发展完成后也是如此。有种网络速度越来越快的错觉

与UIKit原生控件相比，ASDK的rangecontroller、astable view和ascellectionview可以用来监视可视的视图区域，维护工作区域，触发网络请求并在正确的时间绘制，以及异步布局单元格

建议在此阅读:预加载和智能预加载(iOS)(https://draveness.me/preload)

不同于本机控件的重用机制

一个细胞

这意味着列表只显示一种样式，而表格视图只需要注册一个单元格

在这种情况下，如果一些常规优化是适当的，滚动的流畅度仍然是可接受的(与ASDK的差距很小，但它仍然可以用肉眼区分)

此时的差距主要体现在列表中一些数据的第一次显示，以及加载分页时TableView的等待时间过长。当然这两点是可以不断优化解决的

相反，就是来回滑动显示的数据，两者差距很小，大概是59.7-59.9和59.9的差距(我在胡说八道)

综上所述，经过适当的优化，UIKit与ASDK的差距在单细胞下并不明显

各种细胞

这意味着一个列表中有许多不同的样式，而TableView必须通过注册n Cell来实现

在这种情况下，假设有五种单元格，屏幕可以同时显示六个单元格。这时如果第一屏只是显示全部五种细胞，那么后续的滑动情况就会和单个细胞的表现一致。如果第一屏只显示一种内容，其他四种都没有出现在屏幕上，那么当某一种第一次出现在屏幕上时，就会出现明显的堵塞；我尝试过解决这个问题，提前创建所有Cell实例对象，缓存重用同一个子视图，异步预画成图片，缓存(pit)，这些都收效甚微

不用说，ASDK仍然是59.9

复用差异

我喜欢也讨厌TableView的重用机制。方便之处在于直接与数据绑定后，可以很容易的更新和修改。只保证setModel简洁是可以的，但是业务绑定多的时候就麻烦了。

下面重点介绍表节点。Table Node的重用机制是没有重用，只有缓存，每个CellNode都是全新的，所以会有一些特殊的地方:

CellNode和数据源之间没有绑定关系:即使创建后删除了数据源，TableNode仍然可以正常显示

数据直接决定了创建什么样的CellNode:这个很重要。TableViewCell的呈现方式大致如下:add 空 false data子视图-->:数据填充-->:涉及到布局或者图文时刷新比较复杂

CellNode只有一步:添加真实数据的子视图；因此，可以根据业务逻辑直接处理控件和布局，而无需刷新一次或多次

演示:这里的要求是每组一张大图+N张小图，每组3到5张