Question

Heres the problem. I have an app that is essentially an image gallery, it pulls images down from an xml feed, and archives them locally, then gradually loads 5 images at a time into the scroll view to be displayed.

I have had thousands of problems with using [UIImage imageNamed:…] and NSURLRequest/NSData as both cause the app to cache excessive amounts of data. Anyway, I now have the app running at an almost constant 25-30MB, with no sudden spikes, and with only a few kB of data being leaked from memory (due to NSKeyedArchiver and me retaining some values). However the app ALWAYS gets terminated by the OS for (what seems like) no apparent reason.

Sorry if I’m being a bit stupid and not spotting something, the crash report does appear to be telling me that tonnes of memory has been paged by the app, however the allocations and leaks instrument is telling a different story… and really I supposed my question is more along the lines of “why is instruments lying to me?”

Incident Identifier: D258E503-D024-4265-B079-E6C47DE5DA29
CrashReporter Key:   c3904eb2c9cf4bf4f89f53fb9c836ad44586684f
OS Version:          iPhone OS 3.2.1 (7B405)
Date:                2010-09-21 13:27:50 +0100

Free pages:        464
Wired pages:       12587
Purgeable pages:   0
Largest process:   MediaLib

Processes
         Name                 UUID                    Count resident pages
        MediaLib <6db92ce87a5d7e287702f2cb87ba8c53>   30579 (jettisoned) (active)
     debugserver <f885fe2348e72988381a73137cc90c7b>     127
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e>      64
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e>      64
            afcd <ddda2413b8953e5c56721dfe05a82d78>      68
    syslog_relay <1c73f841b191556b6911bc6b4736b50f>      63
      DTMobileIS <b34df288cd9a07a995933bbd6b66717a>    1169
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e>      64
            ptpd <e3f855cfd629600a4812e7e90c77667e>     191
         syslogd <6990426209e51a8ee13c91cd1a050a2e>      78
    mediaserverd <2eda3ce5e1c8a1a4d7b8271cef1f2d12>     314
     debugserver <f885fe2348e72988381a73137cc90c7b>      74
     debugserver <f885fe2348e72988381a73137cc90c7b>      74
     debugserver <f885fe2348e72988381a73137cc90c7b>      74
             lsd <eb108595d2a932a8d244d1ab7386cd0f>     121
            apsd <0775f0d80d1cd1fb4b562d2f94caf051>     172
         notifyd <74e4a487a89c31f68917b22605baf6c6>      68
        BTServer <21dd98c0ab29b910cd51cb703a9cb9b9>     107
      CommCenter <e4b9cc04f083f22232c92ee1363fe669>     170
     SpringBoard <745085d9a24a8529f0ceb6c33d766873>    4821 (active)
      accessoryd <59ca0ba146c28bf5c8ab6e3d2e81bbad>      97
         configd <36001fe17103f8af6d3b525cb23ac8a0>     305
   fairplayd.K48 <2d997ffca1a568f9c5400ac32d8f0782>      85
       locationd <60fd4d90fec18a76ffc0b8a45351fe54>     600
   mDNSResponder <a6f01dd493e3d2bfe318f5d44f8508e2>     107
       lockdownd <378f09833cdc57b1b60e42d79c355938>     273
MobileStorageMou <7f2cd9f90fab302a42a63460b1c4d775>      67
         launchd <880e75c2db9c0f670516c58935e89b58>      80

**End**

Many thanks in advance for someone who can give me a slap and point me in the right direction 😉

EDIT:

I have just run the app through the activity monitor instrument and this is giving me a “Real Memory” readout of 65-80MB, could this be due to allocation of memory on another thread, which isn’t picked up by the allocations instrument?

Answer 1

You should know that NSImage#imageNamed: caches the image. In other words, you lose fine control over the life cycle of those images. Use NSImage#initWith... instead and the cache will not be used.

Also know that a .png image that is a 2KB download can easily be a 6MB image when loaded into an UIImage. Image data is decompressed when loaded into an UIImage so don’t look too much to the original size. Look at the size of the bitmap. Usually simply width * height * 4.

You mention that NSURLConnection and NSData are causing memory issues. This is probably because of improper usage. Like failing to do proper memory management.

Post code or more details if you want better hints about resource management.