java - 黑莓优化 - 来自磁盘或 RAM 的背景图像？

Question

我很好奇是否有人知道这是真正的优化还是不必要的膨胀。

我有一些屏幕是通过用户交互从堆栈中推送和弹出的，并且所有屏幕都具有相同的背景图像。

我没有在每个屏幕上加载图像，而是实现了一个静态方法，该方法在第一次访问时从磁盘加载图像，然后将位图保存在静态变量中以备将来使用。

有没有什么方法可以对此进行剖析，或者有人知道它的缺点吗？

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

Answer 1

我想将 Bitmap 作为静态字段的唯一原因是加快创建另一个也使用相同位图的屏幕。恕我直言，这是一个很好的方法，但是您的问题的答案可能会有所不同，具体取决于您使用位图的方式:

• 您是否直接在某些paint() 中的Graphics 实例上绘制它？
• 你在画之前调整它的大小吗？
• 您是否从位图中创建了一个Background 实例？在这种情况下，您需要调查 Background 实例是否为其内部使用创建了位图副本(在这种情况下，RAM 消耗可能会加倍(2 个位图)，因此最好共享在屏幕上显示 Background 实例而不是位图)。

另一点 - 听起来可能存在没有使用位图的屏幕实例的情况。如果是，那么您可以检测到这种情况以使 _bgBitmap 无效，因此如果操作系统决定释放一些 RAM，它可以 GC 位图实例。但是，如果应用程序工作流暗示要很快创建这样的屏幕，那么让位图保持 Activity 状态可能更便宜。

另外，位图有多大？如果它相对较小，那么您就可以不用进一步优化了(您当前的延迟加载已经足够好了)。您可以通过了解其大小和高度来计算 RAM 中消耗的字节数:int size = 4 * width * height。您还可以记录/弹出从资源加载位图所花费的时间。如果比较小，那可能连现在的懒加载都不用了？请注意，计时应仅在真实设备上进行，因为 BB 模拟器在时间上比设备快。