【发布时间】:2019-05-31 22:44:04
【问题描述】:
我正在尝试了解 UICollectionViewLayout 的工作原理并找到此示例代码。
https://developer.apple.com/documentation/uikit/uicollectionview/customizing_collection_view_layouts
在示例代码(以及我能找到的所有其他示例)中,它具有cachedLayoutAttributes 对象并计算prepare() 中所有项目的布局。
我发现此模式有 2 个问题。
一个是如果数据源的数量足够大,在prepare()方法中计算所有东西都需要时间(并且每当collectionView的布局发生变化时都会重新计算),所以看起来效率不高。
另一个问题是layoutAttributesForItem 或layoutAttributesForSupplementaryView 没有机会被调用。只有layoutAttributesForElements 被调用,它似乎足以布置单元格/补充视图。
我阅读了文档,但它只说必须覆盖这些方法。我最好的猜测是我应该使用覆盖这些方法来返回适当的UICollectionViewLayoutAttributes 并从layoutAttributesForElements 调用它们。然而,每当用户滚动 UICollectionView 时,都会调用这个 layoutAttributesForElements,所以它似乎也不是很有效。
我想知道layoutAttributesForItem和layoutAttributesForSupplementaryView被调用的情况是什么,如果数据源的数量很大,什么/何时/哪里是计算UICollectionViewLayoutAttributes的最佳方式/地点/时间。
更新
感谢您的评论。然而,它似乎是关于失效周期的优化。
旨在支持失效上下文的布局对象可以使用 UICollectionViewLayoutInvalidationContext 对象中的信息来优化它们在失效周期期间的行为。
这意味着UICollectionViewLayoutAttributes 已经设置并且只有必要的部分无效,对吧?
那么,第一次应该在哪里计算UICollectionViewLayoutAttributes?如果我错了,请告诉我。
【问题讨论】:
-
阅读 UICollectionViewLayout 文档,尤其是。 “使用无效上下文优化布局性能”部分。还有很多关于这个主题的有用的 WWDC 视频,例如 WWDC 2014 session 226。
-
同年的第 232 届会议。
-
@matt 谢谢。我更新了问题。
-
很明显,一个最小的实现是仅当您收到对矩形中项目布局属性的请求时才执行计算和缓存。这些都是最初需要出现在屏幕上的所有项目。但是,您必须执行 一些 整体初始计算,因为第一个大问题是内容视图需要多大。
标签: ios swift uicollectionview uicollectionviewlayout