Application Memory leakage confirmation and locating

 

1. Determine how memory leakage occurs.Suddenly one day, tester told us that memory leakage occurs when com. Android. browser is repeatedly started/exited. First, we need to reproduce it. The ophone SDK provides two Commands: procrank and dumpsys meminfo [pid] to view the current memory usage. As follows: $ procrank PID VSS RSS PSS USSCmdline 935 68544 K 42160 K 19570 K 15840 KSystem_server 1002 37600 K 35124 K 14912 K 12804 KOMS. Home 1221 33828 K 33828 K 12259 K 9440 KCom. Android. Phone 2537 31916 K 31916 K 11510 K 9324 KCom. Android. browser 2956 28768 K 28768 K 9034 K 7152 KCom. hiapk. Market... 854 268 K 268 K 89 K 84 K/System/bin/servicemanager 859 444 K 444 K 86 K 28 K/System/bin/SDM 920 268 K 268 K 85 K 80 K/System/bin/cbmon 883 404 K 404 K 84 K 28 K/System/bin/SDM 857 276 K 276 K 81 K 76 K/System/bin/debugadh $ dumpsys meminfo 2537 currently running services: meminfo cancel dump of service meminfo: Applications memory usage (Kb): uptime: 12697585 realtime: 49787601 ** meminfo in PID 2537 [COM. android. browser] ** native Dalvik other total size: 6432 4295 N/A 10727 allocated: 5823 3142 N/A 8965 free: 4 1153 N/A 1157 (PSS ): 3396 1858 6166 11420 (shared dirty): 1260 4872 692 6824 3332 (priv dirty): 1612 1608 6552 objects views: 50 viewroots: 1 appcontexts: 2 Activities: 1 assets: 3 assetmanagers: 3 local binders: 14 proxy binders: 73 death recipients: 2 OpenSSL sockets: 0 SQL heap: 275 dbfiles: 0 numpagers: 4 inactivepagekb: 82 activepagekb: 0 $ for procrank we Refer to the USS Column, Dumpsys info. Let's look at priv dirty. If there is no automated testing tool, the problem can only be reproduced manually. Let's start/exit the browser 50 times. Before doing this, we will write a script testleak. Sh to record the browser memory changes in this process. Here we only use procrank to observe, which is enough. Testleak. Sh #! /System/bin/sh while true; do date>. /procrank. log procrank>. /procrank. log echo>. /procrank. log sleep 5 done is used to allow the system to output the procrank result to procrank every five seconds. log. Push the script to a directory on the mobile phone and execute :#. /testleak. sh & repeat the test steps several times. With Excel, we can use procrank. log finds out the browser-related results, assuming this is the case. Pid vss rss pss uss got line... 2537 29048 K 29048 K 12735 K 8628 k com. android. browser 2537 29168 K 29168 K 12854 K 8748 k com. android. browser 2537 29088 K 29088 K 12775 K 8668 k com. android. browser 2537 29488 K 29488 K 13177 K 9072 k com. android. browser 2537 29348 K 29348 K 13037 K 8932 k com. android. browser 2537 29540 K 29540 K 13229 K 9124 k com. android. browser 2537 29564 K 29564 K 13253 K 9148 k com. android. browser 2537 29460 K 29460 K 13149 K 9044 k com. android. browser 2537 29460 K 29460 K 13149 K 9044 k com. android. browser 2537 29484 K 29484 K 13173 K 9068 k com. android. browser... let's make a picture, as shown in figure 1)

Figure 1 USS curve chart

It is obvious that there is a steady increase in repetition. If it does not fall after a period of time, we can consider it as leak. Here, we need to add that some memory leaks are trace-level and may need to be performed several hundred times to see the growth of the curve. In addition, the use time of the testing machine also affects the test results. Generally, the test results on mobile phones that have been used for a period of time are more obvious. 2. Locate the leak location.There are two cases: one is the leakage of pure Java, and the other is the leakage of the underlying layer (C/C ++. If the code lookup method does not work well, some auxiliary tools are needed. First we need a tool that is mat, it is free, you can directly use the RCP version or install its Eclipse plug-in, is the http://www.eclipse.org/mat/downloads.php. Analyze the hprof file to see which objects are not released. Let's get a hprof file that stores a snapshot of the current memory usage of a process. # Chmod 777/data/MISC # Kill-10 2537 this will generate an hprof file with the current time in the/data/MISC directory, for example, the heap-dump-tm1275041385-pid2537.hprof then we need to use the tool hprof-Conv provided by the ophone SDK to convert the above hprof to the format that mat can read. $ ADB pull/data/MISC/heap-dump-tm1275041385-pid2537.hprof desktop /... SDK/tools # hprof-Conv/data/MISC/heap-dump-tm1275041385-pid2537.hprof pid2537.hprof open with mat or eclipse (if mat plug-in is installed), select [ Leak suspects report], 2: Figure 2 select [ Open dominator tree for entire heap] Figure 3 select [ Group result...], Select [ Group result by Class Loader], 4: Figure 4. We mainly look at the objects column. 5: Figure 5 because hprof saves a memory snapshot, we can get an hprof file before the program starts, and get another file after 50 tests, if the number and frequency of objects increase together, the corresponding class is the leaked object. With reference to the code, we can easily find the leak location. However, if the number of objects does not change regardless of the number of executions, you have to consider whether it is native. This situation has to be taken into special consideration. The most straightforward method of positioning is to try to comment out the memory leak and repackage it for testing. In fact, this method is the most effective if you have doubts. However, if you haven't determined the scope of the leak many times, try other methods. The ophone SDK provides APIs for obtaining memory information, using the following: activitymanager = (activitymanager) getsystemservice (activity_service); memoryinfo info = new memoryinfo (); activitymanager. getmemoryinfo (Info); log. I ("memory free:", "" + info. availmem); add these logs to the relevant Code involved in the test step to obtain a series of Memory changes, so that you can see where the problem occurs. Solving leaks is not covered in this article. Appendix :· VSS-Virtual set size: virtual memory consumption (including memory occupied by shared libraries )· RSS-Resident set size: physical memory used (including the memory occupied by the shared library )· Pss-Proportional set size physical memory used (proportional allocation of memory occupied by the Shared Library)

USS-Unique set size physical memory occupied by the process (excluding the memory occupied by the Shared Library)