我正在使用MediaCodec播放1080p @ 60fps视频。这是使用Android Lollipop 5.1的飞思卡尔SabreSD平台。
最初由于BufferQueue同步模式，FPS低于60.我现在可以通过将BufferQueue更改为与JB中的异步来设置为70FPS。
现在我面临的下一个挑战是视频滞后，当我开始与屏幕交互时，FPS急剧下降到40（拉下通知栏，按下音量按钮等）。
所以我运行了rafika MultiSurfaceActivity和Record GL，当没有触摸或打扰屏幕时，我可以看到所有的测试都能顺利播放，但是一旦我开始从顶部滚动通知栏并长时间继续，fps就会得到减少到35-40FPS。
我已经在Kitkat 4.4.2和JB 4.2.2上确认了相同的测试，它们似乎工作正常。
从Gallery中播放MP4时的行为相同。当我们开始使用通知栏
时，视频会卡住并且滞后很多任何人都可以解释从Kitkat到Lollipop有什么变化可能会导致这个问题（VSync，Triple Buffering？）。
答案 0 :(得分：1)
弹跳球是软件渲染的，所以任何吸收CPU时间的东西都会让它变慢。在具有中级CPU和大显示器（例如Nexus 10）的设备上，它永远不会接近60fps。因此，当你正在使用导航栏时减速并不会让我感到惊讶，但如果它在你停止使用导航栏后仍然很慢，那么那就是一点点怪异。
视频播放受影响较小，因为CPU的影响较小。
对此类问题的调查通常首先使用systrace来捕获＆＃34; good＆＃34;中的痕迹。并且＆＃34;坏＆＃34;陈述，比较两者。
BufferQueue的关键点＆＃34;异步模式＆＃34;如果消费者无法跟上生产者的话，那就是允许框架下降。它主要用于SurfaceTexture，其中生产者和消费者在同一个应用程序中，可能在同一个线程上，因此让生产者停顿等待消费者可能导致程序挂起。我不确定你的意思是需要它超过60fps，但我猜你在显示器上丢帧的速度要快于渲染帧...所以你并没有真正增加帧率，您只是使用BufferQueue来删除帧而不是使用Choreographer来决定何时需要自己删除它们。
无论如何，在Lollipop完成之前，我已于2014年6月离开Google。如果KitKat上的某些功能正常，但棒棒糖很奇怪，我恐怕无法提供很多见解。如果您可以轻松地重现行为，那么可能需要捕获一个演示该问题的视频（指出设备上出现问题的第二部智能手机，以便他们可以看到您如何操作设备）并在{{3上提交错误}}
OP上传的一些痕迹：
查看kitkat跟踪，SurfaceFlinger中发生了一些奇怪的事情。主线位于postFrameBuffer很长一段时间（23-32ms）。它最终会被唤醒，并且CPU行表明它正在等待来自＆＃34; galcore守护程序＆＃34;的活动，这是我不熟悉的（似乎特别针对Vivante GPU）。
棒棒糖痕迹仅显示CPU行，就好像捕获是在没有必要标记的情况下完成的。我不相信kitkat和棒棒糖之间的systrace capture命令发生了显着的变化，所以我很困惑为什么用户空间启动的日志记录会消失，但内核线程调度的东西仍会存在。确保您已指定sched gfx view。
较新的棒棒糖痕迹只有大约一秒的好数据。当你看到＆＃34;没有完成＆＃34;它意味着一个＆＃34;开始＆＃34;记录没有匹配＆＃34;结束＆＃34;记录。您可以使用-b标志增加systrace日志记录缓冲区大小。我认为那里已经足够了。
查看/system/bin/surfaceflinger行，您可以看到＆＃34; good＆＃34;跟踪，postFrameBuffer通常在大约16ms完成，但它仍在等待galcore。放大388ms（使用WASD键）。在388.196ms，在CPU 2行上，你可以看到galcore做了一些事情。完成后，surfaceflinger行顶部的细线从浅灰色（睡眠）变为绿色（运行）。在388.548ms，再次在CPU 2上，galcore再次运行，然后在surfaceflinger行上，您看到queueBuffer开始执行。
＆＃34;坏＆＃34;跟踪看起来相同。例如，您可以在101.146ms和101.666ms处看到两个galcore执行，其中对surfaceflinger行的效果似乎相似。关键的区别在于postFrameBuffer花费的时间，大约16毫秒，＃34;好＆＃34; ＆＃34;坏＆＃34;约30ms。
所以这似乎不是一种行为转变;相反，事情需要更长的时间，错过最后期限。
据我所知，SurfaceFlinger受到galcore守护进程的阻碍。在＆＃34; good＆＃34;中都是如此。并且＆＃34;坏＆＃34;案例。要查看应的时序，您可以在Nexus设备上运行systrace，或与其他设备（例如https://www.dropbox.com/s/g7qe01xvmfyvpak/kitkat.zip或this case study中的跟踪）进行比较。如果放大，您可以看到doComposition在几毫秒内执行，postFrameBuffer在十分之几毫秒内完成。
总结：你没有好事和坏事，你有坏事和坏事。 :-)我不知道galcore是什么，但你可能需要与GPU OEM进行对话。