大家都知道，在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，就是在我们想象不到的地方出现的。

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

在播放视频的时候，整个设备的cpu使用率会非常高（90%左右），而AudioHandler使用的内存会不断上涨，也就是发生了所谓的内存泄露。
这还没完，在播放结束的时候，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，但是深层的原因并没有找到：

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