Android: Memory Optimization details.

Due to the special nature of Android systems, the installed software is installed in the memory by default, so as users install more and more software, the memory available for running programs is getting smaller and smaller, this requires that we use as little memory as possible when developing Android programs. Based on my personal development experience, I have summarized the following methods to optimize the memory:

1. If an object obtained by creation or other methods is no longer used, it is automatically set to null.
2. Try to zoom in or out or flip images in the program. The memory occupied by image operations may be larger than the image itself.
3. Try to put some static objects (especially set objects) in the SQLite database. Use SQL statements to search and match the data.
4. Some connection resources should be released if they are not used, such as input and output streams of Database Connection Files. Avoid releasing in special circumstances (such as exceptions or other circumstances)
5. Some long-period Objects Reference short-period objects, but these short-period objects may only be used within a small range. Therefore, this risk should also be cleared during memory check.
6. An object is referenced by multiple objects, but only one object is released. This object may not be released.

 

 

 

I. Android memory mechanism

Android programs are written in Java, so the memory management of Android is similar to that of Java. The programmer allocates memory for the object through new, and all objects are allocated space in the Java heap. However, the release of the object is done by the garbage collector. In C/C ++, the memory mechanism is "Who is polluted and who is responsible for governance". Java is more user-friendly and a dedicated garbage collector (GC) is invited for us ).

How can GC check whether an object has been deprecated? Java adopts the principle of Directed Graphs. Java considers the reference relationship as directed edges of a graph, and directed the directed edge from the quotor to the referenced object. A thread object can be used as the starting vertex of a directed graph. This graph is a tree starting from the starting vertex. All objects that can be reached by the root vertex are valid objects and GC will not recycle these objects. If an object (connected subgraph) is inaccessible to this root vertex (note that this graph is a directed graph), we think this (these) object is no longer referenced and can be recycled by GC.

Ii. Android memory overflow

How does Android memory overflow occur?

The android virtual machine is a register-based Dalvik. Its maximum heap size is generally 16 m, and some machines are 24 m. Therefore, the memory space we can use is limited. If our memory usage exceeds a certain level, an outofmemory error occurs.

Why is memory insufficient? I think there are two main reasons:

• Due to program errors, some resources (such as context) can be referenced for a long time, resulting in Memory leakage and unreleased resources.
• Saves multiple objects (such as Bitmap) that consume too much memory, resulting in memory exceeding the limit.

3. Static

Static is a keyword in Java. When it is used to modify a member variable, the variable belongs to the class, rather than the instance of the class. Therefore, the life cycle of a variable modified with static is very long. If you use it to reference some instances that consume too much resources (the case of context is the most), you should be cautious.

 
 

  
  
Public class classname {
  
  
Private Static Context mcontext;
  
  
// Omitted
  
  
}
 
 

The above code is very dangerous, if the activity is assigned to mcontext. Even if the activity has been ondestroy, the activity will not be released because there are still objects that store its reference.

Let's take an example in the android document.

 
 

  
  
private static Drawable sBackground;  
  
  
     
  
  
 @Override  
  
  
 protected void onCreate(Bundle state) {  
  
  
   super.onCreate(state);  
  
  
     
  
  
   TextView label = new TextView(this);  
  
  
   label.setText("Leaks are bad");  
  
  
     
  
  
   if (sBackground == null) {  
  
  
     sBackground = getDrawable(R.drawable.large_bitmap);  
  
  
   }  
  
  
   label.setBackgroundDrawable(sBackground);  
  
  
     
  
  
   setContentView(label);  
  
  
 }  
 
 

Sbackground is a static variable, but we found that we did not explicitly Save the reference of contex. However, when drawable is connected to view, drawable sets the view as a callback. Because the view contains the reference of context, we still save the reference of context. The reference chain is as follows:

Drawable-> textview-> Context

Therefore, the context is not released, and memory leakage occurs.

How can we effectively avoid such a reference?

First, we should try our best to avoid using static member variables to reference instances that consume too much resources, such as context.

Second, use the application context whenever possible. Because the application context has a long life cycle, it will not cause memory leakage if referenced.

Third, use weakreference instead of strong reference. For example, you can use weakreference <context> mcontextref;

For details about this part, refer to the article in the android document.

4. Thread-caused fault

Threads are also an important source of Memory leakage. The main cause of thread Memory leakage is the uncontrollable thread lifecycle. Let's consider the following code.

 
 

  
  
public class MyActivity extends Activity {  
  
  
    @Override  
  
  
    public void onCreate(Bundle savedInstanceState) {  
  
  
        super.onCreate(savedInstanceState);  
  
  
        setContentView(R.layout.main);  
  
  
        new MyThread().start();  
  
  
    }  
  
  
  
  
  
