2012-03-29 149 views
0

所以,我用Monkey測試第一次測試了我的遊戲。我設法在沒有崩潰的情況下運行了大約3分鐘,但最終崩潰時出現了內存不足的錯誤,我試圖弄清楚如何讓它變得更好。Android中的內存管理

  • 有一個正面的屏幕將開始一項活動:

    我的程序結構如下。

  • 次要活動是大部分行動的地方,也是我墜毀的地方。上充氣命令
  • 我崩潰
  • 我的遊戲勢力肖像模式,它更容易讓1點比佈局工作2 ...
  • 有許多與我的次要活動相關的類變量。我會在下面列出非靜態的。我還包含了一些關於這些事情並不明顯的線索。

我想知道的是我如何改善我的程序的內存管理,使其不會崩潰。我懷疑我需要手動刪除其中的一些變量,但我不確定這樣做的正確位置是什麼。謝謝!

private Level_Score_bar score_bar; // Custom view 
private number_viewer num_viewer; // Custom view 
private number_pad num_pad;  // Custom View 
private int time,score,level,num_remaining,current_var,change_loc,time_remaining; 
private ArrayList<Integer> the_key; 
private ImageView Number_to_select; 
private Boolean update_viewer; 
Random rseed; 
Vibrator bzzz; 
long ctime; 
private Activity self=this; 

private SharedPreferences prefs; 
private Editor prefs_edit; 

的內存不足的發生

setContentView(R.layout.level_layout); 

這種佈局是相當複雜的,包含多個圖像視圖,按鈕,文本視圖等

+0

很高興知道你的代碼在哪裏得到了OOM。如果可以的話,發佈堆棧跟蹤和相關代碼片段。 沒有真正相關,但根據Java命名約定,變量不應該有下劃線(除非它是靜態最終的),而是應與下一個字中的第一個字母一起寫入大寫: http://docs.oracle.com .com/javase/tutorial/java/nutsandbolts/variables.html – Jave 2012-03-29 13:22:21

+0

@Jave:包含內存不足的行。我也應該學習Java約定,我可能會研究這個...... – PearsonArtPhoto 2012-03-29 13:25:10

+0

「R.layout.level_layout」包含什麼?大圖像或類似? – Jave 2012-03-29 13:26:10

回答

2

這聽起來像你需要檢查出「Allocation Tracker」工具,可在日蝕中的「DDMS」透視圖中找到。

這會告訴你究竟哪些數據結構正在消耗內存

+0

我有一個公平的想法,什麼是消費內存,但我不太確定我需要做些什麼... – PearsonArtPhoto 2012-03-29 13:50:34

+0

你需要確切地知道哪個組件導致你的內存問題,比你可以專注於修復那。您可以調整範圍,以確保在正確的時間創建\刪除變量,還可以將一些經常訪問的項目緩存在內存中,以確保您只創建單個實例。 – Booger 2012-03-29 13:57:15

1

嘗試在onresume()中使用System.gc();以避免在imageview中使用高分辨率或高內存圖片時發生內存泄漏。

注意: 對於使用位圖的圖像查看,默認垃圾回收未被調用,因此當圖像內存較高時,執行內存超過了分配的內存。手動garbasge收集完成,以避免內存泄漏。最好調用onresume();

3

所以事實證明,我是在堆的毛邊。我使用了不少圖像,結果證明我已經超過了「正常」的堆大小。我已經成功通過縮小一些圖片來改善這種情況,但最好的解決方案來改變我的表現爲以下內容:

<application 
    android:label="@string/app_name" 
    android:icon="@drawable/logo" 
    android:screenOrientation="portrait" 
android:largeHeap="true"> 

的一大堆讓我做未來的升級(其中包括水平設計等,這將佔用相當多的空間......)總而言之,它應該是一個相當小的影響。

我選擇了@ Booger的回答,因爲這是允許我做一些研究並發現我的堆空間不夠大的一塊,但我還包括了@ Ramam-Mystry的一段代碼。

我也用過這個excellent question在我的任務中的很多答案。我開始存儲引用而不是位圖,以及一些其他相關位。總而言之,我的記憶體消耗下降了25%,並持續改善。

另一個提示可能是使用Activity中的onLowMemory()函數,修剪當時不需要的內存。