ByteBuffer / IntBuffer / ShortBuffer Java类是否快速?

前端之家收集整理的这篇文章主要介绍了ByteBuffer / IntBuffer / ShortBuffer Java类是否快速?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我正在研究Android应用程序(显然是Java),最近我更新了我的UDP阅读器代码.在这两个版本中,我设置了一些缓冲区并接收UDP数据包:

byte[] buf = new byte[10000];
short[] soundData = new short[1000];
DatagramPacket packet = new DatagramPacket (buf,buf.length);
socket.receive (packet);

在初始版本中,我将数据一次放回一个字节(实际上是16个PCM音频数据):

for (int i = 0; i < count; i++)
    soundData[i] = (short) (((buf[k++]&0xff) << 8) + (buf[k++]&0xff));

在更新的版本中,我使用了一些我开始时不知道的很酷的Java工具:

bBuffer  = ByteBuffer.wrap (buf);
sBuffer  = bBuffer.asShortBuffer();
sBuffer.get (soundData,count);

在这两种情况下,“计数”正在正确填充(我检查过).然而,我的流媒体音频似乎出现了新的问题 – 也许它的处理速度不够快 – 这对我来说没有任何意义.显然,缓冲区代码正在编译成三个以上的JVM代码语句,但是当我开始这个时,第二个版本会比第一个版本更快,这似乎是一个合理的假设.

很明显,我并不是说我的代码必须使用Java NIO缓冲区,但至少乍一看,它看起来似乎很难做到这一点.

任何人都有一个快速,简单的Java UDP阅读器的建议,以及是否有一个普遍接受的“最佳方式”?

谢谢,
R.

最佳答案
通常,直接使用基本类型比使用对象更有效,因为您避免了创建对象,函数调用等的一些开销.

有理由使用速度以外的实用程序对象:方便性,安全性等.

在这种特殊情况下测试差异的最佳方法是实际测量它.尝试使用大型数据集的两种方法并计时.然后,您可以决定在这种情况下是否值得获益.

您还可以使用Android的分析器来查看问题的确切位置.见TraceView.

猜你在找的Android相关文章