Android Studio中.so包使用問題介紹

簡介

最近在項目中遇到了關于.so包使用中的問題，在此記錄下問題的解決方案。

本文會介紹到關于.so包在Android Studio中的使用和在使用過程中的問題以及其解決方法。

使用

.so包在Android Studio中的使用其實就是通過gradle腳本告訴編譯器去哪里找，而默認的配置中也包含了某個文件夾下就能直接識別。

這個能直接識別目錄就是項目的/src/main/文件夾下的jniLibs文件夾中，其中jniLibs得自己創建，文件名必須是這個。因為在默認的配置中有這么一句

sourceSets {
    main {
        jniLibs.srcDirs = ['src/main/jniLibs']
    }
}

這就是在告訴編譯器，我的.so包你可以去哪里找到。

明白了原理，我們也可以修改這個配置，例如改為

sourceSets {
    main {
        jniLibs.srcDirs = ['libs']
    }
}

這樣我們就可以像Eclipse那樣把so包直接放到libs文件夾下了。

使用也是比較簡單，而當我們在引用了一些第三方的庫的時候，基于某些原因使用到了.so包，但是提供的cpu架構又不統一，就會導致在某個cpu架構下找不到對應的.so包，這時候程序就會毫無疑問的崩潰掉，而且這種問題有時候還不是那么容易測到。

而導致這個問題的原因也在描述中說到，其實就是因為在某些cpu架構下沒有找到對應的.so包，既然找到了問題，那么就簡單了，因為我們只要保證在程序添加的cpu架構中都包含使用到的.so包，那么就不會出現找不到的問題了，其中缺省的.so包可以使用armeabi架構下的對應.so包來代替；

解決問題的原理說清楚了，操作起來就簡單了，有兩種方法：

把引用到的三方庫的so包都統一保留某些個cpu架構的
使用gradle腳本只留下萬能的cpu架構（armeabi）,具體為什么只留下一個的原因，主要是在使用的過程中發現該腳本不會把某些沒有.so包的cpu架構復制過去，那就還是沒有，所以只留armeabi，因為這個是肯定會有的，腳本如下：

ndk {
    abiFilters 'armeabi'
//, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a', mips, mips64
加入需要生成的架構
}

這樣問題就基本解決了，如果只保留一個的話，就會在某些架構上三方庫的性能下降，但是至少保證了幾乎不會直接奔潰。