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 寄存器。