解決Android Native內(nèi)存泄漏系統(tǒng)化的示例分析

這篇文章主要為大家展示了“解決Android Native內(nèi)存泄漏系統(tǒng)化的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“解決Android Native內(nèi)存泄漏系統(tǒng)化的示例分析”這篇文章吧。

導讀：C++內(nèi)存泄漏問題的分析、定位一直是Android平臺上困擾開發(fā)人員的難題。因為地圖渲染、導航等核心功能對性能要求很高，高德地圖APP中存在大量的C++代碼。解決這個問題對于產(chǎn)品質(zhì)量尤為重要和關鍵，高德地圖技術團隊在實踐中形成了一套自己的解決方案。

分析和定位內(nèi)存泄漏問題的核心在于分配函數(shù)的統(tǒng)計和?；厮?。如果只知道內(nèi)存分配點不知道調(diào)用棧會使問題變得格外復雜，增加解決成本，因此兩者缺一不可。

Android中Bionic的malloc_debug模塊對內(nèi)存分配函數(shù)的監(jiān)控及統(tǒng)計是比較完善的，但是?；厮菰贏ndroid體系下缺乏高效的方式。隨著Android的發(fā)展，Google也提供了棧回溯的一些分析方法，但是這些方案存在下面幾個問題：

1.棧回溯的環(huán)節(jié)都使用的libunwind，這種獲取方式消耗較大，在Native代碼較多的情況下，頻繁調(diào)用會導致應用很卡，而監(jiān)控所有內(nèi)存操作函數(shù)的調(diào)用棧正需要高頻的調(diào)用libunwind的相關功能。

2.有ROM要求限制，給日常開發(fā)測試帶來不便。

3.用命令行或者DDMS進行操作，每排查一次需準備一次環(huán)境，手動操作，最終結(jié)果也不夠直觀，同時缺少對比分析。

因此，如何進行高效的?；厮荨⒋罱ㄏ到y(tǒng)化的Android Native內(nèi)存分析體系顯得格外重要。

高德地圖基于這兩點做了一些改進和擴展，經(jīng)過這些改進，通過自動化測試可及時發(fā)現(xiàn)并解決這些問題，大幅提升開發(fā)效率，降低問題排查成本。

一、棧回溯加速

Android平臺上主要采用libunwind來進行?；厮荩梢詽M足絕大多數(shù)情況。但是libunwind實現(xiàn)中的全局鎖及unwind table解析，會有性能損耗，在多線程頻繁調(diào)用情況下會導致應用變卡，無法使用。

加速原理

編譯器的-finstrument-functions編譯選項支持編譯期在函數(shù)開始和結(jié)尾插入自定義函數(shù)，在每個函數(shù)開始插入對__cyg_profile_func_enter的調(diào)用，在結(jié)尾插入對__cyg_profile_func_exit的調(diào)用。這兩個函數(shù)中可以獲取到調(diào)用點地址，通過對這些地址的記錄就可以隨時獲取函數(shù)調(diào)用棧了。

插樁后效果示例：

這里需要格外注意，某些不需要插樁的函數(shù)可以使用__attribute__((no_instrument_function))來向編譯器聲明。

如何記錄這些調(diào)用信息？我們想要實現(xiàn)這些信息在不同的線程之間讀取，而且不受影響。一種辦法是采用線程的同步機制，比如在這個變量的讀寫之處加臨界區(qū)或者互斥量，但是這樣又會影響效率了。

能不能不加鎖？這時就想到了線程本地存儲，簡稱TLS。TLS是一個專用存儲區(qū)域，只能由自己線程訪問，同時不存在線程安全問題，符合這里的場景。

于是采用編譯器插樁記錄調(diào)用棧，并將其存儲在線程局部存儲中的方案來實現(xiàn)?；厮菁铀?。具體實現(xiàn)如下：

1.利用編譯器的-finstrument-functions編譯選項在編譯階段插入相關代碼。

2.TLS中對調(diào)用地址的記錄采用數(shù)組+游標的形式，實現(xiàn)最快速度的插入、刪除及獲取。

