Android memory detection tool

No matter how careful you are, it is impossible to completely avoid bad code. At this time, some tools are required to help us check whether there is any place in the code that will cause memory leakage. The ddms in Android tools comes with a very good memory monitoring tool heap (here I use the ADT plug-in of eclipse, and take the real machine as an example, the situation in the simulator is similar ). To monitor the memory usage of an application process using heap, follow these steps:
1. After eclipse is started, switch to the ddms perspective and confirm that the devices view and heap view are all open;
2. Connect your phone to your computer via USB. Make sure that the phone is in "USB debugging" mode instead of "Mass Storage ";
3. After the connection is successful, the device serial number and running process information are displayed in the devices view of ddms;
4. Click the process you want to monitor, such as the system_process process;
5. Click the "Update Heap" icon in the top row of the selected devices View Interface;
6. Click "cause GC" in the heap view;
7. In the heap view, the details of the memory usage of the selected process are displayed.
Note:
A) clicking the "cause GC" button is equivalent to requesting a GC operation from the VM;
B) when the memory usage information is displayed for the first time, you do not need to constantly click "cause GC". The heap view interface will be refreshed on a regular basis, the changes in memory usage can be seen during the continuous operation of applications;
C) the parameters of the memory usage information can be known Based on the name and will not be described here.
 
How can we know whether our program has the possibility of Memory leakage. Note that a type in the heap view is called data.
Object, that is, the data object, which is a large number of class objects in our program. One column in a row of data object is "Total ".
The value is the total memory size of all Java Data Objects in the current process. Generally, the size of this value determines whether memory leakage exists. You can judge this as follows:
A) constantly operate on the current application, and observe the total size value of the data object;
B)
Under normal circumstances, total
The size value is always stable within a limited range. That is to say, because the code in the program is good, the object is not garbage collected, therefore, although we continuously generate many
In the continuous GC process of virtual machines, these objects are recycled, and the memory usage will reach a stable level;
C) if the Code does not release the object reference, the total size value of the data object will not be significantly reduced after each GC, as the number of operations increases, the value of total size increases,
The process is killed until the upper limit is reached.
D) The system_process process is used as an example. In my testing environment, the total size of the Data Object occupied by the system_process process will normally be 2.2 ~ 2.8, and when the value exceeds 3.55, the process will be killed.

In short, using the heap View tool of ddms can easily confirm whether our program has the possibility of Memory leakage.