Android上使用leaktracer的经验分享

前言

上周使用了LeakTracer来分析我们项目的SDK的内存问题，最终的成效还算可以。工具能正常使用，通过内存泄漏日志文件中的函数调用堆栈，结合查看源代码找到不少的内存使用不当的问题。我的使用场景是：

1. 在初始化SDK前调用 leaktracer::MemoryTrace::GetInstance().startMonitoringAllThreads()，启动内存监控。
2. 在销毁SDK后再调用leaktracer::MemoryTrace::GetInstance().writeLeaksToFile("/sdcard/rt_leak.log") ，结束内存监控，并输出日志文件
3. 通过日志文件case by case的分析问题

几条干货

跟大家分享下如几点

• 官网的源码收集到的函数地址是进程地址空间的绝对地址，不利于后面的函数符号的解析，这里推荐使用这个哥们优化后的源码 AndroidLeakTracer，主要优化点是，使用dladdr来做地址的转换（绝对地址换成so中的相对地址），有了相对地址，使用add2line工具还有有符号信息的so就能解析出具体的函数调用堆栈点的函数名，还有源文件的行号等信息了
• 接入方式的话我是直接采用了源码的接入方式，把leaktracer源码放在我们SDK工程下跟SDK的源码一起编译并生成so，然后在AS的demo module去使用SDK的so 。有尝试过在demo module的jni层接入，即在demo 的cpp目录下放leaktracer的源码并构建，但始终收集到的日志解析出来的函数调用栈的符号解析不正常！（这个后期有时间需要研究下）
• LeakTracer项目提供的日志文件的解析脚本 leak-analyze-addr2line（perl脚本） 中有使用到add2line命令行工具，所以需要