具有复杂格式的UITableViewCell的最佳方法

Question

我是iOS开发的新手，思考如何最好地解决一个相当简单的设计问题。我想显示一组项目，每个项目都具有草图结构。在给定的集合中，不超过10个项目。

每个项目包括缩略图图像，标题，模糊和一组按钮。有两个并发症：

1. 文本数量和按钮数量是可变的。
2. 文本需要一些内部格式（斜体和粗体）。

我考虑过这些方法：

1. 使用带有自定义，可调整大小的UITableViewCell的表视图，可能使用类似OHAttributedLabel的文本。对于可变数量的按钮，要么以编程方式布局，要么可能使用新的集合视图（对于较旧的iOS，必须使用第三方网格视图）。

2. 使用基于UIWebView的自定义单元格的表格视图。

3. 将整个集合作为一个UIWebView。

4. 使用带有剖面的表格视图;每个项目都有自己的部分，并将按钮和文本解析为行。

很想获得有关更有经验的iOS开发者如何处理此问题的建议。

编辑：我现在正在考虑最好的方式：

5）对整个事情使用UICollectionView。

更新：最后，我把整个事情放在代码中作为自定义表格单元格（即＃1）。这是一个很好的选择，不仅仅是因为答案中给出的原因，而是因为作为iOS开发的新手，我需要掌握一些东西。甚至没有使用按钮的集合视图，因为我担心性能以及支持iOS5的麻烦。

我认为使用整个设计的集合视图（＃5）将是一个优雅的解决方案，我实际上开始沿着这条路走下去。然而，上面简化图中没有显示的一些复杂情况使得这种复杂性变得难以处理。

第二次更新：＃1结果是死路一条。我的最终解决方案使用了UIWebView（＃3） - 请参阅答案。

Answer 1

我找到了一些资源，这些资源可能对某些正在进行复杂tableviewcell并希望快速滚动的人有用。我还在开发它，但我想先和你们分享一下。

1. Facebook iOS发布说明：他们提到了技术：核心文本，表高度的预/异步计算，在后台线程上做了很多事情，在核心数据中保存了布局属性。 http://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920

2. 快速滚动示例：https://github.com/adamalex/fast-scrolling

3. Apple的示例项目TableViewSuite。第四个例子。 https://developer.apple.com/library/ios/#samplecode/TableViewSuite/Introduction/Intro.html

非常接近解决方案..是

Answer 2

我知道这是一个老线程，但我发现它非常有趣，因为我现在刚刚作为iPhone开发人员来解决这些类型的性能问题。我在Facebook工程公司的Facebook网站上发现了一篇非常有趣的文章，描述了他们如何实施UITableView并克服动态调整大小问题，以及快速内容管理。似乎他们使用更深层的对象预先计算并保持所有异步并在可能的情况下预先缓存。我将提供该文章的链接，但我将复制解决此问题的部分。希望对你有帮助。这是链接https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920和最相关的摘录：

  

（重新）建立速度

     

我们在本机iOS上构建的最大优势之一就是能够快速启动应用程序。现在，当您在新的Facebook for iOS上滚动浏览新闻Feed时，您会发现它感觉比以前快得多。我们实现这一目标的一种方法是重新平衡我们执行某些任务的位置。例如，在iOS中，主线程驱动UI并处理触摸事件，因此我们在主线程上执行的工作越多，应用程序感觉就越慢。相反，我们会在后台执行计算成本高昂的任务。这意味着我们所有的网络活动，JSON解析，NSManagedObject创建以及保存到磁盘都不会触及主线程。

     

再举一个例子，我们使用Core Text来布局我们的许多字符串，但布局计算很快就会成为瓶颈。使用我们的新iOS应用程序，当我们下载新内容时，我们异步计算所有这些字符串的大小，缓存我们的CTFramesetters（创建起来可能很昂贵），然后在我们将故事呈现到UITableView时使用所有这些计算。

     

最后，当您启动Facebook for iOS时，您希望看到您的新闻Feed，而不是加载微调器。为了提供尽可能好的体验，我们现在立即显示以前缓存的内容。但是这引入了一个新问题：如果你的新闻提要中有很多故事，UITableView会通过为你的新闻提要中的每个故事调用委托方法-tableView：heightForRowAtIndexPath：来投入一个小扳手，以便弄清楚如何高大的滚动条。这将导致应用程序从磁盘加载所有故事数据并仅计算整个故事布局以返回故事的高度，这意味着当您累积更多故事时，启动会逐渐变慢。

     

这个特定问题的解决方案有两个主要部分。首先，当我们进行初始异步布局计算时，我们还将故事的高度存储在Core Data中。这样做，我们完全避免在-tableView：heightForRowAtIndexPath：中进行布局计算。其次，我们拆分了我们的“故事”模型对象。我们只在启动时从磁盘中获取故事高度（以及其他一些东西）。稍后，我们将获取其余的故事数据，我们必须执行的任何布局计算都是异步执行的。

     

所有这些以及更多内容会导致滚动时的高帧率和仍然响应的应用。

Answer 3

我最初接受（并实施）@ Daij-Djan的回答，但现在我相信最好的方法是＃3（UIWebView）。它取决于性能。

UITableView可以很好地处理具有子视图的自定义单元格，尤其是在具有不同高度的单元格的上下文中。按钮行使滚动起伏不定。正如Apple在Cells and Table View Performance中所建议的那样，我确保子视图都是不透明的，但是没有办法遵循“避免重新播放内容”的建议。

添加到动态单元格高度和属性字符串上，这些表格滚动得非常糟糕。我想下一个优化是覆盖drawRect，但在那时我决定尝试UIWebView。

UIWebView也不是没有性能问题！随着内容的增长，它的滚动性能降低得相当快，但是，我可以通过隐藏内容并让用户根据需要“打开”它来管理它。

Answer 4

没有1可能是最直接紧随其后的工作＃2但是 正如ACB所说，它也是最灵活的，IMO肯定会提供最佳的外观感觉

no 3有效，但不会感觉像是'html-ish'

没有4听起来像高速公路到地狱（稍后。它将是修改/维护的PITA）