加入收藏 | 设为首页 | 会员中心 | 我要投稿 河北网 (https://www.hebeiwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 业界 > 正文

iOS开拓必然要实行的 Texture(ASDK)

发布时间:2019-05-18 10:32:08 所属栏目:业界 来源:程序君
导读:媒介 本篇所涉及的机能题目我都将按照滑动的流通性来评判, 包罗掉帧环境和一些现实体验 编译情形: 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 包括的 TableViewCel
副问题[/!--empirenews.page--]

媒介

本篇所涉及的机能题目我都将按照滑动的流通性来评判, 包罗掉帧环境和一些现实体验

  • 编译情形: 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

图形异步渲染

凡是我们以为 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

(编辑:河北网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读