iOS_10中UICollectionView和UITableView的变化

What's New in UICollectionView in iOS 10?

在iOS 10中,UIKit的两个容器控件得到新的特性,apple在会上强调了这些新特性所带来的性能提升,现总结如下:

1.cell生命周期的变化

只有UICollectionView支持这项更新,且貌似开启prefetchingEnabled才行,具体表现为,与当前区域较为临近的离屏cell将不会立即进入reuse队列,而是仍然驻留在那个位置,等待用户往上滑动去再现它,这样一来,cellForItemAtIndexPath将不会被反复调用——这些没有被立即recovery的cell们再重见天日之后只会往delegate发送willDisplayCell进行一下通知而已。那么联系到大多数情况我们都在cellForItemAtIndexPath函数内部做model的填充,那么当用户的确在某个cell区间之内反复滑动,可以明显缓解由于反复的图片加载、文字绘制等操作带来的瞬时cpu压力。但是对于某些情况下,例如cell每次被显示出来都可能处于不一样的状态,那么就需要将这些状态改变移步到willDisplayCell了。

对于iOS 10之前的UIKit,其实我们也可以定制一种机制来避免,当被reuse的cell被重新使用并且它上面的内容与当前需要填充的内容一致,被重新填充一遍的浪费。(比如self.model == model)

2.prefetchDataSource

这个新的协议属性是UICollectionView和UITableView都支持的。这个协议其实是用来通知我们,当前滑动到某个区域后,根据这次滑动的方向接下去可能还会滑向哪些indexPaths。好让我们做一些数据上的预备或者销毁。

分为2个函数:

required: prefetchRowsAtIndexPaths

这个协议方法提供一个数组,这个数组提示了按着本次滑动方向,再接下去要碰到哪些indexPaths了。

以UITableView为例,回调过来的这个数组为当前屏幕边缘的indexPath的接下去(上或者下)第10个开始算的indexPath,假设我当前向下滑动,底部的section:0 row:15变成了section:0 row:16,此时协议回传section:0 row:26(之前已经将17-25传给我们了)给我们,此时如果我们改变了方向往上滑动,那么协议会一口气返回10个indexPath给我们,而这10个是最顶部显示indexPath前面的10个。

optional: cancelPrefetchingForRowsAtIndexPaths

这个协议返回的数组用于在,当我们快速滑动到某个区域后又立刻按着反方向滑动,那么原本被预估要出现的几个indexPath会被取消掉这样,这个数组就是存储被取消预估的indexPath,经过测试,假设此时最顶部是section:0 row:10,并且方向为上的估算indexPaths有10个了(row : 0-10),那么当我们往下滑动到顶部为section:0 row:16的时候,这个协议会回调一个section:0 row:0给我们,也就是差了15个这样的个数之后就会调用该协议来告诉我们该取消去预估算的indexPath了。

目前从UITableView看来,这个功能用处不大,他只是提供一个参考值给我们。通过用户的手势和拉动的屏幕距离来估算给我们一段可能出现的区间,这个区间又是根据apple自己定的规则(即上面提到的,提前10个、返回10个、差15个开始取消),实际上用户的操作行为难以被估算,很可能这些预读取的索引只有10%的命中率:假设用户是突然改变滑动方向,此时咱们已经接受过上下方向共20个的预读索引了,然后用户只在当前区间进行小幅度的上下滑动,那么预读操作只会命中边缘的1-2个。

3.prefetchingEnabled

仍然是UICollectionView独占,提供了cell的预读取功能。具体表现在,当我们滑动至某个区域的时候,例如section:1  item:5到section:1 item:10这个区间,那么UICollectionView就会去读取cellForItemAtIndexPath来预先加载大概section:1 item:3到section:1 item:12这样的区间,这个预读操作apple是说为异步的,但是本着UIView必须在主线程下操作的规矩,应该指的是 当前的滚动结束之后layoutSubviews被调用完了在下一次runloop中去访问cellForItemAtIndexPath 这样,利用用户屏幕静止的时间去读取。

预读取了cell并存储在reuse队列中之后,当这些cell真的需要被显示了,那么就可以willDisplayCell通知一下直接刷出来,这样一来,用户感觉不到诸如图片的下载这样的读取过程。

当开启这个功能时,prefetchDataSource会受到影响,预估算indexPath的策略会和关闭这个功能的时候不一样。也就是关闭的时候prefetchDataSource同UITableView一样的机制。

同样由于某些需求,这个功能可以随时被关闭。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,080评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,422评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,630评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,554评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,662评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,856评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,014评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,752评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,212评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,541评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,687评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,347评论 4 331
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,973评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,777评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,006评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,406评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,576评论 2 349

推荐阅读更多精彩内容