鑽石舞台

本文整理了JNI開發中常見的問題和解決方案。

智能語音交互SDK工程模塊編譯時指定的ANDROID_PLATFORM統一是23：-DANDROID_PLATFORM=23,ndk使用的是版本是17，在手上現有設備跑的都沒問題，但是在一個新採購的temi移動機器人上跑不起來，定位到問題是信號處理庫報了下面問題：

最開始以為是信號處理庫中用到了什麼不兼容方法，把庫的實現都改為空實現後仍報該錯誤，網上查詢到是target version和目標設備不對應會報該錯，機器人的系統版本是6.0，信號處理庫編譯時Application.mk中設置的APP_PLATFORM := android-26，修改完後就果然解決。

https://github.com/android/ndk/issues/126

https://github.com/android/ndk/issues/1188

官網中對該問題有介紹：

當嘗試加載原生庫時，這些錯誤會顯示在日誌中。此符號可以是 __aeabi_* 中的任意一個；其中 __aeabi_memcpy 和 __aeabi_memclr 可能是最常見的。此問題已記錄在問題 126 中

與上一個類似，也是API版本問題。

在統一頭文件之前，NDK 並不支持 _FILE_OFFSET_BITS=64。如果在構建應用時定義了該選項，系統會靜默地忽略它。現在，_FILE_OFFSET_BITS=64 選項受統一頭文件的支持，但在舊版本的 Android 中，很少有 off_t API 可用作 off64_t 變體。因此，如果將該功能與舊版 API 級別搭配使用，會導致可用函數減少。

r16 博文和 bionic 文檔對該問題作了詳細解釋。

問題：build 請求獲得的 minSdkVersion 中不存在的 API。

解決方案：停用 _FILE_OFFSET_BITS=64 或提高 minSdkVersion。

正常情況我們在方法裡面申請的local reference會在方法執行完後自動釋放，所以一直沒有太在意local reference的釋放，結果在一個線程的looper方法中有兩個jstring使用完一直沒釋放，導致交互多輪後泄露崩潰。

常見問題類型：

確保類名稱字符串的格式正確無誤，JNI 類名稱以軟件包名稱開頭，並用斜線分隔，例如 java/lang/String。如果要查找某個數組類，則需要以適當數量的英文方括號開頭，並且還必須用「L」和「;」將該類包裹起來，因此 String 的一維數組將是 [Ljava/lang/String;。如果要查找內部類，使用「$」而不是「.」，可以在 .class 文件上使用 javap 是查找類的內部名稱。

如果啟用代碼混淆，請確保查找的類名未被混淆。

如果類名稱形式正確，可能是遇到了類加載器問題。FindClass 需要在與代碼關聯的類加載器的啟動類搜索。它會檢查調用堆棧，如下所示：

最頂層的方法是 Foo.myfunc。FindClass 會查找與 Foo 類關聯的 ClassLoader 對象並使用它。

採用這種方法一般情況可以滿足我們的需求。但是如果在native線程（比如通過調用 pthread_create，然後使用 AttachCurrentThread 進行附加），可能會有問題。因為在這個線程中沒有堆棧幀，如果從此線程調用 FindClass，JavaVM 會在「系統」類加載器（而不是與應用關聯的類加載器）中啟動，因此嘗試查找特定於應用的類將失敗。

可以通過以下幾種方法來解決此問題：

在 JNI_OnLoad 中執行一次 FindClass 查找，然後緩存類引用以供日後使用。在執行 JNI_OnLoad 過程中發出的任何 FindClass 調用都會使用與調用 System.loadLibrary 的函數關聯的類加載器（這是一條特殊規則，用於更方便地進行庫初始化）。如果我們的應用代碼要加載庫，FindClass 會使用正確的類加載器。

通過聲明原生方法來獲取 Class 參數，然後傳入 Foo.class，從而將類的實例傳遞給需要它的函數。

在某個便捷位置緩存 ClassLoader 對象的引用，然後直接發出 loadClass 調用，這個比較麻煩一些，而且緩存classloader可能也會存在一些問題。

使用java/lang/ClassLoader的getClassLoader,然後調用findClass:

stackoverflow.com/questions/1…

我們在其他平台，比如linux中聲明了返回值類型為int，實際函數體沒有return可能沒有問題，但是Android平台會直接崩潰。

使用 NDK 進行構建所依據的 API 級別與 Java 中的 compileSdkVersion 所代表的含義截然不同。NDK API 級別是您的應用支持的最低 API 級別。在 ndk-build 中，這是指 APP_PLATFORM 設置。對於 CMake，這是指 -DANDROID_PLATFORM。（如果使用的是 externalNativeBuild，系統會自動使用您的 minSdkVersion。)

