我非常深入地开发我的 Android 应用程序，当我第二次弄乱我的音频文件以尝试更长的音频剪辑（1000 毫秒长）时，我现在又遇到了音频故障。在我没有遇到 160 毫秒长的文件出现任何故障之前。
没有进入我的代码，我只是想知道文件大小或文件类型是否对性能有任何影响？我相信我正在使用示例Player渲染类（源）（用于原始文件输入），它似乎在每个回调中加载文件的音频数据。这可能会从更大的数组中加载数据会减慢速度？虽然，它也可能是我添加到回调中的新功能/逻辑。
我知道人们经常谈论使用 mp3 和使用 FFmpeg 解码。有没有人在 mp3 和 raw 之间进行过任何基准测试，使用 mp3 是否有任何性能优势，或者主要是为了减少您的 APK 大小？
抱歉，如果这已在某处讨论过，但是，我无法找到任何文章提到这两种文件类型之间的这一方面。更仔细地观察渲染类，我的直觉告诉我文件大小“不应该”是一个因素......否则我会继续调试，如果可以的话，可能会得到一些系统跟踪。
要使用@llogan 的建议来回答，这里有一些使用 ffmpeg 命令行实用程序的基准：
mp3：
ffmpeg -benchmark -i sound.mp3 -f null -
ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libavresample 3. 7. 0 / 3. 7. 0
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
Input #0, mp3, from 'sound.mp3':
Duration: 00:00:01.03, start: 0.023021, bitrate: 121 kb/s
Stream #0:0: Audio: mp3, 48000 Hz, stereo, s16p, 121 kb/s
Metadata:
encoder : LAME3.100
Stream mapping:
Stream #0:0 -> #0:0 (mp3 (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf57.83.100
Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Metadata:
encoder : Lavc57.107.100 pcm_s16le
size=N/A time=00:00:01.00 bitrate=N/A speed=83.6x
video:0kB audio:188kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=0.008s
bench: maxrss=37292kB
生的：
ffmpeg -benchmark -f s16le -channels 2 -sample_rate 44100 -i sound.raw -f null -
ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libavresample 3. 7. 0 / 3. 7. 0
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
[s16le @ 0x56493de82c00] Estimating duration from bitrate, this may be inaccurate
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, s16le, from 'sound.raw':
Duration: 00:00:01.09, bitrate: 1411 kb/s
Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (pcm_s16le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf57.83.100
Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
Metadata:
encoder : Lavc57.107.100 pcm_s16le
size=N/A time=00:00:01.08 bitrate=N/A speed= 819x
video:0kB audio:188kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=0.001s
bench: maxrss=36752kB
通过这些结果，（如果我没看错的话）它似乎比.raw7ms.mp3快了。在内存消耗方面，.raw节拍.mp31 MB。如果使用 48000 流速率进行解码.raw，则.mp3内存消耗会减少 2 MB。
使用这些数据，似乎使用 Raw 在技术上可能会更快，尽管 mp3 具有文件大小非常紧凑的优势。所以对我来说，我的文件大小相对较小（190kB x 9 个文件），这不是一个很大的因素。话虽如此，加载声音文件的时间不到 10 毫秒并不可怕，我认为这不会影响您的应用程序的性能。
如果您正在制作节拍器应用程序，大概您只是在播放与用户选择的节奏同步的“咔哒”声。
如果是这样，我的建议是将您的“点击”声音存储在 MP3 中，在应用程序启动时将其解码到内存中，然后通过监控音频流回调中请求的帧数在正确的时间播放它。
MP3 的解码时间变得无关紧要，因为您不是实时进行的。
与任何压缩 mp3 文件相比，始终 RAW PCM 将播放得更快。
Mp3 文件包含 - mp3 编码数据 - 需要解码为原始 PCM，然后由任何播放器播放。
与 mp3 文件（压缩）相比，RAW PCM 文件（未压缩）的尺寸更大。
如果您将此文件与 APK 捆绑在一起，则 APK 的大小会发生变化。