- 浏览: 527920 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
landerson:
明显就有要求的嘛
ANDROID轻量级JSON序列化和反序列化[转] -
jimode2013:
很不错,就是需要这个方法
多个UIViewController使用addSubView,第二个 UIViewController 不响应旋转[转] -
w11h22j33:
...
[转]NSMutableArray中的自动释放对象让我郁闷了一整天 -
w11h22j33:
UILabel* label = [[UILabel a ...
Iphone开发 -
w11h22j33:
http://mobile.51cto.com/iphone- ...
获得通讯录中联系人的所有属性[转]
Finding iPhone Memory Leaks: A “Leaks” Tool Tutorial
There are plenty of different places to get a mobile application designed. The problem is that they’re quite expensive. You might be able to figure out how to create your own, but it will probably look very basic. Instead, a good mobile application development software can make it even easier, so that you can build great looking apps all by yourself.
The Mobile design Starter Kit includes all the themes and scenarios you need to build whatever app you want. There are customizable and standard files that allow you to sell or offer anything you want through the kit. Everything is there, so once you spend the money, you can create as many mobile apps as you want – and even sell the apps if this is your thing.
I’ve been using Instruments a lot lately as I approach the end of my game development cycle. I’ve found it especially useful for tracking down memory leaks in my game. I figured that since I found Instruments so helpful, it might be helpful for other people to get a quick introduction on how to use it to track mem leaks.
What is a memory leak and why should I care?
A memory leak is when your program loses track of a piece of memory that was allocated. The consequence is that the “leaked” memory will never be freed by the program. This usually happens when a piece of code does a “new,” “malloc,” or “alloc” but never does a corresponding “delete”, “free” or “release” respectively.
When you new, malloc, or alloc, what the Operating System is doing is giving your program a chunk of memory on the heap. The OS is saying, “here, have this block of memory at this memory address.” It expects you to hold a reference to that memory address (usually in the form of a pointer) and it’s relying on you to tell the OS when you’re done with it (by calling free, delete, or release).
Memory leaks happen when you throw away your pointer to that memory. If your program no longer knows where on the heap your memory is allocated, how can you ever free it?
So why should you care? In the most minor case, you’re wasting memory that will be freed when the user quits your app. In the worst case, you could have a memory leak that happens every frame. That’s a good way to end up crashing your program, especially if a user lets it run for a long time.
For more general information on memory leaks, have a look at Wikipedia for a start:
http://en.wikipedia.org/wiki/Memory_leak
How do I know I’ve got a memory leak?
Some memory leaks are easy to see by looking at your code. Some are much more difficult. This is where Instruments comes in. Instruments has a “Leaks” tool that will tell you exactly where you’re leaking memory so that you can get in there and fix it!
An Example App
I’ve created an example application that leaks memory in two places: in an Objective-C view controller, and in a C++ class I’m using in the app. The code is available from Github here. Below are excerpts from the code below that contain the leaks we’ll track down:
InstrumentsTestViewController.mm Excerpts
// 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!"]; }
LeakyClass.mm Excerpts
// Leaky excerpts - see GitHub for complete source LeakyClass::LeakyClass() { mLeakedObject = new LeakedObject(); } LeakyClass::~LeakyClass() { }
I’m going to go ahead a build my InstrumentsTest iPhone app in Debug and get it running on my iPhone. (You’ll have to set up the code signing to work on your device.) Once I’ve done that, I’ll boot up Instruments (typing “Instruments” into Spotlight should find it).
Instruments
When you launch Instruments, you should be given the chance to select from a variety of different Instrument tools to use. On the left-hand side, choose iPhone. On the right-hand menu, double-click the “Leaks” tool:
Once you’ve done that, you should see a window that looks like this:
Make sure your iPhone is still connected to your computer. In the top-left corner of the window you’ll see a drop-down menu that says “Launch Executable”. Click on that and make sure that your iPhone (not your computer) is selected as the active device. Then scroll down to “Launch Executable” and you should see a list of all the apps that are installed on your iPhone. Find the app that you want to run “Leaks” on (in this case, InstrumentsTest) and click it.
You’re now ready to go. Click on the red “Record” button and it will launch your application for you and start recording every memory allocation you do. It will also automatically check for leaks every 10 seconds.
You can change how often the automatic leak check runs, or you can set it to run only when you tell it too (when it checks for leaks, the entire app will freeze for about 3-5 seconds, so it can be annoying if you’re trying to play test and check for leaks at the same time). What I usually do is set it to manual control, and then hit the “Check for leaks” button whenever I need to (e.g. after loading a new game mode, after quitting the game back to the main menu, etc). Click on the Leaks row and use the View -> Detail button in the top right corned of the window to set/view options. For this example, I’m going to leave it on auto.
After the app has run for a few seconds, the auto leak check will run and lo and behold, it has found two memory leaks! Fantastic! What do we do now?
Extended Detail View
Instruments is very sneaky: it doesn’t make it obvious what to do next. What you need to notice is that row of buttons along the bottom of the window. See that little one made up of two rectangles? Hover your mouse over it and it will say “Extended Detail View”. (Note: You can also open this via View -> Extended Detail)
Click that button and a window opens up on the right-hand side of the screen that provides all kinds of handy details about your leaks!
Click on one of the memory leaks. The Extended Detail View will show you a complete stack trace to the point where your leaked memory was allocated. In our example above, clicking on the first leak reveals that a leak occurred inside [NSString initWithUTF8String]. If you look one step higher in the stack trace, you’ll see the last call inside my app was to [InstrumentsTestViewController viewDidLoad].
Here’s the really cool part, double-click on that line in the Extend Detail View and it opens an XCode window right to the culprit!
In this case we see that it was the first NSString allocation that leaked. Here’s where you need to do a bit of detective work. This is an extremely simple case, but it can get more tricky to find out why something’s leaky. Let’s take a closer look at our example.
In viewDidLoad we allocate some memory for the string, like this:
mMyLeakyString = [[NSString alloc] initWithUTF8String:"I'm a leaky string."];
And in dealloc, we release it like this:
[mMyLeakyString release];
So your immediate reaction might be that there shouldn’t be a leak. However, let’s search the code for all references to mMyLeakyString. That turns up this line inside doSomethingNow:
mMyLeakyString = [[NSString alloc] initWithUTF8String: "Look, another alloc, but no release for first one!"];
Notice that we’ve allocated a new string and assigned the pointer to mMyLeakyString. The problem is that we never released mMyLeakyString before it started pointing to something else. So the original string is now floating around on the heap and we have no way of freeing that memory. What the release call inside dealloc is actually doing is freeing the 2nd string that we allocated in doSomethingNow, because that’s where the pointer is pointing.
So, to fix this, we might change doSomethingNow to something like this:
- (void) doSomethingNow { [mMyLeakyString release]; mMyLeakyString = [[NSString alloc] initWithUTF8String: "Look, another alloc, but released first one!"]; }
What this does is release the first string we allocated before we point mMyLeakyString to our new string. When you build and run your app in Instruments again, you’ll see there’s one fewer memory leak. Of course, there are probably some better ways to handle NSStrings in your project, but if you had to do it this way, this would fix it.
Let’s take a look at that second leak. Clicking on it again reveals the callstack of what led to the leak. Finding the last call inside our app shows that the leak came from inside the LeakyClass::LeakyClass() constructor:
Double-click that in the stack and it opens up the culprit in XCode again:
Here we see the constructor does a new of a LeakedObject. But what’s this? The destructor never deletes the pointer? Well that’s no good! For every new, there needs to be a corresponding delete! So let’s change the destructor to this:
LeakyClass::~LeakyClass() { if (mLeakedObject != NULL) { delete mLeakedObject; mLeakedObject = NULL; } }
Build and run your app through Instruments again and you should be memory leak free!
I’ve chosen these two examples, even though they’re both very simple, because they show that Instruments can be used to track down memory leaks both in your Objective-C objects, as well as your C++ classes that are integrated into your app.
So go forth and fix your memory leaks! Because remember, a mem leak-free app is a happy app!
Similar articles:
发表评论
-
iOS App性能优化
2014-01-03 11:23 1650http://www.hrchen.com/2013/05/ ... -
iOS多线程编程Part 3/3 - GCD
2014-01-03 11:21 1593http://www.hrchen.com/2013/07/ ... -
iOS多线程编程Part 2/3 - NSOperation
2014-01-03 11:20 4491http://www.hrchen.com/2013/06/ ... -
iOS多线程编程Part 1/3 - NSThread & Run Loop
2014-01-03 11:17 7046http://www.hrchen.com/2013/06/ ... -
iOS移动网络环境调优那些事[转]
2014-01-02 17:10 2661http://xiangwangfeng.com/201 ... -
生成APNS Service证书的步骤[转]
2013-05-23 09:19 5639要进行推送服务的第一件事就是获取推送证书。它用来对你通过SS ... -
xcode 环境,多工程联编设置【转】
2013-02-28 21:59 8881http://blog.csdn.net/vienna_zj ... -
干掉你程序中的僵尸代码【转】
2012-12-22 11:05 927随着万圣节越来越流行,我感觉有必要跟大家讨论一下一个 ... -
一个文本框搞定信用卡相关信息的输入[转]
2012-12-22 11:03 1089http://beforweb.com/node/134 ... -
【转】深度技术分析“为什么ios比android流畅”
2012-09-23 19:41 1404原文 Andorid更新了一个版本又一个版本,硬 ... -
Iphone开发
2012-09-17 22:46 11631. NSClassFromString 这个方法 ... -
HowTo: Install iPhone SDK 2.0 – 3.1 for XCode 3.2[转]
2012-09-06 09:00 1179原文链接 So… you’ve installe ... -
Xcode 中设置部分文件ARC支持[转]
2012-08-03 10:57 1703ARC是什么 ARC是iOS 5推出的新功 ... -
xcode4 设置调试错误信息小结【转】
2012-07-19 14:37 1758方案1:NSZombieEnabled 先选中工程, ... -
[Cocoa]XCode的一些调试技巧【转】
2012-07-19 14:35 1171XCode 内置GDB,我们可以在命令行中使用 GDB ... -
[IPhone]如何使用Leak检查内存泄漏[转]
2012-07-19 14:34 1187简介 在IPhone程式开发中,记忆体泄漏(内存泄漏)是 ... -
获得通讯录中联系人的所有属性[转]
2012-06-21 14:04 1565获得通讯录中联系人的所有属性 ,看代码: ABAdd ... -
多个UIViewController使用addSubView,第二个 UIViewController 不响应旋转[转]
2012-06-20 23:51 16373------------------------------- ... -
shouldAutorotateToInterfaceOrientation 不触发或者不执行的问题[转]
2012-06-20 22:58 1413今天遇到一个很郁闷 ... -
UIViewController生命周期-学习笔记[转]
2012-06-20 22:57 1092UIViewController生命周 ...
相关推荐
Finding memory leaks发现内存的泄漏(6KB)
Finding memory leaks发现内存的泄漏(6KB)
finding alphas a quantitative approach to building trading strategies MOBI电子书
1. Are there any memory errors in the following programs? If so, list all of them. Assume that the user enters in correct input, and that the sizes entered are at least one. Write your solution in a...
A*寻路的C#源码,包含库的源码和demo程序。包含逐步的寻路和马走日的寻路,包含从Excel读取地形的源码。本人Blog中有说明:https://blog.csdn.net/KenZhang1031
afrog 是一款性能卓越、快速稳定、PoC 可定制化的漏洞扫描工具 - A tool for finding vulnerabilities
CVPR-2018论文合集--SLAM DNN CNN 目标检测与目标识别 视频目标分割 图像分割 自然语言处理 自动驾驶
IBM HeapAnalyzer is a graphical tool for discovering possible Java heap leaks. Steps Download: https://public.dhe.ibm.com/software/websphere/appserv/support/tools/HeapAnalyzer/ha457.jar Open a ...
finding a majority among n votes.pdffinding a majority among n votes.pdffinding a majority among n votes.pdffinding a majority among n votes.pdfv
Finding Memory Leaks Issues with System RAM Issues with Battery Life Power Measurement Options Sources of Power Drain Addressing Application Size Issues Crash Reporting Using ACRA In-App Diagnostics ...
Although 2 GB of address space may seem like a large amount of memory, application such as SQL Server could leverage more memory if it were available. The boot.ini option /3GB was created for those ...
estimation procedure for two applications: 1) finding the parameters of a mixture of Gaussian densities, and 2) finding the parameters of a hidden Markov model (HMM) (i.e., the Baum-Welch algorithm) ...
a star method for finding path planning of a moving object
Title: 10 Lessons About C++ You Need To Learn To Become A Master Programmer Author: Andrew Webb Length: 376 pages Edition: 1 Language: English Publication Date: 2015-03-21 ISBN-10: B00V2LR8NI 10 ...
VisionPro_Shape Finding 帮助文档,英文版说明直线、圆、椭圆的查找
Finding Memory Leaks Issues with System RAM Issues with Battery Life Power Measurement Options Sources of Power Drain Addressing Application Size Issues The Role of Scripting Languages The Scripting ...
A Recommender System for Finding Passengers and Vacant Taxis
It serves as a blueprint for those in charge of finding solutions to this considerable challenge. Table of Contents Chapter 1: Software Modernization: a Business Vision Chapter 2: Software ...
Mobile Marketing Finding Your Customers No Matter Where They Are,英文版本,PDF 格式,大小 5 Mb,作者:Cindy Krum。 Topics include • Getting started fast with mobile marketing • Understanding the ...
截至 20100209 最新版本《iPhone 应用程序开发全教程》。英文名: Beginning iPhone 3 Development Exploring the iPhone SDK.pdf,作者 Dave Mark & Jeff LaMarche。 内容预览: Prelims Contents at a Glance ...