了解内存泄漏检查工具 - iPhone
上面给出的图像是我的应用程序泄漏的图像。
在这里我想了解的是，在扩展细节中 - 您可以看到不同的颜色，例如浅绿色，浅粉色，浅棕色，浅紫色。
每种颜色代表什么？
现在另一个困惑是“如何找到造成内存泄漏的代码？”
内存泄漏的上限是多少 - 实际的 iPhone 可以继续使用。 （假设10字节没问题，20字节没问题，200字节有问题）
- 每种颜色代表什么？
- 哪种颜色表示我们的代码/从哪个细节我们可以找到我们分配对象和对象的代码。忘记释放它？
（例如 - 单击 UIKit 第二个单元格的详细信息 - 我们无法访问代码）
- 为什么我们必须解决所有泄漏问题？ - 即使是一次泄漏也会让 iPhone 堵塞？
- 为什么 iPhone 允许泄漏保留在内存中？ / 为什么应用程序终止后垃圾收集不会自动完成？
- 如果我尝试释放应根据工具释放的对象，我的应用程序会异常终止。如果我不解除分配，我的应用程序可以完美运行，怎么样？
- 为什么建议您在视图中等待10秒或更长时间，如果有泄漏，仪器会检测到泄漏？
Above given images is of my application leaks.
Here I want to understand that, in Extended Detail - you can see different colors like light green, light pink, light brown, light purple.
What does each color indicates?
Now the other confusion is "How to locate the code which is creating a memory leak?"
Upto what limit of memory leak - the actual iPhone can go on with.
(suppose 10 bytes no problem, 20 bytes no problem & 200 bytes a problem)
- What does each color indicates?
- Which color indicates our code / From which detail we can get to the code where we have allocated the object & forgot to dealloc it?
(For example - On clicking of UIKit second cell in detail - we cant get to the code)
- Why we must resolve all the leaks? - even a single leak can chock up iPhone ?
- Why iPhone allows leaks to be remain in memory? / why garbage collection isn't done automatically after termination of application?
- If I try to dealloc objects which should be deallocated according to instruments, My application terminates abnormally. If I don't dealloc, My application runs perfectly, How?
- Why it is suggested that you wait in a view up to 10 or more seconds, if there is a leak, leak will be detected by Instruments?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
忽略颜色，在其中 [DashBoard viewDidLoad] 是泄漏的根源，它是如何初始化 URLConnection 的（可能在连接完成时您没有释放它？）
现在回答您的其他问题：
即使是一次泄漏也会堵塞
iPhone ？
是的。部分原因不仅是你会耗尽内存，而且由于整个手机只有这么多内存，看门狗应用程序会不断监视你的应用程序，如果发现内存使用，它会提前关闭它只会不断增长……
在记忆中？ / 为什么垃圾收集
之后不会自动完成
终止申请？
当应用程序退出时，所有应用程序内存都会被释放。
应根据
仪器，我的应用
异常终止。如果我不这样做
dealloc，我的应用程序运行
完美，怎么样？
在这里我无能为力，你真的需要阅读更多关于保留/释放内存周期的内容......如果你释放一个保留计数为0的对象，应用程序会崩溃，因为该对象消失了。
观看时间长达 10 秒或更长时间，如果
有泄漏，将会泄漏
仪器检测到？
由于仪器的工作原理是每隔一段时间对内存进行采样，因此仪器在执行操作后可能需要一些时间来读取内存。
Ignore the colors, in that one the [DashBoard viewDidLoad] is the source of the leak, something in how it's initializing a URLConnection (possibly you did not free that when the connection was finished?)
Now to answer the other questions you had:
even a single leak can chock up
iPhone ?
Yes. Part of the reason is not only that you will simply run out of memory, but since there is only so much memory to go around for the whole phone a watchdog application is constantly monitoring your app and will shut it down early if it sees memory use only ever growing...
in memory? / why garbage collection
isn't done automatically after
termination of application?
All your application memory is freed when the app quits.
should be deallocated according to
instruments, My application
terminates abnormally. If I don't
dealloc, My application runs
perfectly, How?
Here I can't help, you really need to read more on the retain/release memory cycle... if you release an object that has a retain count of 0, the app crashes because the object is gone.
a view up to 10 or more seconds, if
there is a leak, leak will be
detected by Instruments?
Because instruments works by sampling memory every so often, so it might take a little bit for instruments to get around to reading the memory after an action.
首先，堆栈中的内容根据它们来自哪个库进行着色，因此它不包含那么多信息。
其次，我不会担心 iPhone 能承受多少泄漏，而是专注于不泄漏。
要查找泄漏，有几个选项：
分配、保留或复制对象（包括使用@property (retain)或(copy)），您必须release或自动释放它。First of all, the things in the stack are colored by which library they come from, so it doesn't contain that much information.
Second, instead of worrying about how much leakage the iPhone can take, I'd focus on not having it leak.
To find leaks, there are a couple options:
alloc,retain, orcopyan object (including using@property (retain)or(copy)), you mustreleaseorautoreleaseit.颜色代表调用堆栈正在经历的不同库。
泄漏是由代码中进行分配的框架引起的，即使实际分配发生在操作系统库的深处。 Instruments 正在向您显示泄漏内存的分配位置准确。您必须找出代码中的哪一行导致了分配泄漏，这将是右侧堆栈中的帧之一。
实际的 iPhone 没有太多 RAM 可用于您的应用程序。我倾向于保守地估计大约 25MB 的 RAM 可供我的应用程序使用。如果代码使用得足够多，任何泄漏，无论多么小，都可能沉没。
The colors represent the different libraries the call stack is going through.
The leak is caused by the frame in your code that made the allocation, even if the actual allocation is taking place deep within an OS library. Instruments is showing you exactly where the leaked memory was allocated. You'll have to figure out which line in your code resulted in the leaked allocation, which will be one of the frames in the stack on the right.
The actual iPhone doesn't have much RAM available to your application. I tend to conservatively estimate about 25MB of RAM for my application to work with. Any leak, no matter how small, can sink the proverbial ship if the code is used enough.
在堆栈扩展视图中查找您的应用程序名称。内存分配通常显示在最后，因此您可以确切地知道哪个库负责内存分配。所以你应该从你的代码出现的那一行向下追踪到最后。颜色只是让跟踪与相同库相关的代码行变得更容易。相同的库调用将使用相同的颜色。
至于追踪泄漏本身。首先，在扩展视图中双击该行，转到您的应用程序调用，并尝试了解到底泄漏了什么。有时您可以用不泄漏的替代品来替换泄漏的呼叫。例如，我使用调用 imageNamed 从包中检索图像，应用程序由于内存不足而不断崩溃。我刚刚在 google 上搜索了 imageNamed Leaks，发现了关于如何在我的应用程序中实现图像现金的非常有用的文章。事实上，imageNamed API 存在泄漏。 iphone SDK中存在泄露的API。
另外，尝试检查您如何使用分配/保留/释放等，无论您释放还是自动释放分配的内存。
祝你的侦探工作顺利。
Look for your application name in the stack extended view. Memory allocation usually shown in the end, so you know exactly which library is responsible for memory allocation. So you should trace from the line your code appear downwards till the end. Colors just make easier to trace lines of code, that are related to same libraries. Same library calls will be colored with the same color.
As for tracing leak itself. First go to your application call by double-click on the line in extended view and try to understand what exactly leaks. Sometimes you can replace the leaking call with non-leaking substitute. For example, I used a call imageNamed to retrieve images from the bundle, the application was constantly crashing because of memory shortage. I just googled imageNamed leaks and found very useful article on how to implement image cash in my application. Indeed, imageNamed API leaks. There are API that leaks in iphone SDK.
Also, try to check how you're working with alloc/retain/release and so on, whether you release or autorelease your allocated memory.
Good luck in your detective work.
我也遇到仪器泄漏的问题。我今天第一次使用泄漏运行我的应用程序，发现了几个泄漏。不应该是泄漏的泄漏，因为它们无法泄漏，除非正在执行一些神奇的代码并提高我的对象的保留计数。我了解内存管理指南，知道如何使用自动释放池等。但是，如果我在其上放置一些控件，即使是基于空视图的应用程序也会包含泄漏。只需点击大约 2-3 次即可。来吧，尝试一下。我真的不明白信息工具试图提供的信息。这些“泄漏”是真的泄漏，还是只是仪器应用程序怀疑的事情？如果一个没有用户代码、只有几个控件放在空视图上的空应用程序会泄漏内存吗？
I too have problems with leaks in instruments. I run my app today for the first time using leaks and found several leaks. Leaks that shouldn't be leaks because there is no way for them to leak, unless some magical code is executing and raising the retain count of my objects. I understand the memory management guidelines, know how to use autorelease pools, etc. But even an empty view based app contained leaks if i put a few controls on it. And just click around 2-3 times. Go ahead and try it. I don't really understant the information instruments is trying to provide. Are those "leaks" really leaks, or just things that are suspicious to the instruments app? Should an empty app with no user code, only a few controls put on an empty view leak memory?