I'm having a memory issue with one specific ViewController and memory. When I launch my app in debug mode, it launches with 40mb memory usage. (I have no idea if this is already a lot or not -- what is common?). Then, when I open this specific view, it spikes up to about 120mb. The issue is, when I pop this view (with the navigationController popViewController), the memory stays up at 120mb. And then, when I re-open it, it spikes to 200mb (a 80mb increase every time).
With other similar ViewController it spikes up to 120mb too, but when I close the view, it goes back down to more or less 40mb.
The problem is that this specific view contains quite a bit of code (about 1000 lines...) and it's impossible for me to post everything here.
What methods should I use to specifically locate the issue in xCode?
For anyone I might be able to help with this:
use the tools in xCode as recommended. There are some great tutorials online.
In my case it was an issue with an [NSTimer] which kept a strong reference to my view, so it never got released afterwards, thus stacking up memory. Make sure to stop your time when you pop a view.
Related
Long story here, so bear with me...
I have a view controller which, when presented more than three times throughout the life of an application session, will hang and lock and freeze my entire application. Even the Springboard locks up until my app's fully backgrounded! In Xcode's inspector, I noticed rather alarmingly that the memory footprint would jump a good 5-8 MB every time I presented that view, and it wouldn't go down again after dismissal. By the time the fourth invocation rolls around, the app's already using 40 MB of memory.
My first thought was, "OMG, itz a memry leek!" The second one told me to hop into Instruments and track it down.
While the Leaks tool did help some, it only told me that the app was leaking like crazy. All it would tell me was that, somewhere in these four second intervals, I had gained between "4 new leaks" and "17 new leaks." They did correspond to my opening that view, though, and once I started commenting random stuff (and following the sometimes helpful guidance of the Allocations tool), I tracked most of them down to three extra lines of code. "Oh well, I don't need those views anyway!" Those three lines no longer exist, and Instruments no longer complains.
My only complaint here is that my UI still behaves the same! On the fourth presentation, the entire app slows down. Upon further inspection of Xcode's instruments, I see that not only is the memory still going up (only to 30 rather than 40 MB this time), but the CPU activity has tanked!
Ok, granted I should have looked there in the first place, but I ain't perfect!
I ran the app again, and found that the overall CPU activity rose consistently the more I presented that view controller. By the third one, it was up to 40-60%. The main thread seemed pretty clear, and most of the activity was spread between eight other background threads (who knows what all those do).
The fourth time I opened that view, I had expected everything to block like crazy. It didn't. The CPU just... stopped. It was running at around 50-ish% when, by the time my finger had left the screen, it was down at 1%. All of the thread graphs shrunk from spiked stalagmites to tiny waves in a puddle. According to the pie chart, the vast majority of the processor was free to do as it liked. It doesn't like me.
I literally have no clue why it does this. I've been stuck in a room for days now trying to figure this out. Any help or advice would be much appreciated.
Does anyone have any idea why this happens, how this happens, or what I can do to make this not happen?? I'm drawing a blank here...
Thank you so much!
It should be noted that I got these by running the app on my iPhone 5s. Yes, I did try on the simulator, but my little MacBook Air took it like a champ, and was no help in figuring this out, except to tell me that the problem happened on iPhones.
I've run into this before, and the following is my general approach that usually allows me to fix these types of memory leaks.
First I would put a print statement into you viewController to see if your VC is being deallocated when it is being popped.
deinit {
print(self.description)
}
The next step, in the case that the ViewController is not being deallocated, I would start by removing core pieces, bottom up, commenting them out chunks one step at a time, yet leaving the back control that hides the view controller visible. Usually you can isolate the memory leak once you see the deInit get called after removing some code, you may have hit the part that made a strong cycle reference.
One more thing, ensure that all your delegates are declared weak, and search through your code for closures, and check that the closures aren't holding hard references within, especially to self.
Also, checkout this article to see the about using unowned or weak, when passing in instances into a closure, could be helpful.
http://krakendev.io/blog/weak-and-unowned-references-in-swift
I've developed an iOS application. There is a main screen which is displaying a google map and there are many markers, polygons etc in it.
At the beginning app was using around 120MB of memory.
- I touched settings button of my app and went to the settings page. there is no code. only segue connection in the storyboard (red line on the image)
- then I came back to the map screen (white line on the image)
You can see the memory allocation. every time when I open the map screen memory usage is increasing
What is the problem. What should I do?
The graph you have captured in Xcode is a decent overview of your memory consumption, but I'm afraid you are going to have to use more specific tools to diagnose this leak: Instruments comes shipped with Xcode and will help you track memory leaks; you will have to research (at least) the Leaks and Allocations instruments to figure out why your View Controller isn't being released.
While it is impossible to diagnose without seeing your code, that graph heavily suggests that your map view controller is not being released (hence the steady growth each time you create a new one)
To hazard a guess, I'd imagine you are creating a new mapView in viewDidAppear rather than viewDidLoad
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.
I have an iPad app (IOS 4.3 & 5.0) that is creating a UIView with at least 2 subviews every time the user pages forward or backward. The 2 subviews are UIWebView objects.
On every relevant swipe the old UIWebViews are removed and deallocated properly (removeFromSuperview then stopLoading and set delegate to nil) and the parent UIView is deallocated. I can confirm that both parent UIView and the 2 child UIWebViews are absolutely gone.
I can see the retain count on the webviews as they are being removed and I am quite sure that they are indeed removed every time.
However my memory allocation continues to increase on every swipe by ~200-350k . No leaks in instrument but I can see the memory usage going up slowly.
On iPad 1 the app eventually (within 6-10 minutes of moderate usage) receives multiple memory warnings and is terminated. LowMemory crash log...etc is generated.
We use stringByEvaluatingJavaScriptFromString and loadRequest to populate the Webviews. Memory usage creeps up even when nothing is injected or loaded into the webViews.
Is anybody experiencing this kind of behavior with UIWebViews ? Has anyone dealt with this successfully ?
Thoughs, comments & answers would be greatly appreciated.
Try to use Instruments but with the "Allocations" template and watch the "# Living" columns for UIWebView. I usually use it like this:
Profile app with Allocations template
"Warn up" the app by going thru all tabs, scroll around etc.
Press "Mark Heap", this will create a "Baseline" heapshot
Do the thing you think causes objects to stay around
Press "Mark Heap" again, this will create a "Heapshop #" heapshot
Inspect the objects in "Heapshop #" which will show size and number of objects created and alive since the last heapshot.
Goto 4
Not aware of any leak, but if you are destroying and re-creating the same view hierarchy every swipe, why not store the views and re-use them instead?
Regardless of whether they leak, webviews are computationally expensive to set up, so re-using them and just reloading the content should give you a performance boost, and may solve your leak as well.
are you still seeing this issue? I traced something which looks like unbounded memory usage (not necessarily a leak, but I get low memory warnings and eventual process termination) by calling stringByEvaluatingJavaScriptFromString over and over:
[webview stringByEvaluatingJavaScriptFromString:#"something()"];
It seems like there is something odd there.