我想在我的Android應用程序中使用硬件浮點支持，這會大量使用OpenCV庫。但是，當我設置硬浮動的gcc標誌時（如here和here所述），我收到鏈接器錯誤： XXX.o uses VFP register arguments, output does not。然後添加鏈接器標記-Xlinker --no-warn-mismatch，這些標記使這些錯誤消失，但應用程序立即崩潰，看起來是與OpenCV庫的第一次交互。OpenCV支持Android的硬件支持
究竟發生了什麼？我是否編譯我的代碼的硬浮點版本並將其與軟浮點OpenCV鏈接？
是否有OpenCV4Android版本的預構建二進制文件使用硬浮點架構？如果沒有，是否有可能編譯這樣的版本？如何做到這一點？在使用OpenCV時，是否有更智能的方式來利用硬件浮點支持？
爲了使用硬件浮點單元，您不需要構建硬浮點模式。只要您爲armeabi-v7a ABI構建，它將使用硬件浮點單元（VFPv3）。
爲了說明問題，硬 - 浮點選項（通過將-mhard-float參數添加到編譯器或構建armeabi-v7a-hard ABI）僅改變參數傳遞給函數的方式。在內部，Android將所有浮點/雙精度函數參數傳遞到整數寄存器中。這確保了在FPU上的現代設備上運行時，爲armeabi（ARMv5不保證浮點單元，需要以這種方式傳遞這些參數）構建的代碼仍然可以工作。也就是說，函數將所有浮點參數存入整數寄存器，並將它們移到FPU寄存器，以完成函數內的所有計算。
當使用硬浮選項構建時，這些參數直接在FPU寄存器中傳遞，但是隨着第二個鏈接指出，這要求您調用的所有代碼都使用相同的選項構建，並且JNI函數條目積分需要用JNICALL正確標記。
所以你從硬鞭毛中獲得的實際好處只不過是你爲每個函數調用保存了一些指令（並且正如第一個鏈接中的答案指出的那樣，這些都相當便宜）。根據圖書館的功能結構，這可能意味着一個完全不重要的變化，或者可能是顯而易見的。不幸的是，我不知道OpenCV內部結構足夠好，可以猜測有多大的潛在加速比率。
所以回顧一下，是的，你是對的，你只是建立你的代碼的硬浮點版本，但將它連接到一個軟浮動ABI版本的OpenCV。爲了使事情順利進行，您還可以在OpenCV的所有函數調用中添加__attribute__((pcs("aapcs")))標記，但這幾乎可以排除所有潛在的優勢，因爲所有繁重的工作（很可能）都是在庫中完成的，而不是在調用代碼中完成。
所以爲了獲得硬浮動ABI的潛在好處，你需要用-mhard-float參數重新構建所有的OpenCV（具體怎麼做，儘管我不能幫你）。但只要它的目標是armeabi-v7a（與參數-march=armv7-a -mfpu=vfpv3），它應該已經使用硬件FPU，它只是使用向後兼容的ABI。 softfp ABI的開銷比完整softfloat版本的開銷小（不是由-mfpu=vfpv3構建的）。