I had an android app built especially for medium screen size android devices.
Now it was required to build that same app for a device called nook-color (by Barnes & Noble)
So for this we made all the images bigger & size & changed the layouts.
The result is that the apk which was 97.5 Mb earlier has now become 124 Mb in size.
Now the testers have complained that the application has become slower and it takes a little longer for any screen to open up. I am wondering whether this is due to bigger images or there is something else.
Can you please tell me what could be the reason for this.
124 Mb for an app seems to be a little bit excessive. I'd suggest trying to scale down the image assets, use Nine Patch images, as well as using PNGCrush
Yes. The delays are (at least in part) due to loading larger images (de-compressing them to bitmaps, to be more exact). Unless you can't help it, you should attempt to convert as many of these images to 9-patches : http://developer.android.com/guide/developing/tools/draw9patch.html.
Related
Apologies in advance for such a basic question, but this is my first app and I can't quite find a clear answer for my situation. All the images in my app are stored in the drawable folder, I'm NOT downloading any images from the internet. All the information I come across when it comes to multiple image sizes seems to refer to the occasion when the app is fetching images from the internet.
So currently most the images in my app are one size, customized for the largest size - xxxhdpi. However, I understand the app is doing some work to "shrink down" those images for the xxhdpi size screens.
I'm having second thoughts about this one size fits all approach. I'm thinking that perhaps the app doing the work to shrink the image down might take up extra memory and negatively impact performance. I've been looking at the Android Studio Profiler and I've been trying to understand the Graphics Process when I look at the Memory Graph.
More generally speaking, is there a benefit to having the smallest size images possible, even for the xxxhdpi? For example, does it hurt (memory wise or in some other aspect) to use a .png image when I could use a lower quality jpg? Again, just to super clear, this is just in the scenario when the app has all of its images in the drawable folder. My app has options where players can change the game background and other images so I want to be sure I'm optimizing how the images for best performance. Thanks.
Memory. If you load a bitmap of x by y pixels, in memory that takes 4*x*y bytes. For a full screen image, you can expext that to be 4000*1000*4 or 16 MB. That's a good chunk of memory to a small device, which also tends to have less RAM. If instead it needed one at half the resolution, you would have 2000*500*4, or 4 MB.
Obviously this scales with size. The smaller your images, the less memory wasted. I wouldn't argue that you need to provide every size, but if you're using large images I'd provide more than one. Also, for anything that isn't incredibly complex (like icons) I'd consider vector images instead (although that's a CPU time vs memory tradeoff).
You mentioned png vs jpg. There's two things to consider there: apk size and image quality. JPG is smaller, so it will lead to a smaller apk size. PNG is lossless, so it will have higher quality (although whether that matters requires a human visual check- it matters less than you'd think on a lot of things). Interestingly it doesn't effect the amount of memory used at runtime, because both are held in the Bitmap object uncompressed.
Does android want that we put different version of an image (for different dpi) to avoid resizing-artifact because their scaling algorithm is not quality-efficient (to be fast i think) ?
But anyway, it's obvious that android will scale all image just for maybe some pixels, so, resizing-artifact does ONLY appear when we do a big resizing ?
Through this questions , i want to understand the utility of putting different size of image and why we don't just put a big resolution image and let android scale down every time.
(I have also a suppositon that i want to confirm, maybe the algorithm take more time when the scale factor is important)
Thx.
If you put the highest quality images in your app, your app consumes more memory (RAM) and if the device has less memory than your app freezes more frequently. This will not provide a good user experience as we all want that our app should be smooth in performance.
Besides all, I had also tested that if we put larger images and try to display them, Sometimes the app also crashed by giving an error of out of memory.
If you want to only place one image in your app to reduce the size of your app than I advise you to do it with .svg images. These images are scalable and the CPU does not have to do extra processing to display them.
I hope it will help you. Thank You
Need to build an android apk less than 20kb, and rest of the contents in the app should download dynamically, does anyone have idea about that.
If i create a simple android app and build it without any source code, it results in 3 MB atleast.
So, so pls someone suggest me how can we create an apk in kb.
I decided this would be a fun challenge, and was able to make a tiny app (no real functionality) that was 16kb. You can find the source code here. It would have been even smaller with only ldpi assets.
Some caveats:
Don't expect an app with any real functionality to come in this small. Keep in mind that 20kb is around 20,000 characters worth of data, which would be about the length of a very short story. 20kb really isn't realistic, and you are going to end up taking up that extra space on your user's phone when you download the "rest of the app" later anyway.
My example has only mdpi assets. Things like launcher icons have to be bundled with your application, so either your icon will look awful on large devices, or you need to modify your requirements.
Some tips:
Enable proguard. Both minification and obfuscation. The latter is a hyper-optimization, but when you are trying to go that small, every bit helps.
Take out any libraries that aren't absolutely mission critical. You aren't going to make it with any of the support library.
Support only the lowest resolution screens you can. ldpi assets will look bad on high density screens, but are exponentially smaller than mdpi, which is exponentially smaller than hdpi, etc. Resources are almost guaranteed to be the largest piece of the app.
Read all of the Shrink Your Code documentation. One great tip if you are using any libraries that provide resources is to use resConfigs to strip out any languages, densities, and native ABIs that you don't need.
Android Studio 3.0 has an "analyze APK" feature that will break down what pieces of the APK are taking up the most space- use that to identify your targets for cutting down the size.
Is there any drawback in only using xxhdpi images and letting android scale the images?
(Yes it might be more cpu intensive, but is it notable?) I tested it on a samsung s2 and the difference were small.
Is there a restriction to only use this if set minSdk to XX, becaus there were no xxhdpi?
Here are a couple drawbacks I can think of:
More CPU intensive to resize the images, the app will use more battery and might feel more sluggish, especially on older devices.
The images that you are going to load will be bigger and will use more memory. On mdpi/hdpi devices, the VM in which your app run will only have a smaller amount of heap memory available, and you might run into Out Of Memory Exceptions much more frequently if you only load high quality images.
The quality of the image might not be as good on mdpi/hdpi devices, because of the resizing. This really depends on what image you are loading, but images with sharp lines might appear a little blurred. But I also want to point out that this only applies if you are really making pngs for each size from a vector graphic. If you are just resizing your xxhdpi png into smaller one, you're probably doing the exact same thing that android is doing on the fly, so there will be no difference at all.
Yes, drawable xxhdpi was introduced in API 19.
If you want to run your app in a lower API level, you wont get any image because the system can't access the xxhdpi drawables.
This is also true if you only use only xhdpi with Android 2.3.
I'm not so sure there is going to be an image quality difference: even if you do provide the different versions of the graphic, they're likely just downscales of the original anyway. I'm willing to bet the difference between doing it at run-time and design-time is not going to be significant enough for a user to notice on a mobile phone screen.
I'm also not sure about a performance difference - however, even you admit that there is likely to be a non-zero negative impact. Given that fact, I think it's worth asking "Why not provide pre-scaled graphics?" There are tools (like the Android Asset Studio Icon Generator) that bring the level of effort required to make that happen almost to 0.
In mobile, any deal where you trade nearly 0 work for any potential performance enhancement is a deal you should take.
In addition to Stephane answer I must say that an image quality would be bad especially on mdpi devices.
I was doing a little project thing for my school...
I made a simple calculator app...with simple mathematics operations...
And when the apk file is created and installed, it was consuming the memory space of more than 700 kb in the phone.
While in the android market(play store), there are just similar apps which are of low sizes and are taking memory space of less than 500. I was creating app in eclipse...
Will somebody plz help me out with this that how they do make apps of simple lower size.??
The smallest APK I created is ~35kB. Size increases dramatically with the included assets. Check the size of your /res, /assets and, if you have it, /raw folders. The APK size will be larger than those three combined. Further, any included lib counts, and adds bulk, even (and especially) the compatibility library, if you use it.
If you're having lot of graphic assets, then you should probably look at using 9-patches. They save a lot of memory.
Please elaborate your question. When you say memory, are you referring to the RAM OR the actual storage memory ?
If you are referring to storage memory...
The storage memory depends on how big your application is. For e.g. IF you have too many images of large size, then app size will increase.
By the way, 700K is not really too much. You are OK.