自定义布局的UICollectionView变为空白

Kyl*_*yle 6 ios uicollectionview uicollectionviewcell uicollectionviewlayout swift

我为使用UICollectionView和自定义UICollectionViewLayout的用户构建了电视指南样式的应用程序。自定义布局使用四个不同的自定义UICollectionViewCells。我遇到了一个非常有趣的问题,困扰了我和我的团队。我的帖子很长,但是这样做的目的是希望为您提供完整的背景信息。如果您有时间阅读并向我介绍您的想法。我将不胜感激。与往常一样,感谢SO社区的所有帮助。

tl; dr-具有自定义布局的UICollectionView(UICollectionViewLayout的子类)随机丢失视图中的所有数据。完全空白。.reloadData()被调用viewDidAppear且无法修复。对于原因感到困惑。

第0节第0项是一种类型的单元格,始终保持在左上方。滚动时,单元格将随您移动并保持在左上角。

第0节第1-n项是第二种单元格,始终保持在顶部。

1-n节,项目0-n是“站”,这是另一种类型的单元,始终沿左边界保留。

所有其他单元格是“显示”和第四种类型的单元格,并根据时间和电台映射到特定的x,y坐标。

这个collectionView的性能非常好,并且在很大程度上使我们能够提供出色的用户体验。但是,当完全加载了10天的数据时。它使用大量的内存。〜100-150MB,取决于阵容,电台数量和节目长度。显示时间越短,意味着将有更多单元格映射到集合视图。

当应用程序使用大量指南数据运行时,有时collectionView会打ic,我的浮动标头将停止移动。然后我所有的细胞都会消失。我们已亲切地将其称为“ 死亡白屏”,因为整个收藏集都变成了空白。此时,滚动条仍然可见,您可以看到自己在滚动,但是没有加载任何单元格。

我们已经使用连接到Xcode调试器的设备创建了几次该问题,并拥有一些数据。调试器仍可提供用于填充所有单元的数据。cellForItemAtIndexPath可以从调试器调用并返回UICollectionViewCell。从调试器打印时numberOfSectionsnumberOfItemsInSections仍然可以正常工作并显示正确的数字。cellForItemAtIndexPath集合为空后,永远不会调用该函数。这种方法的断点将永远不会被击中。仍然可以访问布局,并且可以毫无问题地访问变量。

现在,对于看起来异常的事情,但是我们不知道该怎么办。

collectionView.contentSize并且collectionView.collectionViewLayout.contentSize是不同的。在非中断设备上,通过调试器查看时它们是相同的。

collectionView.visibleCells返回一个空数组。从技术上讲这是正确的,因为我们的收藏处于死亡模式的白屏中……但是这些部分中有部分和项目,因此不确定。

这个问题是间歇性的,但是如果我们足够努力的话,我们通常每小时可以复制几次。我们认为它与内存有关,因为它永远不会在模拟器上发生。仅在物理设备上。

由于这是针对客户的未发布应用程序,因此我将其导航控件涂黑了。 空集合视图的示例

有没有人看到过类似的问题?有人对下一步尝试有任何想法吗?

最后的提示,谢谢您阅读本书!:)

Kyl*_*yle 5

看到有人刚刚提出了这个问题,我想我会回来发表我们的决议。

我们的collectionView正在调用一个单例,该单例正在为该应用程序管理大量数据。当用户滚动以将数据保留在视图中时,单例正在后台填充。这些对单例的后台更新都是通过低优先级运行的后台线程进行管理的。我们构建了线程以首先更新数据存储,然后更新访问器方法以了解新数据。这是我们在线程安全方面的尝试,因为访问者在修改完数据之后才知道除了已经存在的数据以外没有其他数据。但是,这没有用。下面有更多详细信息。

在使用多种设备进行广泛测试之后,我们意识到问题在某些天大量出现,我们获取了这些数据并开始分析给定日期的collectionView单元格,我们发现问题出现的那几天通常,正在生成的单元格具有非常大的尺寸,例如,一行中的单个单元格可能跨越4-5台iPhone的宽度。经过一番搜索,我们发现这是人们经常遇到的问题,大多数人只是缩小了细胞的大小。但是,我们的单元格与时间和长度有关。

进行了更多的研究,我们最终在删除所有线程上大放异彩。这意味着当我们的用户到达集合的末尾时,我们将推送一个模式视图,该视图显示活动指示器并在更新单例时阻止用户输入。这立即解决了我们的问题。

我们的研究笔记:

  • 很大的单元格(宽度或高度)会导致collectionView问题,应格外小心。
  • 这些大型单元可能使问题发生的频率比正常情况高得多,但是,它们似乎并不是造成问题原因。
  • 线程安全是我们的问题,在某些时候collectionView失去了它与数据源的连接,并且无法恢复。我们尝试了几种补救措施来重新链接数据源,但没有一种有效。解决方法是删除所有线程。

希望这可以帮助!