Find out what App stores in Cache - android

my Android app seems to use too much cache space. The apk is less than 2 MB, but the App uses about 5 MB of cache. Now I want to find out what could use that much space.
Maybe it's the background image, which is a 700 KB Jpg (it is a photo)?
I don't store any data explicitly in the cache, so I wonder where these 5 MB come from.
Thanks for your help.

You can try to check the Heap and Allocation Tracker of your application on DDMS
http://developer.android.com/guide/developing/debugging/ddms.html

Related

How much memory your app will take up when develop the android app?

Sometimes we encounter the memory issues,such as the OOM problems.And We inevitably have to manage the memory.Android has set a limit to the memory used bye each app.The maximum limit probably is the 32Min the early versions of android,such as 1.5,1.6,2.1.
Android of v4.0 has exceeded this limit.We can set android:largeHeap to "true" in the AndroidManifest,so the app could increase the memory limit.
I'm develeping the wallpaper app.The app can show many pictures in high definition.But the memory used by the app always reach the limit of more than 60M in the android of 720p, about 100M in the android of 1080p.
The overuse of memory is unacceptable for me.And I'm looking for the means to resolve it all the time.
My friends,How much memory your app will take up when you develop your app during debugging or running?Is there a memory-manage mechanism in the code?Look forward to your reply.
The amount of memory used by bitmaps is based on what's in the bitmap, not the size of the file. There's a few things you can do to reduce the footprint of the bitmap being loaded in to memory, which, in turn will reduce the amount of memory your app is using.
There's a great talk here from Google I/O for memory management that will help and another that will help you check to see if you have any memory leaks as well.
Also, note that if you use Bitmap.Config.RGB_565 you can half the amount of memory that the Bitmap is using (each pixel value is stored in 2 bytes instead of 4)

My android application memory usage too large (as reported by memory managers)

I have a Live Wallpaper app that uses photos downloaded from web to use as a wallpaper.
Memory managers show that my app is using between 90MB and 120MB (it's a device with 1GB RAM). That is a lot. Wallpaper service get's killed often, and sometimes system even reverts to default static wallpaper.
Although I checked thoroughly for any memory leaks and HPROF dump analysis shows that I only have 2 large objects in use: currently used Bitmap for wallpaper (16MB - and this is expected for a 4Mpix image) and class android.content.res.Resource (12MB) with total of 32MB as reported in HPROF overview screen.
dumpsys meminfo shows this:
** MEMINFO in pid 1354 [com.myapp.lwp] **
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 16 16 16 112304 5274 993
Dalvik 41947 19316 41428 74572 53120 21452
Cursor 0 0 0
Ashmem 0 0 0
Other dev 20170 33176 3460
.so mmap 5690 2620 1504
.jar mmap 0 0 0
.apk mmap 64 0 0
.ttf mmap 6 0 0
.dex mmap 604 0 4
Other mmap 1035 300 272
Unknown 5127 472 5116
TOTAL 74659 55900 51800 186876 58394 22445
Objects
Views: 27 ViewRootImpl: 0
AppContexts: 4 Activities: 1
Assets: 3 AssetManagers: 3
Local Binders: 16 Proxy Binders: 23
Death Recipients: 0
OpenSSL Sockets: 1
I read this: How do I discover memory usage of my application in Android? but it doesn't help me to conclude anything...
I also used:
cat /proc/1354/statm
139422 29326 11550 2 0 10330 0
It doesn't help much either.
DDMS shows 63MB heap size.
My questions are?
Is it normal and expected of an app that deals with images of double the screen size?
If not, what is in remaining 60-90MB? (i subctract 30MB that HPROF gave me for total).
What possible can I be doing wrong in my app to use so much memory?
What app actualy do:
1) Download list of photos (max 100) as JSON string and parse that string to get ids and urls for these photos.
2) Download first photo and save it to cache folder
3) Decode photo and if necessary resize it to fit 2Width*Height of screen (photos are actualy smaller that my Full HD screen).
4) Draw it on wallpaper canvas (and draw repeatedly while user is scrolling)
5) If on WIFI download next 10 photos to cache folder (without decoding, just saving)
I have other modes more complicated with more photos simultaneously used but above memory usage is for most simple scenario.
It's not a problem of continuous usage - memory is as described after first start:
If I kill the service, after restart it uses 90MB. After first opening of options screen (small activity/dialog with several options to choose - no graphics except background drawables) memory usage jumps to 124MB and returns to 112MB after screen is closed. After first change of wallpaper photo it jumps to 130+ and returns to 120+. Probably because heap size is increased during bitmap decoding and then stays that way.
What should I do? How to decrease (if it is possible at all) my app memory footprint? Where else to look? I don't expect ready solution but any further guidance can help...
I had the same problem while working on my application. The DUMP and the GC (From Logcat) were both indicating that I'm using around 30-50 MB of memory, fluctuating up and down, which is normal since the GC is running at different times.
However, for some reason it seems the process RAM usage was just building up and not getting released, especially if you have a running service. My process showed that I hit over 300 MB of RAM, so I wasn't sure whether it's just not released (GCed already) or it's being leaked.
What I did to verify is, I let it be for a while after closing the application, and in few hours it showed my service is using 3 MB of RAM only, also, I opened many applications (To force the Android to perform a GC) and again it went back from 300 MB to 3 MB without killing my service, so I assume it just kept building it up without GCing it, so it wasn't leaked.
This is still not a good enough insurance but it's better than nothing, I'm working on trying to find out more about it, hope that helps.
Kindly let me know if you ever figure out the solution to that problem, thanks.

