Some “pitfalls” encountered in using rxjava“

preface

The more you use rxjava, the easier it is to use, so you unknowingly find rxjava everywhere in the code. However, rxjava is not a silver bullet, and there are still many problems to be solved. Here, I briefly summarize some "pits" I have encountered, which may be loose in content.

1、 Consider switching the main thread

A common way to use rxjava is to do processing in other threads, and then switch to the UI thread to update the page. Among them, thread switching uses observeon(). This method can be used to download files in the background and display the download progress in the foreground. However, practice has found that there are pits. If the file is relatively large and the granularity of the download package is relatively small, it will lead to a backlog of notifications and eventually lead to errors.

In fact, this error is understandable. After all, mainlooper works according to message. Too many messages will inevitably lead to some problems. Of course, this is still a more taken for granted idea. In the end, we still need to explore the source code. The principle of observaon has been analyzed in the previous article on rxjava. Here is a brief list of the code. The key point is the inner class of operatorobserveon - observeonsubscriber. Important code fragments are as follows:

The key point lies in the queue member, which stores the messages that need to be sent to the downlink thread. For the main thread, compliance is actually heavy. From the mode of message producers and consumers, too many and too fast messages will lead to message blocking. Even, the blocking situation cannot be reached, because there will be an upper limit on the size of the queue. Offer () in the onnext () method may generate exceptions, depending on the implementation of the queue. But in any case, it can not be infinite, so there is no guarantee that there will be no exceptions.

The method to solve this problem is also very simple, which can reduce the generation frequency of messages in the producer. You can also use judgment to switch threads when necessary without thread switching during message processing, such as using runonuithread().

2、 Rxjava avoids memory leaks

Rxjava's responsive mechanism is essentially implemented by callback, so memory leakage will also occur. If the subscription is not managed, the memory leak will be very serious. For subscription, there are several widely used methods, such as rxlifecycle and simple compositesubscription. As for their use methods, they are actually very simple and will not be repeated here.

When it comes to memory leakage, let's talk about something else. Animation may also lead to memory leakage. The reason is still some callback functions. These callback functions implement the function of view change, but after being revoked, the callback function is not cancelled. At the same time, the view may hold context information, resulting in memory leakage. Recently, it was found that loadtoastview, an open source library, has been leaking memory. The reason is as mentioned above.

summary

The above is the whole content of this article. I hope the content of this article can bring some help to your study or work. If you have any questions, you can leave a message. Thank you for your support for programming tips.