Skip to content

Latest commit

 

History

History
139 lines (102 loc) · 5.15 KB

MemoryManagement.md

File metadata and controls

139 lines (102 loc) · 5.15 KB
Raw

Memory Management

ReactiveCocoa's memory management is quite complex, but the end result is that you don't need to retain signals in order to process them.

If the framework required you to retain every signal, it'd be much more unwieldy to use, especially for one-shot signals that are used like futures (e.g., network requests). You'd have to save any long-lived signal into a property, and then also make sure to clear it out when you're done with it. Not fun.

Subscribers

Before going any further, it's worth noting that subscribeNext:error:completed: (and all variants thereof) create an implicit subscriber using the given blocks. Any objects referenced from those blocks will therefore be retained as part of the subscription. Just like any other object, self won't be retained without a direct or indirect reference to it.

Finite or Short-Lived Signals

The most important guideline to RAC memory management is that a subscription is automatically terminated upon completion or error, and the subscriber removed.

For example, if you have some code like this in your view controller:

self.disposable = [signal subscribeCompleted:^{
    doSomethingPossiblyInvolving(self);
}];

… the memory management will look something like the following:

view controller -> RACDisposable -> RACSignal -> RACSubscriber -> view controller

However, the RACSignal -> RACSubscriber relationship is torn down as soon as signal finishes, breaking the retain cycle.

This is often all you need, because the lifetime of the RACSignal in memory will naturally match the logical lifetime of the event stream.

Infinite Signals

Infinite signals (or signals that live so long that they might as well be infinite), however, will never tear down naturally. This is where disposables shine.

Disposing of a subscription will remove the associated subscriber, and just generally clean up any resources associated with that subscription. To that one subscriber, it's just as if the signal had completed or errored, except no final event is sent on the signal. All other subscribers will remain intact.

However, as a general rule of thumb, if you have to manually manage a subscription's lifecycle, there's probably a better way to do what you want.

Signals Derived from self

There's still a bit of a tricky middle case here, though. Any time a signal's lifetime is tied to the calling scope, you'll have a much harder cycle to break.

This commonly occurs when using RACObserve() on a key path that's relative to self, and then applying a block that needs to capture self.

The easiest answer here is just to capture self weakly:

__weak id weakSelf = self;
[RACObserve(self, username) subscribeNext:^(NSString *username) {
    id strongSelf = weakSelf;
    [strongSelf validateUsername];
}];

Or, after importing the included EXTScope.h header:

@weakify(self);
[RACObserve(self, username) subscribeNext:^(NSString *username) {
    @strongify(self);
    [self validateUsername];
}];

(Replace __weak or @weakify with __unsafe_unretained or @unsafeify, respectively, if the object doesn't support weak references.)

However, there's probably a better pattern you could use instead. For example, the above sample could perhaps be written like:

[self rac_liftSelector:@selector(validateUsername:) withSignals:RACObserve(self, username), nil];

or:

RACSignal *validated = [RACObserve(self, username) map:^(NSString *username) {
    // Put validation logic here.
    return @YES;
}];

As with infinite signals, there are generally ways you can avoid referencing self (or any object) from blocks in a signal chain.

The above information is really all you should need in order to use ReactiveCocoa effectively. However, there's one more point to address, just for the technically curious or for anyone interested in contributing to RAC.

The design goal of "no retaining necessary" begs the question: how do we know when a signal should be deallocated? What if it was just created, escaped an autorelease pool, and hasn't been retained yet?

The real answer is we don't, BUT we can usually assume that the caller will retain the signal within the current run loop iteration if they want to keep it.

Consequently:

  1. A created signal is automatically added to a global set of active signals.
  2. The signal will wait for a single pass of the main run loop, and then remove itself from the active set if it has no subscribers. Unless the signal was retained somehow, it would deallocate at this point.
  3. If something did subscribe in that run loop iteration, the signal stays in the set.
  4. Later, when all the subscribers are gone, step 2 is triggered again.

This could backfire if the run loop is spun recursively (like in a modal event loop on OS X), but it makes the life of the framework consumer much easier for most or all other cases.