"Android" discovers program memory leak point through leakcanary

Background

Memory leaks are a headache for beginners, because it is not like crashing, and in the development environment you can troubleshoot the problem with the error messages that are prompted.

You don't even know if our app has a black hole that eats up memory in a nook and cranny.

Troubleshoot Android memory leaks compare the bottom-end approach: Use the official Memory Analysis tool (MAT), a better two introductory article: (i) and (ii)

But the process is more patient,

We novice can also choose another app plug-in leakcanary, integration of this plugin, we use the app, when we encounter memory leak point, it will pop up the notification, and tell the leak point (release does not bounce box).

Actual combat

Let's use our own blog Park app client to test the memory leak problem.

1: Integrated Leakcanary1.1:build.gradle Inside:

Dependencies {   ' com.squareup.leakcanary:leakcanary-android:1.3.1 '    com.squareup.leakcanary:leakcanary-android-no-op:1.3.1 ' }

1.2:application added to the OnCreate method of the parent class:

@Override      Public void onCreate () {        super. OnCreate ();        Leakcanary.install (this);}

2: Test Memory leak

Leakcanary will automatically create a report app on your phone and click on it to see some information about memory leaks (if any)

In the use of our client, it prompted the discovery of a memory leak, the class name, the reference chain is given out, so the user-friendly prompt information, can very quickly locate the problem

Observing the message, we found that the reason for this problem is because the anonymous class implicitly references activity, which causes the activity to be recycled. Where the problem occurs:

Mwebview.setonscrolllistener (new  Scrollwebview.onscrolllistener () {            @Override              publicvoid onscroll (intint  y) {                - mpreviousypos);                 = y;            }        });

There are a lot of solutions, and when it comes to recycling, just make sure that the activity is not being strongly referenced by other objects.

Our solution is to use weak references so that callers don't care about the memory leaks that a strong reference might cause.

 PackageZhexian.learn.cnblogs.ui;ImportAndroid.content.Context;ImportAndroid.util.AttributeSet;ImportAndroid.webkit.WebView;Importjava.lang.ref.WeakReference;/*** WebView that can be scrolled*/ Public classScrollwebviewextendsWebView {PrivateWeakreference<onscrolllistener>Monscrolllistener;  PublicScrollwebview (Finalcontext Context) {        Super(context); }     PublicScrollwebview (FinalContext Context,FinalAttributeSet attrs) {        Super(context, attrs); }     PublicScrollwebview (FinalContext Context,FinalAttributeSet Attrs,Final intDefstyle) {        Super(context, attrs, Defstyle); } @Overrideprotected voidOnscrollchanged (Final intLFinal intTFinal intOLDL,Final intOldt) {        Super. onscrollchanged (L, T, OLDL, Oldt); Onscrolllistener Listener=Monscrolllistener.get (); if(Listener! =NULL) Listener.onscroll (L, T); }     Public voidSetonscrolllistener (FinalOnscrolllistener Onscrolllistener) {Monscrolllistener=NewWeakreference<>(Onscrolllistener); }     Public InterfaceOnscrolllistener {voidOnscroll (intXinty); }}

"Android" discovers program memory leak point through leakcanary