AndroidNative内存泄漏系统化的解决方案是什么-创新互联

今天给大家介绍一下AndroidNative内存泄漏系统化的解决方案是什么。文章的内容小编觉得不错，现在给大家分享一下，觉得有需要的朋友可以了解一下，希望对大家有所帮助，下面跟着小编的思路一起来阅读吧。

10余年的囊谦网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整囊谦建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联从事“囊谦网站设计”,“囊谦网站推广”以来，每个客户项目都认真落实执行。

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

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

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

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

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

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

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

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

一、栈回溯加速

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++项目产出普通库及对应的内存测试库。

二、体系化

经过以上步骤可以解决获取内存分配栈慢的痛点问题，再结合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端通过内存曲线及调用栈信息来排查问题了。

以上就是AndroidNative内存泄漏系统化的解决方案是什么的全部内容了，更多与AndroidNative内存泄漏系统化的解决方案是什么相关的内容可以搜索创新互联网站建设公司，之前的文章或者浏览下面的文章进行学习哈！相信小编会给大家增添更多知识,希望大家能够支持一下创新互联网站建设公司，！

当前文章：AndroidNative内存泄漏系统化的解决方案是什么-创新互联
网站路径：http://cqcxhl.com/article/dsijpp.html