https://github.com/ReactiveCocoa/ReactiveObjC/blob/master/Documentation/MemoryManagement.md
Memory Management
1：you don't need to retain signals in order to process them.
Subscribers
1:Before going any further, it's worth noting that subscribeNext:error:completed: (and all variants thereof) create an implicit subscriber using the given blocks.
2:Any objects referenced from those blocks will therefore be retained as part of the subscription
3: Just like any other object, self won't be retained without a direct or indirect reference to it.
Finite or Short-Lived Signals
1: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
2:However, the RACSignal -> RACSubscriber relationship is torn down as soon as signal finishes, breaking the retain cycle.
3: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
1: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.
2:Disposing of a subscription will remove the associated subscriber, and just generally clean up any resources associated with that subscription.
3: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
1: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:
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?
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.
