CODEWITHSUNDEEP
iosiphoneswiftmemory-leakscpu
AverageHelper
AverageHelper

Reputation: 2221

iOS CPU Activity Suddenly Dies

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).

Hey look, it's running hot!

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.

Where did it all go??

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.

Upvotes: 0

Views: 88

Answers (1)

AntonTheDev
AntonTheDev

Reputation: 919

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

Upvotes: 1

Related Questions