So I have just completed coding an application in xCode 5.1.1 running on a iOS 7 device (App is ARC Enabled). Everything is complete and no crashes are occurring but I want to make sure the application is problem free before submitting it for review.
I have put log statements in each of my view controllers DEALLOC methods to make sure they are being called..not one of them is being called, ever! Not sure if this is how it is supposed to be in an ARC-Enabled application? Also, it worries me because when I run the application and switch to the "Debug Navigator" tab the memory usage of the app continues to increase, as if view controllers are not being released after they are dismissed or a push/modal segue happens. Any help or thoughts would be greatly appreciated on the matter.
Thanks.
Looks like you are having strong references to view controllers that you are not aware of. Use the static analyser to warn you about any reference cycles. In general, look at warnings and fix them. You may have things stuck in an NSArray unexpectedly. Check all variables holding these view controllers, are there any stored in objects, that you might have to change to nil?
Related
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.
I`ve searched a lot about this problem but I didn´t find anything, hoping someone does it, here is my question:
Ive tested the app in the simulator a lot of times. I have ARC and all the outlets released in the viewDidUnload (Ive quite a lot of images). When I run it on the simulator, the memory continues rising again and again, when changing between views.
For example, I have a button in a view. And right clicking it, I drag it to another view, connecting them. Do I need to release anything relating in this way the views? If so, where I put the code? (I have a .h and .m for each view).I have read a lot of questions like this, but all off them referred to views related by code, not using the drag option
(Style - modal)
Please I would thank a lot any clue or help, as I have to solve this problem in a short period of time,
Thanks in advance :)
viewDidUnload is not called anymore starting with iOS6. That might explain what is happening.
Called when the controller’s view is released from memory. (Deprecated in iOS 6.0. Views are no longer purged under low-memory conditions and so this method is never called.)
Furthermore, viewDidUnload was usually called when the view was unloaded due to memory pressure, so you were anyway expected to call it from your dealloc method.
Try doing your niling in dealloc or viewDidDisappear.
You should also be aware, if you use UIImage's imageNamed to load your images, that this method will cache the images. So even when you remove them from your views they remain in the system's cache.
Without seeing your code it is not possible to say more than 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 just started learning the instruments tool, and I'm pretty sure what I am seeing is not good. When I look at allocations, specifically the column "Live Bytes" and "Overall Bytes", I see the number continually increases as the app runs...
My app has two view controllers. A table view, and the second view controller displays detailed information about the row they selected in the table view, downloaded from the internet.
I kept clicking a row in the table view, followed by clicking the back button in the navigation bar... and LiveBytes continued to increase.
I'm guessing this means that my objects aren't being released from memory... but please correct me if I'm wrong.
MY QUESTION IS: How do I use the data in instruments/allocations to track down this memory issue? How do I find the objects not being released from memory?
I'm looking for tips on how to use these tools to clean up any memory problems my app has.
Thanks!
XCODE 4.2.1, deploying to iOS 5.0+
EDIT: I'm looking at the #living column and seeing objects like UIScrollView continuously increase... and never decrease. When I click the back button in a navigation bar, are objects automatically released from memory? When are objects released, or do I need to do it manually? Or could I be running into an issue due to using strong pointers, causing objects to not be released?
Whenever you want to observe memory usage in a cyclic pattern, there's the wonderful Heapshot analysis in the "Allocations" instrument.
Start your app and go to a default state.
In Instruments, press the "Mark Heap" button to create the "Baseline".
Do something in your app like pushing a view controller.
Return to the default state.
Press the "Mark Heap" button again to create a heapshot.
Repeat about five times from step 3.
This will result in a list of heapshots, each showing the objects that are still alive from that cycle. If your app has no leaks there will be no objects left in the middle heapshots.
The first one or two cycles might have warmed up some caches, the last two might not have cleaned up some reused resources. That's why it's usually a good idea to make four to six heapshots.
The magic in the heapshot analysis lies in the fact that the heapshots show you the leaked objects from previous cycles and remove them automatically when the objects are released later. In contrary to the "Leaks" instrument it also finds abandoned memory, not only leaks.
Most Probably you have discarded the arm64 and are running your app with armv7 only. Add both arm64 and armv7 as architectures
I think one of the best ways to solve memory issues is to use ARC.
Edit -> Refactor -> Upgrade to Objective-C ARC.
ARC will handle the majority of memory management in your app. Especially sice your app doesn't sound too complex, it might totally eliminate your problem. You still need to watch out for retain cycles and listen to memory warnings though. If you don't want to use ARC (which you should) at least run the static analyzer. Your problem might be something simple that the static analyzer can show you how to fix.
Edit:
You mentioned scroll views- this might be your problem: Memory leak every time UIScrollView is released
The profile tool has an instrument called 'Leaks'. It is similar to the 'Allocations' instrument but it shows you the object that was not released. May be you can use the 'Leaks' tool to find what is the object that was retained and release these object.