07月24, 2016

一次奇葩的Android系统Handler内存泄漏

大家都知道,在Activity之类的组件中使用Handler,容易造成内存泄露,那是由于Handler作为内部类的时候,持有外部Activity的引用,在Activity退出以后,如果Handler还有未完成的工作,则可能导致Activity无法被销毁,内存无法回收。解决办法是将Handler声明为静态内部类,这样就不会持有Activity的引用了,如果Handler需要操作Activity中的对象,则通过弱引用或软引用的方式来引用Activity。

当然如果我要讲的只是这么简单的东西,也不值得用“奇葩”来形容了,先听我描述一下现象。

背景

我要做的是一个语言处理的功能(姑且称其为AudioHandler吧),主要流程是:在service中使用AudioRecord录音,然后不断的将录音的数据传给声音处理模块进行处理。因为要声音处理模块必须对声音进行串行处理,所以最佳的方法是HandlerThread和Handler配合使用。

HandlerThread mConsumerThread = new HandlerThread("MicAudioConsumerThread");
mConsumerThread.start();
Handler mConsumerHandler = new Handler(mConsumerThread.getLooper());

读取录音数据并使用Handler处理的代码如下:

int mReadBufferSize = 3200;
byte[] mReadBuffer = new byte[mReadBufferSize];
int realSize = mAudioRecord.read(mReadBuffer, 0, mReadBufferSize);
mConsumerHandler.post(new Runnable() {
    @Override
    public void run() {
        mAudioDataConsumer.bufferReceived(mReadBuffer, realSize);
    }
});

一切都很顺利,完美!

但是所谓bug,就是在我们想象不到的地方出现的。

问题

测试同学发现这样一种特殊情况:

  1. 在播放视频的时候,整个设备的cpu使用率会非常高(90%左右),而AudioHandler使用的内存会不断上涨,也就是发生了所谓的内存泄露。
  2. 这还没完,在播放结束的时候,AudioHandler程序会完全被卡死,没有任何反应,过一阵子才会恢复正常,设备卡死的期间,AudioHandler和系统的mediaservice进程基本上也会占用cpu90%以上,内存会逐步下降到正常。

从这些现象中,我们做了一个大胆的假设:在播放视频的时候,Handler线程处理任务的速度跟不上新增任务的速度,所以导致了buffer在内存中的堆积,引起内存泄露;而播放完以后,Handler开始处理堆积的任务,导致程序大量消耗cpu时间,产生卡死的现象。

按照这个假设,我对程序做了如下修改:

将HandlerThread和Handler改成Thread和BlockingDeque:

BlockingDeque<Runnable> workQueue = new LinkedBlockingDeque();
Thread mConsumerThread = new Thread(new Runnable() {
    @Override
    public void run() {
        while(isRun) {
            try {
                Runnable runnable = workQueue.takeFirst();
                if (runnable != null) {
                    runnable.run();
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
});
mConsumerThread.start();

读取录音数据并处理改成:

private final static int MAX_DEQUE_SIZE=30;


int mReadBufferSize = 3200;
byte[] mReadBuffer = new byte[mReadBufferSize];
int realSize = mAudioRecord.read(mReadBuffer, 0, mReadBufferSize);
enqueue(new Runnable() {
    @Override
    public void run() {
        mAudioDataConsumer.bufferReceived(mReadBuffer, realSize);
    }
});

private void enqueue(Runnable r) {
    if (workQueue.size()>MAX_DEQUE_SIZE){
        workQueue.pollFirst();//将最老的任务抛弃
    }
    workQueue.offerLast(r);
}

这样修改主要是限制了处理队列中的最大任务数量,如果我们的假设是正确的,就可以一次性解决上面出现的两个bug。后来经过测试,也确实颇有成效。

小结

我们能够做这样的修改的原因,在于语音处理本身的特点是对实时性要求较高的,所以可以把堆积的旧任务抛弃,只处理最新的任务。

虽然我们成功的修复了bug,但是深层的原因并没有找到:

  1. 为什么播放视频结束的时候会卡死,明明是在子线程中处理语音的,ui线程不应该被阻塞。
  2. mediaservice进程cpu使用率为什么在视频结束的时候反而很高。

ps:严格说来确实并不算是内存泄露,只是消费跟不上生产导致不断积累,说是内存堆积更准确。

转载注明出处:十个雨点

本文链接:http://www.siki.space/post/a_strange_handler_mem_leak.html

-- EOF --

Comments