Shulou(Shulou.com)06/01 Report--

This article introduces the reasons for the growth of standby memory in App. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

1. Further excavation of new problems

In the previous section, we introduced the basic process of memory testing and described how to discover and deal with simple memory problems. The Dalvik Heap section summarizes some common problem patterns and how to use tools to identify and deal with these common memory problems.

When simple questions are no longer a problem, we begin to encounter strange problems, similar to the following:

"We have introduced a very simple library in this version, and the memory has increased by 2m."these codes have only initialized a few objects and haven't started using them yet."I just changed one line of code and didn't create a new object."I haven't changed a single line of code. How can it go up?"

This time the problem is this kind of problem, the new version of Dalvik Heap Pss memory has a growth of about 2m. But Dalvik Heap Alloc only grew by 273k. You can also see from Dalvik Heap Free that most of the increased memory is idle.

After observing the problem for a period of time, we have the following findings:

After a long standby time, it was not released back to the system.

There are several code that can lead to memory growth, and as long as the code is blocked, the memory situation will drop to normal.

This code does not allocate much memory, and there are even places where it is not necessary to allocate memory.

Some of the code is not new to this version and has been around for a long time.

After compiling and analyzing the memory using the tailoring function, it is almost certain that the newly added code consumes the memory, but there is no memory leak, and the code does not find a problem after review.

This result makes us confused, the common methods can not find the problem, indicating that there are deeper reasons. The next step is to look for problems from the lower-level Dalvik virtual machine.

1.1 Dalvik Heap internal mechanism

To figure out why DVM is occupying memory and not releasing it, we read the code that allocates memory for DVM. Location in the Android source code under the dalvik/vm/alloc, about 255K. The main processes analyzed are as follows:

1) DVM uses mmap system calls to allocate large chunks of memory from the system as Java Heap. According to the system mechanism, PrivateDirty and PSS are not counted if the classified memory is not actually used. For example, there are many Heap Size/Alloc in figure 1-8, but most of them are shared, and less are actually used. So there is not much memory reflected in PrivateDirty/PSS.

Figure 1-8 processes with more shared memory

2) after the New object, because the data is to be written to the corresponding address, the kernel begins to allocate the 4K physical memory page corresponding to that address.

Alloc.cpp, 176th line:

3) after running for a period of time, start GC, some objects are recycled, and some will exist all the time.

4) in GC, it is possible to do trim. The idle physical pages are released back to the system, showing a drop in PrivateDirty/PSS.

HeapSource.cpp, line 431:

1.2 where the problem lies

After understanding the mechanism by which DVM allocates and frees memory, it is speculated that there may be a page utilization problem (intra-page fragmentation) based on what dumpsys has observed. As shown in figure 1-13, the first line: at the beginning, the memory allocation is full. The second line: after the GC, most of the objects are released and a few remain.

The problem that may arise in this case is that there may be only one small object in the 4K memory of the entire page, but the PrivateDirty/PSS is still calculated at 4K.

In a typical jvm virtual machine, there is a Compacting GC mechanism to clean up memory objects and move scattered memory together. But according to DVM's code, DVM's Mark-Sweep algorithm cannot move objects, that is, without memory consolidation, which creates a memory hole.

After guessing the possible problems, you need to verify whether it is caused by the guess. Since the object instance data of MAT contains address and size information, we first export the data from MAT.

List all object instances in MAT: list_objects java.*, and then select all data to export to CSV format, as follows:

Class Name,Shallow Heap,Retained Heap,class java.lang.Class @ 0x41fdd1e8 Class Name,Shallow Heap,Retained Heap,class java.lang.Class @ 0x41fdd1e8 class test.bxi$3 @ 0x432501c8 Class Name,Shallow Heap,Retained Heap,class java.lang.Class @ 0x4324fef8meme 0paramedicol class test.bxh @ 0x4324fc8meme 48meme class test.bxh @ 0x4324f438parentin 248class test.bxg @ 0x4324f2480.0parentin class test.bxd$1 @ 0x4324f028.0m.0x4324f0280.0x4324f0280.0x4324f0280.0x4324f02800.0x4324f0280.0x4324f028.0.0x4324f438.0x4324f438.0x4324f438.0x4324f438.0x4324f438.0x4324f438.0x4324f

Deal with the exported csv file, count by page, take the high bit of the address of each object (& 0xfffff000), and the same objects are in the same page. Finally, statistics are classified according to the size of all objects on each page, and the histogram is shown in figure 1-14.

This diagram is the page utilization distribution map of the tested application, with the low utilization page on the left and the high utilization page on the right. If you find an increase in the number of pages with low utilization, the number of small object fragments has increased.

1.3 optimize Dalvik memory fragmentation

In order to be able to identify the problematic code, we will continue to process the data obtained in the previous step. Take out the memory block addresses of all pages that use less than 2K, then import the addresses into MAT using OQL, and analyze what the corresponding object is. As shown in figure 1-15, you re-import the address into the list of objects you get in MAT:

Here, we can basically see which objects cause the fragmentation of memory, and the first few classes with a large number of natural suspects are more suspicious, so we can first analyze the relevant code of the first few classes. You can also conduct targeted memory tests on this code to observe the memory situation.

Through code analysis and simulation experiments that generate these objects, we restore the basic process of the problem:

The process of generating objects requires more temporary variables.

During the batch generation process, the virtual machine did not do GC because there was still free memory.

GC is done after completion, erasing all 00:00 variables, leaving fragmented memory.

The following figure shows the similar code that caused this problem. Executing this code will result in a lot of fragmentation in memory, resulting in a high PSS footprint.

Private Object result [] = new Object [100]; void foo () {for (int I = 0; I < 100; + + I) {byte [] tmp = new byte [2000]; result [I] = new byte [4];}

Shows the allocation range of the array in similar cases, showing that the memory addresses of each member of the array are discontiguous and far apart. In this case, a lot of physical memory pages are consumed, and Heap Free is added, causing the problem in the example.

According to the above process, we figured out the cause of the problem and found the problem code. Then we should sum up some experience for reference. For testers, there are two experiences:

MAT is a good helper for exploring the Java heap and finding problems, quickly discovering common problems such as pictures and large arrays. But the functionality provided by MAT alone is not everything. For example, the data for this problem is hidden in the address of the object.

For Android testing experience, it may be easy to find a variety of testing experience and guidance on application code and framework, while there is not much low-level and performance-related testing experience.

The smallest unit of memory allocation is the page, which is usually 4K.

For developers, the following two lessons may be helpful:

Try not to create many temporary variables in the loop.

Large loops can be broken up, segmented, or executed on demand.

What is the reason for the growth of App standby memory is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.