Iphone 为什么静态字符串会泄漏？

我有以下代码来检索iOS应用程序上的文件路径：

static const NSString * fullPathFromRelativePath(NSString *relPath)
{
    // do not convert a path starting with '/'
    if(([relPath length] > 0) && ([relPath characterAtIndex:0] == '/'))
        return relPath;

    NSMutableArray *imagePathComponents = [NSMutableArray arrayWithArray:[relPath pathComponents]];

    NSString *file = [imagePathComponents lastObject];    
    [imagePathComponents removeLastObject];

    NSString *imageDirectory = [NSString pathWithComponents:imagePathComponents];

    NSString *fullpath = [[NSBundle mainBundle] pathForResource:file
                                                         ofType:NULL
                                                    inDirectory:imageDirectory];
    if (!fullpath)
        fullpath = relPath;

    return fullpath;    
}

static const char * fullCPathFromRelativePath(const char *cPath)
{
    NSString *relPath = [NSString stringWithCString:cPath encoding:NSUTF8StringEncoding];
    const  NSString *path = fullPathFromRelativePath(relPath);
    const char *c_path = [path UTF8String];
    return c_path;
}

static const char * relativeCPathForFile(const char *fileName)
{        
    NSString *relPath = [NSString stringWithCString:fileName encoding:NSUTF8StringEncoding];        
    const NSString *path = fullPathFromRelativePath(relPath);
    const char *c_path = [[path stringByDeletingLastPathComponent] UTF8String];    
    return c_path;
}

在调试控制台中，我收到了很多这样的消息：

objc[4501]: Object 0x6e17060 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
objc[4501]: Object 0x6e12470 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
objc[4501]: Object 0x6e12580 of class __NSCFData autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug

代码有什么问题？（我甚至在使用iOS 5的“自动”保留/发布等功能）

---

干杯。

我认为这不是真正的泄密。苹果已经讨论过几次了，在模拟器上，这是模拟器库如何处理NSAutoReleasePool的一个已知的伪错误，但不足以保证修复，因为你的mac电脑的内存比设备大得多。在WWDC，他们提到有几个地方NSZombie不能正确处理自动释放，但我记不起是在哪个会话中。除非您注意到仪器中这些物体的泄漏，否则您不必担心。如果使用仪器发现泄漏，请提交一份文件

---

不要仅仅因为方法看起来可能正在泄漏，就在方法周围创建自动释放池。在ARC上，这无论如何都不起作用，除非你修改了你应用程序的main（）函数，否则你会有一个自动释放池来包装所有内容。如果在调用该方法后创建一个额外的自动释放池而不分析表明内存压力过大的数据，实际上会使应用程序的性能变差。

如果在main.m文件中删除了NSAutoreleasePool调用，或者如果此代码是在单独的线程中执行的，则会发生这种情况。

---

因为不能将NSAutoreleasePool与ARC一起使用，所以必须将线程代码放入@autoreleasepool块中

当您在堆栈中没有任何释放池的线程上自动释放对象时，会显示此消息。默认情况下，主线程上始终有一个自动释放池。它是在通常由应用程序的main（）函数调用的

UIApplicationMain（）函数中创建和管理的。但是，您创建的其他线程（使用
performSelectorInBackground:
或
NSThread
）没有自动释放池，除非您专门将自动释放池放在那里，因此该后台线程上的任何自动释放对象都没有池可供以后释放，并且只会泄漏

如果要启动后台线程，首先应该创建一个自动释放池。在ARC下，使用新的
@autoreleasepool
构造来执行此操作。
您是否尝试在非ARC应用程序中运行相同的代码？通过这样做，您可以确认这是ARC问题还是框架中的真正bug。ARC还不成熟，苹果已经多次声明它还没有完成，而且肯定有漏洞

如果您关心正在创建的明显自动释放对象的数量，请围绕相关代码使用
@autoreleasepool{…}
构造。这比NSAutoreleasePool要多得多，反正你不能在ARC代码中创建NSAutoreleasePool。
如果你在后台线程中有代码，你就没有一个自动释放池来包装所有东西；UIKit为您创建的自动释放池仅适用于主线程。这是事实，并且可能是Apple推动开发人员使用block&GCD的主要原因之一。但是OP没有提到在后台线程上工作……不，OP没有提到后台线程，但是这个错误几乎只发生在后台线程上，除非您修改main（）以不调用UIApplicationMain（），这是不可能的。NSAutoreleasePool，OP明确说明了这一点。无法编译。无法使用NSAutoreleasePool对象。ARC提供@autoreleasepool块。这些工具的优点是比NSAutoreleasePool更高效。从您提供给我的页面复制的是正确的。你给海报的推荐无效。谢谢！，仍然习惯于弧：）。在第一个方法中围绕@autoreleasepool包装代码修复了这个问题。（这是@autoreleasepool，不是@autorelease）嘿，这个答案是正确的。我没有通过任何CocoaAPI创建更多线程，但我有一些新线程是由较低级别的C函数创建的，这就是问题的原因所在。我用@autoreleasepool包装了第一个方法，问题得到了解决。我的头还在弧上绕着：）