Memory issues loading images for app

Describing background, as I may just have a terrible approach to the problem - self learning.
I'm writing an app for android, and testing it on default AVD, which is set to WVGA800 with 512 'device ram size' and 240 'Abstracted LCD density'.
I have some images, and I put them into drawable-hdpi.
There are 458 KB (not MB) worth of images in that folder.
All images are in PNG format.
The issue is that when I try to load my biggest image (used for background), it throws: java.lang.OutOfMemoryError
This is the call to load the image:
BitmapFactory.decodeResource(status.getResources(), R.drawable.background);
This is identical to how I load the rest of images (33 in total).
It makes sense to me, that it would run out of memory on biggest image, but my total size of folder is 458 KB, so I wouldn't expect to run out of 512 MB Ram set on device.
I never unload any images, I keep them loaded, and use as needed.
I wrote a different app before, where my total size of images was 563 KB with 82 images total, and I didn't have this issue (using the same AVD). In fact the prior app used to make a couple of copies of each image by flipping it, and still didn't run out of space. Current app is failing on initial load - before much happened.
Could someone point me at what the issue could possibly be? And how I can solve it, or maybe mention if my approach is wrong (self-teaching myself from examples)
I'll give you some hints on how i manage to lessen that problem
If you plan to support all devices, put all your resource into the xhdpi folder. especially the background
File size != memory size
Keep in mind a few things:
Your application has a memory limit (this depends on the android version). You don't get all the device memory. I think that first android version have a memory limit of 16mb.
The size of the file doesn't represent the size of the bitmap in memory. For example a 32bit ARGB bitmap will take 32*width*height bits
If you are dealing with big images then scale them first. Calculate the size you need (this will probably be the size of your ImageView) and load a resized copy of the bitmap. You can do this using BitmapFactory.Options
Yea, this is a pretty common problem. So in older versions of android OS, the bitmap was loaded into native memory and not the JVM. The garbage collection process would really have 2 cycles. One to clear out the memory in the JVM and the other to clear out the memory in the native memory (for bitmaps). If you want to work on older devices, you will need to handle this situation by either recycling your bitmaps Bitmap.recycle() or calling System.gc()
There are two problems that you might be hitting:
1. You have other bitmaps that are un recycled.
2. You really are running out of memory because that single image is too big. (Make sure the other images are correctly recycled or gc'd so that it doesn't add to the memory footprint). In this case, no much you can do.
ALso, as mehmet suggested, you can read this

Android: Out of memory error when loading text files. How to get available memory before loading files

I want to load a text file in a wordprocessing apps. But I get out of memory error when files are of too big. I finalized that I can load upto 1 MB files. But sometimes I get out of memory even for 1MB files. But I have to say before loading whether I can load files or not.
I tried for solution of finding maximum possible available memory, apart from freeMemory(),
that is freememory + (maxmemory - totalmemory) which will give the total possible available memory for the application. (Say it will be around 18MB to 20 MB). But I get outofMemory error after completely utilizing the heap. say for example(24 MB).
My question is really that (18MB to 20 mb) of "maximum possible available memory" is utilized for allocation when loading 1MB file.
How much of memory should be available to load 1MB file.
How can I roughly compute it.
Is there any way out of PSS, Privatedirty. I couldn't understand much about PSS. But I couldn't get much info regarding of summing up in article "How to discover memory usage of my application in Android"
Thanks
Remember, the way you store the files in variables matters quite a lot. Using char array manually is one of the most memory-efficient ways, but you still need to account for every character taking 16 bits, or 2 bytes. So, if you have text file using some 8-bit encoding and you load it into char array, it takes twice as much space.

Way around 1mb file size restriction?

My app needs to save files that will range from about 2-20mb. When I tried to do this I was getting an OutOfMemoryException. I did some reading and it's looking like Android has a file size limit of 1mb. Is this correct? If so, is there a way around this limitation, other than splitting up every file into 1mb chunks?
The main application need to be small, like < 1 MB but you can save as many files as you want and as large as you want as long as you save them on the memory card. The available space that can be used for applications (and other secure data) is limited, usually under 128 MB. So basically you need to keep your application small and put the large part as an add-on or extra files that can be put on the memory card. If you application will use 20MB from the available space it will drastically reduce the number of people that will use it.
OutOfMemoryError means you exceeded the VM's RAM budget, which is 16MB or 24MB depending on what device you're on. It has nothing to do with file sizes.
The 1MB limit you're probably referring to is the maximum size of a compressed asset in an APK file.
Files in your app-private data area or on external storage can be as large as the filesystem will allow them to be. (I've heard the FAT32 implementation Android uses for SD cards has a 2GB limit for individual files, but don't remember the resolution of that thread.) Available disk space will likely be a larger concern.
Going back to your original problem, check the logcat output (via adb logcat or DDMS) to see if there are any messages from the garbage collector right before the OOM fired.

Categories

Resources