I am writing my whole app from code and i am not using storyboard.But My app is using much memory. I have some view controller,TableViewController, collectionView and some webview in my apps.
And I am pushing all viewController and instantiating navigationViewController from RootviewController to it's childviewController.
And I am think that the ARC is not working is enable in my project.And When the memory reaches maximum my app is kill by iPhone.
wow, that's a lot of memory!
I don't have much experience with webviews, but I might be able to help with the other components.
As a suggestion: Make use of the debugger to go through your code step by step and keep an eye on the memory inside XCode.
You might be able to find out which part of your code generates so much memory usage that way.
If you can't find the problem: It is very hard to tell where this effect comes from. It might be a little easier if your post your code (preferably commented) so we can dig deeper into what might be causing this problem.
Cheers,
Ferdinand
check if there are any memory retain cycles, when refrencing self inside closure always use weak reference.
Related
I am going in and out of UIViewControllers.
Every time I am going in memory increases, but when I am getting out (pressing Back) memory is not decreasing.
I have weak #IBOutlets, vars and lets.
How can I fix it?
p.s. One of the #IBOutlet is container pointing to another UIViewController
Ignore the comments suggesting retain/release breakpoints and peppering your code with log calls; that's an unwieldy tactic that misses entire classes of problems. Abizern's suggestion to use Instruments is a lot more spot-on. Run the Leaks instrument to look for leaked instances. Browse the other memory instruments as well. Instruments is a &#&$&-ing magical debugging tool and so many developers ignore it for reasons I can't fathom. Spend a few minutes with a tutorial and you'll save months of debugging time over your career.
It sounds like you are creating a new UIViewController every time you switch between views. Try to create the segue to be an unwind segue, this will remove the current view from the stack. Otherwise it appears that you are just continually adding to the stack of views. Tell me if this works.
I have a question about Storyboard, Segues and memory management. If I read about it on forums people say this is working properly but I was wondering the following, I made a small video to illustrate:
https://www.youtube.com/watch?v=ixs1Fiv5M9s
I grabbed a source from github explaining segues and unwinding them
I tested this in debugging and indeed I see all functions including dealloc is working
I run instruments and check how many times 2de view controller is created (every time #Persistent is increasing)
I check for changes in memory between the 2 states, and a lot is still in memory? But View controller is gone?
I am looking for the wrong data in instruments? I guess looking for memory leaks using modal and dismissing a view controller is not the right way to do this?
Can somebody explain me how to look for memory leaks? I need this for a much bigger app that is using a lot of segues, and sometimes this app crashes because of memory warnings...
I was working with a project in Xcode 4.2, which is not using any storyboards but normal xib's.
ARC was working super fine and was happy with that, No problems.
Now the Odd problem araised when I upgraded from Xcode 4.2 to Xcode 5 (Still not using storyboards).
I pop a screen using 'popViewControllerAnimated' function, and obviously, the Screen is popped.
But when I analyzed on the memory allocation, I found that the screen memory is not released even after the screen is popped.
Moreover, when I open that screen again, memory is allocated and not released even when I close it.
Seems more like a retain cycle, but I'm damn sure that I've never used 'retain'.
Now I've upgraded to Xcode 5.1.1 and this Odd issue, still persists.
To convert my project to 'Storyboard' design is a complete burden for me thats why I'm preserving ordinary xib's.
I'm now tired of Google'ing and searching all the forums including Stackoverflow.com.
Guys, Please help me figure out the issue.
Its a life Saver for me.
ARC is not magic. ARC keeps track of strong references to objects. When the number of strong (owning) references to an object drops to zero, the object gets deallocated.
If one of your view controllers is not being released, it means there is a strong reference to it somewhere. One possibility is a "retain cycle", where 2 objects each have strong references to each other. This happens when you do things like have an object that owns another helper object, and the helper object has a (strong) pointer back to the owning object. The usual solution is to make owners keep strong references to their objects, and owned-to-owning pointers weak (like delegates).
There is no way for SO readers to find your problem for you.
Have you tried running the analyze tool on your code? It may point to the problem for you. You should also run the program through the Leaks instrument as Phillip suggested. Both of those tools are very helpful, although neither is 100% foolproof.
Failing that, you might need to find a senior-level iOS developer with whom you can sit down and do a code review. Often, in the process of explaining the logic and implementation of your program to somebody else, you find the problem yourself.
Check if you are setting in one view controller as the delegate of the popped view controller. Because when that popped view controller is dismissed, you must set the delegate to nil. Is common to forget this.
In developing my current app, I ran into some issues that I eventually traced back to a low memory warning. Part of the low memory is coming from my (liberal) use of UIWebViews, which are apparently consuming a lot of memory.
I didn't think this would be an issue, since a view that isn't currently visible should just vanish when the low memory warning is thrown, unfortunately it turns out that anything connected to the UITabBarController remains in the heirarchy and doesn't release. By manually releasing (and then recreating in viewWillAppear) the views, I make things work decently. But it doesn't completely solve the memory warning issue.
So what I need to do is manually release the view -- and the large amount of memory that winds up connected to it -- and then restore it. Since I don't want to build it programmatically (that's what IB is for!), I need to somehow reload it from storyboard.
Or, alternatively, I'm being an idiot and there's something really obvious to make my life easy.
After more experimentation, it turns out that on the one hand, my understanding of view life cycles was slightly flawed, and on the other my experiments were tainted by having accidentally let zombie objects on.
Views will, in fact, unload their contents in a low memory condition and reload them later -- that's part of what 'viewDidLoad' and 'viewDidUnload' are designed for! Putting init code in them, as some tutorials I read did, was a major error. That init code should go in the designated initializer -- even if that can be annoying to figure out which initializer is designated.
I'm making an app that has a few view controllers with UIDatePicker controls.
After having lots of memory warnings, I've done a lot of debugging on the cause. Using instruments, I was able to see that whenever a view controller containing a UIDatePicker appeared, memory usage was going up by 2-3mb. Ultimately, this leads to a memory warning. While I can do so much in here, and have seen a dramatic decrease in crashes since re-writing these functions, I'm still not comfortable with this behaviour and want to fix it.
The UIDatePicker's are part of the XIB file. I've tried taking them out of the XIB and programmatically adding them. This doesn't solve the problem. I've also tried using a (thread-safe" singleton. This limits memory usage to only one instance (so memory usage doesn't increase), but I'm trying to avoid singletons wherever possible. Should I just suck it up and use a singleton?
I'm seeing this behaviour on iOS 5 and 4.3, across all devices that run it. I'm using ARC, as the title suggests.
Instruments does not show any memory leaks.
Here is a screenshot from Instruments. Each step up in usage is when a VC containing a date picker appears. The baseline at the start of the graph is 2.3mb of memory usage.
http://i.stack.imgur.com/1S7ns.png
Cheers!
The tool you want to use here is called heapshot. It will help you narrow down the types of objects that are being incorrectly held onto. As #sudo notes, the problem is probably in your delegate rather than the date picker itself. You're probably not "leaking" in the strictest sense of the term. You're probably just holding onto memory that you didn't mean to (which looks a lot like a leak).
You should take a careful look at whether you have any circular strong references. Do you have objects that have a strong reference to their delegate for instance? That will typically lead to a retain loop (which will never be released under ARC). Heapshot can help you find these objects.
I seem to have solved my own question. As this was an inputView, and I also had a UIToolbar with a "Done" button as the inputAccessoryView.
So now I create these programatically in viewWillAppear. In viewWillDisappear, I set the UITextField's inputView and inputAccessoryView to nil, and the date picker and date picker toolbar to nil.
They are no longer in the XIB file.This seems to work really well - memory spikes up by 3mb, then goes back down the second the views disappear. Now the app is running consistently at under 10mb of live memory - it spikes up to 15mb on occasion but very rarely.
Thanks for the help sudo rm -rf and Rob - heapshot analysis helped to try and get to the bottom of it.