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

导读: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端通过内存曲线及调用栈信息来排查问题了。

系统效果示例:

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 分析Android内存泄漏的几种可能

    前言 内存泄漏简单地说就是申请了一块内存空间,使用完毕后没有释放掉.它的一般表现方式是程序运行时间越长,占用内存越多,最终用尽全部内存,整个系统崩溃.由程序申请的一块内存,且没有任何一个指针指向它,那么这块内存就泄露了. 从用户使用程序的角度来看,内存泄漏本身不会产生什么危害,作为一般的用户,根本感觉不到内存泄漏的存在.真正有危害的是内存泄漏的堆积,这会最终消耗尽系统所有的内存.从这个角度来说,一次性内存泄漏并没有什么危害,因为它不会堆积,而隐式内存泄漏危害性则非常大,因为较之于常发性和偶发性内

  • Android 有效的解决内存泄漏的问题实例详解

    Android 有效的解决内存泄漏的问题 Android内存泄漏,我想做Android 应用的时候遇到的话很是头疼,这里是我在网上找的不错的资料,实例详解这个问题的解决方案 前言:最近在研究Handler的知识,其中涉及到一个问题,如何避免Handler带来的内存溢出问题.在网上找了很多资料,有很多都是互相抄的,没有实际的作用. 本文的内存泄漏检测工具是:LeakCanary  github地址:https://github.com/square/leakcanary 什么是内存泄漏? 内存泄漏

  • Android内存泄漏终极解决篇(上)

    一.概述 在Android的开发中,经常听到"内存泄漏"这个词."内存泄漏"就是一个对象已经不需要再使用了,但是因为其它的对象持有该对象的引用,导致它的内存不能被回收."内存泄漏"的慢慢积累,最终会导致OOM的发生,千里之堤,毁于蚁穴.所以在写代码的过程中,应该要注意规避会导致"内存泄漏"的代码写法,提高软件的健壮性. 本文将从发现问题.解决问题.总结问题的三个角度出发,循序渐进,彻底解决"内存泄漏"的问题

  • 浅谈Android应用的内存优化及Handler的内存泄漏问题

    一.Android内存基础 物理内存与进程内存 物理内存即移动设备上的RAM,当启动一个Android程序时,会启动一个Dalvik VM进程,系统会给它分配固定的内存空间(16M,32M不定),这块内存空间会映射到RAM上某个区域.然后这个Android程序就会运行在这块空间上.Java里会将这块空间分成Stack栈内存和Heap堆内存.stack里存放对象的引用,heap里存放实际对象数据. 在程序运行中会创建对象,如果未合理管理内存,比如不及时回收无效空间就会造成内存泄露,严重的话可能导致

  • Android 内存溢出和内存泄漏的问题

    Android 内存溢出和内存泄漏的问题 在面试中,经常有面试官会问"你知道什么是内存溢出?什么是内存泄漏?怎么避免?"通过这篇文章,你可以回答出来了. 内存溢出 (OOM)是指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory:比如只申请了一个integer,但给它存了long才能存下的数,那就会出现内存溢出. 内存泄露 (memory leak)是指程序在申请内存后,无法释放已申请的内存空间,一次内存泄露危害可以忽略,但内存泄露堆积后果很严重,无论多少内存

  • Android 内存泄漏的几种可能总结

    Java是垃圾回收语言的一种,其优点是开发者无需特意管理内存分配,降低了应用由于局部故障(segmentation fault)导致崩溃,同时防止未释放的内存把堆栈(heap)挤爆的可能,所以写出来的代码更为安全. 不幸的是,在Java中仍存在很多容易导致内存泄漏的逻辑可能(logical leak).如果不小心,你的Android应用很容易浪费掉未释放的内存,最终导致内存用光的错误抛出(out-of-memory,OOM). 一般内存泄漏(traditional memory leak)的原因

  • Android内存泄漏终极解决篇(下)

    一.概述 在 Android内存泄漏终极解决篇(上)中我们介绍了如何检查一个App是否存在内存泄漏的问题,本篇将总结典型的内存泄漏的代码,并给出对应的解决方案.内存泄漏的主要问题可以分为以下几种类型: 静态变量引起的内存泄漏 非静态内部类引起的内存泄漏 资源未关闭引起的内存泄漏 二.静态变量引起的内存泄漏 在java中静态变量的生命周期是在类加载时开始,类卸载时结束.换句话说,在android中其生命周期是在进程启动时开始,进程死亡时结束.所以在程序的运行期间,如果进程没有被杀死,静态变量就会一

  • Android常见的几种内存泄漏小结

    一.背景 最近在项目的版本迭代中,出现了一些内存问题的小插曲,然后自己花了一些时间优化了APP运行时内存大小的问题,特此做个总结,与大家分享. 二.简介 在Android程序开发中,当一个对象已经不需要再使用了,本该被回收时,而另外一个正在使用的对象持有它的引用从而导致它不能被回收,这就导致本该被回收的对象不能被回收而停留在堆内存中,内存泄漏就产生了.内存泄漏有什么影响呢?它是造成应用程序OOM的主要原因之一.由于Android系统为每个应用程序分配的内存有限,当一个应用中产生的内存泄漏比较多时

  • Android开发:浅谈MVP模式应用与内存泄漏问题解决

    最近博主开始在项目中实践MVP模式,却意外发现内存泄漏比较严重,但却很少人谈到这个问题,促使了本文的发布,本文假设读者已了解MVP架构. MVP简介 M-Modle,数据,逻辑操作层,数据获取,数据持久化保存.比如网络操作,数据库操作 V-View,界面展示层,Android中的具体体现为Activity,Fragment P-Presenter,中介者,连接Modle,View层,同时持有modle引用和view接口引用 示例代码 Modle层操作 public class TestModle

  • 详解Android内存泄漏检测与MAT使用

    内存泄漏基本概念 内存检测这部分,相关的知识有JVM虚拟机垃圾收集机制,类加载机制,内存模型等.编写没有内存泄漏的程序,对提高程序稳定性,提高用户体验具有重要的意义.因此,学习Java利用java编写程序的时候,要特别注意内存泄漏相关的问题.虽然JVM提供了自动垃圾回收机制,但是还是有很多情况会导致内存泄漏. 内存泄漏主要原因就是一个生命周期长的对象,持有了一个生命周期短的对象的引用.这样,会导致短的对象在该回收时候无法被回收.Android中比较典型的有:1.静态变量持有Activity的co

随机推荐