Memory usage in UIImagePickerController
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.
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.
November 12th, 2008 at 2:57 pm
[...] in UIImagePickerController I just wrote a blog post analysing the issue in a bit more depth at The Airsource – Memory usage in UIImagePickerController Airsource – Mobile Software Experts The Airsource – A blog on mobile [...]
January 23rd, 2009 at 1:00 pm
[...] run out of memory (after picking like, seven photos). Fortunately, a little digging around led to the solution. Essentially, it involves keeping one instance around and continually re-using [...]
April 15th, 2009 at 8:15 pm
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?
April 15th, 2009 at 8:30 pm
Oops! Here’s my email: sophtware@gmail.com
April 15th, 2009 at 8:34 pm
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.
October 21st, 2011 at 8:31 pm
windows 7 anytime upgrade starter to professional…
[...]The Air Source » Blog Archive » Memory usage in UIImagePickerController[...]…