通过重新压缩其内容来减小 APK 的大小 [英] Reducing APK size by re-zipping its content

问题描述

我有一个非常大的 apk 文件，我正在尝试减小它的大小.已经使用了所有常用技术，例如 Proguard 和图像压缩.尽管如此，apk 还是相当大 - 大约 25mb.

I have a pretty large apk file, and I'm trying to reduce its size. Already used all the common techniques, such as Proguard and image compression. Still, the apk is quite large - about 25mb.

维基百科说:

APK 文件是一种存档文件，特别是 zip 格式基于 JAR 文件格式的包，以 .apk 作为文件名扩展名.

APK files are a type of archive file, specifically in zip format packages based on the JAR file format, with .apk as the filename extension.

我最近注意到，如果我解压缩 apk(Android Studio 的工件输出)，使用 7-Zip 重新压缩它并对其进行签名，那么大小会神奇地减少 2.5mb(到 ~22.5mb).我可以将它上传到 Play，安装并运行它而不会出现问题.

I've recently noticed that if I'll unzip the apk (Android Studio's artifact output), re-zip it using 7-Zip and sign it, then the size magically decreases by 2.5mb (to ~22.5mb). I'm able to upload it to Play, install and run it without an issue.

这是我的问题:

• 在解压和解压过程中是否有任何数据被擦除?重新压缩过程?
• 如果没有，为什么 aapt(Android Studio 使用的)打包文件以如此低效的方式?
• 如果是，哪些数据正在被擦除(请在我可以阅读更多相关信息)?如果出现什么问题我会用这个方法吗?

谢谢！

编辑 [5/13/2015]:

压缩 APK 内容对我来说效果很好.但是，我必须谨慎对待原始资源(通常放在 res/raw 下).例如，调用 Resources#openRawResourceFd作为参数的压缩资源将以以下异常结束:

Compressing the APK contents worked well for me. However, I had to be cautious with raw resources (typically placed under res/raw). For example, invoking Resources#openRawResourceFd with a compressed resource as parameter will end with the following exception:

java.io.FileNotFoundException: 这个文件不能作为文件打开描述符；它可能被压缩了

java.io.FileNotFoundException: This file can not be opened as a file descriptor; it is probably compressed

因此，请记住将原始资源从压缩中排除.

Therefore, remember to exclude raw resources from compression.

推荐答案

我可以将它上传到 Play，安装和运行它没有问题.

I'm able to upload it to Play, install and run it without an issue.

仅在您尝试过的设备上.例如，我怀疑您没有尝试 API 级别 1 设备.

Only on the devices that you tried. I suspect, for example, that you did not try an API Level 1 device.

在解压和解压过程中是否有任何数据被擦除?重新压缩过程?

Is there any data that wiped during unzip & rezip process?

我们无法回答这个问题.唯一可以回答这个问题的人就是您，因为您是执行特定解压缩和重新压缩过程"的人.您应该能够分析您的两个 ZIP 文件并查看不同之处，例如某些文件类型的压缩率更高、由于您运行重新压缩过程"的方式而丢失的文件等.

We have no way of answering that question. The only person who can answer that question is you, as you are the one who did your specific "unzip & rezip process". You should be able to analyze your two ZIP files and see where the differences are, such as higher compression ratios on certain file types, files that got lost by the way you ran your "rezip process", etc.

一般来说，唯一应该丢失的是任何 zipalign-ing，如果您没有自己重新应用.

In general, the only thing that should be lost would be any zipalign-ing, if you did not reapply that yourself.

如果不是，为什么 aapt(Android Studio 使用的)以如此低效的方式打包文件?

If no, why aapt (the one that Android Studio uses) packages files in so inefficient manner?

尺寸不是唯一的考虑因素.访问速度是另一回事，因为许多内容(例如资源、资产)都保存在 APK 文件中，并根据需要随时读取.解压逻辑的内存消耗是另一个考虑因素.

Size is not the only consideration. Speed of access is another, as many things (e.g., resources, assets) are kept in the APK file and read out of there on the fly as needed. Memory consumption for the decompression logic is yet another consideration.

Android 设备，尤其是早期设备，有很多限制，磁盘空间只是其中之一.尽管随着硬件的进步，其中一些限制已经放宽，但构建工具致力于向后兼容性——例如，您现在应该能够编写可以在 API 级别 1 设备上运行的应用程序.这对工具造成了限制，使其无法随时间变化.

Android devices, particularly early ones, have many constraints, disk space being but one of them. Even though some of these constraints have been relaxed as hardware has advanced, the build tools are dedicated to backwards compatibility -- you should be able to write an app today that can run on an API Level 1 device, for example. That puts constraints on the tools in terms of how they can change over time.

如果我使用这种方法会出现什么问题?

What could go wrong if I'll use this method?

您的应用可能无法在 Android 设备上运行，这些设备的运行时设置对 APK ZIP 压缩算法的使用做出了某些假设.理想情况下，您的应用程序在任何地方都能正常运行.至少，您需要在您支持的每个 API 级别上测试您的应用 - 较旧的 API 级别可能更有可能偷工减料"并假设您的方法将无效.

Your app may not work on Android devices, where their runtimes are set up making certain assumptions about the APK ZIP compression algorithms use. Ideally, your app will run fine everywhere. At minimum, you would want to test your app on every API level that you support -- older API levels may be somewhat more likely to "cut corners" and make assumptions that your approach will invalidate.

这篇关于通过重新压缩其内容来减小 APK 的大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！