My current game project is getting large enough that when I deploy for testing I'm waiting a few minutes to actually get this to my phone. Sometimes I have other things to work on, but sometimes I have to sit and wait. This is unfortunately slowing down the development process.
I'm already sure the biggest factor in this is package size. My package is now just under 18 Megs, but I know there are apps out there with much larger packages.
Is there any tricks, phone settings, or eclipse settings that might speed deployment other than reducing the package size?
Regards.
While this doesn't quite meet your criteria of 'other than reducing the package size', my guess is that most of that filesize probably comes from textures and audio resources.
Instead of packing them all in the APK under the res/ folder, I might recommend temporarily copying the resources to the device's filesystem, and then load them from there instead of your resources. Then when you repeatedly upload your APK you don't have to keep transferring the same resources over and over.
If you load your resources from a mostly centralized location it should be just a couple lines of code change to change from loading from res to loading from a file. You can repackage them as resources again when your game is closer to release and you don't have to do so many iterations.
what you want is an android emulator. you can install the emulator as a Eclipse IDE plugin.
http://developer.android.com/tools/sdk/eclipse-adt.html
#"Unfortunately my system is so slow (and old) that the emulator runs like molasses in comparison to running the app on the actual device."
http://dev.blogs.nuxeo.com/2011/10/speeding-up-the-android-emulator.html
Related
My generated APK is around 6MB.
I am using ProGuard.
However, after installed into phone device, it takes up space around 60MB.
I would like to know, which dependencies cause huge installed space (60MB)
I look at How to check the size of dependencies in an android app? and https://medium.com/google-developers/making-the-most-of-the-apk-analyzer-c066cb871ea2
I use "Build → Analyze APK".
But, it can let me know where does 6MB (size of APK) come from. But, it doesn't let me know, why it does take up to 60MB in user phone.
Google tooks most of the method counts.
But, I don't think Java code with ~40,000 methods and reference ~50,000 methods, can consume up to 60MB space.
I had checked my assets folder and res folders. Their size is 2MB and 3MB respectively. Hence, I have no idea what is the major contribution to 60MB app installed size.
Is there any good way, to inspect and reduce app installed size?
The other day I was inspecting "App Info" from an app I'm developing and to my surprise I detected an enormous amount of Mb were being used as "cache" (the app didn't download any content yet, it was just a mockup). At first I thought I could be some heavy libraries I'd added (fresco..) so I decided to create a blank project an try to figure out what was the problem.
I've tried 2 scenarios: pre-lollipop and lollipop. With this I found out there is some difference with the way they handle "data" but the overall apk size was the same. Though here, in pre-lollipop (4.4.4) there was almost no "cache"(FIRST IMAGE) in lollipop... well 8 mb of "cache".
All of this wasn't enough since the other apps I'd developed in lollipop and above had way less "cache". I started thinking what could be the difference and finally I think I've found somthing, gradle version!
The project build with gradle 1.5 has smaller apk size and almost no "cache" (both lollipop and pre-lollipop)
Is there something I'm missing? Why the sudden increase in "cache" size.
Is there any way to avoid this while using the latest gradle version?
Instant Run ships incremental chunks of your app, reflecting changes that you made to the code. That stuff still needs to be loadable by your app, so they apparently are putting that information in some location that gets counted as "cache" (getCacheDir()?).
Similarly, your app's main APK itself will be a bit larger, as it has to contain a chunk of code that knows how to load these dynamically-changing bits.
If you need to measure these values, either disable Instant Run, or run a release build (which automatically is non-Instant Run).
When I install my app on my main/new phone, the installed size is around 18.5MB
and when I install my app on an old Samsung Galaxy Ace (Mk1), for some reason, it installs with pretty much the same size, as you see here:
It runs perfectly on my main phone, but obviously, the old Galaxy Ace really struggles with it.
Now, I download a random game from the Play Store and with that one you can see the results here:
Much better, it takes up less space on the less capable phone than it does on the more capable phone.
However, my question is, where can I start to try to figure out why my app doesn't exhibit this desired behaviour?
Information about my project
I have provided 4 sets of Graphics within my project and they are:
Graphics
XHDPI: Total of 3.73MB
HDPI: Total of 2.87MB
MDPI: Total of 1.33MB
LDPI: Total of 1.03MB
Sound
OGG Sound Files: 202KB
MP3 Soundtrack: 5.6MB
The (Unsigned and signed) APK file is about 16.02MB
Apart from that there is a classes.dex file within the APK which is about 3.5MB.
In Eclipse, I link BaseGameUtils and Google-play-service-lib jar files.
I know that my game is slightly more resource hungry than the other game I downloaded - but that isn't the point of this question. I need to make sure that the size of the installed app is smaller on lesser capable phones than it is 'better' ones but as you can see, mine is exactly the same.
Any help would be appreciated.
Edit
Additional information if it helps:
The Samsung Galaxy Ace is running Android 2.3.4 Gingerbread
The other phone is running Android 4.4.2 Kit Kat
the answer is the picture.. you see android apps can specify locations where apps are supposed to be installed, whether internal or external- you can do that in your android manifest file
android:installLocation="auto"
Looking at your app you from the settings screenshot you have not specified that element in your manifest hence the "move_to_sdCard button" is inactive. Your apps installs in internal memory
coming to the other app, looking at the screenshot you will see that the "move_to_phone button" is active because they specified that feature hence since there wasn't enough space on your device it automatically installed your app on the internal-external memory or strictly external memory.. But when that feature is set not all resources or files are installed on the internal-external memory they are shared, so the size gets trimmed in the process hence that ouput.
Speaking about the lag of your app, you need to digg into your codes pretty much. also newer apis contain functions the old ones do not have, hence you need to re-evaluate the kinds of codes you choose..
Hope i am lucid enough
Probably the "Other App" is using the Multiple APK technique to publish the App on the Play Store. With this feature you can build and deploy several apk(s) each targeting a specific device density screen. In this way you can reduce the apk dimension since each apk will have only the resources for his target and automatically the Play Store will deliver the correct one.
I'm creating a version of my game for app stores such as Amazon, which don't have the APK expansion mechanism - so I put all the files in my "assets" folder.
However, my 300+ MB APK seems to create a lot of problems:
When I try to install it with ADB on either the emulator or Samsung Galaxy S2, about 75% of the times it fails. From Samsung, I get INSTALL_FAILED_MEDIA_UNAVAILABLE (although it's not mounted, and there's plenty of free space), and from the emulator, I get just 'null'.
Again, this happens about 75% of the time, completely random.
My game locks up at a certain point in native code. There's absolutely nothing there that can lock up or has anything to do with the OS - just plain C++ logic.
I verified that this issue happens ONLY when I push large assets into the APK. If I remove the assets (completely unused, just pushing large files there), the issue doesn't happen.
Just to clarify - in order to test that, I manually pushed the game files into the device, so it has nothing to do with the asset extraction.
This is very weird, and I'm starting to consider getting my own expansion file server.
Any ideas?
UPDATE:
Found the solution to #2. The code base I was using was doing something hackish in the background with the APK assets, that's why it locked up. I removed that code, so #2 is irrelevant.
The only issue now is difficulty installing large APK files.
How about making two seperate apps for the game?
One for the game code and the other for just the large assets. Pardon my intrusion.
I found that the installation problem happens only with ADB.
By manually copying a big APK to the device external storage, and then installing using a file manager app, there is never a problem.
Regarding the 2nd problem - as updated on the original question - it was a specific problem with the app (someone wrote shitty code that manipulates all the APK assets).
When dimensions of a project start being considerable the plugin of Android for Eclipse starts not working properly and also very slow, when it comes to XML modifications, refractoring the code from the XML files becomes tedious. Also sometimes it doesnt recognize strings resources. And I have to clean the project(which sometimes is like the solution for windows of restart the computer...)
Do you know about solutions to improve this behaviour? As I think it will be really helpful.
There are two things impacting eclipse's performance: I/O and memory....
I/O: Buy Good SSD disk. Full stop.
Memory:
There are few ways to improve performance:
1) include the following lines in eclipse.ini (with at least these values):
-vmargs
-Xms160m
-Xmx2048m
(that is if you have enough memory)
2) Use 32-bit eclipse on 64-bit system
That might be surprising, and it is only valid if you have not very big amount of memory (few gigs). 32-bit eclipse take about 50-60% of memory comparing to 64-bit one - the thing is that in 64-bit java every object/field etc. take 2x much memory as in 32-bit java. Until java supports (so far experimental) compressed references taking less space, it might well be that memory limits will be hit with 64-bit version where 320bit should work just fine.
Eclipse can run slow if you have too many projects open, especially if the projects are very large. I remember when i had like 3 sample projects open at the same time and eclipse went from running on 200 meg to running at 500 meg, it was really slow untill i closed all the projects i wasnt using, it also depends which type of computer you have, if your computer doesnt have very much ram then eclipse will run slow. My computer cleans projects really slow when i have a bunch of projects open.
Please make sure that eclipse.ini doesn't contains following line:
CompileThreshold=5
I have taken this line from some superfast Eclipse jvm config, but that option just makes compilation terribly slow.