我正在编写一个视频处理应用程序,遇到以下性能问题:
我的应用程序中的大多数方法在cpu时间和实时之间存在很大差异。

我使用DDMS TraceView进行了调查,发现这些差异的主要原因是某些基本方法(例如MediaCodec.start()或MediaCodec.dequeueOutputBuffer())中的上下文切换。

MediaCodec.start()例如具有0.7ms Cpu时间和24.2ms Real时间。上下文切换用完了97%的实时时间。android - 上下文切换太昂贵-LMLPHP

这不是一个真正的问题,但是该方法经常被调用,并且它不是唯一出现这种症状的方法。

我还需要提到,所有处理都在单个AsyncTask中进行,因此在单个非UI线程中进行。

上下文切换是执行不当还是无法避免的线程现实的结果?

我非常感谢在此问题上的任何建议。

最佳答案

首先,我怀疑时间实际上是在上下文切换上花费的。 MediaCodec.start()将花费一些时间,等待媒体服务器进程与视频驱动程序对话,这可能就是您所看到的。 (除非您使用的是软件编解码器,否则您的过程不会执行任何实际工作,而是将IPC请求发送到与硬件编解码器进行通信的mediaserver。)时间过去了。

其次,AsyncTask线程在lower priority执行。由于MediaCodec应该在硬件编解码器中进行所有繁重的工作,因此这不会影响吞吐量,但是可能会对延迟产生某些影响,因为其他线程将由调度程序确定优先级。如果您担心性能,请停止使用AsyncTask。您可以自己进行线程管理,也可以使用java.util.concurrent中的便捷助手。

第三,如果您真的想知道涉及多个线程和进程时发生了什么,您应该使用systrace,而不是traceview。在here中找到一个使用systrace和自定义跟踪标记(以观察CPU内核旋转)的示例。

10-08 18:05
查看更多