An Android app memory cleanup and monitoring tool for developers

Memorymonitor

An Android app for developers to use memory cleanup, monitoring tools, you can get the current phone memory usage ratio, the available memory size, check whether an app has a memory leak.

and sorted out some ways to optimize memory.

0.GitHub Address

• Https://github.com/cundong/MemoryMonitor

1. Memory cleanup

It can be used to test your own development activity, fragment robustness, simulate activity, fragment the recovered scene, test your program to preserve and restore the current scene.

For example: open one of your development activity, Fragment, cut into the background, clean up the memory once, after cutting it back to the foreground, see if there is a null pointer exception, and whether the state of the program is restored.

2. Memory Monitoring

The memory in the Android system, like the Linux system, has a lot of shared memory. Each app accounts for a private and public two-part memory, and we can get to both parts of the app's PSS value.

PSS (Proportional Set Size): The physical memory that is actually used, that is, the memory that the application occupies, and the memory that is allocated to the application in proportion to the shared memory.

The total PSS value for the monitored app is obtained once every 1 seconds by changing the program.

Use a feature (which may cause oom to try), see if PSS is soaring, or use it for a long time without lowering it.

If it soars after use and is not down for a long time, then it will definitely lead to Oom (after the object has been used and is quoted as not released), if the total PSS soared after use, but can be lowered after use, it may lead to oom, we still need to go to 1.1 to troubleshoot what caused the cause.

If we soar after use and have been down for a long time, we need to use mat to further analyze the problem.

3. Memory optimization

Android virtual machine is a register-based Dalvik, its maximum heap size is generally relatively small (the lowest end of the device 16M, and later the device becomes 24m,48m, etc.), so we can use the memory space is limited. OutOfMemory errors occur if we use a memory footprint that exceeds a certain limit.

There are several scenarios in which memory overflow may occur:

1) Incorrect use of static variables

If a variable is a static variable, it belongs to the entire class, not to the specific instance of the class, so the life cycle of the static variable is particularly long, and if the static variable refers to some resource-consuming instance, such as context, there is a risk of memory overflow.

Google Developer Blog, gives an example: http://android-developers.blogspot.jp/2009/01/avoiding-memory-leaks.html
A case in which a long reference to the context causes a memory overflow is specifically introduced.

This situation:

Static Sbackground variables, although not explicitly holding a context reference, but:
When we execute view.setbackgrounddrawable (drawable drawable);
Drawable will set the view to a callback (via the Setcallback () method), so there is an implicit reference chain: Drawable holds View,view holding the context
Sbackground is static and the life cycle is particularly long, which results in a context overflow.

Workaround:
1. Use the context of the application instead of the context of the activity;
2. In the OnDestroy () method, unbind the activity from the drawable, thereby removing the drawable reference to the activity so that the context can be recycled;

2) long period of the class, anonymous internal classes for a long time holding external class references cause the related resources can not be released

Long-period class, anonymous internal classes, such as Handler,thread,asynctask.

Handleroutofmemoryactivity shows a memory overflow caused by handler.

Threadoutofmemoryactivity shows a memory overflow caused by thread.

Asynctaskoutofmemoryactivity the memory overflow that is thrown when Asynctask is shown.

3) memory overflow caused by bitmap

This is usually caused by an attempt to load an oversized image into memory, or an excessive number of images that already exist in memory, causing a memory overflow.

4) database cursor not closed

Under normal circumstances, if the amount of data obtained by the query is small, there is no memory problem, and the virtual machine can guarantee that the Cusor will eventually be released, if the cursor data volume is large, especially if there is blob information inside, should ensure that the cursor occupied memory is released in a timely manner, Instead of waiting for the GC to handle it.

5) Some details in the code

• Use 9path as much as possible
• Adapter to use Convertview
• All kinds of listening, broadcasting and so on, register the same time remember to cancel the registration
• Use the object to be destroyed in time, you can use the local variables do not use global variables, the function is done to remove the reference to him
• Do not generate objects in the loop where they are called, such as New Onclicklistener () in GetView (), so that when dragging, a large number of objects will come out.
• Use Android's recommended data structure, such as HashMap Replace with Sparsearray, to avoid enumeration types (twice times the memory consumption of enumerated types on Android platforms is the static constant)
• Optimize your project with the Lint tool
• string concatenation using StringBuilder or StringBuffer
• Use static anonymous inner classes as much as possible, and use weak references if you need a reference to an external class
• Use for loops
  Use
  final int size = Array.Length;
  for (int i = 0; i< size;i++)
  To replace:
  for (int i =0;i < array.length;i++)

At last.

I've sorted out some of the developments that could lead to memory overruns, put them in Com.cundong.memory.wrong, and give an optimization approach, placed in Com.cundong.memory.right.

An Android app memory cleanup and monitoring tool for developers