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.
