AndroidNative內(nèi)存泄漏系統(tǒng)化的解決方案是什么-創(chuàng)新互聯(lián)

今天給大家介紹一下AndroidNative內(nèi)存泄漏系統(tǒng)化的解決方案是什么。文章的內(nèi)容小編覺(jué)得不錯(cuò)，現(xiàn)在給大家分享一下，覺(jué)得有需要的朋友可以了解一下，希望對(duì)大家有所幫助，下面跟著小編的思路一起來(lái)閱讀吧。

10余年的囊謙網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整囊謙建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“囊謙網(wǎng)站設(shè)計(jì)”,“囊謙網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

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

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

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

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

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

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

因此，如何進(jìn)行高效的棧回溯、搭建系統(tǒng)化的Android Native內(nèi)存分析體系顯得格外重要。

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

一、?；厮菁铀?/strong>

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

加速原理

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

插樁后效果示例：

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

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

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

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

1.利用編譯器的-finstrument-functions編譯選項(xiàng)在編譯階段插入相關(guān)代碼。

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

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

typedef struct {  void* stack[MAX_TRACE_DEEP];  int current;} thread_stack_t;

初始化TLS中thread_stack_t的存儲(chǔ)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.實(shí)現(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的第二個(gè)參數(shù)call_site就是調(diào)用點(diǎn)的代碼段地址，函數(shù)進(jìn)入的時(shí)候?qū)⑺涗浀揭呀?jīng)在TLS中分配好的數(shù)組中，游標(biāo)ptr->current左移，待函數(shù)退出游標(biāo)ptr->current右移即可。

邏輯示意圖：

記錄方向和數(shù)組增長(zhǎng)方向不一致是為了對(duì)外提供的獲取棧信息接口更簡(jiǎn)潔高效，可以直接進(jìn)行內(nèi)存copy以獲取最近調(diào)用點(diǎn)的地址在前、最遠(yuǎn)調(diào)用點(diǎn)的地址在后的調(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.將上面邏輯編譯為動(dòng)態(tài)庫(kù)，其他業(yè)務(wù)模塊都依賴于該動(dòng)態(tài)庫(kù)編譯，同時(shí)編譯flag中添加-finstrument-functions進(jìn)行插樁，進(jìn)而所有函數(shù)的調(diào)用都被記錄在TLS中了，使用者可以在任何地方調(diào)用get_tls_backtrace(void** backtrace, int max)來(lái)獲取調(diào)用棧。

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

libunwind單線程

TLS方式單線程獲取

libunwind 10個(gè)線程

TLS方式 10個(gè)線程

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

優(yōu)缺點(diǎn)

優(yōu)點(diǎn): 速度大幅提升，滿足更頻繁?；厮莸乃俣刃枨?。

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

二、體系化

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

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

內(nèi)存監(jiān)控沿用LIBC的malloc_debug模塊。不使用官方方式開(kāi)啟該功能，比較麻煩，不利于自動(dòng)化測(cè)試，可以編譯一份放到自己的項(xiàng)目中，hook所有內(nèi)存函數(shù)，跳轉(zhuǎn)到malloc_debug的監(jiān)控函數(shù)leak_xxx執(zhí)行，這樣malloc_debug就監(jiān)控了所有的內(nèi)存申請(qǐng)/釋放，并進(jìn)行了相應(yīng)統(tǒng)計(jì)。  用get_tls_backtrace實(shí)現(xiàn)malloc_debug模塊中用到的__LIBC_HIDDEN__ int32_t get_backtrace_external(uintptr_t* frames, size_t max_depth)，剛好同上面說(shuō)的棧回溯加速方式結(jié)合。  建立Socket通信，支持外部程序經(jīng)由Socket進(jìn)行數(shù)據(jù)交換，以便更方便獲取內(nèi)存數(shù)據(jù)。  搭建Web端，獲取到內(nèi)存數(shù)據(jù)上傳后可以被解析顯示，這里要將地址用addr2line進(jìn)行反解。  編寫測(cè)試Case，同自動(dòng)化測(cè)試結(jié)合。測(cè)試開(kāi)始時(shí)通過(guò)Socket收集內(nèi)存信息并存儲(chǔ)，測(cè)試結(jié)束將信息上傳至平臺(tái)解析，并發(fā)送評(píng)估郵件。碰到有問(wèn)題的報(bào)警，研發(fā)同學(xué)就可以直接在Web端通過(guò)內(nèi)存曲線及調(diào)用棧信息來(lái)排查問(wèn)題了。

以上就是AndroidNative內(nèi)存泄漏系統(tǒng)化的解決方案是什么的全部?jī)?nèi)容了，更多與AndroidNative內(nèi)存泄漏系統(tǒng)化的解決方案是什么相關(guān)的內(nèi)容可以搜索創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司，之前的文章或者瀏覽下面的文章進(jìn)行學(xué)習(xí)哈！相信小編會(huì)給大家增添更多知識(shí),希望大家能夠支持一下創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司，！

當(dāng)前標(biāo)題：AndroidNative內(nèi)存泄漏系統(tǒng)化的解決方案是什么-創(chuàng)新互聯(lián)
鏈接URL：http://muchs.cn/article38/dsijpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、電子商務(wù)、網(wǎng)站策劃、面包屑導(dǎo)航、企業(yè)建站、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)