系統對函數引用的解析通常發生在庫加載時，而不是首次調用時，因此，對於並非始終存在並通過 API 級別檢查保護對其的使用的 API，將無法引用。如果 API 被引用，那麼此 API 就必須存在。

問題：NDK API 級別高於設備支持的 API 級別。

解決方案：將 NDK API 級別 (APP_PLATFORM) 設置為應用支持的最低 Android 版本。

對於以下錯誤日誌消息，請參閱這條詳細的 Stack Overflow 解答。

問題：某些 ABI 需要 libatomic 才能為原子操作提供一些實現。

解決方案：在鏈接時添加 -latomic。

對於以下錯誤消息：

此處的實際符號可能是前綴為 __atomic_ 的任何符號。(ndk-build 和 CMake 會替我們處理這個問題。對於其他構建系統，我們需要手動處理。)

問題：在跨共享庫邊界拋出異常或 dynamic_cast 失敗時，無法捕獲異常。

解決方案：為我們的類型添加一個關鍵函數。關鍵函數是某個類型的第一個非純的外聯虛擬函數。可參閱關於問題 533 的討論。

C++ ABI 規定，當且僅當兩個對象的 type_info 指針相同時，兩者才具有相同的類型。只有當捕獲的 type_info 與拋出的異常匹配時，系統才會捕獲異常。這項規則同樣適用於 dynamic_cast。

如果某個類型沒有關鍵函數，系統會將其 typeinfo 作為弱符號發出，並在加載庫時合併匹配類型信息。如果在可執行文件加載完畢後動態加載庫（也就是說通過 dlopen 或 System.loadLibrary 加載），加載器可能無法合併已加載庫的類型信息。當出現這種情況時，這兩種類型就不會被視為等同。

對於非多態類型，類型不能具有關鍵函數。對於非多態類型，RTTI 是多餘的，因為可使用 std::is_same 在編譯時確定類型等同性。

在我們的應用中使用預構建庫（這些庫通常是第三方庫）時，需要特別注意。一般來說，請注意以下規則：

生成的應用的最低 API 級別是應用所有庫的最大 minSdkVersion 值。

如果我們的 minSdkVersion 是 16，但使用了依據 21 構建的預構建庫，那麼生成的應用的最低 API 級別為 21。如果預構建庫是靜態的，那麼對於此規則的違反將會在構建時顯示出來，但在預構建共享庫運行時才會顯示。

應使用相同的 NDK 版本生成所有庫。

由於違反的情況極少，此規則比大多數規則的靈活性略高，但無法保證使用不同 Major 版本的 NDK 構建的庫之間的兼容性。C++ ABI 並非穩定版，在過去有過變化。

具有多個共享庫的應用必須使用一個共享 STL。

就 STL 不匹配而言，可以通過小心謹慎地操作來避免由此引起的問題，但最好直接避免該問題。為避免該問題，最好避免在您的應用中使用多個共享庫。

本文介紹了JNI開發過程中常見的問題，比如版本問題，定位符號失敗問題以及不同平台函數實現的差異等。後續可以持續維護迭代本文檔。

原文鏈接: https://juejin.cn/post/7083127329156759559