When I run gradle task "assembleDebug" for just getting a debug release I put on my phone it also generates another apk: MyApp-debug-unaligned.apk.
I think I understand what "alignment" of a zip means. That it has optimized placement of file boundaries for easy unzipping (correct me if I'm wrong). It's just an optimization and really doesn't have much to do with Android specifically.
So, since Android keeps all apps as apks and only seems to unzip them at run time, it would benefit to only install the aligned, optimized apks. It also takes a seemingly trivial amount of time to zip-align the package, but maybe that's just due to the size of my particular apps.
When would an unaligned zip be beneficial over it's aligned alternative? Or is it just because you have to have an unaligned version to align and the process doesn't clean up the unaligned file after it's done?
You would Never use an unaligned APK.
It's an intermediate product that isn't cleaned up. In my opinion it should be.
How It works:
What aligning does is it puts images and other large bits of uncompressed data on a 4 byte boundary. This increases the file size but causes them to belong to a certain page. It avoids having to pick up multiple pages from the APK for a single image (that is it minimizes the number of pages picked up). Since the image begins on a 4 byte boundary, there is a higher chance we will not pick up junk data, that is related to other processes.
This in the end allows me to waste less RAM and run faster, by picking up less pages. A trivial but good optimization
About the time it takes, it is relatively trivial, so it is worth it. Obviously, the more uncompressed data you have the more time it takes but it never is very significant. IMHO the compiler should throw away the unaligned file but I guess someone wanted to keep it.
Resources:
Announcement of ZipAlign
http://android-developers.blogspot.com/2009/09/zipalign-easy-optimization.html
Current ZipAlign Docs
http://developer.android.com/tools/help/zipalign.html
About Data Structure Alignment (read about padding)
https://en.wikipedia.org/wiki/Data_structure_alignment
Related
I'm trying to get the Unity mobile Android APK build size to below 150mb, but it's currently at 170mb. I'm reading through many online docs, but can't find anything that so far reduced my build size. (For reference, I'm creating a "Virtual OS" where many virtual apps are bundled into one, and can be experienced in many different environments, so that increases size.)
My main question is, how can I find the biggest file size "offenders" in my project? Unity's doc tells me to look into the Editor Log's Build Report list, but the files mentioned in the top there (as "uncompressed", e.g. my 20k something PNG becomes a 1+mb file in that list), mainly textures, do not actually help when I next time remove them in another test build. Neither does it relevantly help when I change the Android texture setting to something more highly compressed (e.g. 1024 max Mitchell, which I had for most of my files anyway).
I've tried both APK building, as well as ABB, but both results are quite big. (Switching the API Compatibility Level from .NET 4x to 2 doesn't help either.) I'm compiling to 64bit architecture.
Edit: A first big improvement became removing an (unneeded for Android) Oculus directory (and accompanying Package Manager packages). But this wasn't shown in any charts.
Thanks for any pointers!
I created a new project in Android Studio and nothing more (by that I mean having a main activity which does nothing). But when I checked the size of a project folder on my disc I saw it tooks over 40MB! I looked into the project file's content and I saw there folders for which I have questions about:
1) What is the purpose of folder (and it's content) MyProgram/build/generated? Is there a possibility to not create it? (I would save 30MB on my disc by deleting it.)
2) I presume that I shouldn't delete MyProgram/app/build/intermediates so I'm wondering if it'll grow with development of MyProgram? And if the answer is "yes" then how much the size will change? (It tooks almost 10MB now and I'm afraid what will happen when I do something more in my code.)
What is the purpose of folder (and it's content) MyProgram/build/generated?
For a module (e.g., app/) build/generated/ contains Java source code and other files that are generated as part of the build process.
If you are referring to the build/generated/ that appears off of the project root directory, that contains... a JAR. This is an odd place for the build tools to put this particular type of file.
Is there a possibility to not create it?
I don't think so. However, its contents will not go into your APK file. If your development machine is so short on disk space that a 30MB file makes a difference, you will have a very difficult time doing Android development.
I'm wondering if it'll grow with development of MyProgram?
Most likely.
how much the size will change?
That will vary by the size of your app (your code, third-party libraries that you add, etc.) and changes to the build tools over time. It is impossible to tell you exactly how large it will get.
The size from the basic "Hello world" is the minium, doesnt matter if the size is 30 mb or more, is just about the development code, when you generate de APK to share and install your app the basic "Hello world" the size is 2.5 - 3.5 mb. depends from the version of android studio are you using actually, the last version form android studio add somethings.
How i say the real size from you apk is the important, for example if you create the drawables resources for the diferents densities when you install the app just keep 1 density resources, an application size average 7 - 10 mb. A simple app is weird is the size exceeds this numbers.
1) build/ directory and build/intermediates/ is output of the build process,contains Java source code, do not delete.
2) repeat the 1) answer, do not delete.
The Android docs say:
Finally, if the application is being signed in release mode, you must
align the .apk with the zipalign tool. Aligning the final .apk
decreases memory usage when the application is -running on a device.
Does this mean memory usage as in "hard drive space" or memory usage as in "ram" while the process is running?
see: http://developer.android.com/sdk/installing/studio-build.html#detailed-build
It can help to reduce the RAM footprint.
Uncompressed assets can be memory-mapped directly from the APK file, which allows them to occupy "clean" pages rather than "dirty" pages, and have each page loaded only when needed. The advantage of "clean" pages is that they can be evicted and reloaded from the source, whereas "dirty" pages cannot. (For more details, see this answer.)
Compressed assets must be uncompressed before they are used, so they are generally uncompressed fully when first accessed, and occupy "dirty" pages.
The alignment is useful for certain types of files that are expected to be aligned in memory. During early Android development, PNG files were mapped directly, but the PNG library was reading data 32 bits at a time. The emulator was configured to signal a bus error on unaligned 32-bit accesses, so the app crashed. To avoid this issue, zipalign was created to adjust the archive to ensure that the file contents have 32-bit alignment, and the asset manager was updated to only use direct mapping for aligned files.
zipalign has no real impact on disk space. It makes the file 0-3 bytes larger for each uncompressed asset in the APK.
Coming back to the question in the subject: depending on the app's assets and how they're used, running zipalign might reduce the app's chance of being killed. However, there's no reason you can't run zipalign on a debug release. It just adds a bit of padding to the zip file structure.
So, I have a lot of strings (I reckon more than 100, easily.)...
I have 6-7 XML files across which these strings are spread out.
Now during development, it was obviously easier to put some similar strings into one file for convenience.
But now that I'm going to put my app on the market, I want it to be as efficient and fast as possible, even if by mere milliseconds.
Here's what I did :
I just made a copy of my project, exactly same , except I just made another XML file, copy-pasted all of the other files strings , and deleted all the other files.
Now I got 1 XML file.
Problem is My development device is new, and has 1GHz CPU...So I didn't really notice a difference, I want to know whether having just one XML file would be better for low end (and also high end) devices...
To be honest, this falls into the category of problem where readability would be more important than performance. The performance difference between reading 6-7 files or just 1 would be barely anything, definitely nothing noticeable to the user.
I'd go with whichever makes your code cleanest as the readability will be worth more in the long run than saving 1 nanosecond of performance if it means losing hours of dev when you revisit it an it's just a mess of xml.
I'm creating an app with 3 different languages. Every language contains a separate audio file (8 mb each).
Is it possible to split/export the project to 3 different .apk files prior to release on Market? I really do not want to put everything in one .apk due to the 24+ mb file size.
I can see a few options...
Manually build each one, release them as separate products in the Market in each language, e.g. "MyApp English", "MyApp Francais" etc. You could limit which countries see each one, to reduce confusion.
Same as above, but use Ant to automate the Android build process, so you can have one project for the app, but easily build a version in any language. Ant is quite involved, but I'd that in about a day you could learn enough to get an Ant build script running for your project. Android has built-in command line tools to help, so it'll create an initial Ant script for you (look at the "android" command line tool).
Create a single app, and when it starts, ask the user to confirm the language they want, and then start the download. Ideally you'd download a little bit initially to allow the app to work, and download the rest in the background so they don't have to wait. 8MB is quite a lot of data, so beware people will data expensive data plans so I think it is polite to always ask their permission for the download.
If it were me I'd probably lean towards the last option as it's simpler to build one app, and with sucha big download, the user needs to be in control of the process. Bear in mind many people wouldn't download an 8MB app if they knew beforehand it is that big.