我有一个应用程序，可以从TCP / IP端点连续接收XML消息流。收到每条消息后，应用程序将其内容摘要到一组核心数据实体中。这是通过三个上下文结构完成的：
这种安排使流处理脱离主线程。该应用程序通常每秒或每两秒钟接收10-150条消息。解构并保留每个消息之后，将保存Stream上下文。在A6级设备上，CPU使用率通常不足15％。
但是我的问题是记忆。如果我将NSFetchedResultsController连接到Main上下文，则它们到达时会得到很好的消息流。但是，如果进行概要分析，我会发现我的NSManagedObject计数逐渐增加。最终，内存压力将导致应用终止。
经过12分钟的分析后，该应用程序已使用6300条XML消息并解析了121,000个属性。这将消耗7.8MB的属性资源，438KB的消息资源，现在应用程序总大小为54MB。显然，这是不可持续的。
Instruments指出所有对象仍处于活动状态。在互连网上浏览时，我相信我可能会有一个保留周期，从而不会导致对象出现故障。但是，在文档中尚不清楚使用“ refreshObject”的建议是否适用于此。
一旦接收到XML，就创建一个Message实体。接下来，使用XML的根节点作为名称以及相关的位来创建Type实体。类似地，为那些元素的每个元素和子元素以及XML的任何内联属性创建一个property元素。这是一个有趣的部分，因为它具有对消息的引用（用于所有属性的平面表示）以及与自身的层次childProperties关系。在此过程结束时，将保存上下文，并且主上下文将其选中，FRC将显示新行。
一种想法是在每保存几百条消息后就重置Stream上下文。如果我断开FRC的连接，我基本上可以保持水平-但是，当我重新连接FRC时，这感觉很不好，并且不能解决问题。
任何想法将不胜感激。