I decided to take on this challenge.
This blog post outlines the bug squashing journey I’ve had, some of the techniques I’ve tried, and some pitfalls to look out for.
Investigating unrelated multiple crashesI started with checking the stack trace of these crashes, but unfortunately, these didn’t provide any clarity into why these crashes are happening.
In most of these crashes, the application crashed while trying to pull an object from an array or dictionary.
There was no seemingly good reason to believe these objects were nil, or that we’ve looked for any non-existing keys or out-of-bound indexes.
I knew that like most iOS applications, our app is multi-threaded, but our scenario didn’t have multiple threads modifying the same objects.
The second thing I did, is to look at the device’s hardware details where these crashes happened (Luckily, our crash reporting and analytics are highly detailed).
There I found the culprit: many of our crashes were related to low memory (RAM) on the device.
Just to make sure, I made sure the app leaked by checking Xcode’s memory usage graph.
Starting with the obviousSo, how do you even know that your app has a memory leak?Well, it’s quite simple:Launch the application.
Navigate through your app, invoking all classes, network requests & computations, database transactions, etc, more than once.
Open Debug Navigator (Command-7) In Xcode, tap on Memory and look at the Memory Use graph.
If you see your memory bar quickly escalating, much like the image below, you can be quite positive that your app is retaining memory space without releasing it.
Focusing on RxAs the title of this blog might’ve hinted, tracking RxSwift-specific memory leaks is a very interesting topic with its own strategies.
With that, how can we know that the RxSwift code leaks?Well, it’s simpler than you would think.
RxSwift provides its own internal mechanism that counts the current resource count for all subscriptions across your app.
You have to compile RxSwift with the TRACE_RESOURCES compiler flag to get this ability.
This information is exposed via the Resources.
total property.
You could create an interval timer and constantly print out the current resource count to see what’s going on:This code creates an observable which run on the main thread.
Every second, it prints how many resources are allocated by your subscriptions.
If your console prints something similar to this:Rx Resource Count: 5434Rx Resource Count: 5461Rx Resource Count: 6179Rx Resource Count: 6446Rx Resource Count: 6450Rx Resource Count: 6739Rx Resource Count: 6771Rx Resource Count: 7273Rx Resource Count: 7807Rx Resource Count: 8349Rx Resource Count: 9184Rx Resource Count: 10000Rx Resource Count: 10510.
Then congratulations!.Your Rx code leaks.
Main reasons for Rx-related Memory LeaksIf you’ve ever developed with Rx, you’ll know that reactive architectures comprise streams and subscribers.
The stream will only start producing elements once subscribed to.
In general, there are two common pitfalls causing RxSwift memory leaks:You forget to properly handle your subscription, by either adding it to a Dispose Bag (disposed(by:)), or by storing the Disposable for manual disposal.
This is a relatively rare scenario, as the compiler will warn you.
Dispose me!The owner of the subscription or it’s DisposeBag is still retained by another object.
This prevents the subscription or the bag from properly deinitializing and freeing the memory.
Disposing your Memory LeaksYour basic steps will be:The first rule of subscriptions is …The first rule of The Fight ClubNo, but seriously.
The first rule is that you should always add your subscriptions to a DisposeBag, even if you know your sequences will surely terminate.
Actually, as mentioned earlier, you can’t disobey this step without getting a compiler warning.
To be on the safe side, whenever you see operators such asdrive, subscribe, bind, bind(to:), emit, or any other operator which returns a Disposable — you should take care of its disposal.
Using disposed(by:) is the easiest and safest way to do this.
You can also “manually” control the lifecycle of your stream using operators such as take(1) or takeUntil(rx.
deallocated).
2.
Your Dispose Bag will clear its subscriptions only when the Dispose Bag’s owner is released.
Therefore, you should be sure your Dispose Bag is tied to the life cycle of your subscriptions.
As a thumb rule — Don’t create a dispose bag in one class, and share it with another class.
Nothing good will come from that.
A very common scenario where developers accidentally do this is when using UITableViewCells.
As opposed to UIViewControllers, which get released and empty their Dispose Bag, a cell doesn’t really get deallocated, but gets reused.
For that reason, you must be sure to clear your Dispose Bag (or simply create a new one) whenever your cell is about to be reused.
Instead, your cells should have their own Dispose Bags, and destroy them upon reuse.
3.
Finally, we get to the most common leak:While this might seem OK at first, this is a classic retain cycle, since the closure holds self and self holds the closure, letting none of them ever get released.
This isn’t specific to working with RxSwift, but it is still a very common pitfall when working with it.
Using a [weak self] (or unowned) capture group is the quickest way to deal with this:Now, consider the following code:Do you really need the [weak self] in that UIView.
animate closure there?.Well, in this specific case there is no need to weakly capture self, since even though the animation block retains self, self doesn’t actually retain the animation block — so there’s no cycle.
The last example is a special case since in pure MVVM it shouldn’t really happen.
Unfortunately, I worked with an SDK that required me to provide an entire prepared view.
In my view, I had code similar to this one:Take a guess, what is the problem here?When binding the stream of UISwipeGestureRecognizers to viewModel.
viewDidSwiped, the View Model now retains the Gesture Recognizer.
What you might miss, is that the gesture recognizer also holds the view itself, which means it would be the same as the View Model holding self directly.
MyView holds viewModel, and viewModel also holds MyView as well, since it’s held by the gesture recognizer.
One solution to this is just to get a weak reference to the gesture:An even better solution is to get only a portion of the gesture that doesn’t retain self:Get only a copy of the frame, not the entire gestureTo recapIf you suspect that a piece of code is leaking, simply use the handy resource count tracking method you learn about earlier:This will easily save you tons of hours trying to figure out if a memory leak actually exists, as well as confirming that it’s fixed.
Hope you’ve enjoyed this article, and may your apps be leak-free.
What’s the next leak you plan to fix with this?If you have any comments or notes, feel free to leave a comment below.
.