仪器和内存泄漏
我正在使用 XCode 仪器中的泄漏工具来查找内存泄漏(见图)。每次我在应用程序的不同点运行应用程序时,都会出现一些泄漏。我查看扩展的细节,我从来没有指出我编写的任何代码,只指出内置于 xcode 基础中的代码。两个示例是:
http://imageshack.us/photo/my-图片/192/screenshot20110728at102.png/
http://imageshack.us/photo/my-images/853/screenshot20110728at102.png/
正如您所看到的,一些问题来自 Message UI 库。我唯一使用的地方是这里:
-(void)displayComposerSheet
{
MFMailComposeViewController *mail = [[MFMailComposeViewController alloc] init];
mail.mailComposeDelegate = self;
[mail setSubject:@"Suggestions"];
[mail setToRecipients:[NSArray arrayWithObjects:@"[email protected]", nil]];
[self presentModalViewController:mail animated:YES];
[mail release];
}
-(void)launchMailAppOnDevice
{
NSString *recepient = [NSString stringWithFormat:@"mailto:[email protected]"];
recepient = [recepient stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:recepient]];
}
-(void)mailComposeController:(MFMailComposeViewController *)controller didFinishWithResult:(MFMailComposeResult)result error:(NSError *)error
{
[self dismissModalViewControllerAnimated:YES];
}
我该如何解决这个问题?谢谢!
I'm using the leaks tool in XCode's instruments to find memory leaks (go figure). I have a few leaks each time I run my app at different points in the app. I look at the extended details, and I'm never pointed to any of the code I wrote, only code built into the foundation of xcode. Two examples of this are:
http://imageshack.us/photo/my-images/192/screenshot20110728at102.png/
http://imageshack.us/photo/my-images/853/screenshot20110728at102.png/
As you can see, some of the problems come from the Message UI library. The only place I use that is here:
-(void)displayComposerSheet
{
MFMailComposeViewController *mail = [[MFMailComposeViewController alloc] init];
mail.mailComposeDelegate = self;
[mail setSubject:@"Suggestions"];
[mail setToRecipients:[NSArray arrayWithObjects:@"[email protected]", nil]];
[self presentModalViewController:mail animated:YES];
[mail release];
}
-(void)launchMailAppOnDevice
{
NSString *recepient = [NSString stringWithFormat:@"mailto:[email protected]"];
recepient = [recepient stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:recepient]];
}
-(void)mailComposeController:(MFMailComposeViewController *)controller didFinishWithResult:(MFMailComposeResult)result error:(NSError *)error
{
[self dismissModalViewControllerAnimated:YES];
}
How can I fix this? Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
找出泄漏的来源并不总是一件容易的事,远程帮助则更加复杂。
在您的情况下,可能有帮助的是泄漏的内存地址旁边显示的小箭头。如果单击它,您应该会看到一个包含当时完整堆栈跟踪的信息窗格。检查那里显示的方法列表并查找您的某些方法,然后单击它以检查代码。
在 Instruments 中您无法做太多其他事情来了解泄漏对象的创建位置。然后你应该找出你可能在哪里错过了发布它。
至于Apple SDK,有一些内存泄漏的报告,你可以在网上找到,但它们确实很少。
如果 Instruments 不能帮助您,您需要考虑的一个重要因素是:当 Instruments 报告泄漏时您的应用程序正在做什么?从网络检索数据,显示新视图,等等......这可以帮助界定您进一步调查的领域。如果泄漏多次出现,这对于确定程序的哪一部分可能产生泄漏也具有很大的价值。
如果您对此有所了解,请检查完成该操作的代码。一种技术(我知道这可能听起来很奇怪,但尝试一下)是删除/注释掉代码块,然后检查泄漏是否仍然存在。
“删除/注释掉代码块”可能意味着很多事情,从不发出网络请求,到避免使用某种类型的类并将其替换为另一个类型。这并不总是一个简单的过程,因为您会损害应用程序的功能,因此您必须利用有关如何删除功能并使您的应用程序“可测试”的知识。如果幸运的话,这可以帮助您进一步界定导致泄漏的代码。
请记住,静态分析工具也可以提供帮助,并且泄漏并不完美,有时它是错误的。还有另一种发现泄漏的技术不是基于泄漏,而是基于对象分配。根据我的经验,这非常强大,我强烈鼓励您也尝试一下,尽管我怀疑这在这种情况下没有帮助。它被称为 堆快照分析。
Finding out where a leak comes from is not always an easy task, helping remotely is even more complex.
In your case, what could help is the little arrow that is shown next to the memory address of the leak. If you click on it, you should get shown an information pane with the full stack trace at that moment. Inspect the list of methods presented there and look for some method of yours, then click on it to inspect the code.
There is not much else you can do in Instruments that get an idea about where the leaked object was created. You should then figure out where you could have missed releasing it.
As to Apple SDK, there are a few memory leaks that are reported and that you can find out there on the web, but they are really seldom.
If Instruments does not help you, one important consideration for you is: what was your app doing when Instruments reported the leak? Retrieving data from the web, displaying a new view, whatever... this could help in delimiting the field of your further investigation. If the leaks shows up multiple times, this could also be a great value to identify what part of your program could be producing it.
If you get a clue about that, then go check the code that accomplishes that. One technique (I know that it might sound strange, but try it) is removing/commenting out chunks of code and then checking to see whether the leak is still there.
"Removing/commenting out chunks of code" may mean many things, from not making a web request, to avoid using a class of a type and replacing it with another. This is not always a simple process, because you impair the app functionality, so you have to use your knowledge about how remove functionality and leave your app "testable". If you are lucky, this could help you further delimiting the code that is causing the leak.
Keep in mind that also the static analysis tool could help, and that leaks is not perfect, sometimes it is wrong. There is another technique to discover leaks that is not based on Leaks, but on Object Allocation. This is very powerful in my experience and I strongly encourage you to try that also, although I suspect that it will not help in this case. It is called heapshot analysis.