The most primitive memory leak test
Repeat the critical suspicious path multiple times, observing the memory curve from the memory monitoring tool, whether there is a rising trend and does not fall back significantly when the program returns.
This way can find the most basic, but also the most obvious memory leak problem, the user value of the most, the operation of small, cost-effective extremely high.
Mat Memory Analysis Tool
2.1 Mat Analyze the total memory footprint of the heap to determine if there is a leak
in devices, click the program you want to monitor. Click the "Update heap" in the top row of icons in the Devices view to click the "Cause GC" button in the heap view. The process that needs to be detected can be monitored.
In the middle of the heap view, there is a type called data object, which is an object of the class type that exists in our program. In the data object row, there is a column "total size", whose value is the amount of memory for all Java data Objects in the current process, in general, the size of this value determines whether there is a memory leak. It can be judged as follows:
Enter an application, continue to operate the application, while observing the data object's total size value, under normal circumstances the total size value will be stable in a limited range, that is, because the code in the program is good, there is no object is not garbage collection situation.
Therefore, although our continuous operation will continue to generate many objects, and in the process of the virtual machine continuous GC, these objects are recycled, memory consumption will fall to a stable level; Conversely, if there is no object reference in the code, then the total of the data object The size value does not come down significantly after each GC. As the number of operations increases, the value of total size becomes larger and higher until an upper limit is reached, causing the process to be killed.
2.2 Mat analyzes hprof to locate the cause of memory leaks. This is an effective means of using mat to locate problems after a memory leak occurs. A) Dump out memory leaks the memory image hprof, analyzing the class of suspected leaks:
B) Analyze external objects that hold references to such objects
C) Analyze the GC path of these objects that hold the reference
D) Analyze the GC path of each object individually
From this path it can be seen that a Antiradiationutil tool class object holding a mainactivity reference causes Mainactivity to fail to release. At this point it is necessary to enter the code analysis at this time Antiradiationutil reference holding is reasonable (if Antiradiationutil held a mainactivity context causes the program to exit Mainactivity can not be destroyed, That is usually a memory leak).
The 2.3 mat locates the root cause of the memory leak by comparing the hprof to the front and back of the operation. To find a memory leak, you typically need two dump results to compare, open the Navigator history panel, and add histogram results from two tables to Compare basket. A) The first hprof file (Usingfile > Open Heap Dump). B) Open histogram view. C) in Navigationhistory view (if you don't see it from window >show view>mat-navigation history), right-click Histogram and select Add to Compare Baske T.
D) Open a second hprof file and redo steps 2 and 3. E) switch to compare basket view, then click Compare the Results (the red "!" in the upper right corner of the view!) icon).
F) Analysis of comparison results
You can see the data object comparison results of two hprof.
In this way, you can quickly locate the object increment held before and after the operation, further locating the actual cause of the memory leak caused by the current operation is what data object was compromised.
Note: If the dump file obtained with the mat Eclipse plug-in is not required to be converted, it can be opened in the mat, and ADT will automatically convert. While the mobile SDK Dump files to be converted to be mat recognition, the Android SDK provides this tool Hprof-conv (under Sdk/tools) first, to go through the console into your Android SDK tools directory to execute the following command:
./hprof-conv Xxx-a.hprof Xxx-b.hprof
For example Hprof-conv input.hprof out.hprof
You can now open the out.hprof in the eclipse's mat.
Mobile Butler memory leak daily monitoring scheme
The current daily monitoring of memory leaks by the mobile Butler will automatically run and output the presence of suspected leaked report messages, regardless of the size of the compromised object. The core technologies involved are ASPECTJ,MLD self-research tools (the principle is virtual reference) and Uiautomator.
3.1 AspectJ Insertion Pile monitoring code The phone butler currently uses an ant script to add the MLD monitoring code, and the ASPECTJ's syntax enables the insertion of piles.
The reason for using ASPECTJ is the flexibility to isolate the project source and monitoring code, through different compilation scripts to package a different use of the installation test package: If the test package is through the aspect of the MLD monitoring code, then the completion of the operation will output the specified format of the log file, As a data base for subsequent analysis work.
3.2 MLD Implementation Monitoring Core Logic This is a mobile phone butler within a tool engineering, formal packaging will not break in, BVT and other daily monitoring test package can be scored. After a break, you can add a detection object that needs to be monitored by means of an interface such as AddObject (through reflection to check if the tool is included and called), and the tool automatically detects if a leak occurs at a given time (such as exiting the Butler).
The rationale behind this memory leak detection is that virtual references are primarily used to track the activities of objects that are reclaimed by the garbage collector. A virtual reference must be used in conjunction with a reference queue (Referencequeue) (The virtual reference function must be associated with the specified). When the garbage collector prepares to reclaim an object, if it finds that it has a virtual reference, it automatically adds the virtual reference to the reference queue associated with it before reclaiming the object's memory. The program can see if the referenced object is going to be garbage collected by judging whether the reference queue has been added to the virtual reference.
Based on the above principle, the MLD tool adds a virtual reference to the type object when it joins the monitoring type AddObject, noting that the virtual reference does not affect the object being recycled properly. Therefore, the Referencequeue reference queue can be used to count whether the monitored objects that have not been reclaimed exceed the specified threshold.
With phantomreferences (virtual reference) and Referencequeue (reference queue), when Phantomreferences is added to the associated Referencequeue, the object is considered to be or is in the garbage collector recycle phase.
The core of the MLD monitoring principle at present, the mobile phone Butler has done most of the class memory leak monitoring, including a variety of activity,service and view pages, to ensure that the technology can bring users the most smooth product experience. Next, let's briefly describe the core of the tool's judgment. Depending on the memory state that is monitored by the virtual reference, there are several strategies to determine if there is a memory leak. (1) The simplest way is to directly in the monitoring to set the maximum number of the existence of the type, for example, each DAO object can only have the most one in theory, so once there are two identical DAO, it is generally leaked; (2) The second case is when the page exits the program exits, The list of objects that cannot be freed after the GC is retrieved, and these object types become suspect objects of memory leaks; (3) The last one is more complicated, and the basic principle is to judge the increase of the number of objects according to the historical operation. The growth rate of the object type is fitted by least squares based on the increase of the object, and if the XP value is exceeded, the list of objects that are suspected of being compromised is included.
3.3 Uiautomator The final step of automating the repetitive operation is simple. With so many repetitive UI operations, it's a waste of manpower to make a point of manual labor. We use Uiautomator for automated operation testing. At present, the daily automated test of the mobile Butler has covered the main path of each function, and the configuration file is used to flexibly drive the use case to delete and change, to maximize the reuse value of the use case with the version. At this point, the mobile phone Butler memory leak test program is complete, but also welcome the road to the cattle to communicate more and more powerful memory leak tool box scheme!
Memory leaks from getting started to mastering the trilogy in the Troubleshooting chapter
