UIViews associated with memory leaks

My GUI for an iPhone app uses numerous UIViews. The user "flips" through these views when they tap a button to go forward or backward. The views are stored offscreen and are added to an actual view only when the program needs to display it.

During the flip process, the program tells the parent view (a uiscrollview) to remove any existing subview using the removeFromSuperView method, and then adds the new subview, which is the new page that the user should see.

However, after several repeats of this process on the device, the program crashes with gdb exit status 101, which I found is caused by an out of memory error.

I tried diagnosing this problem using the Leaks tool, but to no avail. There is only 1 or 2 small memory leaks and the total mem usage on the device by the program is only 2.5 mb. Is it possible that video memory, not system memory, is running low?

I came across this post regarding backgroundColor and mem usage, but I need further explanation. Should I reduce setting the backgroundColor to prevent the UIView's CALayer from hogging too much memory?

Yes, I use an NSArray to store these views off-screen. In total, they don't take up that much memory, but the memory problem occurs after I periodically add and remove UIViews from the main ScrollView. Another thing to note is that if I page back and forth between 2-3 of the same view instances, nothing happens, and everything works fine. However, if I flip ahead through 10 or more views, the program crashes. It feels like I almost have a grip on this problem.

obsoleteModel81 2009-08-14 06:10:26

It's hard to say without knowing exactly what you're doing. So, two things:1. Add some code showing what you're doing in your question, so we can better help you.2. My guess is that you're adding views on demand to this area, and as you page through more "unique" views (i.e. ones you haven't seen before), you use more and more memory. Try the following: in the same place you call removeFromSuperview, also call `[yourArray removeObject:view];`. If that solves your issue, then we know what the problem is and can come up with a clean/suitable solution.

Itay 2009-08-14 06:17:49

It seems like removing the view from the cache after displaying it prevented the memory problem from occurring. First, it's important to note that all views were initialized prior to any rendering. However, although there is no longer a memory issue since views are deallocated after it's removed from the scrollview, the program no longer has the ability to page back. (It can only page ahead)Is real-time initialization of view components the best option here, or is there an alternative solution?

obsoleteModel81 2009-08-14 06:33:12

Without code, it's nearly impossible to say. Generally, you shouldn't be keeping views around if you are not displaying them. Instead, save enough state such that you resurrect them, and then just create a new view. So if somebody tries to page back from view X, you need to load view X-1. Finally, to avoid load times/flickering, if the user wants to see view X, you should preload view X-1 and X+1. This way, you're always one view ahead.If you post some example code of what you're doing, I'll be able to give some more concrete advice.

Itay 2009-08-14 06:37:57

This suggestion solved my problem. I just store the models in an array instead of the actual views. Initially I thought that the overhead of rendering views immediately was too high, but it's actually not.

obsoleteModel81 2009-08-15 04:29:57

Kiyoshi definitely has the right idea, and the right link. The techniques I'm talking about are alluded to in the PageControl sample, but they're not complete - you still have to remove unused subviews.

Itay 2009-08-14 07:05:03

ansaurus

tags:

views:

answers:

UIViews associated with memory leaks

related questions