I am a newcomer to the world of Android. Few days ago I tried to write a program whose purpose is to enable / disable bluetooth by following instruction in a book for beginner and succeeded. However its size is 888 kb, compared with one bluetooth enabler application that I found on the Internet, whose size was only 56kb. Was my code too complicated ? Which ways can I take to review my code for a smaller size ?
First off without seeing the code or even comparison of the two apps it's hard to make a comparison. However, some things that come to mind are
Proguard
Fewer/smaller icons and images (only 1 image for mdpi)
Fewer layouts
But either way, I wouldn't be worrying much about 900kB. Most template apps generated by Android Studio will have some minimum size.
Make sure in your Gradle file you have minifyEnable.
If you have a ton of images in your app, you need to optimize them to the resource sizes.
Related
I have developed HelloWorld Android Application which just prints Hello World using eclipse and from tutorial https://developer.android.com/training/basics/firstapp/index.html?hl=it,but to my surprise the app takes 2.21 MB of memory. Can you please suggest way to reduce this size to few kb's as this should not take much space, as I haven't added any images or code in it.
An APK is a zip file, you can open it and figure out what's taking the space. If that doesn't hint you enough come back and add this info.
Also, take a look a look at proguard
Edit: Oh wait, I might have misunderstood you, did you mean storage space or runtime memory ? (RAM)
Are you sure you are talking about runtime memory? Even a simple "Hello world" application with no icon from the default Android project has a 10MB heap with 9MB allocated on my phone. Its installed size is listed as 1MB.
I do not know how to reduce memory usage in such a simple app but I can give you some tips to reduce installed size; however, there is a limit to how small you can go.
If you have an icon for all screen resolutions from mdpi to xxhdpi, it will cost you 44KB. I have found the practical lower limit for a usable app to be a little above that; I have a reasonably small app that is only 95KB. However, this is expanded during installation; expect your app to take up to twice the APK's size once installed.
A good way to get rid of space for a small app is to remove the support library. It is included by default in new projects, and takes from 400-600KB. However, removing it comes at a cost - many user interface improvements such as fragments are only supported on older platforms using the support library, so you will either have to restrict the tools you are able to use or your target user base.
Only way i found to reduce runtime memory is to use various optimization techniques. Here is the tutorial Android Dveloper. This tutorial will help you in increasing performance of your application as well as reducing the runtime memory consumption of your application.
I have the following scenario:
An app for Android devices that has a few hundred classes. I am using Flash CS5.5, developing in AS3 using AIR for Android.
The app is a puzzle game and each class represents one of the elements from the puzzle. Each class is a derivative of a base class and only holds a few specific information like unique name, category, place in puzzle. Each class also has attached an 80 x 80 px image to it. However, there's about 300 classes like this.
The application runs very smoothly ONCE IT LOADS because it takes forever for the application to publish and then for it to run on the mobile device. I have no issue with the exporting/publishing time being high and the installation time on the mobile device being quite high. But each time I run the application from the mobile device, it takes some 2 minutes for it to load which is abnormally high, not even high-end 3d FPS games load for that long. Tests are done on a HTC Sensation running Android 4.0 and, subsequently 4.1.
My question is, what can I do to help reduce this initial startup time? I mention again, the app runs smoothly once loaded since it is really not that complex nor does it use a lot of graphics aside the many 80x80 JPG images attached to each class. In early testing, when I had like 20-30 classes only implemented, everything was smooth. When I added all the elements needed for the game after the game's logic was complete, everything was slow to load.
Thank you for any answers/suggestions.
If you want to speed up compile times for an AS3 project in Flash CS5.5, go into the Actionscript 3 settings for your .fla and turn off 'Warnings mode'. Warnings mode has a bit of overhead because it tries to give you helpful warnings when migrating code from AS2 to AS3. If you know what you're doing, you can turn this off and save lots of time.
1) File > Publish Settings.
2) Click the wrench icon next to 'Actionscript 3.0'
3) Uncheck 'Warnings Mode'
This cut doing compile times on a big project for me quite a bit. Another thing that helps is to divide up your assets into smaller swfs/swcs that are just brought in during runtime.
Only a partial answer, I'm not sure how to fix up a slow load time on an Android device. Good luck!
I've spent the last few days trying to remove memory leaks in my game, resulting in many out of memory errors. I'm on the verge of adding a significant amount of graphics, that while not hugely complicated, will add significantly to the processing requirements of my system, and I'm a bit worried about my memory usage, and I was hoping someone might have some tips for me. I don't want to go below Android 2.1, so please tailor any answers to that end.
First of all, my game consists of:
2 activities, 13 XML files (Some relating to a small part of a layout, some dialogs, and 2 directly related to activities.
A number of drawables, made in Adobe Illustrator and converted to PNG. These are probably large, but not unusually large, and for the most part, only small amounts of them are in memory at any given time.
Quite a few dialogs.
Targeted towards Android 1.6 and above.
I used the newest Admob, and as a result, I have to build against 3.2.
My default heap size for my emulators is around 24 MB.
A few sample images from my game:
What I have learned:
Despite my total app size being only around 500K, I somehow am taking up 24 Megs, as calculated by adb shell procrank.
I have done considerable optimization, but am not seeing large increases in memory.
Using tools to find what is in the Heap typically only show around 7 MB avaliable, with around 3 MB being used. Sometimes, when opening new dialogs and the like, I see an increase, but I can't say that I see it being all that large...
MAT shows that none of my classes are using an unusually large amount of memory.
So, given all of this, my questions.
Is 24 Mb an actual requirement to develop to (1.6+ android)?
Assuming it is, how can I both allow for nicer graphics for systems which can handle it, but not crash and burn for older systems?
What are some common gotchas that I can use to improve my memory usage?
Without seeing your actual code, I can't say if the following will be relevant to you or not. However, it is worth a shot.
If you are not already doing so, you can consider using something called an LruCache. http://developer.android.com/reference/android/util/LruCache.html
Using this tool, you can determine at what point your cached objects (such as Bitmaps) will become eligible for garbage collection. So, if you want to set it at 4mb (for example) the OS will deal with it should it try to grow beyond it. (See docs for implementation details and a good example).
The only downside is that that little gem only came along with 3.2, so you would have to make that your min SDK in the AndroidManifest, or do a check programatically at run time for the api level to determine if you can use it. Pre 3.2 I would say you need to call recycle() on any Bitmaps you are using, but if you have optimized already I would think the chances are good you are already doing this.
This is a nice little snippet about the difference between the heap and native memory. http://code-gotcha.blogspot.com/2011/09/android-bitmap-heap.html It may (depending on what you are doing) help you to understand why you are not seeing the drop in memory you are expecting.
And finally this post from SO should help when dealing with heap size as well:
Detect application heap size in Android
Hope that helps.
I'm currently building an Android project that I believe will use quite a lot of RAM, much more than the default max heap size set by devices.
The app will be the only one that runs on our Android machines (they're single-purpose), so I'm not worried about slowing down other processes. I want all the resources possible to go to this one program.
I know that I can use
android:largeHeap="true"
to give myself more room. However, in another post, a commenter suggested that this setting does not override the machine-specific max heap size. Is this true? And if so, is there another way to exceed this limit?
As an aside, I saw some posts that show how to do this natively. Unfortunately, I'm a mere Java programmer and so I have to work within the constraints of Dalvik.
This option is only for Honeycomp tablets ATM.For API levels below Honeycomp the only thing you can do is increase the heap size of all applications (Rooted phone) I haven't actually used is but check this video from Google IO at 06:00. It said that expands the heap size. So probably he is correct and not the commenter you mentioned :D
Hi all
I'm having an problem with my JNI library.
The execution time of the same code changes from one phone to the other.
I thought it was just because we were testing on an old phone but recently I run on htc legend and all the jni code was slow...
I run the profiler and its really a night and day difference:
on some phone the jni functions take 15% to 20% as on the other phones it takes 40% and 50% for the same conditions...
anybody has an explanantion?
If one of the phones use JIT (Just In Time) Compiler added in Foryo (2.2) than that one should be much faster then your older ones. Are you testing it using the same android version?
Apart from that Some devices are better in float-point math than others. Devices which does not implement an FPU will emulutae float point operations. Here you can find a nice blog post about it: http://www.badlogicgames.com/wordpress/?p=71.
There are planty of sources on how to implement a float point system using fixed point arithmetics: http://en.wikipedia.org/wiki/Fixed-point_arithmetic
Processors are certainly not created equal; they have different feeds, speeds, caching and such. The obvious explanation is that is is the processor.
Additionally system-wide things may impact processing - if you are, say, processing an image taken by the camera using JNI, the size of the image may be device-specific.
Additionally you have to check you are measuring thread-time and wall-clock time; if look at timings relative to the parts of the code that are Java, you might be seeing a relative speed-up in the Java (e.g. JIT in Android 2.2) and not a slow-down in the JNI.