在Android上解码Java或C/C++中的Airplay数据包

前端之家收集整理的这篇文章主要介绍了在Android上解码Java或C/C++中的Airplay数据包前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在为一个 Android应用程序的子部分工作AirPlay接收器.我使用以下框架:

https://github.com/pentateu/DroidAirPlay

虽然这在一些中档设备(如miPad)上运行良好,但我们需要在低规格的自定义设备上运行.自定义设备正在以比miPad慢10倍到20倍的速度解码airplay数据包.结果,音频分组失去时间同步,并且由于解码分组所花费的时间,音频永远不会重新同步.

我正在寻找Play商店中的其他一些airplay接收器应用程序,从我可以看到它们倾向于基于Shairport(https://github.com/abrasive/shairport)用于播放接收器方面.

**注意:**基于Shairport的框架似乎不会在低端设备上遇到同步问题.

我使用的框架很大程度上基于Shairport框架,除了它是用Java编写的.

对于解码数据,C/C++远远优于Java吗?

如果是这样,使用NDK通过C或C实现指导DroidAirPlay框架的解码部分会给我带来很大的性能提升吗?

提前致谢

马特

解决方法

虽然Java编译为在虚拟机中运行的字节码,但它可能不一定比本机编译的可执行文件(无论是否为C/C++)更慢(或更快).这一切都取决于程序!

在这种情况下,Java可能会变慢,原因有很多:

>解码实现可能只是编码/优化不佳? (这不是Java的错)
> Java编译器可能会为JVM生成次优代码.
> Java的一些语言结构对于此处的速度/资源要求来说太慢了.
> JVM只是另一个抽象层和罪魁祸首
>垃圾收集在上面?!

(我必须在这里注意,我不是Java的专家!)

但是,我仍然不会调用Java本质上比C或C慢.我相信你可以在互联网上找到many-a benchmarks和测试,比较一种语言和另一种语言,有些人声称在一定程度上(出于骄傲和自我?).但这些测试只是特定情况,通常测试较大语言的特定方面(例如哈希映射查找性能!).

LLVM在C上有一个three part blog post,为什么未定义的行为允许编译器生成仍然正确但更有效的代码,代价是推断运行时安全检查或决定i 1总是在i之后,完全忽略整数溢出的存在.如果程序员不小心,这可能会带来灾难性的后果.

用Bjarne自己在Abstraction and the C++ machine model的话来说:

C++ was designed to be a systems programming language and has been used for
embedded systems programming and other resource-constrained types of
programming since the earliest days.

因此,我认为C和C可以比Java更进一步,因为这种不确定的行为和对它的限制较少. (而且还有内联汇编位,但这不是严格的C!)

猜你在找的Android相关文章