android armeabi armeabi-v7a(v7a和x86)

了解起因
昨天师傅问，你知道这俩个是什么么？有什么作用么？(如下图所示)

现在还记得我那一脸蒙比的样子，诺诺的回答不晓得。师傅说这个是为了兼容一些手机，(此处省略滔滔不绝若干。。。)。听的我更加蒙比了，之前只是知道要把.so库扔进去，但是为什么扔，就不懂了，何谈我怎会知道那目录？(PS:还是自己差太多了。。。)好尴尬。。。

查询前期准备
首先按照四个部分来查询，分别如下：
一. lib和libs是否一样？
二. .so库又是什么鬼？
三. .so库又该如何存放？
四. libs下armeabi等的作用是什么？

查询ING

一. lib和libs是否一样？ 
放在lib中的是被reference的，放在libs中的是被include的。 
放在libs中的文件会自动被Eclipse所include。所以不要把API放到libs里去。 
lib的内容是不会被打包到APK中，libs中的内容是会被打包进APK中

二. .so库又是什么鬼？ NDK编译出来的动态链接库。 
一些重要的加密算法或者核心协议一般都用c写然后给java调用。这样可以避免反编译后查看到应用的源码。

三. .so库又该如何存放？ 
放置 .so 文件的正确姿势其实就两句话： 
• 为了减小 apk 体积，只保留 armeabi 和 armeabi-v7a 两个文件夹，并保证这两个文件夹中 .so 数量一致 
• 对只提供 armeabi 版本的第三方 .so，原样复制一份到 armeabi-v7a 文件夹

BUT，处理.so文件时有一条简单却并不知名的重要法则。

你应该尽可能的提供专为每个ABI优化过的.so文件，但要么全部支持，要么都不支持：你不应该混合着使用。你应该为每个ABI目录提供对应的.so文件。

四. libs下armeabi等的作用是什么？
存放.so库，主要针对不同的设备兼容，也可以说是专门针对不同Android手机下CPU架构的兼容。
下面就来扯一下安卓cpu
Android 设备的CPU类型(通常称为”ABIs”)

早期的Android系统几乎只支持ARMv5的CPU架构，你知道现在它支持多少种吗？7种！
Android系统目前支持以下七种不同的CPU架构：ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS64和x86_64 (从2014年起)，每一种都关联着一个相应的ABI。
应用程序二进制接口（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集，内存对齐到可用的系统函数库。在Android 系统上，每一个CPU架构对应一个ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。

如下图所示：

各版本分析如下：
• mips / mips64: 极少用于手机可以忽略
• x86 / x86_64: x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现 对 arm .so 的兼容，再考虑 x86 1% 以下的市场占有率，x86 相关的两个 .so 也是可以忽略的
• armeabi: ARM v5 这是相当老旧的一个版本，缺少对浮点数计算的硬件支持，在需要大量计算时有性能瓶颈
• armeabi-v7a: ARM v7 目前主流版本
• arm64-v8a: 64位支持

所谓的ARMv8架构，就是在MIPS64架构上增加了ARMv7架构中已经拥有的的TrustZone技术、虚拟化技术及NEON advanced SIMD技术等特性，研发成的。

64位ARMv8架构中包含两个执行状态：AArch32（也就是我们常说的ARMv7）和AArch64（ARMv8）。AArch64执行状态针对64位处理技术，引入了一个全新指令集A64（也就是基于收购的MIPS64架构），而AArch32执行状态将支持现有的ARM指令集。所以64位的ARM处理器中同时包含着32位的ARMv7和64位的ARMv8两种架构。因此：

看到这里，你一定明白了，ARM64位处理器和电脑的64位处理器是两个截然不容的概念，他并不是64位就能原生向下兼容32位程序，而是通过64位处理器中集成的32位架构来运行32位程序。说得通俗点，它不是以64位形态来运行32位程序，却是以32位的形态运行32位程序的。

由于目前新出的64位处理器包含两个架构，而且制程技术没有提升（28nm），同时在手机与平板上，芯片面积有着严格的限定，不能过分增加，这导致64位ARM处理器平均分配到每个架构的晶体管数量锐减，也就是说从64位处理器中的32位架构方面，对于同规格的32位处理器而言，不但没有提高，性能反而是一定规模下降的。但处理器厂家又必须给消费者一个交代，以更好的推广64位，所以厂家就必须在其他方面提升性能，以弥补CPU的晶体管数量减少带来的损失。比如：更换性能更强的GPU、提升内存带宽、多核心虚拟单颗核心提升单核性能、联合跑分软件商修改跑分权重（提升GPU分数，降低CPU分数的权重）等等。这样，扬长避短，最终到达消费者手里，用跑分软件一跑，确实有提升，用户开心，厂家腰包也鼓了。

