I have a frame animation with 135 frames that should swap 25 times per second. The frames are 700X1000 pixels with 240 dpi. The problem I have is that whenever I define in the XML animation file more than 5 frames the application crashes. The frames are found in the drawable folder. I tried copying them to the drawable-xhdpi but this did not solve the problem.
Thanks,
Simon
Problem that loading images consumes all heap memory (memory that has your application avaliable) which is 32MB or 64MB. Images are loaded in on heap as Bitmap in ARGB - 4 bytes per pixel. Try to subsample animation images. Your animation has 135*700*1000*4 bytes = 360.5 MB.
You can use method decodeResource with BitmapFactory.Options opts that has parameter inSampleSize where you can set subsampling of image. Also parameter inPreferredConfig can be used to set RGB_565 instead of ARGB_8888 in case when you don't need transparency in images.
The error clearly says that you are trying to use more memory. This directly points to the image sizes. So, you need to resize your images to use lesser memory. One which can be used for this reason is BitmapFactory.Option. Or else go with manually resizing your images take care that it suit all your needs.
Heap size is the amount of memory allocated to an application to
execute.
The heap size for android applications are determined by the device
RAM. For example if the device has RAM of 179 MB, the android
applications will only get the heap size of 18MB.
Find about it more here. more on how to Load Large Bitmaps Efficiently is found here.
As the stack trace says, it's causing OutOfMemory error.
Since the frames are with higher resolution and no.of frames are also more, it's giving this exception.
Related
I am using 10 png images of size 20-30kb in imageView, but the allocated memory increases from 70mb to 270mb when this activity loads.
So why this too much of memory is allocated to these images.
This is the screenshot of memory allocation
This is one of my image
File size doesn't matter. No, matter your image is of 20kb but its resolution is quite big. When image is loaded into memory it takes memory equal to totalNoOfDotsInImageBitmap * 4bytes
and totalNoOfDotsInImageBitmap = width *height of image.
4 bytes - because of ARBG ( 1 byte per argument) for single dot of bitmap
so reducing width and height of image may solve your problem.
Depending on where you are putting the assets it may be trying to load a file that is too large.
For instance, if you have it on drawable or nodpi-drawable a device with a low density will try to load a potentially large image.
Also, bear in mind that the actual file size is not that important as it is probably small due to compression, but the image has to be converted to bitmap when it gets drawn, so if the actual size is too much that can also cause an OOM.
If you have access to the original I would recommend using a vector drawable (it's a simple shape so should be ok) and AS will generate the required PNG files for older versions.
Searched and only find solutions for scale the bitmap to reduce its dimensions and size. But I am looking for a way to reduce the bitmap's memory byte count and don't change its dimension.
The images are from remote sources, they are not in our control. , after save the images to device locally, they will be shown as thumbnail later. Noticed it frequently throws OOM exception. The first step was to scale down the bitmap to a smaller dimensions when loading from the file (such as 500x500, or 300x300), here has some suggestions, which helps a little bit.
A closer look find the scale downed bitmap may still have large byte count (from a few hundreds k to over one meg).
Since for this case the bitmap with lower resolution in memory should be ok, so is there a way it can keep the bitmap's dimensions but reduce it memory byte count?
Thanks!
You can read it in as RGB_565 instead of ARGB_8888, to reduce the bit depth from 4 bytes/pixel to 2 bytes/pixel. However, that's all you can do, as the memory footprint of a Bitmap is the number of pixels times the bit depth per pixel.
In the attempt of performing animation with large set of images, I tried with FrameAnimation but I found of outofmemory exception with large set of images, after some exploration for the solution I found one good solution here Pinhassi's solution.
This one helps me to achieve animation but not smoothly because it taking a time to load the images. Then I decided to decode bitmap before starting the animation (giving bitmap instead of resID to ImageView). Through this I got smooth animation. But it is taking a time to decode the bitmap from the resources.
Is there any better approach to do the same? Any suggestion would be appreciated.
Details of the image
Total Number of images =30;
Image Dimension =1000x 720;
Size =180kb
Devices on which I am performing
Manufacture: Motorola
Model: MZ601
Android Version: 3.0
To decode Bitmap
Bitmap mBitmap=BitmapFactory.decodeResource(getResources(),resID);
int bitmapSize= mBitmap.getRowBytes()*mBitmap.getHeight())
The approximate bitmapSize values is 3000000 (might be it is in bytes) converting it to kilobytes 23437.5kb
Here original png file is 180kb but after decoding it, taking nearly 2MB of data. Why?
Is I am doing anything wrong in analyzing the size of bitmap?
If yes, then how to get the size of decode bitmap?
If no, then any one explain why it is taking large space?
Note: I don’t want to scale the bitmap since it is perfect to my device screen dimension which is (1280 x 752).
Thanks
In advance for valuable suggestions and solutions.
Here original png file is 180kb but after decoding it, taking nearly
2MB of data. Why?
Assuming 1 byte per pixel with three color channels(RGB) Byte size = 3X(1000X720)/(1024*1024) = 2.05 MB approx.
There is a limit such processing can reach with plain bitmap loading, that's why Video codec's exist.
I use a skin in my app,and load something like 1.5 Mb of images at some of the activities.
This shouldn't be a problem.... 1.5 Mb + default of ~6Mb for the app when loaded... however, things are quite different.
each png I load as a drawable in my layout xmls, is being multiplied by at least 10 from its actual size...., I wrote a sample app with nothing except for a black screen, and loaded it once without anything on it and got native-heap of 5.8Mb, and then loaded it with a small png of 25Kb and guess what.... 6.25Mb.
I loaded my application with nothing but the skin, and it started with 14.5Mb!!!!!!!!
so now I am in the middle of doing a bitmap recycle operation after each and every activity change.
Is this a known issue with android?
png files are loaded with much bigger size inside the native-heap?
is there a solution other than my current plan?
Thanks.
PNG files (as well as many other image formats, such as JPEG) are compressed files, pretty much similar to zip-files. When you load them into memory they will be uncompressed
and take more space consequently.
How much depends on the internal image config, the default is ARGB8888, which takes 4 bytes per pixel. So the memory consumption only depends on the image size, not on the filesize on disk (which can get pretty small. For example: A 500x500 px bitmap consisting of one color has a good compression ratio).
Example for a 500x500 px image is 500*500*4 bytes = 0.954 MB, which is almost one megabyte.
I'm loading 100 images from Asset folder to an array object. The pictures are quite small (png ~20k each), and im using this code do to it, and to prevent memory leak & optimized performances:
in a loop:
// create resized bitmap from asset resource
InputStream istr = assetManager.open(pics[i]);
Bitmap b = BitmapFactory.decodeStream(istr);
b = Bitmap.createScaledBitmap(b, 240, 240, true);
where pics[i] is a list of filenames which sits in my Asset folder.
The code works for me, but i still receive from time to time Errors from users (i see it on Developer Console errors):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:468)
at android.graphics.Bitmap.createBitmap(Bitmap.java:435)
at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
Is there anything i can do to improve it? or this is Android's world, we can never deliever a perfect application?
Of course you can improve something: Don't load too much pictures into the memory at the same time (or reduce their size). Some devices don't have much memory available. Your device may have a higher heap limit than some of your customers phones. Therefore it crashes for them when it works for you (see this video for some heap limits [at 4:44]).
You may get the available heap size via ActivityManager.getMemoryClass().
To improve this, test which pictures you need right now (which are displayed) and are which not. Load only the required ones and recycle the bitmaps you don't need anymore.
Also try using the BitmapFactory.decodeResource() and BitmapFactory.Options.inSampleSize. This allows you to load images at a lower resolution directly without loading them at the full size and then resizing them as you did here.
Bitmaps aren't compressed so they are stored in width * height * 4 bytes. It means that every image uses about 225 KB of memory. 100 images require about 22 MB of memory. The minimal heap size is 16 MB, but devices usually have 24+ MB heap. And this heap is used not only for data but also for activities, view and so on. That means you can't load 100 bitmaps of this size.
As a rule of thumb you should only ever need to show what the user can actually see. Holding anything else (graphics) in memory is just icing on the cake. This is why devices with higher resolution screens will have larger heap sizes available.
For example, on a 320x480 screen, you would only need as a minimum, 320x480x4=614400 (600kb).
Taking this concept into mind, you need to consider whether you need to hold 100 Bitmaps in memory. Is the user looking at 100 Bitmaps at one time? In that case you can reduce the quality of the images without degrading the user experience (there are only so many pixels on the screen). Is the user scrolling through 100 Bitmaps? Then dump and load images dynamically as appropriate (with a bit of caching for smoothness).
There is always a workaround.