我不确定我是否理解正确。看起来它正在做相反的事情。如果我保持标志android:extractNativeLibs设置为true,应用程序会占用用户空间约70MB(是的 ...),但如果我将此标志设置为false,则安装在设备上的应用程序大小会跳到大约95MB左右。所以我不确定用户是否会欣赏这一点。
我不确定我是否理解正确。看起来它正在做相反的事情。如果我保持标志android:extractNativeLibs设置为true,应用程序会占用用户空间约70MB(是的 ...),但如果我将此标志设置为false,则安装在设备上的应用程序大小会跳到大约95MB左右。所以我不确定用户是否会欣赏这一点。
预计地,我并没有发现两个选项在加载性能上有显著的区别。
extractNativeLibs="false"选项可能适用于以下情况:
例如,对于使用Unity制作的游戏,由于其较大的本地库,这个选项几乎不适用。
Android App Bundle是由Google Play宣布的一种新的分发机制,更多详情请参见官方网站https://developer.android.com/platform/technology/app-bundle/和https://developer.android.com/guide/app-bundle/
它具有显着优势,其中最重要的是150 Mb的最大大小限制。重要提示:这是下载大小,而不是应用程序包本身或生成的APK的大小。(APK由Play生成并在设备上动态交付,更多详情可在官方的Android资源上了解到如何工作)。
构建AAB时,它默认将extractNativeLibs标志设置为"false"。但是,由于Google Play在交付给最终设备的APK上应用压缩,这并不影响下载大小。这意味着该标志仅在Android App Bundles的情况下带来好处 - 安装更快,几乎没有施加向最大大小限制施加压力的额外成本,占用磁盘空间更少。
然而令人困惑的是,当你接近150 MB的限制时如何计算下载大小,因为AAB大小并不代表下载大小。在中有一个特殊的命令来计算它,详情请参阅https://developer.android.com/studio/command-line/bundletool#measure_size或直接上传到Play。如果你的AAB远低于150 MB,那就没必要担心了。
(更新:使用150 MB的应用程序包大小限制,而不是500 MB;显然,在开发人员预览版中提供了500 MB,但现在已经不公开了)。
extractNativeLibs="false"
如果你的 APK 包含多个 ABI,可能会适得其反。假设你正在使用一个每个 ABI 都有 10 MB 大小的库,并且可以压缩到 5 MB。如果你有 3 个 ABI,则结果如下:
extractNativeLibs="true":
APK: 15 MB (3 x 5 MB)
Extracted: 10 MB
Total: 25 MB
extractNativeLibs="false":
APK: 30 MB (3 x 10 MB)
Extracted: 0 MB
Total: 30 MB
截至2019年,缓解此问题的推荐方法是使用Android App Bundle格式。
.aab
捆绑格式,则情况并非如此。 - Gil但是,这需要一些重要的先决条件才能实现,这就是事情变得更加复杂的地方:
更新:以下部分仅适用于Android Studio版本2.1及以下版本。 从Android Studio 2.2 Preview 2和最新版本的构建工具开始,构建过程将自动将本机库未经压缩和页面对齐存储在APK中。
更多信息: 链接
更新:如果您手动签署应用程序,则在何时调用zipalign很重要。
注意:您必须在应用程序构建过程中的两个特定点之一使用zipalign,具体取决于您使用的应用程序签名工具:
来源:zipalign | Android Developers
Android 6+将阻止您安装未对齐的带有未压缩本机库的APK。旧版Android不会关心并始终提取本机库。
android:extractNativeLibs=”false”
能够使总大小更小,但事实上相反 - 它大约增加了~25MB。在Android 7.1.1上进行了测试。 - egoldx