更新了重要的新信息（見底部）編輯了更好的日志代碼我正在追蹤我們的應用程序中的一些圖形損壞，并將其追溯到這個函數（我已經在其中大量記錄了日志）：public final int p_PostDraw(){ bb_std_lang.print("Dissolve encountered."); float t_d=c_GColour.m_dissolve; bb_std_lang.print("Cached dissolve value locally: "+c_GColour.m_dissolve+ " " + t_d); c_GColour.m_dissolve=c_Gel.m_colstack.p_Top().m_a; bb_std_lang.print("Updated dissolve value: " + c_GColour.m_dissolve); c_Gel.m_colstack.p_Top().m_a=1.0f; bb_std_lang.print("Monitoring t_d="+t_d); super.p_PostDraw(); bb_std_lang.print("Monitoring t_d="+t_d); c_GColour.m_dissolve=t_d; bb_std_lang.print("Dissolve post restore " + c_GColour.m_dissolve); return 0;}大多數情況下，這會按預期工作，但在游戲中的某個時刻，會記錄以下內容：09-30 14:40:59.086 10545-11101/? I/[Monkey]: Dissolve encountered.09-30 14:40:59.086 10545-11101/? I/[Monkey]: Cached dissolve value locally: 1.0 1.009-30 14:40:59.086 10545-11101/? I/[Monkey]: Updated dissolve value: 0.109-30 14:40:59.086 10545-11101/? I/[Monkey]: Monitoring t_d=1.009-30 14:40:59.087 10545-11101/? I/[Monkey]: Monitoring t_d=-1.6314132E-1909-30 14:40:59.087 10545-11101/? I/[Monkey]: Dissolve post restore -1.6314132E-19為您分解一下：靜態值m_dissolve被復制到局部變量t_d中，并且值為 1.0f。然后將靜態值修改為 0.1f 并用于子對象的渲染。完成后，局部變量t_d在用于恢復靜態值之前再次被記錄，但同時神秘地變成 -1.6314132E-19 （這個值每次似乎都不可預測地不同）。我不知道本地 Java 變量會以這種方式被破壞。
3 回答
慕森卡
TA貢獻1806條經驗 獲得超8個贊
我在使用 LibGDX 發布的游戲中也遇到了這個問題，就像 tscissors 一樣。
經過幾個月的調試，現在我確信我遇到的問題與被破壞的浮點變量有關，就像這篇文章中所描述的那樣。
對我來說，一個簡單的解決方法很有幫助：在AndroidManifest.xml設置屬性時成功android:vmSafeMode消除 true了錯誤，因為它禁用了 JIT 優化。
參見安卓說明：
android:vmSafeMode
指示應用程序是否希望虛擬機 (VM) 在安全模式下運行。默認值為“假”。此屬性是在 API 級別 8 中添加的，其中“true”值會禁用 Dalvik 即時 (JIT) 編譯器。
此屬性在 API 級別 22 中進行了調整，其中“true”值禁用 ART 提前 (AOT) 編譯器。
MMMHUHU
TA貢獻1834條經驗 獲得超8個贊
這是一個非常奇怪的問題，似乎是 ART/JIT 中的錯誤。我可以看到至少 3 個不同的開發者故事都遇到同樣的問題。我認為可能會有更多，但這個錯誤確實很難重現。
我在使用 LibGDX 框架開發游戲時遇到了這個問題。該框架中的 UI 是通過大量復雜的計算創建的，并且在那里大量使用了浮點數。在我的例子中，UI 組件收到了錯誤的坐標，因此布局完全被破壞。
奇怪的是，您無法使用 DEBUG apk 重現此問題，只能使用 RELEASE apk 重現。更改清單的值android:debuggable=true也不起作用。所以調試真的很痛苦，你需要監控logcat并驗證float變量的值。
解決方法
在我真正需要 UI 相關方法之前，我強制編譯器對它們執行“去優化”。我創建了模擬“Table”組件，用其他模擬組件填充它（創建類似于真實組件的布局），并調用我在日志中看到的方法（當去優化發生時）。我每次在應用程序啟動時都會進行此操作，并且問題似乎對我來說已“修復” - 此后“去優化”永遠不會發生，并且在此之后布局始終正確。
我希望它能幫助那些在這個問題上花費了大量時間的人。
哈士奇WWW
TA貢獻1799條經驗 獲得超6個贊
我不知道本地 Java 變量會以這種方式被破壞。
如果某處的某些本機代碼破壞了包含該變量的堆棧幀，則可能會發生這種情況t_d。
如果本節中存在競爭條件或內存危險，也可能會發生這種情況：
float t_d=c_GColour.m_dissolve;
bb_std_lang.print("Dissolve pre stack: " + c_GColour.m_dissolve);如果你仔細觀察，你實際上并沒有打印t_d。c_GColour.m_dissolve您正在做的是在將...分配給后打印 ... 的（表觀）值t_d。它可能已經改變了。
（請注意，您正在訪問一個裸變量m_dissolve，顯然沒有任何同步。即使聲明為 ，這里也存在潛在的競爭條件m_disolve。volatile）
添加回答
舉報
0/150
提交
取消