I have been struggling with this issue for a while and i noticed that many people came across the same thing by reading many posts here and on other forums. Just this morning i realised what i was doing wrong and i thought of sharing it just in case someone stumbles over it in the future.
the problem in my implementation was that within viewDidLoad of view controller (VC1) i was setting its view property to a new view controller (VC2) which forces i believe the framework to exit viewDidLoad of VC1 without reaching its end, hence not calling the consequent delegate function of the view controller: viewWillAppear, viewWillDisappear, viewWillAppear, and viewWillDisappear!
So my solution was to delay all the code that has to do with creating and setting VC2 to be called from within viewDidAppear instead of viewDidLoad. If you do it from viewWillAppear you will get to the same trouble.
Hope it helps
AF
Why would you go to all this bother just to save the memory of a UIViewController?
sizeof(UIViewController) gives 132 bytes. Even knowing that a view controller will create a fair few support objects so it's going to take up more memory than that this is a fantastic example of premature optimization.
I'd give it a fair chance that the code solution you have gone for will :
(a) leak memory in edge cases
(b) fail on further updates to iOS
(c) be a nightmare to debug by any coder other than yourself
(d) be a nightmare to debug by yourself in more than a few weeks
Why not just write your app using the frameworks provided and profile it - if this tiny amount of memory is causing you problems the fine, implement your solution. If not, leave well alone.
Related
I have a simple UIViewController whose view is created via a Nib. Here's the structure of the Nib:
And a screenshot of the layout:
Whatever the previous view (there are 2 possibilities), there is significant stutter/lag when transitioning to this view. Even the keyboard animation is lagged. Also, this is only on an actual device.
I've tried removing the MKMapView to see if that was the case, but it didn't make a difference.
Is the Nib too complex? Should I load everything via code? I'm not sure what it could be, but its really annoying, especially when the rest of the app is super crisp.
As far as code goes, its nothing special: just alloc/init a view, push it onto a UINavigationController, etc. Nothing in the viewWillAppear:/viewWillDisappear:.
Coming from Reddit, where you posted code (probably want to do that here too):
My guess would be the lag is coming from the section from line 44 through 80ish, where you build the overlay. Something in there might be taking longer than you think (Spotpoint unSerialize sounds fishy). You typically want to do as little work as possible in viewDidLoad, since that is called as the UI is transitioning to the new view controller.
Try throwing that code into a GCD queue or running it in the background, and see if that helps the loading stutter.
I've got a fairly basic app that I'm updating - and as part of the update I'm implementing memory warning management.
When the memory warning method gets called, I release any view controllers not in use (and these in turn release any of their objects). Everything seems to work fine, there are no leaks etc as far as I can tell.
What isn't working:
Using the 'allocations' instrument, there is a lot of memory that isn't being released when a simulated hardware warning is called. Here's what I do when testing:
1 - start the app - this is the original jump in memory shown below.
2 - add a new view controller - this is the second spike.
3 - Return to the main view controller and simulate a hardware memory warning - this is the (small) drop in memory towards the end. This warning should completely release the additional view controller and associated objects.
Although everything is released, there is a lot of memory that remains. As far as I can tell, it's something like cached animations etc that iOS does. In a real low memory situation though, this should be released, and not stick around as this is where the majority of the memory goes.
How can this memory be released - or what am I doing wrong? Any pointers would be much appreciated - thanks!
-
EDIT: Thanks for all the answers so far! Although unfortunately I still haven't been able to solve the issue yet. Furthermore, the memory weirdness only seems to occur when using modal view controllers.
I've noticed that I actually have a background loading method for the extra view controller called when the app launches, to make things run smoothly. This indicates that the second spike in memory is completely due to something other that the view controller - maybe animations or something? Anyhow the problem still remains - what is this extra memory being used for, and how do I release it when I need to?
I could potentially create a mini project that exhibits the behavior if it would help. Thanks :)
Are you really sure you are not retaining your UIViewController or its objects? You shouldn't have to simulate a memory warning to see a decrease in allocations after releasing your controllers.
I attached a screenshot showing how my application looks after pushing and popping a UIViewController three times, using a UINavigationController.
EDIT
To answer your comments: UIViewController belongs to UIKit and is not thread safe, which means you should not be creating one in a background thread. This could potentially be the cause of the memory leak, since it will not be added to the main autorelease pool.
There's a really-really great screencast about memory analysis with Instruments from WWDC 2010. That's how I learned how to track similar issues.
You should check out http://developer.apple.com/videos/wwdc/2010/. To be specific http://developer.apple.com/videos/wwdc/2010/?id=311.
I'm writing a navigation app for iPhone at the moment and I'm having a very weird crash issue and was wondering if anyone had come across (and solved) this issue.
I have two views, both of which contain UITableViews and one that uses cells loaded from a nib. When I push and pop from one view to the other, after a couple of presses (usually 7 to 10) with everything loading and displaying as it should the app suddenly crashes. The debugger shows that CALayer was the last thing running, but I don't use any custom implementation of this class.
My first thought is that I've over-released an object, but after two days of playing with the code I can't identify any zombies.
Does anyone know what's going on here? Can post parts of code if required.
UPDATE:
Looks like zombies are being created on UIView delegate methods, namely viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear. Will investigate further tomorrow. :D
What you can do is to set breakpoints at the dealloc methods of the related classes, and see if the crash happens in one of the method. And also usually by looking at the callstack when the crash is happening, you can tell whether it's a memory related crash or not.
In a multi-view application, do you think its better to let views automatically get unloaded in memory tight situations, or to actually only ever have one View Controller allocated at a time, and when you switch views, the new one is created, the old one removed, the new one adde d and the old one released. Deallocating every time also means that there is a slight delay when switching to a new tab (very slight). So What do you think?
Also, I'm a bit confused about how and when and where and by who views are released (through viewDidUnload) automatically. If someone could clarify that for me, thanks.
In general, don't unload views unless you have to (didReceiveMemoryWarning) or it makes sense (something like a login form that's unlikely going to be used again).
You can't really assume that you have a fixed amount of memory. iPhone's have less memory than iPod touches. iPhone 3GS's have more memory than either. Jail-broken handsets often have substantially less memory.
By only releasing views when you have to you're making your app run faster on the 3GS and allowing it to run when there's less memory available.
The didReceiveMemoryWarning method releases the view if it is not visible. The following is from the documentation (v3.x):
The default implementation of this
method checks to see if the view
controller can safely release its
view. This is possible if the view
itself does not have a superview and
can be reloaded either from a nib file
or using a custom loadView method. If
the view can be released, this method
releases it and calls the
viewDidUnload method.
Obviously you also need to release any cached data. SDK2.x does not have the viewDidUnload method.
Depends, if you have a bunch of Views that the user switch back on forth from often then I would say to keep those in memory at that time, if theres views where the user wont come back to for awhile then you can probably unload that viewController and save memory. However if you have views that are taking up a ton of memory each then it might be wise to unload the viewcontroller when its not in use. Its really a matter of how often you are going back to the views and how much memory the view takes, also how many views you have. Taking these things into consideration you should be able to make a good decision of when to keep the viewControllers around and when the unload them. I believe that the view is a round as long as the ViewController is around (unless u release it explictly, which might have bad side effects (dont know)) , viewdidUnload just tells you that the view was unloaded of the screen, not too sure on that point tho.
I've implemented a View Controller, and I'm trying to do some very basic initialization in initWithNibFile...which I understand to be the designated initializer for View Controller objects.
I've tried to put breakpoints on the code, and have put very simple NSLog statements into it as well. Regardless...I'm not seeing it be executed (and the object i'm attempting to alloc/init inside the function is also not being allocated - so I'm about 99% sure I'm not hitting the code.
Is there something I need to do elsewhere to cause this method to be invoked?
I'm getting a clean build, no warnings or errors. And the app successfully loads up the View, and I can invoke a ButtonClick method I've coded and connected to this same View Controller.
Any suggestions would be appreciated.
TC
I ended up moving my allocation logic to viewDidLoad, and that works fine.
Not sure why the initWithNibFile was not working...but I'll take the small victory !!!
Thanks for offering to look at the code bpapa.
You probably need initWithCoder: It's what the SDK uses to read from nib files during startup.
initWithNibFile: is almost never called by the system. Usually you call this manually. The documentation is quite misleading on this point.
In any case, be careful doing too much initialization in the initWithXXXX methods. The view's targets and actions aren't likely to be set up and connected yet. viewDidLoad is almost always the right place to do viewController setup anyways.