導讀：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單線程
Android Native 記憶體洩漏系統化解決方案 - TLS方式單線程擷取
Android Native 記憶體洩漏系統化解決方案 - libunwind 10個線程
Android Native 記憶體洩漏系統化解決方案 - TLS方式 10個線程
Android Native 記憶體洩漏系統化解決方案
從上面幾個統計圖可以看出單線程模式下該方式是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端通過記憶體曲線及調用棧資訊來排查問題了。
系統效果示例：