如何阻止GC_CONCURRENT如此頻繁地運行？

我正在使用一個線程，它使用AudioRecord類記錄音頻並放在recorderBUffer（它是Short []）的鏈表中），一個單獨的線程對此數據進行編碼並將其放置到playerBuffer（鏈表[ ]）。爲了播放音頻我使用AudioTrack類和onPeriodicNotification（）我從playerBuffer讀取數據並將其寫入軌道。如何阻止GC_CONCURRENT如此頻繁地運行？

該代碼很簡單，直接顯示。然而，它沒有按照它應該的方式工作。 GC_CONCURRENT一直在吃，這導致AudioTrack頻繁重啓（我猜！）。我從logcat的以下信息： -

04-09 12:25:13.757: E/Constructor(10100): inside constructor 
04-09 12:25:13.757: I/ApplicationPackageManager(10100): cscCountry is not German : INS 
04-09 12:25:17.429: E/startRecording(10100): start Recording 
04-09 12:25:17.445: I/AudioCapturer(10100): Audio Recorder created 
04-09 12:25:17.546: I/Audio Player(10100): Audio Track instance created buffer Size : 2972 
04-09 12:25:17.546: I/SpeexThread(10100): Thread Started Successfully.. 
04-09 12:25:17.734: D/dalvikvm(10100): GC_CONCURRENT freed 55K, 44% free 3208K/5639K, external 408K/517K, paused 4ms+6ms 
04-09 12:25:17.945: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 39% free 3765K/6151K, external 408K/517K, paused 3ms+8ms 
04-09 12:25:18.148: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 36% free 4277K/6663K, external 408K/517K, paused 3ms+8ms 
04-09 12:25:18.414: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 33% free 4981K/7367K, external 408K/517K, paused 3ms+9ms 
04-09 12:25:18.734: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 29% free 5877K/8263K, external 408K/517K, paused 3ms+9ms 
04-09 12:25:18.828: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:19.164: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 26% free 7093K/9479K, external 408K/517K, paused 3ms+9ms 
04-09 12:25:19.710: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 22% free 8693K/11079K, external 408K/517K, paused 3ms+9ms 
04-09 12:25:19.984: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:20.414: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 19% free 10741K/13127K, external 408K/517K, paused 3ms+9ms 
04-09 12:25:21.156: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:21.171: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 16% free 12789K/15175K, external 408K/517K, paused 3ms+11ms 
04-09 12:25:21.976: D/dalvikvm(10100): GC_CONCURRENT freed <1K, 14% free 14837K/17223K, external 408K/517K, paused 3ms+9ms 
// same messages errors continue 
04-09 12:25:28.117: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:29.242: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 8% free 29172K/31559K, external 408K/517K, paused 3ms+11ms 
04-09 12:25:29.273: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:30.445: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:30.507: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 8% free 31220K/33607K, external 408K/517K, paused 4ms+12ms 
04-09 12:25:31.601: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:31.820: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 7% free 33268K/35655K, external 408K/517K, paused 3ms+12ms 
04-09 12:25:32.757: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:33.187: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 7% free 35316K/37703K, external 408K/517K, paused 3ms+13ms 
04-09 12:25:33.929: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:34.593: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 7% free 37364K/39751K, external 408K/517K, paused 4ms+11ms 
04-09 12:25:35.085: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:36.039: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 6% free 39412K/41799K, external 408K/517K, paused 3ms+12ms 
04-09 12:25:36.242: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:37.406: W/AudioTrack(10100): obtainBuffer() track 0x1d0478 disabled, restarting 
04-09 12:25:37.617: D/dalvikvm(10100): GC_CONCURRENT freed 1K, 6% free 41460K/43847K, external 408K/517K, paused 5ms+13ms 
04-09 12:25:38.640: D/dalvikvm(10100): GC_FOR_MALLOC freed 1K, 6% free 43507K/45895K, external 408K/517K, paused 933ms 
04-09 12:25:38.656: I/SpeexThread(10100): exitting Thread 
04-09 12:25:38.656: E/stopRecording(10100): stop Recording

的AudiTrack每隔幾毫秒重新啓動，垃圾收集幾乎是連續調用。我怎樣才能最大限度地減少GArbage Colloection調用，以及AudioTrack重啓後的原因是什麼？ plz幫助...

來源

2012-04-09 aProgrammer

親愛downvoter，如果他們的一些問題，請發表評論，這樣我可以改進的問題和學習...謝謝！ – aProgrammer 2012-04-10 06:39:38

感謝你有一個垃圾收集器老兄，你不想阻止它，它的清理是因爲你的實現有問題，你需要使用AudioTrack發佈一些代碼以獲得更多幫助。（我不downvoter） – Rob 2012-04-11 14:58:24

@Rob，謝謝...我仍然在研究同樣的問題...不久我會發布我的進度... – aProgrammer 2012-04-12 05:27:25

一個temporaral問題的解決方案是通過使用dalvik.system.VMRuntime.getRuntime().setMinimumHeapSize(32 * 1024 * 1024);增加HEAPSIZE但是這種做法是不建議，並應避免。

通過廣泛的調試我發現真正的問題是由於重疊接口和一些泄漏功能。後來我刪除接口之一，重新設計的整體解決方案和重新分解的代碼和解決我的問題。

如果你有一些其他的解決辦法，請分享，

來源

2012-04-12 07:38:31 aProgrammer

非常好，謝謝你分享。 – Rob 2012-04-12 15:02:56

我有同樣的問題，你可以請張貼一些您的修補程序的樣本？我知道他們可能是特定的，但可能仍然有用。謝謝 – Onheiron 2012-06-08 12:36:17

我只是在onCreate（）裏面增加了上面這行代碼來增加內存大小。它工作，但是後來你需要重構你的代碼，以便優化內存使用... – aProgrammer 2012-06-11 05:05:05

如何阻止GC_CONCURRENT如此頻繁地運行？

回答

相關問題