Xcode：5.0.2 iOS：7.0.x
当用户登录我的应用时，我有一个有条件地显示的辅助视图。此辅助视图显示用户必须在其经过身份验证的会话的生命周期中选择其中一个作为“默认”值的项目列表。我的绝大多数用户只能看到这个次要视图。
项目列表以JSON格式从Web服务返回，可以是1项到1000项之间的任何位置。如果返回一个，则辅助视图甚至不会显示。
json的每个项目将再次包含两个元素，id和itemName。我估计在最糟糕的情况下下载几百kb，并且它是一次性下载。也许可搜索的API而不是数据转储是更好的做法？
结果返回后，它们将被处理为两个NSArray。我NSArray NSDictionary id我需要检索一次NSArray，NSString itemName包含UITableView - 用于填充For retrieving ID reference:
[ { id: 0, itemName: "one" }, { id: 1 itemName: "two" } ]
For populating the UITableView data source
[ "one", "two" ]
并执行关键字搜索;
UITableView现在我需要UITableView中的这些数据。由于这是一次性操作（稍后可更改，但用户通常不会定期更改）我计划将整个数组添加到UILocalizedIndexedCollation。
通常，您应该在表格视图中放入的最大尺寸是多少？这会给我带来一些严重的记忆问题吗？在搜索100的时候，关键字搜索将如何公平 - 1000。
我也在考虑更新用户界面，以便非常密切地关注联系人应用程序（{{1}}？），这样会对此产生影响。
谢谢，
答案 0 :(得分：0)
我还强烈建议CoreData采用UIFetchedResultController方法。这是为您的问题精心设计的解决方案。当您从Web下载数据时，FetchedResultController将显示空表视图，当下载完成或“足够”时，您可以显示数据而不会阻止用户界面。
此外，如果您想一次显示一个庞大的数据库，控制器会在用户向下滚动时“自行”获取更多数据。
当然，此处也支持UILocalizedIndexedCollation。
答案 1 :(得分：0)
拥有JSON，相应的Foundation表示将消耗大约 RAM的5倍于字节长度。
因此，例如，如果您的JSON是300 Kbyte（UTF-8），那么NSJSONSerialization将创建一个可能消耗1.5 MB RAM的Foundation层次结构。
这个数量非常适合RAM。
当且仅当您不想持久化 JSON表示或相应的模型时，并且不希望出于其他原因（例如编辑，撤消，回滚，等等，我强烈反对使用核心数据：因为在最坏的情况下你的数据仍然“小”，所以没有必要在假设它可以保护你的内存的情况下使用核心数据。 / p>
核心数据也不便宜，记忆明智。在您的情况下，使用Core Data实际上会导致您的App消耗更多 RAM，因为SQLite的缓冲区和缓存，核心数据缓冲区和缓存以及内部结构。在实践中并且考虑到具有1000个对象的场景，Core Data / SQLite方法将消耗大约4 MB。这比您的JSON表示大约多3倍。另一方面，当元素数量大幅增加以及存在内存压力时，Core Data可能不会消耗更多的RAM。