The beginning of the nonsense:RxSwiftCalled at the end of the task sequence execution codedispose()ordisposeBy()Method, actually there’s a question here, soRxSwiftWhat exactly is being destroyed? Because there are many associated objects that are created during the creation of the task sequence to keep the program running, ultimately the objects that the outermost closure needs to sink, their destruction permission is transferred to the outside world, and when to destroy them is up to the needs of the program.

First, the application scenario of Dispose and DisposeBag

IOS encapsulates a simple UITableView chain listening click events function ideas and implementation

Let’s look at the logic to implement:

The Dispose method call directly destroys the internally created objects in the chain

DisposeBag manages chained internally created object destruction nodes

The previous article did not add processing to the life cycle of internally created objects. In order to ensure that all objects inside the program were modified with static, Dispose and DisposeBag were created to manage the internally created objects in chain.

Dispose

KDSDisposeBag.h

Again, this is wrapped in a method return block.

KDSDisposeBag.m

Take a look at the changes in kDSDelegateProxy.m

The tableViewDelegateProxy circled earlier is a static modifier global variable, so now it’s a temporary variable.

Create a WSLDispose on the rxRegistSelected method of UITableview + kds. m to store the UITableview proxy object provided by KDSDelegateProxy

Run the code to persist the intermediate procedure variable without dispose method on the KDSDisposeBag object

If you click on the cell, it is not possible to print indexPath in the click event, as shown below:

Why was it all destroyed without calling dispose? In fact, the reason is very simple, there is no other class in the whole process except the block holding the Dispose object, so after the completion of the block will be directly destroyed, the key to solve the problem is to associate the tableView with the Dispose object.

The implementation is as follows:

Dispose is associated in UITableview +KDS. M

Modify the rxRegistSelected method

The associated object will be disassociated before the current object (UITableView) is released, so there is no need to worry about releasing. Of course, you can also set the association property of the associated object to OBJC_ASSOCIATION_ASSIGN without increasing the reference count.

Okay, let’s run the code again

The life cycle of dispose object follows tableView, so it is not destroyed, so the console can print.

Call the Dispose method to try it out.

The proxy class is destroyed, and of course the click event block cannot be executed

Because the life cycle of dispose object follows tableView, after controller is destroyed -> tableView is destroyed -> Dispose object is destroyed

As shown in figure:

Three, KDSDisposeBag package

The purpose of KDSDisposeBag is also simple, that is, to transfer the release of intermediate objects held by KDSDispose object to KDSDisposeBag object.

KDSDisposeBag.h

KDSDisposeBag.m

Let’s run the code

Normal print

Normal destruction

Fourth, summary and thinking

There’s no real meaning in KDSDisposeBag here, because the reference count is +1 when the tableView is added to the superview, so the life cycle is the same as the current controller, so if you change it to some other type of object, even if it’s a temporary variable, So the point of DisposeBag is to hold all the temporary variables created during the execution of this code until the end of the controller’s life.

Furthermore, RxSwift or RAC, whose purpose is to sink verbose code and expose it to sequential concatenation commands, is quite complex to implement internally, so there is no need to be confused as to why a lot of code is written in a single sentence

Article is only for personal thinking, poor code, god do not laugh