關于Java.lang.UnsatisfiedLinkError的錯誤解決辦法

把原本一直在魅藍metal測試的android地面站換到S6 edge中運作就報java.lang.UnsatisfiedLinkError: No implementation found for void com.mmc.groundstation.activities.activity.GroundStationActivity.startVideoStream(java.lang.Object) (tried Java_com_mmc_groundstation_activities_activity_GroundStationActivity_startVideoStream and Java_com_mmc_groundstation_activities_activity_GroundStationActivity_startVideoStream__Ljava_lang_Object_2)

其實在Android開發中，我發現通常引用了一些第三方的sdk的so庫之後，不同機型之間就會發生這樣一個錯誤，

Java.lang.UnsatisfiedLinkError！

舉個例子：

你原先的項目中隻使用了A公司提供的so包，他隻提供了armeabi這個架構的so包，後來項目需要又引用了B公司的提供的sdk，裡面提供的so包還挺全的，arm64-v8a，armeabi-v7a，mips，mips64，x86等等，結果你就全放進去了， 後來發現突然某手機就出現了崩潰，然後一般都是因為這個問題

Java.lang.UnsatisfiedLinkError

是以呢，為了解決這個問題，也有人提出了解決辦法：

這種情況一般是由于libinet.x.x.x so(x.x.x代表版本号，比如libinet.1.6.2)檔案未加載成功導緻的，解決方法有兩種：  

方法一：  

首先确認libs目錄下每個存放so檔案的目錄是否包含了libinet.x.x.x.so檔案。  

比如armeabi和armeabi-v7a,但是armeabi-v7a中沒有libinet.x.x.x.so，這是不允許的，請從armeabi中複制。  

比如x86_64沒有libinet.x.x.x.so，請從我們提供的demo中對應的x86_64目錄複制（不能從demo的armeabi目錄複制，因為平台類型不一緻，保證從demo中同名的目錄複制檔案）。  

方法二：  

僅僅保留armeabi和x86目錄，删除其它多餘的目錄(比如arm64-v8a,x86_64等)，同時确認armeabi和x86目錄有libinet.x.x.x.so檔案。  

注意，這裡所說的僅僅保留armeabi和x86目錄是指主工程和所有依賴工程都隻能僅僅保留armeabi和x86目錄，若主工程或者某一個依賴工程中包含了其他目錄(例如x86_64)，還是會存在問題的。  

如果用這種方法處理後沒有解決該問題，請用解壓軟體解壓apk，然後看一下lib目錄下是否隻有armeabi和x86目錄，如果有armeabi和x86目錄以外的目錄，說明你一定沒有删除幹淨，一定沒有删除幹淨，一定沒有删除幹淨，重要的事情說三遍，自己再仔細檢查一下！  

另外，删除其他工程中armeabi-v7a, arm64_v8a，x86_64目錄不會影響這些工程的功能的，也不會在其他手機上産生适配問題，是以放心的删除吧！  

另外，删除其他工程中armeabi-v7a, arm64_v8a，x86_64目錄不會影響這些工程的功能的，也不會在其他手機上産生适配問題，是以放心的删除吧！  

另外，删除其他工程中armeabi-v7a, arm64_v8a，x86_64目錄不會影響這些工程的功能的，也不會在其他手機上産生适配問題，是以放心的删除吧！  

重要的事情說三遍！！！  

so加載原理可以參考： http://www.jianshu.com/p/cb05698a1968

然後呢，我也找了一些瘦身APK的資料，發現好像隻保留armeabi這個檔案就可以了，别問為什麼，微信就隻有這一個檔案夾，要是覺得自己apk太大了， 就删掉其他的吧，保留這一個就ok了。

參考見：

http://blog.csdn.net/a774838634/article/details/52758096

1.apk中有對應平台的檔案夾，但是檔案夾裡卻沒有對應的so。

舉個例子，apk中lib下面一旦出現x86檔案夾，程式運作的時候就會去加載x86對應的庫，但是如果此時x86檔案夾沒有将so放進來，則會遇到報錯。

2.第三方對平台的相容政策與自己不一緻。

可能第三方選擇了隻支援armeabi（假設某支付sdk），但是我們的遊戲在Application.mk中配置了APP_ABI := all，如此，我們的遊戲打包出 了所有平台的so，但是第三方卻隻有armeabi檔案夾對應的so，造成程式運作異常，這種情況在開發期間最常見，一些小公司由于測試人員不足或者測試裝置不足，上線後才發現這個問題也不奇怪。

二、對于平台的支援，我們應該如何選擇。

armeabi-v7a确實是可以相容armeabi的，而v7a的CPU支援硬體浮點運算，目前絕大對數裝置已經是v7a了，是以為了性能上的更優，就不要為了相容放到armeabi。 x86是可以相容armeabi平台運作的，無論是armeabi-v7a還是armeabi，同時帶來的也是性能上的損耗，另外需要指出的是，打包出的x86的so，總會比armeabi平台的體積更小，對于性能有潔癖的童鞋們，還是建議在打包so的時候支援x86。具體會有怎樣的性能損耗，作者還不能說的非常清楚，可以通路下intel官方在csdn的部落格。 總結一下在項目中的表現就是: 

如果項目隻包含了 armeabi，那麼在所有Android裝置都可以運作； 如果項目隻包含了 armeabi-v7a，除armeabi架構的裝置外都可以運作； 如果項目隻包含了 x86，那麼armeabi架構和armeabi-v7a的Android裝置是無法運作的； 如果同時包含了 armeabi， armeabi-v7a和x86，所有裝置都可以運作，程式在運作的時候去加載不同平台對應的so，這是較為完美的一種解決方案，同時也會導緻包變大。

參考見：

http://blog.csdn.net/duguang77/article/details/38512957