Memory Leaks FAQ-Beginner

As a joke ape, I decided to write about my recent learning experience.

1. Introduction

Memory leaks are one of the key factors that lead to oom throughout the Android development process. The idea is that the GC cannot reclaim objects that were supposed to be recycled, and this object caused a memory leak. What harm does it have? The memory size of the phone is limited, and if it can't be released, you won't be able to create new objects, your new interface and so on will not work properly, then the program will be Oom (OutOfMemory).

2.OOM and memory leaks

Oom Popular point is that you have 2 toilets in your home, originally you and your wife with the words, are enough, one day you accidentally made people, from home with 1+1=3 personal. One day early in the morning, you get up and find your tummy uncomfortable, "I want to go to the bathroom!" (Request the system to allocate free memory to the current app). Hey, honey, you're in there, so I'm going to the next one. (The system begins to analyze the memory you need and spare memory, ready to allocate). Ah, son you also squat ah (finished, 2 toilets are occupied, insufficient memory, boom! boom! You must be a rush at this time, the crap can't help, it must be abnormal Ben collapse. The Oom,app program exited unexpectedly).

So what about memory leaks? For example, you bought a bunch of erasable artboards (artboard = phone, artboard space limited = memory Limited), you just started to draw a painting, slowly used a lot of artboards. At this point you still continue to draw, found that there is no new drawing board, had to find just used, but you found that the wrong brush, resulting in the wipe off! (Abnormal use of the context causes memory leaks and the GC does not reclaim memory.) And so searched all the artboards, did not find a blank place (not allocated to the new free memory to the app), had to end the painting (memory leaks caused insufficient memory, the app Oom).

3. Configuration

This is a primary article, not too much to describe the theory of things, Daniel's articles have been written, I will no longer describe. So how do we solve the problem of memory leaks? For the small white we certainly want to have an easy-to-use, quick-positioning memory leak plug-in, then I recommend leakcanary fool-type detection tool for everyone.

OK, the first step must be how to quote this in the project? First, the way that Android Studio projects reference third-party libraries is what you need to know. The following 2 references are in the Build.gradle (1 position in the figure below, 2 not in the OH). What, why are there 2 of them? In fact, there are 3, the reason is very simple, you will not formally release the package also add memory leaks it? Of course, it can be officially released, the relevant references are all killed.

{    debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3‘    releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3‘}

The quote is over, let's start doing some initialization operations. Write down the following 2 sentences in your application implementation class.

/**     * 内存泄露检测     */    private RefWatcher refWatcher;    publicstaticgetRefWatcher(Context context) {        TTApplication application = (TTApplication) context.getApplicationContext();        return application.refWatcher;    }  @Override    publicvoidonCreate() {        super.onCreate();        refWatcher = LeakCanary.install(this);//内存泄露检测}

and add this to the base class of your fragment.

  @Override    publicvoidonDestroy() {        RefWatcher refWatcher = TTApplication.getRefWatcher(getActivity());        refWatcher.watch(this);//内存泄露检测    }

All right, all of our configurations are complete. Let's take a break and see a nice leg.

Oh, sorry to put it wrong.

4. Common memory leaks

The following is the mantra "Oh Manimani coax", "Run My App", "come out, the evil memory leaks." See

If there is a memory leak, there will be a notification message (1 position) of the shield above, and you can enter the details screen (2 position) when clicked. In the picture above the

, we can find some clues, such as the callback that caused the memory leak. I recalled the code, because this project is MVP mode, p-tier holds activity context and iview interface. Common leaks are basically the result of context holding, so in response, I use the P-layer to hold weak references. Weak references, objects with only weak references have a shorter life cycle. As the garbage collector thread scans the area of memory it governs, once an object with only a weak reference is found, its memory is reclaimed, regardless of whether the current memory space is sufficient or not. Also, the callback interface you just had to set NULL. This allows the following destroy method to be called in the OnDestroy method when the activity is destroyed. It is important that the network request cancel when the interface is destroyed, such as the volly framework cancellation based on the request tag, so as to avoid the interface callback caused by memory leaks. In addition, animations are suspended or destroyed when the interface is left or destroyed.

private WeakReference<ShoppingCartActivity> mBaseActivity;  private IShoppingCartView mIShoppingCartView;    publicShoppingCartPresenter(ShoppingCartActivity context, IShoppingCartView            iShoppingCartView) {        new WeakReference<>(context);        mIShoppingCartView = iShoppingCartView;    }     @Override    publicvoiddestroy() {        null;    }

There is also a common is the use of handler. Usually we're done with the new one, and Android studio displays a large yellow warning area. At this point, you need to solve the problem by using static inner classes and weak references. You can use the Mactivity.get () instead of the context where you normally need it.

staticclass CommentHandler extends Handler {        WeakReference<HomeActivity> mActivity;        CommentHandler(HomeActivity activity) {            new WeakReference<>(activity);        }        publicvoid handleMessage(Message msg) {            super.handleMessage(msg);        }    }

In the app it is inevitable that webview loads the Web page, and then this is also a scary start. WebView interface Memory leak resolution, do not set the XML WebView, but rather in the way code creates a view object initialization, and the interface is destroyed when the call destroy methods.

    WebView  mWebView  =new WebView (this);  @Override    protectedvoidonDestroy() {        ifnull) {            mWebView.getSettings().setBuiltInZoomControls(true);            mWebView.setVisibility(View.GONE);// 把destroy()延后            mWebView.removeAllViews();            mWebView.destroy();        }        super.onDestroy();    }

In addition, toast is best used applicationcontext, if the activity of the context, toast has not finished the time to exit the current interface, this is the memory will also leak.
As for the context and bitmap between the drip, I used the fresco picture loading frame, still good. And there is a lot of information on this, and I am not prepared to describe it for the time being.

Well, the simple use of leakcanary is here. Next time to depth analysis of the memory leak of the point drip.

Memory Leaks FAQ-Beginner