Android Native 内存泄漏系统化解决方案

导读：C++内存泄漏问题的分析、定位一直是Android平台上困扰开发人员的难题。由于地图渲染、导航等核心功能对性能要求很高，高德地图APP中存在大量的C++代码。解决这个问题对于产品质量尤其重要和关键，高德技术团队在实践中造成了一套本身的解决方案。

分析和定位内存泄漏问题的核心在于分配函数的统计和栈回溯。若是只知道内存分配点不知道调用栈会使问题变得格外复杂，增长解决成本，所以二者缺一不可。

Android中Bionic的malloc_debug模块对内存分配函数的监控及统计是比较完善的，可是栈回溯在Android体系下缺少高效的方式。随着Android的发展，Google也提供了栈回溯的一些分析方法，可是这些方案存在下面几个问题：

1.栈回溯的环节都使用的libunwind，这种获取方式消耗较大，在Native代码较多的状况下，频繁调用会致使应用很卡，而监控全部内存操做函数的调用栈正须要高频的调用libunwind的相关功能。

2.有ROM要求限制，给平常开发测试带来不便。

3.用命令行或者DDMS进行操做，每排查一次需准备一次环境，手动操做，最终结果也不够直观，同时缺乏对比分析。

所以，如何进行高效的栈回溯、搭建系统化的Android Native内存分析体系显得格外重要。

高德地图基于这两点作了一些改进和扩展，通过这些改进，经过自动化测试可及时发现并解决这些问题，大幅提高开发效率，下降问题排查成本。

1、栈回溯加速

Android平台上主要采用libunwind来进行栈回溯，能够知足绝大多数状况。可是libunwind实现中的全局锁及unwind table解析，会有性能损耗，在多线程频繁调用状况下会致使应用变卡，没法使用。

加速原理

编译器的-finstrument-functions编译选项支持编译期在函数开始和结尾插入自定义函数，在每一个函数开始插入对__cyg_profile_func_enter的调用，在结尾插入对__cyg_profile_func_exit的调用。这两个函数中能够获取到调用点地址，经过对这些地址的记录就能够随时获取函数调用栈了。

插桩后效果示例：

这里须要格外注意，某些不须要插桩的函数可使用__attribute__((no_instrument_function))来向编译器声明。

如何记录这些调用信息？咱们想要实现这些信息在不一样的线程之间读取，并且不受影响。一种办法是采用线程的同步机制，好比在这个变量的读写之处加临界区或者互斥量，可是这样又会影响效率了。

能不能不加锁？这时就想到了线程本地存储，简称TLS。TLS是一个专用存储区域，只能由本身线程访问，同时不存在线程安全问题，符合这里的场景。

因而采用编译器插桩记录调用栈，并将其存储在线程局部存储中的方案来实现栈回溯加速。具体实现以下：

1.利用编译器的-finstrument-functions编译选项在编译阶段插入相关代码。

2.TLS中对调用地址的记录采用数组+游标的形式，实现最快速度的插入、删除及获取。

定义数组+游标的数据结构：

typedef struct {
    void* stack[MAX_TRACE_DEEP];
    int current;
} thread_stack_t;

初始化TLS中thread_stack_t的存储key：

static pthread_once_t sBackTraceOnce = PTHREAD_ONCE_INIT;

static void __attribute__((no_instrument_function))
destructor(void* ptr) {
    if (ptr) {
        free(ptr);
    }
}

static void __attribute__((no_instrument_function))
init_once(void) {
    pthread_key_create(&sBackTraceKey, destructor);
}

初始化thread_stack_t放入TLS中：

get_backtrace_info() {
    thread_stack_t* ptr = (thread_stack_t*) pthread_getspecific(sBackTraceKey);
    if (ptr)
        return ptr;

    ptr = (thread_stack_t*)malloc(sizeof(thread_stack_t));
    ptr->current = MAX_TRACE_DEEP - 1;
    pthread_setspecific(sBackTraceKey, ptr);
    return ptr;
}

3.实现__cyg_profile_func_enter和__cyg_profile_func_exit，记录调用地址到TLS中。