    private class MyThread extends Thread{  
  
  
        @Override  
  
  
        public void run() {  
  
  
            super.run();  
  
  
            //do somthing  
  
  
        }  
  
  
    }  
  
  
}  
 
 

This code is usually very simple and is often used. Let's think about a problem: assume that the run function of mythread is a very time-consuming operation. When we enable this thread, we change the horizontal screen of the device to a vertical screen, generally, when the screen is switched, the activity will be re-created. According to our ideas, the old activity should be destroyed. However, this is not the case.

Because our thread is an internal class of activity, a reference of activity is saved in mythread. When the run function of mythread is not completed, mythread will not be destroyed, therefore, the old activity referenced by it will not be destroyed, so Memory leakage occurs.

 

Some people like to use asynctask provided by Android, but in fact asynctask is more serious. This memory leakage problem occurs only when the run function does not end, however, the internal implementation mechanism of asynctask is to use threadpoolexcutor. the life cycle of the thread object generated by this class is uncertain and cannot be controlled by the application. Therefore, if asynctask is used as the internal class of the activity, it is more prone to memory leakage.

How should we solve the memory leakage caused by such threads?

First, change the internal class of the thread to the static internal class.

Second, use weak references within the thread to save context references.

The solution model is as follows:

 
 

  
  
public abstract class WeakAsyncTask<Params, Progress, Result, WeakTarget> extends  
  
  
        AsyncTask<Params, Progress, Result> {  
  
  
    protected WeakReference<WeakTarget> mTarget;  
  
  
  
  
  
    public WeakAsyncTask(WeakTarget target) {  
  
  
        mTarget = new WeakReference<WeakTarget>(target);  
  
  
    }  
  
  
  
  
  
    /** {@inheritDoc} */  
  
  
    @Override  
  
  
    protected final void onPreExecute() {  
  
  
        final WeakTarget target = mTarget.get();  
  
  
        if (target != null) {  
  
  
            this.onPreExecute(target);  
  
  
        }  
  
  
    }  
  
  
  
  
  
    /** {@inheritDoc} */  
  
  
    @Override  
  
  
    protected final Result doInBackground(Params... params) {  
  
  
        final WeakTarget target = mTarget.get();  
  
  
        if (target != null) {  
  
  
            return this.doInBackground(target, params);  
  
  
        } else {  
  
  
            return null;  
  
  
        }  
  
  
    }  
  
  
  
  
  
    /** {@inheritDoc} */  
  
  
    @Override  
  
  
    protected final void onPostExecute(Result result) {  
  
  
        final WeakTarget target = mTarget.get();  
  
  
        if (target != null) {  
  
  
            this.onPostExecute(target, result);  
  
  
        }  
  
  
    }  
  
  
  
  
  
    protected void onPreExecute(WeakTarget target) {  
  
  
        // No default action  
  
  
    }  
  
  
  
  
  
    protected abstract Result doInBackground(WeakTarget target, Params... params);  
  
  
  
  
  
    protected void onPostExecute(WeakTarget target, Result result) {  
  
  
        // No default action  
  
  
    }  
  
  
}  
 
 

In fact, the thread problem is not only the memory leakage, but also some catastrophic problems. This article does not discuss memory issues.

 

Because 51cto won't let me finish it once, I say that I have too many words, so I passed it separately.

5. Super fat bitmap

It can be said that the vast majority of people who encounter the outofmemory problem are due to the bitmap problem. Because bitmap occupies too much memory, it is a "super fat man", especially a high-resolution image. If you want to display multiple images, the problem is even more significant.

How can we solve the memory problems brought by bitmap?

1. Timely destruction.

Although the system can confirm that the memory allocated by bitmap will eventually be destroyed, it may exceed the Java heap limit because it occupies too much memory. Therefore, when using bitmap, You need to delete the recycle in time. Recycle is not sure that bitmap will be released immediately, but it will imply to the Virtual Machine: "The image can be released ".

Second, set a certain sampling rate.

Sometimes, the area we want to display is very small and it is not necessary to load the entire image. Instead, we only need to record a reduced image. At this time, we can set a certain sampling rate, therefore, the occupied memory can be greatly reduced. The following code:

 
 

  
  
Private imageview preview;
  
  
Bitmapfactory. Options = new bitmapfactory. Options ();
  
  
Options. insamplesize = 2; // The image width and height are 1/2 of the original image, that is, the image is 1/4 of the original image.
  
  
Bitmap bitmap = bitmapfactory. decodestream (Cr. openinputstream (URI), null, options );
  
  
Preview. setimagebitmap (Bitmap );
 
 

Third, use softrefrence)

Sometimes, we do not retain references to bitmap, so we cannot call the recycle function. By using soft references, bitmap can be effectively released when the memory is insufficient. For example:

 
 

  
  
