Detailed explanation of onsharedpreferencechangelistener and solutions for non triggering

Before using onsharedpreferencechangelistener, I encountered a small problem, that is, sometimes onsharedpreferencechangelistener was not triggered. Recently, I spent some time studying and tidying up. This article will introduce the reason why the listener is not triggered, the solution, and some technical details implied therein.

Problem reproduction

Onsharedpreference changelistener is a listener for changes in sharedpreference files in Android. Usually, if we want to monitor, we will implement the following code.

There seems to be no problem with this writing, and many times the onsharedpreferencechanged method can also be called several times. However, after a period of time (a simple demo is not easy to appear, but using GC in DDMS will immediately lead to the following problems), you will find that the previous method is suddenly no longer called, which will affect the processing of the program.

Cause analysis

In short, your registered listener has been removed. First, let's look at the implementation of registeronsharedpreferencechangelistener registration.

As can be seen from the above code, an onsharedpreferencechangelistener object is actually placed in a container of the weakhashmap. After executing the oncreate method in the example, the listener object will soon become the target of garbage collection. Because being placed in the weakhashmap as a key will not prevent garbage collection, when the listener object is recycled, This listener is also removed from mlisteners. Therefore, onsharedpreferencechanged will not be called.

About weakhashmap, read the Translation: understand weak references in Java and learn more.

How to solve

Change to object member variable (recommended)

Take the listener as a member variable of the activity, register it in onresume of the activity, and log off when onpause. It is recommended to process in these two activity life cycles, especially when the sharedpreference value changes, the UI displayed by the activity is processed. This method is the most recommended solution.

Change to static variable (not recommended)

As follows, a variable slistener pointing to an anonymous internal class object is decorated with static, and the internal class object will not hold a reference to the external class. However, this method is not recommended, because a static variable is not related to the external instance, so it is difficult for us to perform some operations with the external instance.

Why is it designed like this

Some people may think that this is a system design trick or bug. In fact, it is not. This is the brilliance of Android designers.

Just like the code in our example, adding a (implicit) local variable to the listener container will lead to memory leakage if the container is just an ordinary HashMap, because the container also has an object pointed to by the local variable, and the object implicitly holds the object of the external activity, so the activity cannot be destroyed. For non static internal class holding and implicit external class reference holding, please refer to the private modifier of Java: "invalidation"

In addition, because local variables cannot be accessed outside their methods, we can only use local variables in methods to register, but we can't use local variables to log out at the right time.

The above is the introduction to Android onsharedpreferencechangelistener and the solutions to problems. Thank you for your support!