Not enough memory? Talk about the most common memory leaks in Android development and how to solve them

[[140732]]

Have you ever felt that the available memory of your Android phone keeps decreasing after you turn it on? A big part of the reason is because of memory leakage. This leaked memory cannot be recycled, so the available memory is getting less and less;

What is a memory leak? GC cannot recycle the object that should have been recycled, and this object causes a memory leak.

1. Forget to recycle Bitmap after use, because the implementation of Bitmap calls the Native method through JNI, and the GC mechanism cannot normally recycle the memory space requested by Bitmap (this was the case before API10, and then it was allocated in the Heap, but in order to be compatible with the old version... calling recycled explicitly can also allow GC to recycle faster);

How should Bitmap be recycled?

 // bitmap!=null should be placed in front. If the bitmap is empty, an error will be reported when calling the isRecycled method.   
 
 if (bitmap!= null &&!bitmap.isRecycled){ 
 
 bitmap.recycled(); //Recycle bitmap   
 
 bitmap = null ; // Make the bitmap object a virtual reference so that GC can recycle it faster   
 
 }

Next, let's talk about two more common memory leaks. You can expand on these two.

 btn_hint.setOnClickListener( new View.OnClickListener() { 
 
 @Override   
 
 public   void onClick(View v) { 
 
        Toast.makeText(MainActivity. this , "Hello" , Toast.LENGTH_SHORT).show(); 
 
 } 
 
 });

Is this very common? You may also write it like this (encapsulating it has the same meaning, as long as you reference the current activity). You may want to ask, is there any problem here?

The problem is that if the user presses the back key before the Toast disappears, this Activity will cause a memory leak.

Reason? Toast holds the current Activity, which prevents the Activity from being destroyed by GC.

Solution: Let Toast hold ApplicationContext; in fact, as long as it is not Layout, Context can use ApplicationContext;

By the way, here's a little tip: In non-Activity, you cannot directly get Context using getContext. You need to rely on Context to get resources. In this case, you can consider maintaining a global Context in your own Application for classes that cannot directly get Context, saving the need to pass parameters around (ApplicationContext is not recommended for views)

 private   static Context mContext; 
 
 public   static MyApplication getInstance() { //For external calls...   
 
 return mApplication; 
 
 } 
 
 @Override   
 
 public   void onCreate() { 
 
 super .onCreate(); 
 
    mContext = getApplicationContext(); 
 
 }

Another common... memory leak

 new Thread() { 
 
 public   void run() { 
 
 //Network request   
 
 }; 
 
 }.start();

Is there a problem here? Are you kidding me?

Create a new thread in the Activity to make a network request. If the thread is not finished and the user presses the back key, the memory leak will also occur.

Reason: The Thread is an anonymous inner class, so it will implicitly hold the outer class (here is Activity)

Solutions: Various; do not use anonymous inner classes, or maintain a thread pool or a thread queue for the entire application. The latter two methods make the thread independent of the Activity to avoid memory leaks.

Context is needed in many places such as resource acquisition, and anonymous inner classes are used in many places, which leads to a great memory leak risk here, but many friends may not have noticed it. I hope this article can give you some inspiration.