AndroidStudio Memory profiler (memory analyzer)

1.Record Java/Kotlin allocations

View the call stack of objects in the java layer and the number of times objects are created in a short period of time. It can be used for fast analysis of memory jitter, and can be used to quickly find the call stack of the object (equivalent to mat). As can be seen from the
insert image description here
above figure, 23 char[] arrays are created in a short time, and the largest char[] occupies 20k, see cll stack The call stack was found to be created by a method in CheckAppProcessTask.

2.Capture heap dump

It is used to obtain the current memory snapshot, view the memory status of the current process app, and can be used to analyze the memory usage of the java layer and the native layer.
insert image description here
Because of 0Leaks in the above figure, there is no Activity/fragment memory leak, so I won’t introduce it here.

Next, analyze how to check the memory usage, call stack and other issues in the memory.

Troubleshoot large memory object usage

For example, it can be seen from the above figure that the memory of the Java layer occupies more objects: the CoroutineScheduler in the coroutine, which occupies 8M of memory.

Then check which objects are causing the occupation:
insert image description here
After checking, it turns out that the CoroutineScheduler in a certain version of the coroutine will create an 8M array object.

Next, check the memory usage of the Bitmap object:

Because the test device is android 12, the bitmap occupies the memory of the native layer in the memory snapshot. Open the bitmap list and find that the maximum memory occupied by the bitmap is more than 500K. Double-click it, check gc, and check the call stack to see which objects hold the bitmap and are not released.

insert image description here
Finally, it is found that the bitmap is held by a view, which is held by the IconManager object.

It is necessary to combine the business and the scene to analyze whether an object should be destroyed and which objects are too many. It is taboo to talk about optimization in the same way .

3.Record native allocations (less used, less familiar)

It is used to view the creation of c++/c objects in the current period of time.
insert image description here
In the Visualization view: Intuitively see the creation of native objects under each thread.
insert image description here
Summary : memory optimization, in essence, reduces memory leaks (not released in usage scenarios) objects) and reduce large object occupation and reduce memory jitter caused by frequent object creation.

Guess you like

Origin blog.csdn.net/hexingen/article/details/131940521