armeabi:針對普通的或舊的arm v5 cpu
armeabi-v7a:針對有浮點運算或高階擴充套件功能的arm v7 cpu(32位ARM裝置)
arm64-v8a:64位ARM裝置
X86: 多為模擬器
向下相容。
arm64-v8a -> armeabi-v7a -> armeabi

以下搬運

這三者都表示的是CPU型別，早期的Android系統幾乎只支援ARMv5的CPU架構，但是現在已經有7種了。ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)，每一種都關聯著一個相應的ABI（應用程式二進位制介面（ApplicationBinary Interface）定義了二進位制檔案（尤其是.so檔案）如何執行在相應的系統平臺上，從使用的指令集，記憶體對齊到可用的系統函式庫）。android現在的主流CPU是armeabi-v7a。armeabi-v7a是針對有浮點運算或高階擴充套件功能的ARMv7CPU。

2.Android裝置如何載入.so檔案：

當一個應用安裝在裝置上，只有該裝置支援的CPU架構對應的.so檔案會被安裝。不同CPU架構的Android手機載入時會在libs下找自己對應的目錄，從對應的目錄下尋找需要的.so檔案；如果沒有對應的目錄，就會去armeabi下去尋找，如果已經有對應的目錄，但是如果沒有找到對應的.so檔案，也不會去armeabi下去尋找了。

以x86裝置為例，x86裝置會在專案中的 libs資料夾尋找是否含有x86資料夾，如果含有x86資料夾，則預設為該專案有x86對應的so可執行檔案，只有x86資料夾而資料夾下沒有so，程式執行也是會出現findlibrary returned null的錯誤的；如果工程本身不含有x86資料夾，則會尋找armeabi或者armeabi-v7a資料夾，相容執行。以armeabi-v7a裝置為例，該Android裝置當然優先尋找libs目錄下的armeabi-v7a資料夾，同樣，如果只有armeabi-v7a資料夾而沒有 so也是會報錯的；如果找不到armeabi-v7a資料夾，則尋找armeabi資料夾，相容執行該資料夾下的so，但是不能相容執行x86的so。所以專案中如果只含有x86的so，在armeabi和armeabi-v7a也是無法執行的。以上就是不同CPU架構執行時載入so的策略。

3.適配不同的平臺

目前主流的Android裝置是armeabi-v7a架構的，然後就是x86和armeabi了。如果同時包含了 armeabi，armeabi-v7a和x86，所有裝置都可以執行，程式在執行的時候去載入不同平臺對應的so，這是較為完美的一種解決方案，但是同時也會導致包變大。

armeabi-v7a是可以相容armeabi的，而v7a的CPU支援硬體浮點運算，目前絕大對數裝置已經是armeabi-v7a了，所以為了效能上的更優，就不要為了相容放到armeabi下了。x86也是可以相容armeabi平臺執行的，另外需要指出的是，打出包的x86的so，總會比armeabi平臺的體積更小，對於效能有潔癖的童鞋們，還是建議在打包so的時候支援x86。

4.第三方平臺的.so庫怎麼處理

關於.so檔案之前有一個坑，svn會把提交的so檔案過濾掉，在接第三方SDK的時候通過SVN更新了文件，但是沒有注意到少了幾個so檔案，浪費了一天的時間去找原因，SVN如何提交so檔案（http://blog.csdn.NET/wds1181977/article/details/40373373）。第三方的類庫只提供了armeabi下的.so檔案，我們專案裡適配了armeabi-v7a和x86，如果不在對應的檔案下放對應的.so檔案，就可能導致某些Android裝置會出一些問題，我們可以複製armeabi下得.so檔案到不同的資料夾下。如果第三方提供了不同平臺的.so檔案，則複製不同平臺的.so檔案到專案中對應的資料夾下即可。