10 iPhone Memory Management Tips

From:?http://akosma.com/2009/01/28/10-iphone-memory-management-tips/

?

Memory management in the iPhone?is a hot topic. And since tonight I’m talking about it on tonight’s monthly meetup of the?French-speaking Swiss iPhone Developers group, I might as well share some tips here from my own experience.

I won’t go dive through the basics; I think that Scott Stevenson did a great job in his?“Learn Objective-C” tutorial at CocoaDevCentral, from where the image below comes. I’m just going to highlight some iPhone-specific issues here and there, and provide some hints on how to solve them.

To begin with, some important background information:

• The?iPhone 3G has 128 MB of RAM, but at least half of it might be used by the OS; this might leave as little as 40 MB to your application… but remember: you will get memory warnings even if you only use 3 MB;
• The iPhone does not use garbage collection, even if it uses Objective-C 2.0 (which can use garbage collection on Leopard, nevertheless);
• The basic memory management rule is: for every [ alloc | retain | copy ] you have to have a [ release ] somewhere;
• The Objective-C runtime does not allow objects to be instantiated on the stack, but only on the heap; this means that you don’t have “automatic objects”, nor things like auto_ptr objects to help you manage memory;
• You can use autorelease objects; but watch out! Since they are not released until their pool is released, they can become?de facto?memory leaks for you…;
• The iPhone does not have a swap file, so forget about virtual memory. When there is no more memory,?there is?no more memory.

  Having said this, here’s my list of tips:

  • Respond to Memory Warnings
  • Avoid Using Autoreleased Objects
  • Use Lazy Loading and Reuse
  • Avoid UIImage’s imageNamed:
  • Build Custom Table Cells and Reuse Them Properly
  • Override Setters Properly
  • Beware of Delegation
  • Use Instruments
  • Use a Static Analysis Tool
  • Use NSZombieEnabled

    Respond to Memory Warnings

    Whatever you do in your code, please do not forget to respond to memory warnings! I can’t stress this much. I have seen application crashes just because the handler methods were not present on the controllers, which means that, even if you do not have anything to clear in your controller, at least do this:

    Or finally, as an NSNotification:

    but this pool is not cleared up until your application quits! This means that during runtime, your autoreleased objects are?de facto?memory leaks, since they are retained until the application quits.?(please see the comments below; I have experienced better performance when avoiding autoreleased objects, but my understanding of pools is misleading?

    I started getting a better performance from my iPhone apps when I stopped using some methods creating autoreleased objects, for example:

    @end

    SomeClass is delegate of Widget. Widget instances might be retained by someone else, which means that even after the release message in the dealloc method, widget might still be alive and call its delegate; if this variable is not nil, widget will send a message to a non-existent object, which will surely crash your application.

    Use Instruments

    The “Leaks” instrument is your friend, and you should use it after you write the first line of code. Typically, I launch it every time before doing a checkin of some new code. In Xcode, select “Run / Start with Performance Tool / Leaks” and you’re done. You can use it in the simulator or on your device.

    Use a Static Analysis Tool

    Use the?LLVM/Clang Static Analyzer?tool. This amazing tool will catch naming errors (regarding the Objective-C naming conventions) and some hidden memory leaks, which are particularly nasty when using CoreFoundation libraries (Address Book, sound, CoreGraphics, etc). You can add it to your daily build script, it’s very easy to use.

    But you must use it. Enough said.

    Use NSZombieEnabled

    Lou Franco has posted an?excellent article about how to use NSZombieEnabled?in your development cycle. The idea is to be able to find which messages are being sent to invalid pointers, referencing objects which have been released somewhere in your code. Always remember who’s the owner of your objects, and check for existence elsewhere!

    And You?

    How about you? What are your tips or best practices you usually use for your iPhone apps? Feel free to share them in the form below.

    Update, 2009-01-29:?I am overwhelmed with the response and traffic that this post has gotten so far! Yesterday evening I had the pleasure of discussing this subject with the guys of the iPhone Developers Facebook group, and I got interesting remarks from Marco Scheurer from?Sen:te?(including a comment below), which I’ve added to this post today.

    Oh, and by the way,?I’ve uploaded the slides here!?They have a Creative Commons license, so feel free to use them if you find them useful.