安裝了一款游戲在小米4上運行是ok的终蒂，在小米5上運行直接crash蜂林！
原因：小米4系列采用的處理器為高通驍龍801，此款處理器是32位處理器拇泣。小米5系列則采用的是驍龍820 悉尾，是64位處理器。查看crash日志可以發(fā)現(xiàn)是是arm64-v8a文件夾缺失對應(yīng)的so庫文件引起的BUG。現(xiàn)在許多三方的SDK都會提供編譯好的so庫文件，但是由于一些原因趁舀，有些SDK并沒有提供對應(yīng)標題所有目錄的so庫文件妻柒，而有的卻提供的全面惫霸，比如百度的SDK就提供有標題列出的所有目錄對應(yīng)的so庫文件猫缭。
如果你有兩個文件夾armeabi和arm64-v8a，在armeabi里面有a.so 和 b.so,而在arm64-v8a里面只有a.so壹店，那么arm64-v8a的手機在用到b的時候就會因為找不到b而報錯了猜丹。由于arm64-v8a是向下兼容的，所以只需要刪掉arm64-v8a文件夾硅卢，讓手機自適應(yīng)去查找armeabi的so庫即可射窒。但是這樣并不能完全的做到完美的兼容，因此在使用JNI庫的時候最好是拿到對應(yīng)文件夾的so庫文件将塑。
為了防止再出現(xiàn)crash脉顿，直接把
早期的Android系統(tǒng)幾乎只支持ARMv5的CPU架構(gòu)，你知道現(xiàn)在它支持多少種嗎点寥？7種艾疟！
Android系統(tǒng)目前支持以下七種不同的CPU架構(gòu)：ARMv5，ARMv7 (從2010年起)敢辩，x86 (從2011年起)蔽莱，MIPS (從2012年起)，ARMv8戚长，MIPS64和x86_64 (從2014年起)盗冷，每一種都關(guān)聯(lián)著一個相應(yīng)的ABI。
應(yīng)用程序二進制接口（Application Binary Interface）定義了二進制文件（尤其是.so文件）如何運行在相應(yīng)的系統(tǒng)平臺上同廉，從使用的指令集正塌，內(nèi)存對齊到可用的系統(tǒng)函數(shù)庫。在Android系統(tǒng)上恤溶，每一個CPU架構(gòu)對應(yīng)一個ABI：armeabi，armeabi-v7a帜羊，x86咒程，mips，arm64-v8a讼育，mips64帐姻，x86_64。
為什么你需要重點關(guān)注.so文件
如果項目中使用到了NDK奶段，它將會生成.so文件饥瓷，因此顯然你已經(jīng)在關(guān)注它了。如果只是使用Java語言進行編碼痹籍，你可能在想不需要關(guān)注.so文件了吧呢铆，因為Java是跨平臺的。但事實上蹲缠，即使你在項目中只是使用Java語言棺克，很多情況下悠垛，你可能并沒有意識到項目中依賴的函數(shù)庫或者引擎庫里面已經(jīng)嵌入了.so文件，并依賴于不同的ABI娜谊。
例如确买，項目中使用RenderScript支持庫，OpenCV纱皆，Unity湾趾，android-gif-drawable，SQLCipher等派草，你都已經(jīng)在生成的APK文件中包含.so文件了搀缠，而你需要關(guān)注.so文件。
Android應(yīng)用支持的ABI取決于APK中位于lib/ABI目錄中的.so文件澳眷，其中ABI可能是上面說過的七種ABI中的一種胡嘿。
Native Libs Monitor這個應(yīng)用可以幫助我們理解手機上安裝的APK用到了哪些.so文件，以及.so文件來源于哪些函數(shù)庫或者框架钳踊。
當然衷敌，我們也可以自己對app反編譯來獲取這些信息，不過相對麻煩一些拓瞪。
很多設(shè)備都支持多于一種的ABI缴罗。例如ARM64和x86設(shè)備也可以同時運行armeabi-v7a和armeabi的二進制包。但最好是針對特 定平臺提供相應(yīng)平臺的二進制包祭埂，這種情況下運行時就少了一個模擬層（例如x86設(shè)備上模擬arm的虛擬層）面氓，從而得到更好的性能（歸功于最近的架構(gòu)更新， 例如硬件fpu蛆橡，更多的寄存器舌界，更好的向量化等）。
我們可以通過Build.SUPPORTED_ABIS得到根據(jù)偏好排序的設(shè)備支持的ABI列表泰演。但你不應(yīng)該從你的應(yīng)用程序中讀取它呻拌，因為 Android包管理器安裝APK時，會自動選擇APK包中為對應(yīng)系統(tǒng)ABI預(yù)編譯好的.so文件睦焕，如果在對應(yīng)的lib／ABI目錄中存在.so文件的 話藐握。
App中可能出錯的地方
處理.so文件時有一條簡單卻并不知名的重要法則。
你應(yīng)該盡可能的提供專為每個ABI優(yōu)化過的.so文件垃喊，但要么全部支持猾普，要么都不支持：你不應(yīng)該混合著使用。你應(yīng)該為每個ABI目錄提供對應(yīng)的.so文件本谜。
當一個應(yīng)用安裝在設(shè)備上初家，只有該設(shè)備支持的CPU架構(gòu)對應(yīng)的.so文件會被安裝。在x86設(shè)備上，libs/x86目錄中如果存在.so文件的 話笤成，會被安裝评架，如果不存在，則會選擇armeabi-v7a中的.so文件炕泳，如果也不存在纵诞，則選擇armeabi目錄中的.so文件（因為x86設(shè)備也支 持armeabi-v7a和armeabi）。
其他地方也可能出錯
當你引入一個.so文件時培遵，不止影響到CPU架構(gòu)浙芙。我從其他開發(fā)者那里可以看到一系列常見的錯誤，其中最多的是"UnsatisfiedLinkError"籽腕，"dlopen: failed"以及其他類型的crash或者低下的性能：
使用android-21平臺版本編譯的.so文件運行在android-15的設(shè)備上
使用NDK時嗡呼，你可能會傾向于使用最新的編譯平臺，但事實上這是錯誤的皇耗，因為NDK平臺不是后向兼容的南窗，而是前向兼容的。推薦使用app的minSdkVersion對應(yīng)的編譯平臺郎楼。
這也意味著當你引入一個預(yù)編譯好的.so文件時万伤，你需要檢查它被編譯所用的平臺版本。
混合使用不同C++運行時編譯的.so文件
.so文件可以依賴于不同的C++運行時呜袁，靜態(tài)編譯或者動態(tài)加載敌买。混合使用不同版本的C++運行時可能導致很多奇怪的crash阶界，是應(yīng)該避免的虹钮。 作為一個經(jīng)驗法則，當只有一個.so文件時膘融，靜態(tài)編譯C++運行時是沒問題的芙粱，否則當存在多個.so文件時，應(yīng)該讓所有的.so文件都動態(tài)鏈接相同的 C++運行時氧映。
這意味著當引入一個新的預(yù)編譯.so文件春畔，而且項目中還存在其他的.so文件時，我們需要首先確認新引入的.so文件使用的C++運行時是否和已經(jīng)存在的.so文件一致屯耸。
沒有為每個支持的CPU架構(gòu)提供對應(yīng)的.so文件
這一點在前文已經(jīng)說到了，但你應(yīng)該真的特別注意它蹭劈，因為它可能發(fā)生在根本沒有意識到的情況下疗绣。
例如：你的app支持armeabi-v7a和x86架構(gòu)，然后使用Android Studio新增了一個函數(shù)庫依賴铺韧，這個函數(shù)庫包含.so文件并支持更多的CPU架構(gòu)多矮，例如新增android-gif-drawable函數(shù)庫：
compile‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’
發(fā)布我們的app后，會發(fā)現(xiàn)它在某些設(shè)備上會發(fā)生Crash，例如Galaxy S6塔逃，最終可以發(fā)現(xiàn)只有64位目錄下的.so文件被安裝進手機讯壶。
解決方案：重新編譯我們的.so文件使其支持缺失的ABIs，或者設(shè)置
ndk.abiFilters
顯示指定支持的ABIs湾盗。
最后一點：如果你是一個SDK提供者伏蚊，但提供的函數(shù)庫不支持所有的ABIs，那你將會搞砸你的用戶格粪，因為他們能支持的ABIs必將只能少于你提供的躏吊。
將.so文件放在錯誤的地方
我們往往很容易對.so文件應(yīng)該放在或者生成到哪里感到困惑，下面是一個總結(jié)：
Android Studio工程放在jniLibs/ABI目錄中（當然也可以通過在build.gradle文件中的設(shè)置jniLibs.srcDir屬性自己指定）
Eclipse工程放在libs/ABI目錄中（這也是ndk-build命令默認生成.so文件的目錄）
AAR壓縮包中位于jni/ABI目錄中（.so文件會自動包含到引用AAR壓縮包的APK中）
最終APK文件中的lib/ABI目錄中
通過PackageManager安裝后帐萎，在小于Android 5.0的系統(tǒng)中比伏，.so文件位于app的nativeLibraryPath目錄中；在大于等于Android 5.0的系統(tǒng)中疆导，.so文件位于app的nativeLibraryRootDir/CPU_ARCH目錄中赁项。
只提供armeabi架構(gòu)的.so文件而忽略其他ABIs的
所有的x86/x86_64/armeabi-v7a/arm64-v8a設(shè)備都支持armeabi架構(gòu)的.so文件，因此似乎移除其他ABIs的.so文件是一個減少APK大小的好技巧澈段。但事實上并不是：這不只影響到函數(shù)庫的性能和兼容性悠菜。
x86設(shè)備能夠很好的運行ARM類型函數(shù)庫，但并不保證100%不發(fā)生crash均蜜，特別是對舊設(shè)備李剖。64位設(shè)備（arm64-v8a, x86_64, mips64）能夠運行32位的函數(shù)庫，但是以32位模式運行囤耳，在64位平臺上運行32位版本的ART和Android組件篙顺，將丟失專為64位優(yōu)化過的性 能（ART，webview充择，media等等）德玫。
以減少APK包大小為由是一個錯誤的借口，因為你也可以選擇在應(yīng)用市場上傳指定ABI版本的APK椎麦，生成不同ABI版本的APK可以在build.gradle中如下配置：
android {
.........
splits {
abi { ? ? ??
enable
true
reset()
include
'x86'
,
'x86_64'
,
'armeabi-v7a'
,
'arm64-v8a'
//select ABIs to build APKs for
universalApk
true
//generate an additional APK that contains all the ABIs
}
}
// map for the version code
project.ext.versionCodes = [
'armeabi'
:
1
,
'armeabi-v7a'
:
2
,
'arm64-v8a'
:
3
,
'mips'
:
5
,
'mips64'
:
6
,
'x86'
:
8
,
'x86_64'
:
9
]
android.applicationVariants.all { variant ->
// assign different version code for each output
variant.outputs.each { output ->
output.versionCodeOverride =
project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI),
0
) *
1000000
+ android.defaultConfig.versionCode
}
}
}
參考文章：
我的Android進階之旅------>Android 關(guān)于arm64-v8a宰僧、armeabi-v7a、armeabi观挎、x86下的so文件兼容問題
