Android-memory overflow-Sub-view not recycled-non-public version

1. install and use the Mat Memory analysis tool: ------------------------- install ------------------------- prepare the environment and test data. We use Eclipse Memory Analyzer V0.8, the installation of MAT in Sun JDK 6 is very similar to that in other plug-ins. MAT supports two installation methods: one is the "single-host version", which means that you do not have to install the Eclipse IDE environment, MAT runs as an independent Eclipse RCP application. The other is the integrated version. That is to say, MAT can also be used as part of Eclipse IDE and integrated with the existing development platform. Update Manager is required for integrated version installation. 1. Start the Software update management wizard through Help-> Software Updates. Figure 1. Select "Available Software" as the first step to install the plug-in, and then add the update address of MAT as shown in step 2: http://download.eclipse.org/policy/mat/0.8/update-site /. Figure 2. as shown in step 3 of installing the plug-in, select the MAT function you want to install. Note that Memory Analyzer (Chart) is an optional installation project, it is mainly used to generate related reports. However, if you need this function, you also need to install the BIRT Chart Engine. Figure 3. After installing the plug-in, you must restart the Eclipse working platform. ------------------------- Use ----------------------- for mat plugin version, is u want to use it: 2.1: open mat view pespective. 2.2 get a img of heap in android dev, u can goto ddms view, and press button. the save the img file. (select the corresponding application .) 2.3 open the imgfile. (usually after a step of 2.2, it will automatically open the things in Step 2.4) u must in mat model then u can .. 2.4 open 2. Mat Analysis of memory overflow problem analysis the three steps below are usually used to analyze the memory leakage problem: first, obtain an overall impression of the system memory status when the problem occurs. Step 2: Find the culprit most likely to cause memory leakage, which is usually the most memory-consuming object. Next, let's further look at the specific situation of this large memory-consuming user, check whether any abnormal behavior exists. The following uses a basic example to show how to use "Three Steps" to view the production analysis report. View one of the reports: overall memory consumption figure 7. as shown in the memory leak Analysis Report 7, the most striking report is a concise and clear pie chart, from which we can clearly see that a suspicious object consumes 99% of the system's memory. Further descriptions of this suspicious object are shown below the figure. We can see that the memory is consumed by java. util. Vector instances. com. ibm. oti. vm. BootstrapClassLoader is responsible for loading this object. The description is very short, but I believe you can find many clues, such as which class occupies the vast majority of memory and which component it belongs. Next, we should further analyze the problem, why does a Vector occupy 99% of the system's memory and who has prevented the garbage collection mechanism from recycling it. View Report 2: analyze the problem. First, let's briefly review the JAVA memory collection mechanism. The Garbage collection in the memory space is completed by the Garbage Collector (Garbage Collector, GC, its core idea is to recognize the available memory space of virtual machines, that is, objects in the heap space. If an object is being referenced, it is called a surviving object. Otherwise, if the object is no longer referenced, it is a spam object, which can reclaim the space occupied by it for redistribution. In the garbage collection mechanism, a group of elements are called root element sets. They are a group of objects directly referenced by virtual machines, such as running thread objects, objects in the system Call Stack and those loaded by system class loader. Each object in the heap space is called layer by layer from a root element as the starting point. Therefore, if an object is referenced by a surviving root element, it is considered a surviving object and cannot be recycled for memory release. Therefore, we can analyze the reference path from an object to the root element to analyze why the object cannot be recycled smoothly. If an object is not required by any program logic but still referenced by the root element, we can say that memory leakage exists here. Now, let's start looking for memory leaks. Click the "Details" link to see the detailed analysis report on suspicious object 1 shown in 8. Figure 8. the detailed analysis report of suspicious object 1 shows the shortest path from GC root elements to memory consumption aggregation points: Figure 9. the shortest path from the root element to the memory consumption clustering point vcTatObP + 7rEvtu8r7XjtcTX7rbMwre + tg = "src =" http://www.bkjia.com/uploads/allimg/131211/0125161315-8.jpg "/> we can clearly see the entire reference chain, the memory aggregation point is a collection of a large number of objects. If you are familiar with the code, I believe this information should provide you with some ideas for Memory leakage. Next, let's continue to see what is stored in this object set and why it consumes so much memory. Figure 10. memory consumption aggregation object information in this figure, we can clearly see that this object set stores a large number of Person object references, that is, it causes memory leakage. At this point, we have enough information to find the leak point. Back to the code, we found that the following code causes memory leakage: LIST 1. code segment for Memory leakage while (1 <2) {Person person = new Person ("name", "address", I); v. add (person); person = null;}. In the preceding example, we can see that using MAT to analyze the heap dump file is very simple, especially for beginners, this is a good auxiliary analysis tool. However, MAT is definitely not just a "silly" memory analysis tool. It also provides many advanced functions. For example, MAT supports querying objects in heap dump using OQL (Object Query Language, supports thread analysis. For more information about how to use these functions, see the help documentation of MAT.