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作为静态字段的唯一原因是加快创建另一个也使用相同位图的屏幕。恕我直言这是一个很好的方法，但你的问题的答案可能会有所不同，具体取决于你如何使用位图：

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

另一点 - 听起来有可能出现没有使用位图的屏幕实例的情况。如果是，那么你可以检测到这种情况，以便使Background无效，所以如果操作系统决定释放一些RAM，它可以GC到位图实例。但是，如果应用程序工作流意味着很快就会创建这样的屏幕，那么将位图保持活动可能会更便宜。

此外，位图有多大？如果它相对较小，那么你可以不用打扰自己进一步优化（你当前的延迟加载足够好）。您可以通过知道它的with和height来计算RAM中消耗的字节大小：_bgBitmap。您还可以记录/弹出从资源加载位图所花费的时间。如果它相对较小，那么可能甚至不使用当前的延迟加载？请注意，时序应仅在实际设备上进行，因为BB模拟器的速度比设备快。

黑莓优化 - 从磁盘或RAM的背景图像？

1 个答案: