Android中libs目录下armeabi和armeabi-v7a的区别

了解原由
昨天师傅问，你知道这俩个是什么么？有什么做用么？(以下图所示)

 

 

如今还记得我那一脸蒙比的样子，诺诺的回答不晓得。师傅说这个是为了兼容一些手机，(此处省略口若悬河若干。。。)。听的我更加蒙比了，以前只是知道要把.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

 

一、手机cpu架构。

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

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

二、前面讲了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支持软浮点运算而高版本的支持硬件浮点运算，这是他们的区别之一。

三、最近在开发高德导航功能，官方文档提示此功能不支持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、SSE二、SSE3 和 SSSE3 的操做码。注意，数据运算一般会涉及处处理基于精度的打包浮点数值；而且须要在 XMM 寄存器之间，或在这些寄存器与内存之间批量传输数据。 XMM 寄存器主要用于取代 MMX 寄存器。