Sorry for putting a obvious question (?) but it is troubling me for sometime. I am using Glide for image loading and find it quite well in memory management. Now I am thinking to move to Vector drawables with the help of MrVector. Do i really need to worry about the memory management?
For further info, each of my image in JPG of size 200KB-300KB will be become just 20- 30 KB in vector drawables. If this info helps in answering the question. Thanks
Yes.
We had some PNG images that were only about 20kb but because we stretched them to the size of the screen, and Android converts them to bitmap in memory, they were more like 50MB!
Switching to vectors saved all of this memory.
Related
In terms of RAM utilized by a drawable when it is rendered on on the screen, does it make any difference if the drawable is a vector or a bitmap?
I understand that vectors take less media storage space, but I'm asking about the resident RAM needed in order to render it, since in theory, it is still being drawn onto a canvas with the same amount of pixels in the end.
Thanks!
From the document I read sometime ago (same question with you).
The different between these 2 options is the size of APK file after all when you release. SVG will help you save size of apk.
The initial loading of a vector graphic can cost more CPU cycles than the corresponding raster image. Afterward, memory use and performance are similar between the two. We recommend that you limit a vector image to a maximum of 200 x 200 dp; otherwise, it can take too long to draw.
Being drawn on view will have those 2 options having same RAM (memory) consumed.
My reference source: https://developer.android.com/studio/write/vector-asset-studio.html#about
use vector drawables for simple shapes. Using the same for complex structures will increase the size of the apk rapidly.
My application use a little memory, it's about 3.4MB, in some old android devices such as GT-I9001. But when i running it in HTC one, my application use very more memory.
Look, the allocated memory is 26.881MB, it's too big, and the free memory only have 2.940MB. Then i use MAT tool check the memory leak, i find the resource bitmap use mach memory.
I can't explain the reason. My application often out of memory. I think Maybe the problem is caused by high screen resolution. If someone also encountered this problem, please join the discussion, thanks!
I debuged the problem, and found some reason:
The onCreate() function in my start activity, and you can see the breakpoint. The application only use allocated memory 3.4MB before calling the setContentView(R.layout.welcome) to load layout xml. Then the application run to next step, it use allocated memory 19MB. So i think this problem must be caused by loading the layout xml.
I modifed the "welcome.xml" file, deleted all widgets, that only have a "RelativeLayout"
But the program also use 19MB memory. Finally, i deleted the backgroud of RelativeLayout and the program memory return to normal size, it only use 3MB.
The size of pictrue "loading_background.png" is only 21KB, i think that perhaps the high screen resolution of high-end device changed the picture size in memory, i will try to use 9.png picture. If you understand this part of the problem, please join the discussion, thanks!
It's not a memory leak if you use big image for background.
File size doesn't matter. When it is loaded into memory it takes width * height of the image * 4bytes.
Use small 9-patch images or shape drawables when possible.
This problem can be solved using drawable-nodpi, look this:
Android background image memory usage
Just try to make a bitmap from 3MB PNG file. You will get a 20MB picture. That's why it's beter to convert your images from PNG to JPG. The quality is not so much different actually, but you will profit a lot from memory side.
just add high resolution images to the xxhdpi folder in drawable. this prevent android scale up the image to the ultra sizes
This is a general question about the way in which Android manages Bitmaps. I am wondering if it is better from a memory perspective to provide correctly sized Bitmaps to ImageViews rather than incorrectly sized Bitmaps that Android has to scale. For a working example if we assume an ImageView 1000 x 1000 and I set a Bitmap that is 1024 x 1024 (FitCentre) Android will have to scale the image. Does it then have to hold on to both the original image and the scaled version, more or less doubling memory usage? If in the alternate scenario I present a 1000 x 1000 Bitmap to the 1000 x 1000 ImageView, is only one image held? Just a question so I know the most efficient way to handle Bitmaps, particularly large images.
The Android will scale your image, but this will happen after your image has loaded in memory, and it won't prevent the notorious OutofMemoryError exception from happening.
The solution would be to scale the image before loading it in memory, and then use it.
The Android documentation explains in details how to mitagate this issue, and in general how to display Bitmaps efficiently: http://developer.android.com/training/displaying-bitmaps/index.html
I am developing an application for android and it contains several images and I have to get them from drawable, so I am using bitmap for them to avoid out of memory exception by rescaling them, but the problem is when rescaling, the resolution (/quality) of the image is reduced. How can I overcome this problem?
You can keep a reference to the original byte array and check your bitmap size against it but I would just use pngs in the appropriate drawable folders. Rescaling/reloading the image yourself and checking for quality could be much more memory hungry in a garbage collected language.
Let android do it's thing..
The only way you can avoid the loss in quality is by scaling the image proportionately in terms of width and height.
For eg : if your resolution is 100x80 try reducing it to 5x:4x . That will somewhat preserve the quality.
I am fighting against OutOfMemoryError in my app.
I created a background image, which is 800 pixel x 480 pixel. When this image is loaded into the view that uses it as background, I think the OS will use 800*480*4 bytes for it. It is a lot of memory.
If I create a 10 pixel x 10 pixel 9-patch image to replace the whole screen image. The OS will auto-scale the 9-patch image to 800x480 when it renders the view that uses the 9-patch. My question is that, in the 9-patch case, how much memory will OS use to draw the scaled 9-patch image? will it be 10*10*4 bytes or 800*480*4 bytes?
Thanks.
Firstly, if it is a background image, and could be scaled, please do so, as it is known to be the best practice (especially for backgrounds) and the slight loss of image clarity could be compensated by choosing the correct colours and/or background pattern.
Regarding memory, if you are using Drawable you are on the safe side. But the Bitmaps are apparently not allocated in a standard Java way but via native calls; the allocations are done outside of the virtual heap, but are counted against it. More on this problem here