void __attribute__((no_instrument_function))
__cyg_profile_func_enter(void* this_func, void* call_site) {
    pthread_once(&sBackTraceOnce, init_once);
    thread_stack_t* ptr = get_backtrace_info();
    if (ptr->current > 0)
        ptr->stack[ptr->current--] = (void*)((long)call_site - 4);
}

void __attribute__((no_instrument_function))
__cyg_profile_func_exit(void* this_func, void* call_site) {
    pthread_once(&sBackTraceOnce, init_once);
    thread_stack_t* ptr = get_backtrace_info();
    if (++ptr->current >= MAX_TRACE_DEEP)
        ptr->current = MAX_TRACE_DEEP - 1;
}
}

__cyg_profile_func_enter的第二个参数call_site就是调用点的代码段地址，函数进入的时候将它记录到已经在TLS中分配好的数组中，游标ptr->current左移，待函数退出游标ptr->current右移便可。

逻辑示意图：

记录方向和数组增加方向不一致是为了对外提供的获取栈信息接口更简洁高效，能够直接进行内存copy以获取最近调用点的地址在前、最远调用点的地址在后的调用栈。

4.提供接口获取栈信息。

get_tls_backtrace(void** backtrace, int max) {
    pthread_once(&sBackTraceOnce, init_once);
    int count = max;
    thread_stack_t* ptr = get_backtrace_info();
    if (MAX_TRACE_DEEP - 1 - ptr->current < count) {
        count = MAX_TRACE_DEEP - 1 - ptr->current;
    }
    if (count > 0) {
        memcpy(backtrace, &ptr->stack[ptr->current + 1], sizeof(void *) * count);
    }
    return count;
}

5.将上面逻辑编译为动态库，其余业务模块都依赖于该动态库编译，同时编译flag中添加-finstrument-functions进行插桩，进而全部函数的调用都被记录在TLS中了，使用者能够在任何地方调用get_tls_backtrace(void** backtrace, int max)来获取调用栈。

效果对比（采用Google的benchmark作性能测试，手机型号：华为畅想5S，5.1系统）：

• libunwind单线程

• TLS方式单线程获取

• libunwind 10个线程

• TLS方式 10个线程

从上面几个统计图能够看出单线程模式下该方式是libunwind栈获取速度的10倍，10个线程状况下是libunwind栈获取速度的50-60倍，速度大幅提高。

优缺点

• 优势: 速度大幅提高，知足更频繁栈回溯的速度需求。
• 缺点: 编译器插桩，体积变大，不能直接做为线上产品使用，只用于内存测试包。这个问题能够经过持续集成的手段解决，每次项目出库将C++项目产出普通库及对应的内存测试库。

2、体系化

通过以上步骤能够解决获取内存分配栈慢的痛点问题，再结合Google提供的工具，如DDMS、adb shell am dumpheap -n pid /data/local/tmp/heap.txt 命令等方式能够实现Native内存泄漏问题的排查，不过排查效率较低，须要必定的手机环境准备。

因而，咱们决定搭建一整套体系化系统，能够更便捷的解决此类问题，下面介绍下总体思路：

• 内存监控沿用LIBC的malloc_debug模块。不使用官方方式开启该功能，比较麻烦，不利于自动化测试，能够编译一份放到本身的项目中，hook全部内存函数，跳转到malloc_debug的监控函数leak_xxx执行，这样malloc_debug就监控了全部的内存申请/释放，并进行了相应统计。
• 用get_tls_backtrace实现malloc_debug模块中用到的__LIBC_HIDDEN__ int32_t get_backtrace_external(uintptr_t* frames, size_t max_depth)，恰好同上面说的栈回溯加速方式结合。
• 创建Socket通讯，支持外部程序经由Socket进行数据交换，以便更方便获取内存数据。

•搭建Web端，获取到内存数据上传后能够被解析显示，这里要将地址用addr2line进行反解。

• 编写测试Case，同自动化测试结合。测试开始时经过Socket收集内存信息并存储，测试结束将信息上传至平台解析，并发送评估邮件。碰到有问题的报警，研发同窗就能够直接在Web端经过内存曲线及调用栈信息来排查问题了。

系统效果示例：

---

本文做者：高德技术小哥

阅读原文

本文为云栖社区原创内容，未经容许不得转载。