综上所述，ARM64位处理器从严格意义来说，叫它ARM32+64更加贴切，他相对于ARM32位处理器，有倒退的地方，也有进步的余地，但正因为倒退激起了ARM进取的决心，让它大刀阔斧的向前变革，不得不说也算一种进步。但ARM64在的手机上真的有用吗？我只能说，目前确实没啥用，但今后或许有。（其他地方搜罗的）

真正的64位手机并不止单纯停留在处理器上，如果只因为它的处理器是64位，就称其为64位手机的话，我们可以毫不犹疑的说这可能是虚假宣传，好在联想很聪明，在发布A678t和A805e宣传的时候，只说64位处理器手机。
“64位处理器手机”与“64位手机”是两种天壤之别的概念：只要是处理器包含64架构位的，就可以称“64位处理器手机”，这种手机也许还运行不了64位程序，只是用来抢占市场，和32位手机比起来优势并不明显。

“64位手机”就不同了：它包含着64位处理器、64位标准系统、64位安卓虚拟机、以及64位程序，这才是真正意义上的64位手机！
谷歌官方曾说，安卓很早前就支持64位了，这话不假，从Android4.0到Android4.4，安卓系统都支持64位的硬件，但是这仅仅表示底层驱动支持64位，能运行在64位的硬件之上，仅此而已。然而，上层运行软件的，无论是Dalvik的虚拟机，还是ART虚拟机都是32位的。也就是说，只要你的手机系统是Android4.0—4.4，即便你的处理器是64位，也只能在32位虚拟机下运行32位程序，就算真的64位程序摆在你眼前，也无法安装。

Android L开始才真正支持32位和64位的ART虚拟机，配合上64位处理器，名正言顺的运行64位软件。但是问题又来了，没有软件商 愿意开发64位程序。
ARMv8是一套不错的指令集，它既支持未来的64位程序，也向下兼容现有32位程序。有了ARMv8的支撑，以后的64位手机操作系统，如Android L 64bit都可以简单、高效地支持现有的32位App，你不用担心兼容性问题。

PS:在2011年11月，ARM公司发布了新一代处理器64位架构ARMv8的部分技术细节（也就是我们常说的Cortex-A57A53），代表着未来移动处理器迈入64位行列。我们得明确一点，ARM公司自己本身并没有64位芯片设计技术，他是通过了收购MIPS64处理器架构的部分技术使用权，再结合ARM的一些特性设计出来的。也就是说：MIPS、ARM、X86三大架构中，唯一没有64位技术的ARM，通过收购MIPS的形式得到了64位。

参考资源如下：
1) https://zhidao.baidu.com/question/1367175903363573459.html?skiptype=2
2) https://www.zhihu.com/question/20235319
3) http://www.voidcn.com/blog/u013278099/article/p-4944290.html
4) https://zhuanlan.zhihu.com/p/23102158
5) https://zhuanlan.zhihu.com/p/21359984

1、手机cpu架构。

讲到armeabi就不得不讲手机cpu了。电脑有电脑的cpu，手机也有手机的cpu。cpu有厂商属性，也有架构属性，架构的话自己简单地理解就是它的内部模块的组成结构。

其中arm架构的手机cpu占市场的大部分，这也是今天的重点。但arm架构的发展历史悠久，也有很多不同的版本。

2、前面讲了cpu架构，为下面的讲述做了一个技术背景的铺垫。

我们在开发Android项目的时候，比如使用高德地图导航或者3d地图的时候就会使用到.so库文件，它们保存在armeabi和armeabi-v7a或arm64-v8a等目录下，这有什么作用呢？

其实这是给app运行时读取的几个目录，但会根据手机cpu架构类型只从其中一个文件夹读取，有点类似values和values-21的作用，但是与它们又有点不同。

后者的规则是：如果手机是21以上的会首先在values-21文件里面查找样式等，如果查找不到才去values文件找；如果手机是21以下的就直接在values文件下找。

前者的规则是：根据cpu架构类型去app的libs里面匹配到对应的目录比如armeabi或者armeabi-v7a，然后就加载这个目录下的.so库；

如果在匹配到的目录下没有对应的库也不会去别的目录下加载；

但是armeabi目录可以匹配所有的arm架构的cpu,意思是指所有的arm架构的cpu的安卓手机如果没有找到最优的对应的目录，则会去匹配armeabi目录。

