在我当前的项目中，我使用了多个 .so 文件。它们位于 armeabi 和 armeabi-v7a 文件夹中。不幸的是，其中一个 .so 文件是 6MB，我需要减小文件大小。我不想使用胖 APK 文件，而只想使用 armeabi 文件并删除 armeabi-v7a 文件夹。
根据 NDK 文档，armeabi-v7a 代码是扩展的 armeabi 代码，可以包含额外的 CPU 指令。这一切都超出了我的专业范围，但我质疑为什么要同时拥有 armeabi-v7a 和 armeabi 代码。两者都必须有充分的理由，对吗？
在我的测试设备上，这一切似乎都很好。这些具有ARM v7 CPU。假设现在一切正常是否安全？
Depends on what your native code does, but v7a has support for hardware floating point operations, which makes a huge difference. armeabi will work fine on all devices, but will be a lot slower, and won't take advantage of newer devices' CPU capabilities. Do take some benchmarks for your particular application, but removing the armeabi-v7a binaries is generally not a good idea. If you need to reduce size, you might want to have two separate apks for older (armeabi) and newer (armeabi-v7a) devices.
EABI = 嵌入式应用程序二进制接口。可执行文件必须符合这些规范才能在特定的执行环境中执行。它还指定了用于 ARM 架构的工具链之间的互操作所需的编译和链接的各个方面。在这种情况下，当我们谈论armeabi时，我们谈论的是 ARM 架构和 GNU/Linux 操作系统。Android 遵循 little-endian ARM GNU/Linux ABI。
armeabi 应用程序将在 ARMv5（例如 ARM9）和 ARMv6（例如 ARM11）上运行。如果您使用适当的 GCC 选项（如-mfpu=vfpv3 -mfloat-abi=softfp）构建应用程序，则可以使用浮点硬件，它告诉编译器为 VFP 硬件生成浮点指令并启用软浮点调用约定。armeabi 不支持硬浮点调用约定（这意味着 FP 寄存器不用于包含函数的参数），但仍然支持硬件中的 FP 操作。
armeabi-v7a 应用程序将在 Cortex A# 设备上运行，例如 Cortex A8、A9 和 A15。它支持多核处理器并支持-mfloat-abi=hard。因此，如果您使用-mfloat-abi=hard构建应用程序，您的许多函数调用会更快。
我不想使用胖 APK 文件，而只想使用 armeabi 文件并删除 armeabi-v7a 文件夹。
相反是一个更好的策略。如果您必须minSdkVersion14 并将您的 apk 上传到 Play 商店，您会注意到无论您是否支持，您都将支持相同数量的设备armeabi。因此，没有任何搭载 Android 4 或更高版本的设备可以从中受益armeabi。
这可能是 Android NDK 甚至不再支持armeabir17b 修订版的原因。[来源]