Blackberry optimization - background image from disk or RAM?

I'm curious if anyone has information on whether or not this is an actual optimization or unnecessary bloat.

I have s开发者_Go百科ome screens that are pushed and popped from the stack via user interaction and all of them have the same background image.

Instead of loading the image on each screen, I have implemented a static method which loads the image from disk the first time it's accessed, then keeps the bitmap in a static variable for future use.

Is there some way to profile this or is anyone aware of a downside to this?

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;
    }
}

---

I suppose the only reason of having a Bitmap as a static field somewhere is to speed up creating another screen that also uses the same bitmap. IMHO this is a nice approach, however the answer to your question may differ depending on how exactly you use the bitmap:

• Do you draw it directly on Graphics instance in some paint()?
• Do you resize it before drawing?
• Do you create a Background instance from the bitmap? In this case you'll need to investigate whether the Background instance creates a copy of bitmap for its internal usage (in this case RAM consupmtion may be doubled (2 bitmaps), so it would be nice to share across screens the Background instance rather than the bitmap).

Another point - it sounds like there maybe a case when there is no screen instances that use the bitmap. If yes, then you could detect such case in order to nullify the _bgBitmap so if OS decides to free some RAM it could GC the bitmap instance. However if app workflow implies such screen to be created soon, then maybe it is cheaper to leave the bitmap alive.

Also, how large is the bitmap? If it is relatively small, then you can just don't bother yourself with further optimization (your current lazy loading is good enough). You can count size in bytes consumed in RAM by knowing its with and height: int size = 4 * width * height. You can also log/popup the time taken to load the bitmap from resources. If it is relatively small, then maybe don't even use the current lazy loading? Note the timings should be taken on real devices only, since BB simulators are in times faster than devices.