In this article we will look at several examples of memory leaks in the Android application. We will also look at fixes for these leaks. I want to show that memory leaks can and should be dealt with. I will not talk about tools for analyzing memory, just give references to the most important ones.

Incorrect AnimationListener

To draw attention to the new functionality, it was decided to use the animation. It was necessary to show for a short period View with a hint. An example can be seen in the image below:


Later discovered a leak Activity.


')
The problem was that the fadeOut animation used the listener from the fadeIn animation, which led to the endless fadeOut animation launch.



Fix it was easy enough.



Animations are often causes of leaks. This is very easy to achieve without forgetting to stop the endless animation or by running the animation for an unreasonably long time.

android.widget.Editor $ Blink

Sometimes memory leaks are found in the platform itself. Once I received this report:



To reproduce a leak, it is enough to create a Dialog with EditText inside and print something in it.


As it turned out, this is a known bug and it has already been fixed . There you can find a hack to fix this leak:

Leak from the manufacturer. Singleton - evil

In one of the reports I got a leak with a non-public, previously unknown to me class. It turned out that this is a private class from one popular manufacturer.



This time I was lucky again and I found a ready-made solution on the network ( 1 , 2 ).

results

As a result, the number of OutOfMemoryError decreased by almost 7 times. The number of RuntimeException, InflateException has also decreased: some of them are OutOfMemoryError caught and wrapped. One of the limiting factors in correcting such errors is that I cannot make updates that do not contain external changes (for users it looks like “Empty update”) In such cases, you have to wait for the implementation of the new functionality to check the results.

findings

• Document non-trivial / obvious code points that fix memory leaks. Often they look suspicious.
• The one who does nothing is not mistaken. Sometimes you have to fix memory leaks in someone else's code.
• You need to know your toolkit (hprof-conv, VisualVM, OQL, leakcanary)
• Be sure to take measurements and watch them (crash-report tools).
• Do not increase the number of errors.

Links

• VisualVM visualvm.java.net
• OQL visualvm.java.net/oqlhelp.html
• leakcanary github.com/square/leakcanary
• Source code of examples github.com/kurganec/leak_examples