为什么android的String.format狗慢？

Question

我正在使用自定义绘制视图实现 ListView 活动，并具有以下代码：

@Override
public void onDraw(Canvas canvas)
{
    super.onDraw(canvas);
    ....
    canvas.drawText(String.format("%02d: %dx%d", position, w, h),
        10, 15, cached_paint);
}

onDraw 方法中几乎没有其他内容，所以这让我很生气为什么滚动效果如此糟糕。偶然我将drawText参数更改为不使用String.format，突然滚动又变成了黄油丝。事实上，以下内容几乎相同但表现良好：

canvas.drawText("" + position + ": " + w + "x" + h,
    10, 15, cached_paint);

我很震惊。为什么后者比调用 String.format 更快？我希望对象串联会生成更多的中间对象，并且总体性能是垃圾，但我发现事实恰恰相反。事实上，当使用 String.format 运行时，我从虚拟机收到了大量分配/释放消息。

那么，为什么 String.format 看起来可以更快（至少在来自对象创建成本昂贵的其他编程语言时）却如此慢？

Answer 1

使用 + 进行字符串连接不会生成大量中间对象；基本上是一个 StringBuffer 及其内部字符数组（如果容量不足，可能会重新分配）。哦，还有连接后的字符串。

此外，使用 + 时，分析进入字符串的对象的数据类型的大部分工作都是在编译时完成的。对于 String.format，这是在运行时完成的。最重要的是，传递给 String.format 的每个基本类型都需要自动装箱，这确实会生成更多的对象。

Answer 2

我惊呆了。

为什么？

为什么后者比调用 String.format 更快？

因为它是用Java编写的。 %02d: %dx%d 不是 Java。每次都必须解析并执行规则。这些规则通过 java.util.Formatter。

现在，可以通过用本机代码 (C/C++) 实现替换 String.format() 来优化它，但我认为 varargs 和 JNI 会变得混乱。

我希望对象串联会生成更多的中间对象，并且总体上会产生垃圾性能，但我发现事实恰恰相反。事实上，当使用 String.format 运行时，我从虚拟机收到了大量分配/释放消息。

这是因为 String.format() 相当复杂并且是用 Java 实现的。

Answer 3

为了获得最佳性能，您可以从 java.text 包创建一个格式化程序并缓存它。

final static DecimalFormat myFormat = new DecimalFormat("###");
@Override
public void onDraw(Canvas canvas)
{
    super.onDraw(canvas);
    ....
    canvas.drawText(myFormat.format(w) + "x" + myFormat(h));
}

为了获得更好的性能，您可以使用更快的字符串连接。但这是一种不同类型的优化，与这个问题无关。