CODEWITHSUNDEEP
iosobjective-c
user1992686
user1992686

Reputation:

Logic help on Memory Management for numerous images?

I'm after some help on logic at the minute(not any code). The aim of the app is to have 2/3/4 different images shown depending on a level number - all within the same view (so the images disappear and new images are placed on screen). Having all these images locally is going to be hugely detrimental to memory. What I'm wondering is the best way to keep memory down. I have been reading the Apple documentation on 'Property Lists' and 'Archiving' although I only understood about a sixth of what I read. I'm aware of GCD, queues and threads, I don't know how to implement them or if they would even be the best way - I literally just know of them.

I would like to have all the images stored, load up the ones I need to the screen depending on the level number variable and then unload them from the screen when the level number variable increases by one. It might be faster to preload the next levels images and unload the current images on screen out of memory once the next levels images are loaded to the screen up.

If that makes any sense at all, I really hope it does.

Thank you in advance for your time and any help :).

Upvotes: 0

Views: 103

Answers (1)

Rob
Rob

Reputation: 438232

A couple of thoughts:

  1. The best way to "keep memory down" is to make sure you don't keep strong references to UIImage objects that are not immediately required. This is sometimes called lazy loading (only creating UIImage objects "just-in-time"). So even though you might have many images that your app might eventually use, only populate UIImageView objects (and their associated image property) for those images you immediately need for your current user interface. And, similarly, make sure you release the strong references to images you no longer need.

  2. The connection between image memory management and property lists and archiving is thin. If you're trying to ask how do you store your images, they're either delivered with your app as part of the app's bundle or you're retrieving them from the network. In the latter case, you might cache those downloaded images in the local file system of the app (the Documents or Library folders), and you might keep track of them in your app's model, which you'd save to persistent storage using property lists (plists) or Core Data (or other forms of persistent storage). It's generally not recommended to try to store the cached images, themselves, in these types of persistent storage. For performance reasons, unless the images are tiny, it's much better to just save the file in your local file system, and keep references to those filename in your persistent storage.

  3. The connection between image memory management and GCD/queues/threads is also thin. Yes, you use a concurrency technology, such as NSOperationQueue or Grand Central Dispatch's dispatch queue, for asynchronous background operations, such as if you want to download images in the background so that it doesn't adversely affect the user interface. That's more of a UX issue than a memory management issue. As an aside, you might also want to investigate using an established third-party framework to simplify this process, such as the excellent general purpose AFNetworking or the image-centric SDWebImage. These will simplify the process of doing asynchronous retrieval of images.

Upvotes: 2

Related Questions