为什么要在armeabi代码上使用armeabi-v7a代码？

在我当前的项目中，我使用了多个.so文件。它们位于armeabi和armeabi-v7a文件夹中。不幸的是.so文件之一是6MB，我需要减小文件大小。我不想使用胖的APK文件，而是只使用armeabi文件并删除armeabi-v7a文件夹。

根据NDK文档，armeabi-v7a代码是扩展的armeabi代码，其中可以包含额外的CPU指令。所有这些都超出了我的专业知识，但是我质疑为什么要同时拥有armeabi-v7a和armeabi代码。一定要有一个很好的理由，对吗？

在我的测试设备上，这一切似乎都可以正常工作。这些具有ARM v7 CPU。可以安全地假设现在一切正常吗？

取决于您本机代码的功能，但是v7a支持硬件浮点运算，这有很大的不同。armeabi可以在所有设备上正常工作，但速度会慢很多，并且不会利用较新设备的CPU功能。一定要为您的特定应用程序设置一些基准，但是删除armeabi-v7a二进制文件通常不是一个好主意。如果您需要减小尺寸，则可能希望为旧（armeabi）和较新（armeabi-v7a）设备使用两个单独的apk。

EABI =嵌入式应用程序二进制接口。可执行文件必须遵循的规范才能在特定的执行环境中执行。它还指定了用于ARM体系结构的工具链之间的互操作所需的编译和链接的各个方面。在这种情况下，当我们谈论armeabi时，我们谈论的是ARM体系结构和GNU / Linux OS。Android遵循小端ARM GNU / Linux ABI。

armeabi应用程序将在ARMv5（例如ARM9）和ARMv6（例如ARM11）上运行。如果使用正确的GCC选项（例如-mfpu = vfpv3 -mfloat-abi = softfp）构建应用程序，则可以使用浮点硬件，该选项可告诉编译器为VFP硬件生成浮点指令并启用软浮点调用约定。armeabi不支持强制浮动调用约定（这意味着FP寄存器不用于包含函数的参数），但仍支持HW中的FP操作。

armeabi-v7a应用程序将在Cortex A＃设备（例如Cortex A8，A9和A15）上运行。它支持多核处理器，并且支持-mfloat-abi = hard。因此，如果使用-mfloat-abi = hard构建应用程序，则许多函数调用将更快。

我不想使用胖的APK文件，而是只使用armeabi文件并删除armeabi-v7a文件夹。

相反的是更好的策略。如果您必须minSdkVersion将14个APK上载到Play商店，则无论是否支持，您都会注意到支持相同数量的设备armeabi。因此，完全没有受益于Android 4或更高版本的设备armeabi。

这可能是Android NDK armeabi根据版本r17b 甚至不再支持的原因。[ 来源 ]