首先一些公共變量聲明爲static類型確實很方便，但請不要濫用，即使你覺得這不會帶來內存上很大的代價，也會破壞代碼的結構，想想一個變量誰都能引用他，在他的職責分配上會很困擾。
而且對於Texture，assetmanager等資源更加建議不要用static。也許你在desktop上測試發現這並沒有問題，但在android上就會發生各種錯誤（紋理丟失，錯誤的紋理）。
desktop關閉後，jvm就關閉進程了，而android沒有很明顯的進程概念，退出遊戲後，仍會保留進程，這是因爲android系統設計者考慮了重複啓動一個activity的代價，所以不會立即關閉進程而是採取內存不足時才關閉。（Gdx.app.exit（）也只是退出遊戲，沒有關閉進程，除非你使用system.exit或killProcess，但這拋棄了android系統設計者的優化技巧）。
再來看看這幾個生命週期吧：application lifetime像上面說的，進程不會立即退出。activity lifetime，libgdx遊戲其實只啓動一個activity，遊戲的生命週期和activity週期纔對得上。opengl lifetime，activity失去焦點它就被回收了。紋理底層的byte是指向opengl contex的，所以activity失去焦點，texture也會丟失內容，但有時你發現再返回activity時顯示正常，這是因爲紋理管理機制自動幫你加載丟失的內容了。可是你退出activity（遊戲）後就沒這麼幸運，java object依賴於應用進程，沒被回收的就不會消失如靜態變量，但紋理內容可是全都消失了，你再啓動遊戲，駐存的static聲明的texture對象又被取來使用，但其指向的opengl context無法恢復，所以你會看到一些詭異的現象。
那麼避免使用static聲明資源吧，有意識的把資源的生命週期和activity的生命週期綁定。釋放資源後使java object無效（賦null）也是避免詭異的好習慣。