Android Native 記憶體洩漏系統化解決方案

amap_tech發表於2019-07-17
Android記憶體

導讀：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端通過記憶體曲線及呼叫棧資訊來排查問題了。

 

系統效果示例：

 

關注高德技術，找到更多出行技術領域專業內容

相關文章