上下文切換太貴

我寫的視頻處理應用程序和所遇到以下性能問題：大部分在我的應用程序的方法有CPU時間和實時之間的巨大差異。上下文切換太貴

使用DDMS TraceView我已經研究並已發現，這些差異的罪魁禍首是上下文中某些基方法的切換，如MediaCodec.start（）或MediaCodec.dequeueOutputBuffer（）

MediaCodec.start（）例如具有0.7ms的Cpu時間和24.2ms的實時時間。該實時的97％被上下文切換用完。

這不是一個真正的問題，但是這種方法經常被調用，並且它不是唯一出現這種症狀的問題。

我還需要提及的是所有的處理髮生在一個單一的AsyncTask，因此對單個非UI線程。

是上下文切換執行不力，或線程中不可避免的現實的結果呢？

我將非常感謝在這個問題上的任何建議。

來源

2016-03-02 Rakatan

首先，我懷疑時間是否真的花了上下文切換。 MediaCodec.start（）將花費一些時間等待mediaserver進程與視頻驅動程序進行通信，這可能就是您所看到的。（除非你使用的是軟件編解碼器，否則你的過程不會執行任何實際的工作 - 它將IPC請求發送到與服務器硬件解碼器對話的mediaserver。）traceview只是報告它最好的猜測，時間過去了。

二的AsyncTask線程在執行lower priority。由於MediaCodec應該在硬件編解碼器中完成所有繁重的工作，因此這不會影響吞吐量，但可能會對延遲產生影響，因爲調度程序會優先考慮其他線程。如果您擔心性能，請停止使用AsyncTask。您可以自己進行線索管理，也可以使用java.util.concurrent中的助手。第三，如果你真的想知道當涉及多個線程和進程時發生了什麼，你應該使用systrace而不是traceview。可以在here找到使用systrace和自定義跟蹤標記（以觀看CPU內核起飛）的示例。

來源

2016-03-02 19:33:57 fadden

你好@fadden，謝謝你的回覆。我有一個問題，但：我如何檢查我是否使用軟件編解碼器或硬件？我正在配置編解碼器，如下所示： String mime = format.getString（MediaFormat.KEY_MIME）; try {解碼器= MediaCodec.createDecoderByType（mime）; }趕上（IOException的發送）{e.printStackTrace （）; } decoder.configure（format，outputSurface.getSurface（），null，0）; 視頻即時解碼是一個標準的Android攝像頭的MP4視頻 – Rakatan

你通常可以通過查看解碼器的名稱，例如告訴「OMX.google.h264.encoder」是軟件，而「OMX.qcom.video.encoder.avc」是硬件。我不知道是否有更好的方法。 – fadden

編解碼器確實是硬件。 OMX.qcom.video.decoder.avc。所以我想我沒有什麼可以嘗試的。我已經使用ExecutorService將處理移至了默認優先級線程，但它並沒有真正的幫助。 – Rakatan

上下文切換太貴

回答

相關問題