最近常使用Instruments这个工具，我发现它对追踪游戏中的内存泄露非常有帮助。自从发现Instruments如此有用后，我就觉得写一篇文章介绍如何使用它来追踪内存泄露对其他人也会有帮助。
什么是内存泄露？我为什么要关心内存泄露？
…此段省略…
访问维基百科可以获得更多关于内存泄露的信息。
我如何知道内存泄露了？
一些内存泄露可以很容易地通过阅读代码来发现，另一些就要困难点了，这就是为什么需要Instruments 的原因。Instruments 有一个“Leaks”工具，它会准确地告诉你什么地方发生了内存泄露，以便你能定位和修复泄露问题。
例子程序
我写了一个例子程序，它有两个地方会发生内存泄露，一个在 Objective-C 视图控制器中，另一个在 C++ 类中。例程可以从这里获得。下边的代码是从例程里摘录的，包含了我们需要追踪内存泄露的代码。
// Leaky excerpts – see GitHub for complete source
- (void)viewDidLoad {
[super viewDidLoad];
LeakyClass* myLeakyInstance = new LeakyClass();
delete myLeakyInstance;
mMyLeakyString = [[NSString alloc] initWithUTF8String:”I’m a leaky string.”];
[self doSomethingNow];
}
- (void) doSomethingNow
{
mMyLeakyString = [[NSString alloc] initWithUTF8String:
“Look, another alloc, but no release for first one!”];
}
// Leaky excerpts – see GitHub for complete source
LeakyClass::LeakyClass()
{
mLeakedObject = new LeakedObject();
}
LeakyClass::~LeakyClass()
{
}
我会先在 Debug 模式编译InstrumentsTest，并在 iPhone 上运行。完成这步，我会启动 Instruments。
当你启动 Instruments，你可以从一堆 Instruments 工具里选择你需要的。在左手边选择 iPhone，在右手边的图标里双击“Leaks”工具：
之后你会看到下边的窗口：
请确保 iPhone 已经连接到了你的电脑，在这个窗口的左上角，你会看到一个下拉菜单，写着“Launch Executable”。单击它，并确保选中的是你 iPhone（而不是你的电脑）作为活动设备。然后移动到“Launch Executable”，你可以看到一个包含了所有已安装 iPhone 程序的列表。找到你希望运用“Leaks”工具的程序（本例中是 InstrumentsTest）并单击它。
你已经准备好了。单击红色的“Record”按钮，它会启动程序并开始记录程序里的每个内存分配操作。它会每10秒自动地检测内存泄露。
你 可以改变多少时间自动检测一次，你也可以手动进行检测（检测内存泄露的时候程序会停顿大约3-5秒钟，如果你想边进行测试边进行内存检测的话，这种停顿将 会干扰到你）。我一般是设置成手动控制，在我需要的时候才单击“Check for leaks”按钮（例如：在loading新的游戏模式之后检测一下，在退出游戏返回 MM 的时候检测一下）。单击“Leaks”，并使用右上角的 View->Detail 按钮来设置和查看选项值，在这个例子里，我将其设置成 auto。
程序在运行一段时间之后，自动内存检测将会发现两处内存泄露。太棒了！现在该干什么呢？
Extended Detail 视图
Instruments 非常懒，它不会明显地指出下一步该干什么。你需要注意的是窗口底部的那一排按钮。看见两个矩形组成的那个按钮了吗？讲你的鼠标停留在上边，它会提示“Extended Detail View”。
单击这个按钮，右边将会弹出一个窗口，里边提供了各种关于内存泄露的详细信息。单击一个内存泄露，Extended Detail 视图将会显示泄露的内存代码的完整调用堆栈。在我们上边的例子中，单击第一个内存泄露提示，它发生在 [NSString initWithUTF8String]。如果你选中调用堆栈里的高亮步骤，你会看到程序最后一次调用是 [InstrumentsTestViewController viewDidLoad]。
双击 Extend Detail 视图中的某行，它会打开 XCode 窗口并显示出问题的代码，这是非常棒的功能。
在本例中，第一次 NSString 分配的时候出现了泄露，你需要做一些处理。这是个非常简单的例子，但找到为什么会发生泄露则要麻烦些。让我们仔细看一下例子。在 viewDidLoad 当中，我们为字符串分配到了内存，如下所示：
mMyLeakyString = [[NSString alloc] initWithUTF8String:”I’m a leaky string.”];
在 dealloc 当中我们用如下方式来释放
[mMyLeakyString release];
你的直觉可能是这样不会发生泄露，但搜索代码中所有用到了 mMyLeakyString 的地方，在 doSomethingNow 中，它是这样用的：
mMyLeakyString = [[NSString alloc] initWithUTF8String:
“Look, another alloc, but no release for first one!”];
注意，我们声明了一个新的字符串，并且将 mMyLeakyString 指向了它。这里的问题是我们没有在更改 mMyLeakyString 的指向前释放它原 来指向的内存。所以原始的字符串依然在堆中，并且我们没有办法释放这部分内存。dealloc 里的 release 操作实际释放的是我们在 doSomethingNow 中声明的字符串所占内存，因为这才是指针所指。
为了修复这个问题，我们可以把 doSomethingNow 改成下边的代码：
- (void) doSomethingNow
{
[mMyLeakyString release];
mMyLeakyString = [[NSString alloc] initWithUTF8String:
“Look, another alloc, but released first one!”];
}
这段代码做的是在我们指定 mMyLeakyString 到新的字符串前释放第一个字符串所占内存。重新编译运行程序，你会看到只有一个内存泄露。当然，在项目中可能有更好的方式来处理 NSString，但如果你这样处理的话可以修复这个泄露问题。
让我们看看第二个泄露问题。单击泄露提示看什么导致了内存泄露。发现这个泄露来自于 LeakyClass::LeakyClass() 构造函数：
![clip_image009[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKuhgRD2R05oDtIHOMcjQREDYnEcJ4paCCdw2w84Y-v8nyFbZ9PNQU32fHmZ1bmNQoOghGLe0xhWdVwQabEctHKsZezlwTXlHJmOppOVXp9Njfk3IKqOGPDguvSIrFJ6Ez1DhVeYFlL8s/?imgmax=800 "clip_image009[1]")
在调用堆栈中双击它，出问题的代码将会再次出现在 XCode 中。
我们看到在构造函数里声明了一个新的 LeakedObject 对象，但是析构函数没有删除，这样不好。对于每一个 new 操作，都需要有与之对应的 delete 操作。所以我们把析构函数改变成下边的样子：
LeakyClass::~LeakyClass()
{
if (mLeakedObject != NULL)
{
delete mLeakedObject;
mLeakedObject = NULL;
}
}
重新编译运行，没有内存泄露了！
我选择这两个例子，虽然非常简单，但他们展示了 Instruments 可以用来追踪 Object-C 和 C++ 中的内存泄露。
修复你的内存泄露问题吧，记住，没有内存泄露的程序才是一个好程序。 原文出处
http://www.mobileorchard.com/find-iphone-memory-leaks-a-leaks-tool-tutorial/
![clip_image009[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmBamWBIBfoh0ee84558MWDEClSoS4rg7ToUDk9NLQE0ICinI5jf7z4jKefUY-lB2cF5CIuuquEL5HyRHnVDu-ay1RaRqErw_e6CIhm5pKjNlqg5LpfCeMuhkgbfmuI9Xb_Q-djpFfzVk/s1600-h/clip_image00913.jpg "clip_image009[1]")
