Memory usage accounting in a navigation controller-based app;

Question

I have a navigation controller-based application that could be active for a relatively long time and can load multiple screens, revisiting some in the course of its life - a business application. When I push a screen I allocate some memory; when I go back (pop it) I need to ensure memory is not lost.

Now in Leaks I have a clean slate. No memory leaked, not so hard to do with the 10.6 static analysis feature and confirmed using instruments. Checking manually, I am sure I am releasing everything allocated in viewWillAppear in viewWillDisappear; everything allocated in viewDidLoad in viewDidUnload; everything allocated otherwise in dealloc.

I have used NSZombiesEnabled in development but I definitely do not have it active now.

When running under Object Allocation however I see memory usage growing. On entering a new view I see memory increasing but not decreasing by the same amount when navigating back. Nor is this simply the system failing to deallocate immediately, when left for some time memory remains static. This behavior is seen on every view.

What techniques can I use to isolate this memory? Should I be aiming for the application returning to some baseline after every view? How can I isolate reporting of memory used by subsystems such as Core Data, where I rely on faulting to load objects and should not be trying to manipulate them explicitly, and the code over which I have full control?

Answer 1

Hi

It is natural that the navigation controllers memory footprint grows as you push views to it. If you are using Core Data anyways you could persist the state of the entire application to Core Data each time you push or pop a view. This way nothing will be lost. The navigationController manages the memory for the viewControllers, so if you exceeds the iPhones memory it will then start deallocating the viewControllers. Core Data manages memory pretty aggressive so it is a good way to go.

By this approach I think you will utilize the memory management of the framework instead of trying to roll your own and potentially introducing long terms memory bugs:)

I would go for something like an Entity per viewController, and an Entity that saves the context in which the were loaded. This way you could just test to see if the framework has deallocated any of your viewController and then restore the navigationController stack if it did.

Hope this was at least something to consider:)