黑莓優化 - 從磁盤或內存背景圖像？

我很好奇，如果有人有關於這是否是實際優化或不必要的膨脹的信息。黑莓優化 - 從磁盤或內存背景圖像？

我有一些通過用戶交互從堆棧中彈出和彈出的屏幕，並且它們都具有相同的背景圖像。

我沒有在每個屏幕上加載圖像，而是實現了一種靜態方法，它在第一次訪問磁盤時加載磁盤中的圖像，然後將該位圖保留在靜態變量中供將來使用。

是否有某種方式來描述這個或有人意識到這個缺點？

public final class App { 

private static Bitmap _bgBitmap = null; 

/* 
* Get a standard background for screens 
* Method caches background in memory for less disk access 
*/ 
public static Bitmap getScreenBackground(){ 
    if (_bgBitmap == null){ 
     try { 
      _bgBitmap = Bitmap.getBitmapResource("ScreenBG.jpg"); 
     } 
     catch(Exception e){} 
    } 
    return _bgBitmap; 
}

}

來源

2011-09-29 Andrew Grothe

只需將可用RAM的數量打印到狀態區域，它在打開和關閉屏幕時似乎會減慢RAM的消耗。仍然不確定是否有任何速度增益。 –

我想有Bitmap作爲靜態字段的唯一原因是地方加快創建也使用相同的位圖另一個屏幕。恕我直言，這是一個很好的辦法，但是回答你的問題可能會因不同的你究竟是如何使用位圖：

你直接繪製它Graphics比如在一些paint()？
您在繪製之前調整它的大小嗎？
您是否從位圖創建Background實例？在這種情況下，您需要調查Background實例是否爲其內部使用創建了一個位圖副本（在這種情況下，RAM收集可能翻倍（2位圖），因此在屏幕上共享Background實例會更好，而不是位圖）。

另一點 - 聽起來好像有沒有使用位圖的屏幕實例的情況。如果是的話，那麼你可以檢測到這種情況，以取消_bgBitmap，所以如果操作系統決定釋放一些內存，它可以GC位圖實例。然而，如果應用程序工作流程意味着即將創建這樣的屏幕，那麼離開位圖可能更便宜。

此外，位圖有多大？如果它相對較小，那麼你可以不打擾自己進一步優化（你目前的懶惰加載是足夠好的）。你可以通過知道它的高度和高度來計算RAM中消耗的字節大小：int size = 4 * width * height。您還可以記錄/彈出從資源加載位圖所用的時間。如果它比較小，那麼也許甚至不使用當前的延遲加載？請注意，只能在真實設備上進行計時，因爲BB模擬器的速度要快於設備。

來源

2011-09-29 19:30:34

謝謝阿明，明天我會嘗試一些建議。 –

似乎操作系統足夠聰明來處理這個問題。在共享位圖時，我沒有注意到RAM使用量的增加。 –

黑莓優化 - 從磁盤或內存背景圖像？

回答

相關問題