Documentation
Documentation states it clearly
zipalign is an archive alignment tool that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.
This tool should always be used to align your .apk file before distributing it to end-users. The Android build tools can handle this for you. When using Eclipse with the ADT plugin, the Export Wizard will automatically zipalign your .apk after it signs it with your private key . The build scripts used when compiling your application with Ant will also zipalign your .apk, as long as you have provided the path to your keystore and the key alias in your project ant.properties file, so that the build tools can sign the package first.
zipalign is an archive alignment tool that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.
This tool should always be used to align your .apk file before distributing it to end-users. The Android build tools can handle this for you. When using Eclipse with the ADT plugin, the Export Wizard will automatically zipalign your .apk after it signs it with your private key . The build scripts used when compiling your application with Ant will also zipalign your .apk, as long as you have provided the path to your keystore and the key alias in your project ant.properties file, so that the build tools can sign the package first.
Cautious Note: zipalign must only be performed after the .apk file has been signed with your private key. If you perform zipalign before signing, then the signing procedure will undo the alignment. Also, do not make alterations to the aligned package. Alterations to the archive, such as renaming or deleting entries, will potentially disrupt the alignment of the modified entry and all later entries. And any files added to an "aligned" archive will not be aligned.
Command Syntax / Usage
To align your apk file (HelloWorld.apk in my case) we can use following comment -
zipalign -f -v 4 HelloWorld.apk HelloWorldOut.apk
To conform that the alignment is done we can use
zipalign -c -v 4 HelloWorldOut.apk
General syntax is
zipalign [-f] [-v] <alignment> infile.apk outfile.apk
zipalign -c -v <alignment> existing.apk
The <alignment> is an integer that defines the byte-alignment boundaries. This must always be 4 (which provides 32-bit alignment) or else it effectively does nothing.
Flags:
-f : overwrite existing outfile.zip
-v : verbose output
-c : confirm the alignment of the given file
Note : In my case if you had see the previous post on exporting the apk from Eclipse by signing it then the apk exported is already aligned. Quoting from documentation "When using Eclipse with the ADT plugin, the Export Wizard will automatically zipalign your .apk after it signs it with your private key". you can easily verify that by running -
zipalign -c -v 4 HelloWorldOut.apk
zipalign -f -v 4 HelloWorld.apk HelloWorldOut.apk
To conform that the alignment is done we can use
zipalign -c -v 4 HelloWorldOut.apk
General syntax is
zipalign [-f] [-v] <alignment> infile.apk outfile.apk
zipalign -c -v <alignment> existing.apk
The <alignment> is an integer that defines the byte-alignment boundaries. This must always be 4 (which provides 32-bit alignment) or else it effectively does nothing.
Flags:
-f : overwrite existing outfile.zip
-v : verbose output
-c : confirm the alignment of the given file
Note : In my case if you had see the previous post on exporting the apk from Eclipse by signing it then the apk exported is already aligned. Quoting from documentation "When using Eclipse with the ADT plugin, the Export Wizard will automatically zipalign your .apk after it signs it with your private key". you can easily verify that by running -
zipalign -c -v 4 HelloWorldOut.apk
Not able to find zipalign command?
I could not find zipalign.exe file in sdk/tools. I had to copy the file from sdk\build-tools\android-4.4W\zipalign.exe to sdk\tools. I have not tried it but upgrading your SDK Build-tools to version 20 seems to fix this issue. Refer cannot find zip-align when publishing app.
Understanding why memory alignment is so important
Aligned access is faster because the external bus to memory is not a single byte wide - it is typically 4 or 8 bytes wide (or even wider). This means that the CPU doesn't fetch a single byte at a time - it fetches 4 or 8 bytes starting at the requested address. As a consequence of this, the 2 or 3 least significant bits of the memory address are not actually sent by the CPU - the external memory can only be read or written at addresses that are a multiple of the bus width. If you requested a byte at address "9", the CPU would actually ask the memory for the block of bytes beginning at address 8, and load the second one into your register (discarding the others).
This implies that a misaligned access can require two reads from memory: If you ask for 8 bytes beginning at address 9, the CPU must fetch the 8 bytes beginning at address 8 as well as the 8 bytes beginning at address 16, then mask out the bytes you wanted. On the other hand, if you ask for the 8 bytes beginning at address 8, then only a single fetch is needed. Some CPUs will not even perform such a misaligned load - they will simply raise an exception (or even silently load the wrong data!).
Reference - what is mean by “memory is 8 bytes aligned”?
In general cases (bus size) it is 4 bytes (32 bits). So we use 4 as the value in zipalign command. So when we do zipalign on an apk some padding is added so that each data is 4 bytes aligned. In this case data can be accessed directly by memory map and no redundant data needs to be loaded into the memory thereby saving RAM.
This implies that a misaligned access can require two reads from memory: If you ask for 8 bytes beginning at address 9, the CPU must fetch the 8 bytes beginning at address 8 as well as the 8 bytes beginning at address 16, then mask out the bytes you wanted. On the other hand, if you ask for the 8 bytes beginning at address 8, then only a single fetch is needed. Some CPUs will not even perform such a misaligned load - they will simply raise an exception (or even silently load the wrong data!).
Reference - what is mean by “memory is 8 bytes aligned”?
In general cases (bus size) it is 4 bytes (32 bits). So we use 4 as the value in zipalign command. So when we do zipalign on an apk some padding is added so that each data is 4 bytes aligned. In this case data can be accessed directly by memory map and no redundant data needs to be loaded into the memory thereby saving RAM.
No comments:
Post a Comment