问题描述
我有一个非常大的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(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使用的软件包)打包文件如此低效的方式?
- 如果 是 ，则清除了哪些数据(请在我可以阅读更多有关它的信息吗?如果发生什么可能会出问题我会用这种方法吗?
- Is there any data that wiped during unzip & rezip process?
- If no, why aapt (the one that Android Studio uses) packages filesin so inefficient manner?
- If yes, what data is being wiped (please post some links where Icould read more about it)? What could go wrong ifI'll use this method?
谢谢！
编辑[5/13/2015]:
压缩APK内容对我来说效果很好.但是，我必须谨慎使用原始资源(通常放在res/raw下).例如，使用压缩资源作为参数将以以下异常结尾:
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:
因此，请记住从压缩中排除原始资源.
Therefore, remember to exclude raw resources from compression.
推荐答案
仅在您尝试过的设备上.例如，我怀疑您没有尝试过API Level 1设备.
Only on the devices that you tried. I suspect, for example, that you did not try an API Level 1 device.
我们无法回答这个问题.唯一可以回答该问题的人是您，因为您是执行特定的解压缩和重新压缩过程"的人.您应该能够分析两个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.
通常，如果您自己没有重新应用，那么唯一应该丢失的内容就是压缩对齐.
In general, the only thing that should be lost would be any zipalign-ing, if you did not reapply that yourself.
大小不是唯一的考虑因素.访问速度是另一个原因，因为许多内容(例如资源，资产)都保存在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 Level 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.
您的应用可能无法在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的大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！