I use Android Studio Profiler dump heap
the use hprof-conv to convert the heap file into a standard format
$ANDROID_HOME/platform-tools/hprof-conv memory-20230112T162214.hprof memory-20230112T162214.conv.hprof
but the MAT Histogram Objects count is not equal Android Studio Profiler
for example
In Android Studio Profiler
byte[] count is 112915 = 82773 + 24578 + 5564
MAT Histogram display byte[] count 106251
Eclipse Memory Analyzer Version 1.13.0
Android Studio Profiler byte[] count is 112915
Android Studio Profiler parse conv hprof byte[] count 112915
MAT parse conv hprof Histogram display byte[] count 106251
Android Studio version
but java.lang.Class count is euqal to 16661
I used OQL
select * from "byte[]"
result is 106251
how to fix the problem make Android Studio Profiler and MAT has same result, same Object count
Related
Nearby I noticed that my Android app often crash because of OOM.
I use Android Studio 3.2.3 Profiler, so I find that native heap are up to 300M.
I want to find the memeory use by every C++ so files, BUT I can not find a tool to accomplish my work.
Any advice is appreciated
adb shell dumpsys mypackage
App Summary
Pss(KB)
------
Java Heap: 11568
Native Heap: 202176
Code: 18576
Stack: 2716
Graphics: 84772
Private Other: 11300
System: 43414
TOTAL USS: 331108
TOTAL: 343727 TOTAL SWAP PSS: 30795
Today I randomly started getting the following error when trying to compile my Adobe Air App from InteliJ Idea.
Failed to package AIR application FARQAndroidFree.apk:
dx tool failed:
UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.Arrays.copyOf(Arrays.java:3181)
at java.util.ArrayList.grow(ArrayList.java:261)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
at java.util.ArrayList.add(ArrayList.java:458)
at com.android.dx.ssa.Dominators$DfsWalker.visitBlock(Dominators.java:263)
at com.android.dx.ss...
[Full error message]
[ADT command line]
I'm using the Adobe AIR SDK 28
Try increasing the amount of memory available to the Java runtime used by IntelliJ to package your application.
You will find this in:
Preferences / Build ... / Compiler / Actionscript ... / Compiler heap size
Try somewhere in the 512 - 1024 Mb mark.
I have an issue in creating new AVD in android studio 3.0.
error is
Invalid argument size '124M'
mksdcard: create a blank FAT32 image to be used with the Android emu
usage: mksdcard [-l label]
if is a simple integer, it specifies a size in bytes if
is an integer followed by 'K', it specifies a size in Ki if
is an integer followed by 'M', it specifies a size in Mi if
is an integer followed by 'G', it specifies a size in Gi
Minimum size is 9M. The Android emulator cannot use smaller images.
Maximum size is 1099511627264 bytes, 1073741823K, 1048575M or 1023G
The same error happens if I use mksdcard from CMD.
AS is installed on win7.
I'm computing the Fourier transform of a 2^18 samples vector using the FFT included in Ne10 ARM library and it doesn't seem to work. It produces a Sigsev error on the Android Studio. The funny thing is that a 512 samples FFT works well. My questions are:
Is there a limitation on the maximum amount of samples I can compute the fft on with this library?:
I'm using:
fftPlan = ne10_fft_alloc_c2c_float32_neon(fftSize);
fftIn = (ne10_fft_cpx_float32_t*)NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));
fftOut = (ne10_fft_cpx_float32_t*)NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));
Are these memory allocating functions thread safe? (I've tested and they seem to)
Leaving out their own FFT benchmark comparisons. Is there any other 3rd party site where I can compare its performance with fftw?
The library produces a "text relocations warning" when I use NDK10e for building the native shared library loaded from my android app, which when using ndk13 produces the following error :
D:/AndroidDevelop/android-ndk-r13/build//../toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: warning: shared library text segment is not shareable
D:/AndroidDevelop/android-ndk-r13/build//../toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: error: treating warnings as errors clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)
I would like to know how I can troubleshoot high memory usage problems of my app on Android. I've search the internet and found out that the DDMS plugin is useful in taking a memory dump of the heap for my app. This however has been useless.
The app "Usage Timelines Free" is showing 94 MBs of memory used, while the DDMS heap dump shows me a total of 8.4 MBs, with the suspected leaks being the resource files.
When I generate a dump from adb (dumpsys meminfo), I get:
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 20 8 20 54588 39431 1892
Dalvik 6732 9952 6396 10756 10028 728
Cursor 0 0 0
Ashmem 184 0 184
Other dev 11462 1172 11384
.so mmap 2467 2072 1156
.jar mmap 0 0 0
.apk mmap 48 0 0
.ttf mmap 2 0 0
.dex mmap 1037 0 0
Other mmap 41 16 32
Unknown 46352 292 46348
TOTAL 68345 13512 65520 65344 49459 2620
How can I know what is behind this huge memory consumption. My app is a foreground monitor service which runs forever, with a few activities which are accessed a few times per day.
Thanks.
Minimize your android data usage. Check the link :http://engineroots.games4punk.com/minimize-your-android-data-usage/
DDMS and got a heap memory dump. It only showed 8.4 MBs being used!
Then you are only using 8.4MB of heap space after a complete garbage collection (a net effect of creating the heap dump).
Note that if you ran this on Android 1.x/2.x, MAT will not report space consumed by bitmaps. Always try to dump the heap from an Android 3.0+ device or emulator.
When I generate a dump from adb (dumpsys meminfo), I get:
My guess is that you are running this on an Android 1.x/2.x device or emulator, and you have a lot of bitmap memory. Try running your heap dump and other tests on an Android 3.0+ environment.
Also, bear in mind that adb dumpsys meminfo does not perform a complete garbage collection, whereas dumping the HPROF file does. The Android garbage collector is optimized to minimize CPU utilization and therefore does not attempt to perform a complete garbage collection. Hence, at runtime, the heap is usually filled with garbage that will be reclaimed, as needed, by the GC engine.
You might also wish to read Dianne Hackborn's essay on this subject.