【简介】

   之前在做一个无埋点SDK相关开发的时候，由于上报逻辑比较复杂，故而想到了用hander队列的形式处理事件的上报，但是SDK上线之后，发现出了一个句柄泄漏的bug，百思不得其解，后来看了Handler的底层源码，又做了一些句柄数的追踪和分析，解决了这个问题。

    一、Handler在java层的机制

    如下图，handler的应用层机制很简单，不同的线程通过handler，发送message到messageQueue里面，对应的Looper开启一个死循环，然后一直轮询，如果队列里有待处理的消息，就处理消息；如果没有消息，则开始休眠，节约资源。个中细节就不在赘述，如有需要，可以自行搜索相关资料。

Handler的应用层机制

    二、Handler的native层机制

    我们首先来看Looper.loop()的源码

Looper.loop()源码

    我们发现，在这个死循环里，它调用了MessageQueue下的next方法，那么我们再看看这个next方法干了些什么：

MessageQueue的next()方法

    关键方法是这个nativePollOnce()：当运行到这里时，会调用native层的方法，系统去轮询一次，如果MessageQueue当前没有要处理的Message，则线程休眠，不占用资源，这里为什么休眠不会产生ANR呢，我们后面会分析。

    我们现在注意一下nextPollTimeoutMillis这个变量，这个变量代表MessageQueue下次被唤醒的时间。我们知道，MessageQueue里Message在加入队列的时候，会按照执行的时间顺序排列；每次消息入队列时，MessageQueue都会尽量计算出一个精确的时间，假如这个时间是计算出来是2000ms，此时消息队列中没有消息需要马上处理时，会判断用户是否设置了Idle Handler，如果有的话，则会尝试处理mIdleHandlers中所记录的所有Idle Handler，此时会逐个调用这些Idle Handler的queueIdle()成员函数，只会会再次调用nativePollOnce()方法，线程阻塞住，不占用资源。当时间到了，会往管道流中写入字节流，唤醒线程，处理Message。

    我们知道，安卓的底层是Linux系统。当Looper休眠时，用的是底层的epoll机制来完成阻塞动作，故而不会产生ANR。

    源码的唤醒调用如图：

MessageQueue.cpp的nativeWake()

    最终调用了Looper.cpp源码的wake()方法

Lopper.cpp的wake()方法

    我们可以看到，唤醒只是往管道流里写了一个”w”的字符流。所以唤醒机制，我们可以直观的理解为：

唤醒机制

    在Linux底层，每个线程所能操作的句柄上限是1024个，一旦超过了这个值，则会报句柄泄漏的错误，导致崩溃。

    所以，是不是我们的上报无埋点的数据时，频繁的休眠唤醒导致句柄数超过了上限呢？

    三、查看线程的句柄数

    我们需要一个root了的手机，如果手头没有能用的测试机，可以使用模拟器。

    我用了一个低版本的模拟器（5.0版本），因为高版本的模拟器也不好直接获取root。

    我们先要获取进程的id，这个可以通过AS的Logcat查看。

    之后通过adb shell进入模拟器，cd到/proc/进程id/fd文件夹下，然后ls -al，就可以在Logcat中打印出当前线程所消耗的句柄。如果你没有root权限，fd文件夹是访问不了的。

    笔者在启动APP后，正常使用了一下APP，接着打印出了当前程序占用的句柄数，发现有800多个句柄开销，大多数是数据库所持有的，搞了半天原来是数据库的问题。但是为了防止意外，笔者已经把SDK中的所有Handler替换掉了。

    四、总结

    在android开发中，我们的这些操作会消耗句柄数：

    1.数据库的读写，不关及时关流会导致句柄开销增大；

    2.文件流的读写，如果操作不好，也容易导致句柄消耗过大；

    3.Handler频繁唤醒等。

    一旦出现句柄泄漏的问题，核心思想就去排查流的读写有没有出问题。因为在安卓底层，Linux对于句柄的操作很多都是通过流来体现的，如果句柄数超过了上限，肯定会出问题。