1.so文件
一種CPU架構(gòu) = 一種對應(yīng)的ABI參數(shù) = 一種對應(yīng)類型的SO庫
早期的Android系統(tǒng)幾乎只支持ARM的CPU架構(gòu)，不過現(xiàn)在至少支持以下七種不同的CPU架構(gòu)：ARMv5，ARMv7，x86，MIPS，ARMv8，MIPS64和x86_64。每一種CPU類型都對應(yīng)一種ABI（Application Binary Interface），這7種CPU類型對應(yīng)的SO庫的文件夾名是：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。
不同類型的移動設(shè)備在運行APP時，需要加載自己支持的類型的SO庫，一般情況下，不需要開發(fā)者自己去判斷ABI，Android系統(tǒng)在安裝APK的時候，不會安裝APK里面全部的SO庫文件，而是會根據(jù)當前CPU類型支持的ABI，從APK里面拷貝最合適的SO庫，并保存在APP的內(nèi)部存儲路徑的libs下面。（這里說一般情況，是因為有例外的情況存在，比如我們動態(tài)加載外部的SO庫的時候，就需要自己判斷ABI類型了。
Android apk的安裝過程
Apk文件其實只是一個歸檔zip壓縮包，最終會被分解各個文件。
1.復(fù)制apk到/data/app 或者/system/app
2. /data/data/包名 -------自動生成存儲數(shù)據(jù)的文件，so文件也是存儲在這里的（系統(tǒng)目錄下的app不會自動生成so文件，而是直接讀取/system/lib 文件夾）。
2.,data/dalvik-cache-------存儲.dex文件,但為了提高運行性能,android系統(tǒng)并不會直接執(zhí)行.dex,而是會在安裝過程中執(zhí)行dexopt操作來優(yōu)化.dex文件,最終android系統(tǒng)執(zhí)行的時優(yōu)化后的'odex'文件(注意:這個odex文件的后綴也是.dex,其路徑在data/dalvik-cache)。對于dalvik虛擬機,dexopt就是優(yōu)化操作,而對于art虛擬機,dexopt執(zhí)行的則是dex2oat操作,既將.dex文件翻譯成oat文件。
2.動態(tài)加載的基本思路和優(yōu)點
基本思路
1.判斷本地的cpu類型
2.通過網(wǎng)絡(luò)下載指定的so文件
3.復(fù)制到指定目錄進行l(wèi)oadLibrary
動態(tài)加載的優(yōu)點
1.靈活，so 文件可以動態(tài)加載，不是綁定死的，修改方便，so 庫有問題，我們可以動態(tài)更新。
2.so 庫文件很大的話，采用動態(tài)加載可以減少 apk 的包，變小。
3.具體實現(xiàn)邏輯
1.判斷本地類型的顯示方式
a.通過獲取android.os.Build.CPU_ABI，android.os.Build.CPU_ABI2
b.通過讀取/proc/cpuinfo文件，然后判斷CPU架構(gòu)
具體代碼：
輸出日志：
04-01 17:47:35.779: E/tag(1457): CPU：armeabi-v7a,--armeabi
04-01 17:47:35.779: E/tag(1457): line：Processor : ARMv7 Processor rev 1 (v7l)
2.通過網(wǎng)絡(luò)下載so文件
3.放到指定目錄
調(diào)用System.loadLibrary()會自動讀取
a./data/data/包名/lib
b./data/app-lib/包名
c./system/lib
d./vendor/lib
所以，目錄可以選擇這幾個，也可以自行選擇其他目錄。調(diào)用其他目錄的時候需要寫路徑全稱
兩種調(diào)用方式示例
a.System.loadLibrary("dbapi")
b.System.loadLibrary("/data/user/0/包名/lib/libdbapi.so")
4.可能遇見的問題
1.加載時間的調(diào)用
動態(tài)加載雖然有很多優(yōu)點，但是有延遲性，如果一些效果在剛啟動就要調(diào)用，就必須打包到apk里面。
2.邏輯需要處理
必須處理在沒有加載成功的情況下，代碼邏輯不引起異常奔潰。
參考
