findlibrary returned null

轉載請標明出處，維權必究：https://www.cnblogs.com/tangZH/p/10181330.html 

該錯誤是在載入so庫的時候出現的，就是找不到so庫。

一、檢查jinLibs目錄下是否有so庫

二、gradle的android{}裡面是否有設置：

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

三、相容性是否正確：

我們使用so庫，需要設置該so庫相容的cpu架構，通常會在jniLibs文件夾裡面新建文件夾：armeabi，armeabi-v7a，x86，然後把so庫放在裡面。

目前主流的Android設備肯定是armeabi-v7a架構的，然後就是x86和armeabi。

那麼Android設備在運行程式時如何選擇載入包中的哪個so呢？

X86：

x86設備會在項目中的 libs文件夾尋找是否含有x86文件夾，如果含有x86文件夾，則預設為該項目有x86對應的so可運行的，只有x86文件夾而文件夾下沒有so，程式運行也是會出現findlibrary returned null的錯誤的；如果工程本身不含有x86文件夾，則會尋找armeabi或者armeabi-v7a文件夾，相容運行。

armeabi-v7a：

現在大多數設備都是armeabi-v7a架構的，該Android設備當然優先尋找libs目錄下的armeabi-v7a文件夾，同樣，如果只有armeabi-v7a文件夾而沒有 so會報錯；如果找不到armeabi-v7a文件夾，則尋找armeabi文件夾，相容運行該文件夾下的so，但是不能相容運行x86的so。所以項目中如果只含有x86的so，在armeabi和armeabi-v7a也是無法運行的。

armeabi

如果項目只包含了 armeabi，那麼在所有Android設備都可以運行

以上就是不同CPU架構運行時載入so的策略。

指定app相容哪種架構：

app.gradle裡面

android{
...
  defaultConfig{
  ...
      ndk {
            abiFilters  "armeabi"  
          }
    }
}

指定要ndk需要相容的架構，這樣其他文件夾的依賴包里的so會被過濾掉,指定了之後，除了armeabi其它文件夾里的so包不會被打包進apk。

想知道自己的so包有沒有被打包進去，一個簡單的方法，就是將軟體包的apk尾碼改為zip尾碼，然後解壓，看看有沒有。

平臺的優缺點：

1、打包出的x86的so，總會比armeabi平臺的體積更小，若是對這個有要求，可以在打so包的時候支持x86

2、armeabi-v7a 第7代 ARM v7，使用硬體浮點運算，具有高級擴展功能（支持 armeabi 和 armeabi-v7a，目前大部分手機都是這個架構），armeabi-v7a確實是可以相容armeabi的，而且性能更優，若是對性能有要求，so包可以支持armeabi-v7a