定義數(shù)組+游標的數(shù)據(jù)結(jié)構(gòu)：

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.實現(xiàn)__cyg_profile_func_enter和__cyg_profile_func_exit，記錄調(diào)用地址到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的第二個參數(shù)call_site就是調(diào)用點的代碼段地址，函數(shù)進入的時候?qū)⑺涗浀揭呀?jīng)在TLS中分配好的數(shù)組中，游標ptr->current左移，待函數(shù)退出游標ptr->current右移即可。

邏輯示意圖：

記錄方向和數(shù)組增長方向不一致是為了對外提供的獲取棧信息接口更簡潔高效，可以直接進行內(nèi)存copy以獲取最近調(diào)用點的地址在前、最遠調(diào)用點的地址在后的調(diào)用棧。

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.將上面邏輯編譯為動態(tài)庫，其他業(yè)務模塊都依賴于該動態(tài)庫編譯，同時編譯flag中添加-finstrument-functions進行插樁，進而所有函數(shù)的調(diào)用都被記錄在TLS中了，使用者可以在任何地方調(diào)用get_tls_backtrace(void** backtrace, int max)來獲取調(diào)用棧。

效果對比（采用Google的benchmark做性能測試，手機型號：華為暢想5S，5.1系統(tǒng)）：

libunwind單線程

TLS方式單線程獲取

libunwind 10個線程

TLS方式 10個線程

從上面幾個統(tǒng)計圖可以看出單線程模式下該方式是libunwind棧獲取速度的10倍，10個線程情況下是libunwind棧獲取速度的50-60倍，速度大幅提升。

優(yōu)缺點

優(yōu)點: 速度大幅提升，滿足更頻繁棧回溯的速度需求。

缺點: 編譯器插樁，體積變大，不能直接作為線上產(chǎn)品使用，只用于內(nèi)存測試包。這個問題可以通過持續(xù)集成的手段解決，每次項目出庫將C++項目產(chǎn)出普通庫及對應的內(nèi)存測試庫。

二、體系化

經(jīng)過以上步驟可以解決獲取內(nèi)存分配棧慢的痛點問題，再結(jié)合Google提供的工具，如DDMS、adb shell am dumpheap -n pid /data/local/tmp/heap.txt命令等方式可以實現(xiàn)Native內(nèi)存泄漏問題的排查，不過排查效率較低，需要一定的手機環(huán)境準備。

于是，我們決定搭建一整套體系化系統(tǒng)，可以更便捷的解決此類問題，下面介紹下整體思路：

• 內(nèi)存監(jiān)控沿用LIBC的malloc_debug模塊。不使用官方方式開啟該功能，比較麻煩，不利于自動化測試，可以編譯一份放到自己的項目中，hook所有內(nèi)存函數(shù)，跳轉(zhuǎn)到malloc_debug的監(jiān)控函數(shù)leak_xxx執(zhí)行，這樣malloc_debug就監(jiān)控了所有的內(nèi)存申請/釋放，并進行了相應統(tǒng)計。

• 用get_tls_backtrace實現(xiàn)malloc_debug模塊中用到的__LIBC_HIDDEN__ int32_t get_backtrace_external(uintptr_t* frames, size_t max_depth)，剛好同上面說的?；厮菁铀俜绞浇Y(jié)合。

• 建立Socket通信，支持外部程序經(jīng)由Socket進行數(shù)據(jù)交換，以便更方便獲取內(nèi)存數(shù)據(jù)。

• 搭建Web端，獲取到內(nèi)存數(shù)據(jù)上傳后可以被解析顯示，這里要將地址用addr2line進行反解。

• 編寫測試Case，同自動化測試結(jié)合。測試開始時通過Socket收集內(nèi)存信息并存儲，測試結(jié)束將信息上傳至平臺解析，并發(fā)送評估郵件。碰到有問題的報警，研發(fā)同學就可以直接在Web端通過內(nèi)存曲線及調(diào)用棧信息來排查問題了。
  

系統(tǒng)效果示例：

以上是“解決Android Native內(nèi)存泄漏系統(tǒng)化的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！