UIImagePickerController has plenty of issues. One of the first to be widely discussed was its memory leak which shows itself when you try to access the PhotoLibrary on the simulator. Fortunately, this leak is limited to the Simulator and does not show up on Device. It has also apparently been fixed in iPhone OS 2.2 – though you obviously need to be aware of it if you are coding for older versions.

There is, however, another more serious problem with the image picker on device [1], which shows up when repeatedly capturing images from the camera. If your application uses the camera, you have a choice. You can either hold open an instance of UIImagePickerController all the time, or you can release the controller when you are done using it, and instantiate it next time you want to use it. Surely the latter is better – you should only hold resources open when you need them.

Fig 1. Memory trace of repeated image captures on device

Figure 1, above, shows the problem with that approach when we moved to the device. We experienced frequent crashes in an application that involved many image captures. We eventually narrowed the problem down to repeatedly capturing images, where the application released the UIImagePickerController after every capture. After 7 or 8 (never more) image captures, the application would either exit, or crash. The trace above shows the memory allocation spiking up during every image capture – and never dropping back down after the 7th image capture. The activity spinner froze, and the device locked up requiring a reset. The freeze occurred inside the UIImagePickerController code, not in application code. We also noted a memory leak from core code that was detected between the 3rd and 4th image capture, which is shown in the trace above

Having identified a means of reliably reproducing the crash [2], and noting that it was occurring within Apple code, not our own, we tried holding open a UIImagePickerController for the lifetime of the application. We have not since experienced a crash. Airsource therefore recommends that developers using UIImagePickerController use a singleton instance over the life of the application [3] rather than creating on demand and then releasing.

[1] All tests run on an iPhone 2G 8GB running OS 2.1 (the bug has not been observed in 2.2)
[2] We validated the test by running it against a 3rd party application called Phanfare which is also dedicated to image capture. We were able to reliably cause Phanfare to crash, by taking a photo, selecting Use Photo, selecting Cancel, and then repeating.
[3] Airsource only ran the test in camera capture mode. According to a post at iPhoneDevSDK.com, the same crash can be experienced in PhotoLibrary mode, albeit with a higher threshold number of image captures.

7 thoughts on “Memory usage in UIImagePickerController

  1. I am no longer sure where you’re getting your information, however great topic. I must spend a while studying much more or figuring out more. Thank you for great information I used to be searching for this information for my mission.

  2. If anyone is interested, here’s the reject notice for my first submission:

    Thank you for submitting ###### to the App Store. Unfortunately it cannot be added to the App Store because it is modifying or extending an undocumented API, which as outlined in the iPhone SDK Agreement section 3.3.1 is prohibited:

    “3.3.1 Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs. ”

    There is no documentation for the custom subclasses or self-contained views of UIImagePickerController – this includes PLCameraView nor it’s custom subclasses (PLImageTile, PLRotationView, PLImageScroller, PLImageView, PLCropOverlay, PLCropLCDLayer, TPBottomDualButtonBar, TPPushButton and TPCameraPushButton) – in the iPhone SDK.

  3. I’m using the camera and after about 5 to 7 pictures, Springboard kills my application. No memory warnings issued. After the first picture my app goes from about 600KB of ram to 6MB of ram usage, but it remains constant after that. Only spiking up when the picture is take and saved to the camera roll.

    I’m keeping the same UIImagePickerController around and reusing it like suggested. I’m also compiling against 2.2 and 2.2.1, and still no luck. If I don’t keep the camera picker around, my app usually crashes after the first or second picture. I’ve even tried scaling the picture to half the size before saving it to conserve memory.

    My first version of the app was rejected by Apple because I used one undocumented API to get around the memory issue. Now that I’ve rewritten it using the “stock” camera control I can’t get around this memory bug.

    I’m willing to give someone access to the full code base of my application if they think they can help. Is it even worth finishing a camera application since 3.0 deprecates the method needed to get the image from the camera anyway?

  4. Pingback: MachWerx » Blog Archive » Memory Usage in UIImagePickerController

  5. Pingback: UIImagePickerController memory issues! - iPhone Dev SDK Forum

Leave a reply


<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>