1

我目前正在为iOS开发一款游戏，但我们遇到了内存泄漏。我们的项目是ARC设置的。我想知道如何确保内存释放。我正在考虑采取的步骤之一是转换形式的代码：

-(void)methodMethod{
    Object* o = [[Object alloc] init];
    // Some logic
}

进入：

-(void)methodMethod{
    Object* o = [[Object alloc] init];
    // Some logic
    o = nil; // Explicit nil assignment
}

两者有区别吗？我应该采取哪些其他措施来确保 ARC 设置中的释放？

我们正在使用 Sparrow 框架。

4

4 回答 4

3

两种方法都做同样的事情。本地对象在离开作用域时被 ARC 设置为 nil，因此手动输入 nil 什么也不做。

如果您想查找泄漏 - 您最好使用 Leaks 工具通过 Instruments 实际运行它并找出泄漏的内容，这将使您更好地了解正在发生的事情。查找保留周期非常方便。

于 2013-05-08T07:33:37.153 回答
2

正如 Abizem 所指出的，这两种方法都会导致相同的结果，并且需要仔细通过 Instruments。结果并不总是容易解释的。

在 ARC 中，您永远不会看到泄漏 - 在通常的 obj-C 含义中 -。有时，iOS 工具会报告泄漏，但大多数（如果不是全部）来自运行时，我倾向于认为它们超出了我的控制范围。但是，您可以看到不受控制的内存增加，这是内存保留的典型特征。在对象上保留强指针是显而易见的原因，在我的情况下，这一直是以下结果：代码块中的保留周期，以及不正确的数据结构清理，即创建对象，然后填充到数组、字典、页面控制等。 . 但后者在应用程序生命周期中未正确清空。

此外，图像处理功能仍然使用嵌入到内部 UIGraphics 库中的标准 malloc/free 指令，因此在这种情况下，您明确需要释放内存（CGImageRelease 等）。ARC在这里无济于事。

希望这有助于缩小问题的范围，正如 Abizem 指出的那样，应该从 Instruments 开始。

于 2013-05-08T08:42:48.907 回答
0

以下是不必要的，但（至少对我而言）评论中的讨论很有帮助，这就是我离开它的原因

将该方法包装在 @autoreleasepool 中。这将使它 99% 确定它正在被释放

-(void)methodMethod{
    @autoreleasepool {
        Object* o = [[Object alloc] init];
        // Some logic
    }
}
于 2013-05-08T07:41:36.700 回答
0

两者都是一样的。

测试您的课程的更好解决方案：

- (void)testDealloc
{
    __weak CLASS *weakReference;
    @autoreleasepool {
        CLASS *reference = [[CLASS alloc] init]; // or similar instance creator.
        weakReference = reference;

        // Test your magic here.
        [...]
    }
    // At this point the everything is working fine, the weak reference must be nil.
    XCTAssertNil(weakReference);
}

这可以为我们要在内部释放的类创建一个实例，@autorealase一旦我们退出块，它将被释放（如果我们没有泄漏）。weakReference将保留对实例的引用而不保留它，该引用将设置为nil.

于 2014-10-12T19:16:03.250 回答