我的推测是arm架构的cpu是向下兼容的，即保留之前版本的功能，而armeabi目录是匹配低版本armv5的，所以高版本的arm架构的cpu可以读取armeabi目录下的.so库文件；查过资料会发现低版本的arm架构cpu支持软浮点运算而高版本的支持硬件浮点运算，这是他们的区别之一。

3、最近在开发高德导航功能，官方文档提示此功能不支持armeabi-v7a，根据以上的讲述：导航功能并没有为armeabi-v7a对应的cpu设计一套.so库文件，所以只能使用armeabi目录下的库文件，所以要删掉armeabi-v7a目录。

armeabi默认选项，
支持基于 ARM* v5TE 的设备
支持软浮点运算（不支持硬件辅助的浮点计算）
支持所有 ARM* 设备

armeabi-v7a
支持基于 ARM* v7 的设备
支持硬件 FPU 指令
支持硬件浮点运算

不同手机由于cpu的不同，使用不同的驱动。
ABI:指应用基于哪种指令集来进行编译，ABI总共有四种，分别是armeabi、armeabi-v7a、mips、x86，它们都是表示cpu的类型。

在我们android APK的根目录有一个 libs文件夹，此文件夹下包含了armeabi 和armeabi-v7a两个文件夹，我们的c代码编译成的本地库（各种.so）就会放在这两个文件夹其中的一个。那armeabi-v7a 与 armeabi有什么区别，都是什么意思呢？

    armeabi和armeabi-v7a是表示cpu的类型，我们知道一般的手机或平板都是用arm的cpu（mips的就悲催的被忽视了），不同的cpu的特性不一样，armeabi就是针对普通的或旧的arm v5 cpu，armeabi-v7a是针对有浮点运算或高级扩展功能的arm v7 cpu。

      在android.mk里可配置以下宏：

TARGET_CPU_API := armeabi

APP_ABI := armeabi

当你编译时出现一些链接动态库的undefine错误，或你的apk运行时出现装载.so动态库错误时，不妨看一下这个cpu类型的配置是否有误。

(1)armeabi和armeabi-v7a 以及x86_罗冲_新浪博客
http://blog.sina.com.cn/s/blog_95c607dd0102uxau.html

 =========================================================================================

现在还有x86的了，其实armeabi 、armeabi-v7a 和x86是编译 NDK 库时，可以使用三种支持的应用二进制接口(ABI)：

1. ‘armeabi’ – 默认选项，将创建以基于 ARM* v5TE 的设备为目标的库。 具有这种目标的浮点运算使用软件浮点运算。 使用此 ABI 创建的二进制代码将可以在所有 ARM* 设备上运行。
2. ‘armeabi-v7a’ – 创建支持基于 ARM* v7 的设备的库，并将使用硬件 FPU 指令。
3. ‘x86’ – 生成的二进制代码可支持包含基于硬件的浮点运算的 IA-32 指令集。

==========================================================================================

什么是 NEON？

NEON* 是一种 ARM* 技术，主要用于多媒体（智能手机和高清电视等）应用。 ARM* 表示其基于 128 位 SIMD 引擎的技术 – ARM* Cortex*（一种串行扩展）—可提供比 ARM* v5 架构至少高 3 倍的性能，以及比 ARM* v6 至少高 2 倍的性能。 如欲了解有关此技术的详细信息，以深入了解 NEON 及其它性能考虑，请访问以下网址： http://www.arm.com/products/processors/technologies/neon.php

此处的关键理念为，各寄存器被“堆积”成一个矢量，其中每一个寄存器均为一个元素，并与其它元素的数据类型相匹配。 在此基础之上，运算在管道内执行，因而这一方法被称作 Packed SIMD。

SSE： 英特尔推出的类似 NEON 的工具

SSE 指面向英特尔架构(IA)的SIMD 流指令扩展。 目前，英特尔® 凌动™ 最高支持 SSSE3（补充 SIMD 流指令扩展 3）。 凌动™ 暂不支持 SSE4.x。后者也是一个 128 位引擎，用于打包浮点数据。 这一执行模式开始于 MMX 技术。SSx 是较新的技术，取代了 MMX。。 如欲了解详细信息，请参阅英特尔《IA-32 和 IA-64 软件开发人员手册》中的“第一卷： 基础架构”部分。网址为： http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html。 目前，SSE 概述部分在 5.5 节。 它提供 SSE、SSE2、SSE3 和 SSSE3 的操作码。注意，数据运算通常会涉及到处理基于精度的打包浮点数值；并且需要在 XMM 寄存器之间，或在这些寄存器与内存之间批量传输数据。 XMM 寄存器主要用于取代 MMX 寄存器。