Precautions for preventing memory leak during Android Projects

In general, Java VM will have gargage collect. However, if the object has reference in other objects, the VM will not cleanup.

A common example is an activity.

Because in a) jump from one activity to another activity or B) in screen rotation, the android system creates a new activity, and the original activity is released, gargage collect .. However, if other classes use this activity, this activity will not be gargage collect, which causes memory leak problems.

Example

public class MyActivity extends Activity {public void onCreate(Bundle icicle) {super.onCreate(icicle);Utility.registerCallback(this);}}public class Utility {private static Classback m_callback = new Callback();public static void registerCallback(Context c) {m_callback.registerCallback(c);}}public class Callback {private context m_context;public void registerCallback(Context c) {m_context = c;}public void unregisterCallback(Context c) {if (c == m_context) {m_context = null;}}}

In the above example, m_context in class callback grabbed myactivity. Therefore, after this activity is completed, garage collect cannot release myactivity.

A solution is to release the reference outside before the activity leaves.

Example

public class MyActivity extends Activity {public void onCreate(Bundle icicle) {super.onCreate(icicle);Utility.registerCallback(this);}public void onDestroy() {super.onDestroy();Utility.unregisterCallback(this);}}public class Utility {private static Classback m_callback = new Callback();public static void registerCallback(Context c) {m_callback.registerCallback(c);}public static void unregisterCallback(Context c) {m_callback.unregisterCallback(c);}}public class Callback {private context m_context;public void registerCallback(Context c) {m_context = c;}public void unregisterCallback(Context c) {if (c == m_context) {m_context = null;}}}

Other related matters

1) digitalclock widget in the SDK. Because digitalclock needs to register an observer, the activity carrying the digitalclock widget will be used as the observer. However, there is a bug in the SDK digitalclock, because there is no unregister observer in the ondetachedfromwindow of digitalclock. The solution is to write a digitalclock by yourself. For details, see the attached code (digitalclocknew. Java ).

2) In the SDK, the toast function maketext requires that a context be passed, but in the toast code, this context will be used as the callback. If activity is passed as the context, memory leak may occur. The solution is to pass application context instead of activitycontext.

How to view memory leak problems

If you suspect that there is a memory leak problem, you can first execute the APK on emulator, then execute ADB shell on the PC, then execute ps, view your process
PID.

After executing suspicious Memory Leak actions on the APK, you can perform the following diagnosis:

1. Run dumpsys meminfo <pid>

This command displays the memory information of the PID. Note that there is a memory leak if the number of activities is constantly increasing. Note that the activity will not be released before gargage collect is executed. You can run manual gargage collect on ddms.

2. Dump the memory of the process to see where the memory leak is located.

Run chmod 777/data/MISC and kill
-10 <pid>, the memory leak of the PID is displayed on/data/MISC, such as the heap-dump-tm1265266619-pid1673.hprof)

Copy this file back to your computer using ADB pull (such as ADB pull/data/MISC/heap-dump-tm1265266619-pid1673.hprof 1673. hprof.

Then, run hprof-Conv (such as hprof-Conv 1673. hprof 1673_a.hprof) on the PC to convert the copied hprof to eclipse Memory tool.
Supported formats.

Using eclipse Memory tool (http://www.eclipse.org/mat ),
Open the converted memory dump. On the eclipse Memory tool, press oql and enter "select * From instanceof Android. App. Activity"
This command can be used to find the instance of Android. App. Activity on the system. (For details, see)

If "unknown" is attached to an object, the object can be gargage collect. If you want to see why other objects cannot be gargage collect, right-click the object and select path to GC roots and exclude weak/soft reference. (Both weak and soft reference can be found by Vm, so they can be gargage collect .)

In Path to GC roots, we can see that widgetmanagerhome is held by the inner class tn in toast.