11

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

草图

每个项目都包括一个缩略图、一个标题、一个简介和一组按钮。有两个并发症：

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

我考虑过这些方法：

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

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

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

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

希望获得有关更有经验的 iOS 开发人员如何解决此问题的建议。

编辑：我现在考虑最好的方法可能是：

5）对整个事情使用 UICollectionView。

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

我确实认为在整个设计中使用集合视图（#5）将是一个优雅的解决方案，我实际上是沿着这条路开始的。但是，上面的简化图片中未显示的一些复杂情况使其变得笨拙。

第二次更新：#1 原来是一个死胡同。我的最终解决方案使用了 UIWebView (#3) - 请参阅答案。

4

4 回答 4

3

我发现一些资源可能对一些正在做复杂的 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。第4个例子。 https://developer.apple.com/library/ios/#samplecode/TableViewSuite/Introduction/Intro.html

非常接近解决方案..是的

于 2013-01-17T16:50:13.720 回答
3

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

（重新）为速度而建

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

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

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

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

所有这些以及更多导致滚动时的高帧速率和保持响应的应用程序。

于 2015-01-25T04:11:23.457 回答
2

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

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

添加到动态单元格高度和属性字符串上，这些表格的滚动效果很差。我想下一个优化将是覆盖 drawRect，但那时我决定尝试 UIWebView。

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

于 2012-12-22T01:49:25.180 回答
1

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

没有 3 个作品，但不会感觉那么流畅/总是有点“html-ish”

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

于 2012-12-02T00:35:23.167 回答