Android系統so庫解析

為適配眾多的cpu架構，實際就是指令集的區別，在開始從複雜指令集改動到簡易指令集的微軟架構之後，又分出若干陣營，那麼這個地方就不展開了，展開我怕篇幅不太夠啊...

armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64

android系統尋找so庫的順序，先區分架構，再去尋找完美適配的架構資料夾，若果找不到繼續向相容的架構尋找，匹配架構成功後，載入這個架構下所有的so到data資料夾中，如果在data中找不到應用中使用到的so庫，那麼會報異常，so link錯誤等等，不會再到其他架構中去掃瞄。

主abi庫：與系統影響本身機器對應的abi庫

輔助abi庫：與系統也支援的abi對應

而，為實現最佳效能，應該提供主abi庫

x86 ：可以執行在armeabi/armeabi-v7a 主要的abi是x86,輔助abi是armeabi-v7a

mips: 只定義了主abi是mips(但是極少用於手機，可以忽略)

armeabi-v7a ：主 armeabi-v7a ，輔助armeabi

只提供一種架構優點：可以減小包的體積

缺點：只提供一種架構，而忽視其他架構，那麼會影響到效能和相容，同時也將丟失掉專門為64位優化的效能。

從根本上來說，系統只會把他區分架構的資料夾整個複製到data目錄，那麼造成乙個問題就是，每個架構的資料夾下都應該是so庫的全量，如果三方服務**商，只給了乙個armeabi-v7a 的架構，而工程中準備只放乙個armeabi的資料夾來減小包大小，那麼應該將v7a中的so庫拷貝到armeabi中。

同時在執行在androidstudio工程中的build.gradle defaultconfig 中新增：

ndk

在打包中，只包含armeabi的架構。

還是來乙個圖來說明這個東西吧，畢竟沒圖你說個啥啊：

那麼實際中我們的取捨遵從的原則：

1.為減小體積，只保留armeabi與armeabi-v7a，一般只保留乙個

2.若只有乙個架構，那麼其他架構中的so，保留的資料夾下有有全量。