记一次 Android 周期性句柄泄漏的排查

滴滴国际化外卖 Android 商户端正常迭代版本过程中，新版本发布并且线上稳定一段时间后，突然触发线上 Crash 报警。

第一次排查发现是在依赖的底层平台 so 库中崩溃，经过沟通了解到其之前也存在过崩溃问题，所以升级相关底层 so 版本。重新发版后短期没有出现 Crash 大面积上报情况，只有零星上报，但不久后又发生了第二次大面积 Crash 上报。具体信息如下图所示：

在定位分析问题的过程中收获很多，通过这篇文章分享该 Crash 的排查过程、问题根因以及一些经验总结，希望能为读者在遇到同类型问题时提供一些参考。    

排查流程

Crash 描述

Crash 的量级，从两次高峰期的峰值来看，集中爆发的峰值为每日50次左右，第二次爆发的峰值最高为173次。同时，Crash 和影响用户数量是一比一。

两次大面积爆发的问题设备集中在华为的三款机型，运行时间都在14天左右，内存情况正常，线程情况正常，此时还没有相关线索指向句柄，所以这个时候没有关注句柄，如下图：

定位分析

从整体的 Crash 描述以及 Crash 统计平台的相关数据来分析，每隔14天就大面积爆发一次，可以确定是周期性问题，这种问题的排查难度较高。

根据上报的错误日志，明确其崩溃位置是在底层的 libpush.so 库，同时和其维护的同学沟通后发现依赖的 so 版本出现过问题，所以我们在第一次大面积上报之后，升级了底层 so 库版本。虽然当时增发版本后没有明显的 Crash 上报，但还是存在零星的 Crash 上报，这让我们放松了警惕，未对问题的根因进行定位，才导致了后面更严重的第二次爆发。

第二次爆发后，通过分析 Crash 统计平台上的173次 Crash 日志信息发现，Crash 代码地址都是“000000000007ce08”，如下图，由于静态库中的代码地址都是固定的，所以对底层 so 库进行了代码定