【问题标题】:NSAsynchronousFetchRequest possible memory leakNSAsynchronousFetchRequest 可能的内存泄漏
【发布时间】:2017-06-13 09:43:55
【问题描述】:

问题: 使用 xcode 工具分析 iOS 应用程序,它似乎是一个很小但至关重要的(sn-p 在整个项目中间接执行)内存泄漏。

描述:我们不使用任何实体引用并遵循典型的苹果建议的核心数据对象上下文堆栈

这里是仪器的屏幕截图,显示由于NSAsynchronousFetchRequest 保持对NSFetchResult 的相互间接引用而导致明显泄漏

根据Instruments

,这里是触发泄漏的代码sn-p(去掉所有不必要的代码,即使[弱自己]仍然没有改变它)
let anEntityFetch = NSFetchRequest<NSFetchRequestResult>(entityName: AnEntity.entityName)

let asyncFetchRequest = NSAsynchronousFetchRequest(fetchRequest: rangeQuantityFetch) { (asynchronousFetchResult) -> Void in
    //
}

do {
    // commenting out the execute there is no leak anymore
    _ = try managedObjectContext.execute(asyncFetchRequest)

} catch {
}

启用编译优化标志也会发生同样的事情。

问题:是否有可能只是 Instruments 或 xcode 错误?或者这是一个已知的核心数据问题?或者任何有用的提示来解决我的问题源将不胜感激。

【问题讨论】:

    标签: swift core-data memory-leaks swift3 instruments


    【解决方案1】:

    这似乎是核心数据对象上下文堆栈的问题。在配置中,我们有一个主上下文,其父上下文有一个写入上下文,该写入上下文具有实际的持久性协调器。 根据memory-leak-on-nspredicate-that-used-in-fetch-request-to-fetch-nsmanagedobject 的说法,问题在于主上下文有父级。

    解决这个问题

    • 按照答案中的指示更改核心数据堆栈
    • 或(似乎 工作,但不是一个干净的解决方案)扩展NSAsynchronousFetchRequest以设置为零request属性 在调用完成块之后(这样参考周期是 ARC 可以释放资源)。

    【讨论】:

    • 我看到了同样的问题,现在无法更改我的整个核心数据堆栈。你能解释一下你的第二个解决方案吗?当我扩展 NSAsynchronousFetchRequest 时,“fetchRequest”属性是 get-only,我不能将它设置为 nil。
    • 我猜有点晚了,但对于未来的读者来说:这个解决方案不再起作用,而且似乎不需要 ios14。
    猜你喜欢
    • 2011-01-03
    • 1970-01-01
    • 1970-01-01
    • 2020-01-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多