/** This example is written by the blogger to describe the usage without verification */
  
  
Private class myadapter extends baseadapter {
  
  

  
  
Private arraylist <softreference <bitmap> mbitmaprefs = new arraylist <softreference <bitmap> ();
  
  
Private arraylist <value> mvalues;
  
  
Private context mcontext;
  
  
Private layoutinflater minflater;
  
  

  
  
Myadapter (context, arraylist <value> values ){
  
  
Mcontext = context;
  
  
Mvalues = values;
  
  
Minflater = (layoutinflater) Context. getsystemservice (context. layout_inflater_service );
  
  
}
  
  
Public int getcount (){
  
  
Return mvalues. Size ();
  
  
}
  
  

  
  
Public object getitem (int I ){
  
  
Return mvalues. Get (I );
  
  
}
  
  

  
  
Public long getitemid (int I ){
  
  
Return I;
  
  
}
  
  

  
  
Public View getview (int I, view, viewgroup ){
  
  
View newview = NULL;
  
  
If (view! = NULL ){
  
  
Newview = view;
  
  
} Else {
  
  
Newview = (View) minflater. Inflate (R. layout. image_view, false );
  
  
}
  
  

  
  
Bitmap bitmap = bitmapfactory. decodefile (mvalues. Get (I). filename );
  
  
Mbitmaprefs. Add (New softreference <bitmap> (Bitmap); // Add arraylist here
  
  
(Imageview) newview). setimagebitmap (Bitmap );
  
  

  
  
Return newview;
  
  
}
  
  
}
 
 

6. Unusual cursor

Cursor Is a class used to manage data sets after data is queried by Android. Normally, if the queried data volume is small, there will be no memory problems, moreover, the virtual machine can ensure that the cusor will be released eventually.

However, if the data size of the cursor table is large, especially if blob information exists, the memory occupied by the cursor should be promptly released, rather than waiting for GC to process. In addition, Android obviously prefers programmers to manually close the cursor, because in the source code, we find that if the garbage collector is used for collection, an error will be prompted to the user.

Therefore, the method of using cursor is generally as follows:

 
 

  
  
Cursor cursor = null;  
  
  
try {  
  
  
    cursor = mContext.getContentResolver().query(uri,null, null,null,null);  
  
  
    if(cursor != null) {  
  
  
        cursor.moveToFirst();  
  
  
        //do something  
  
  
    }  
  
  
} catch (Exception e) {  
  
  
    e.printStackTrace();    
  
  
} finally {  
  
  
    if (cursor != null) {  
  
  
       cursor.close();  
  
  
    }  
  
  
}  
 
 

In one case, we cannot directly close cursor, which is applied in cursoradapter. But note that cursoradapter does not automatically close cursor at the end of acivity, therefore, you need to manually disable it in the ondestroy function.

 
 

  
  
@Override  
  
  
protected void onDestroy() {        
  
  
    if (mAdapter != null && mAdapter.getCurosr() != null) {  
  
  
        mAdapter.getCursor().close();  
  
  
    }  
  
  
    super.onDestroy();   
  
  
}  
 
 

The changecursor function in the cursoradapter will release the original cursor and replace it with the new cursor, so you don't have to worry that the original cursor is not closed.

You may think of using activity managedquery to generate cursor, so that the life cycle of cursor will be consistent with that of acitivity. What a perfect solution! However, managedquery also has many limitations.

The cursor generated by managedquery must not be replaced, because many programs may not have certain query conditions. Therefore, we often use the new query cursor to replace the original cursor. Therefore, this method has a small scope of application.

7. other things to be said.

In fact, there are still many methods and requirements to reduce memory usage. For example, do not use the entire image. Try to use a 9path image. The adapter needs convertview, and so on. Many details can save memory. These all need to be mined. Who is called Android memory.

Due to the special nature of Android systems, the installed software is installed in the memory by default, so as users install more and more software, the memory available for running programs is getting smaller and smaller, this requires that we use as little memory as possible when developing Android programs. Based on my personal development experience, I have summarized the following methods to optimize the memory:

1. If an object obtained by creation or other methods is no longer used, it is automatically set to null.
2. Try to zoom in or out or flip images in the program. The memory occupied by image operations may be larger than the image itself.
3. Try to put some static objects (especially set objects) in the SQLite database. Use SQL statements to search and match the data.
4. Some connection resources should be released if they are not used, such as input and output streams of Database Connection Files. Avoid releasing in special circumstances (such as exceptions or other circumstances)
5. Some long-period Objects Reference short-period objects, but these short-period objects may only be used within a small range. Therefore, this risk should also be cleared during memory check.
6. An object is referenced by multiple objects, but only one object is released. This object may not be released.