Develop Reference

Heap allocation behaves weird - Android

I cannot understand what is happening here - I have been creating a small project just to learn about rotation of an image. But this is not relevant here.
So - I have been doing this before and know how heap works, but right know I cannot get it.
In this small Eclipse project I put an image in the drawable-mdpi folder. The image is
1300 * 1950
So simply - this image will occupy about the following amount of ram (heap)
10 MB (1300 * 1950 * 4)
Red, gree, blue and Alpha. Thats it!
But what is happening. Well see the logcat below!!! the heap of 63 MB for my Samsung Galaxy S3 is almost exhausted.
02-17 08:50:05.144: I/dalvikvm-heap(21097): Grow heap (frag case) to 22.494MB for 10140016-byte allocation
02-17 08:50:05.164: D/dalvikvm(21097): GC_CONCURRENT freed 1K, 5% free 22152K/23175K, paused 12ms+2ms, total 22ms
02-17 08:50:05.329: D/dalvikvm(21097): GC_FOR_ALLOC freed 0K, 5% free 22152K/23175K, paused 11ms, total 11ms
02-17 08:50:05.429: I/dalvikvm-heap(21097): Grow heap (frag case) to 61.174MB for 40560016-byte allocation
02-17 08:50:05.449: D/dalvikvm(21097): GC_CONCURRENT freed 0K, 2% free 61761K/62791K, paused 11ms+3ms, total 22ms
02-17 08:50:06.109: D/libEGL(21097): loaded /system/lib/egl/libEGL_mali.so
02-17 08:50:06.119: D/libEGL(21097): loaded /system/lib/egl/libGLESv1_CM_mali.so
02-17 08:50:06.124: D/libEGL(21097): loaded /system/lib/egl/libGLESv2_mali.so
02-17 08:50:06.179: D/(21097): Device driver API match
02-17 08:50:06.179: D/(21097): Device driver API version: 10
02-17 08:50:06.179: D/(21097): User space API version: 10
02-17 08:50:06.179: D/(21097): mali: REVISION=Linux-r2p4-02rel0 BUILD_DATE=Fri Sep 28 10:42:56 KST 2012
02-17 08:50:06.254: D/OpenGLRenderer(21097): Enabling debug mode 0
First it allocates properly - you can see 10 MB (according to my calculations) and a heap well above that - that is 20 MB. So far so good. BUT THEN IT CONTINUES TO ALLOCATE MEMORY FAR ABOVE THAT LEVEL. Like there was another image of 40 MB (4 times the previous) so the allocated heap ends up in 61 MB, almost tangenting out of memory.
What did I miss here or is it a bug? I have checked all the drawable folders and I know I run this app and not another. I recreated the project to be sure, even changed the image name. restarted the computer AND the device
this is the source code
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
ImageView imgview = (ImageView) findViewById(R.id.image);
Bitmap bm = BitmapFactory.decodeResource(getResources(), R.drawable.image1);
}
the xml-file
<ImageView
android:id="#+id/image"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
/>
more info: The device is rooted

How to release the cached memory by pss in android

While dumpsys meminfo,I found this:
Total RAM: 463136 kB
Free RAM: 170277 kB (48221 cached pss + 68780 cached + 53276 free)
Used RAM: 173253 kB (152085 used pss + 3160 buffers + 176 shmem + 17832 slab)
Lost RAM: 119606 kB
ZRAM: 2168 kB physical used for 2836 kB in swap (51196 kB total swap)
KSM: 4940 kB saved from shared 36 kB
6280 kB unshared; 84220 kB volatile
Tuning: 48 (large 128), oom 108462 kB, restore limit 36154 kB (low-ram)
Does the memory cached by pss(48221 byte) can be release?And how to release

Your RAM is the memory used by your active software, meaning the operating system and the applications that are running. The only way to release memory is to close those applications that you don't need.
To answer your question it is impossible to just clear RAM without closing any applications.
More info: http://android-developers.blogspot.be/2014/01/process-stats-understanding-how-your.html

heap alloc + free < heap size

Follow is part of dumpsys meminfo's outputs:
We can see:
Native heap size is 65 MB
heap alloc is 22MB, while free is about 3MB
but alloc + free is quite smaller then size.
Why?

query about "dumpsys meminfo" in android

When I run "adb shell dumpsys meminfo" on android 4.2, I get the result like
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 28 8 28 16404 12256 3663
Dalvik 14062 10060 13736 20032 15254 4778
Cursor 0 0 0
Ashmem 0 0 0
Other dev 4762 9556 0
.so mmap 11699 1824 1500
.jar mmap 0 0 0
.apk mmap 368 0 0
.ttf mmap 811 0 0
.dex mmap 3736 0 0
Other mmap 114 16 32
Unknown 12064 544 12052
TOTAL 47644 22008 27348 36436 27510 8441
I have read the page of How do I discover memory usage of my application in Android?, but still have several questions:
Why the native Pss, shared dirty private dirty is very small?
the heap size should be smaller than Pss?
What does Unknown mean? Seems very big.
If I want to know how much memory my app uses, which data should I use? The Total Pss? But it doesn't include the native Pss which is nealy zero?

Please refer to the question How do I discover memory usage of my application in Android?.
I would also like you to refer to Detail VSS,RSS,PSS,USS link. The most appropriate data to use for a particular app is
USS (Unique Set Size ) as
USS is the total private memory for a process, i.e. that memory that is completely unique to that process . USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.
which you can get by adb shell procrank | grep <your.package.name>

Troubleshooting android app memory usage problems

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.