這篇文章主要介紹“怎么自動識別Android不合理的內(nèi)存分配”，在日常操作中，相信很多人在怎么自動識別Android不合理的內(nèi)存分配問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么自動識別Android不合理的內(nèi)存分配”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
創(chuàng)新互聯(lián)公司是網(wǎng)站建設技術企業(yè)，為成都企業(yè)提供專業(yè)的網(wǎng)站設計制作、網(wǎng)站制作，網(wǎng)站設計，網(wǎng)站制作，網(wǎng)站改版等技術服務。擁有10余年豐富建站經(jīng)驗和眾多成功案例，為您定制適合企業(yè)的網(wǎng)站。10余年品質(zhì)，值得信賴！
寫在前面
Android開發(fā)中我們常常會遇到不合理的內(nèi)存分配導致的問題，或是頻繁GC，或是OOM。按照常規(guī)的套路我們需要打開Android Studio錄制內(nèi)存分配或者dump內(nèi)存，然后人工分析，逐個排查問題所在。這些方法是官方提供的能力，可以幫助我們排查問題，但難免有些繁瑣，效率比較低。
如果可以自動識別出不合理的Java(含Kotlin)對象分配，這樣繁瑣的工作將會變得簡單。
本文介紹了一種在Art虛擬機上實時記錄對象分配的實現(xiàn)方案，基于此方案就可以實現(xiàn)不合理對象分配的自動化的識別。
方案 | 優(yōu)勢 | 不足 | Dump內(nèi)存 | 可以自動化 | 無法反映出內(nèi)存分配的過程 |
錄制對象分配 | 可以看到每次內(nèi)存分配的情況 | 需要手動啟動，無法自動化 |
字節(jié)碼插樁 | 可以自動化 | 無法記錄不在業(yè)務代碼內(nèi)的內(nèi)存分配 |
Dump內(nèi)存和字節(jié)碼插樁的方案都無法覆蓋運行過程中內(nèi)存分配的過程，無法滿足自動識別的訴求。而錄制的方案目前主要的問題是，不能自動化，如果能實現(xiàn)錄制內(nèi)存分配的自動化，就可以完成我們想要做的事情。
Android Studio是開源的，因此我們很容易在它的源碼里找到一些功能的實現(xiàn)。錄制內(nèi)存分配的代碼在ToggleAllocationTrackingAction這個類里。精簡后的流程如下：
建立ADB連接、構造請求這些都是IDE做的事情，我們需要模擬IDE做這些事情嗎？不需要。我們只需要關注DdmVmInternal是怎么做的即可，很幸運，Android系統(tǒng)源碼的一段測試代碼直接告訴了我們?nèi)绾畏瓷湔{(diào)用DdmVmInternal提供的能力，源碼位置在/art/test/098-ddmc/src/Main.java，這里代碼就不貼了。
調(diào)用DdmVmInternal的方法，成功的在App里開啟了內(nèi)存分配的錄制，也成功的拿到了每次內(nèi)存分配的數(shù)據(jù)。但如果以為事情就這樣OK了，還早了一些。萬萬沒想到，這接口雖然易用，但用得并不爽，有三點：最多只能65535條記錄(size的類型是雙字節(jié)無符號數(shù))。
錄制時對性能影響很小，但每次獲取錄制記錄時特別慢(開發(fā)機實測JDWP封包5秒以上，解包處理10秒以上)。
每次獲取到的記錄可能有重復，要使用這個數(shù)據(jù)需要額外做合并去重的操作。
DdmVmInternal的實現(xiàn)是放在native層的，順藤摸瓜，我們找到了虛擬機里實現(xiàn)內(nèi)存分配錄制的源碼，此處是Android5.1的源碼，其他版本有差異，后面會講到。
這里的關鍵函數(shù)是RecordAllocation，所有對象的內(nèi)存分配都會經(jīng)過這個函數(shù)，因此我們可以Hook這個函數(shù)來捕捉到內(nèi)存分配的事件。方案 | 優(yōu)勢 | 不足 | PLT Hook | 修改PLT表的跳轉(zhuǎn)地址，風險低，易操作 | 使用場景有限，只能Hook一些被外部調(diào)用的函數(shù) |
Inline Hook | 匯編指令級別修改，幾乎能修改所有邏輯 | 修改匯編指令涉及繁瑣的指令修復工作，有一定門檻 |
顯然，PLT Hook并不適合我們的場景，好在目前Inline Hook技術也已經(jīng)比較成熟，看雪有不少大佬都分享了自己的框架，我們要使用Inline Hook無需再處理那些繁瑣的指令修復(關于hook技術的細節(jié)在最后的參考文章里有列舉，有興趣的同學可以翻閱)。至此，我們已經(jīng)可以捕獲到所有的對象分配事件了，但這只是我們邁出的一小步。為了讓對象分配可被跟蹤，我們至少需要三個信息：這是什么對象；分配了多大內(nèi)存；它是怎么分配的。這幾個點看似清楚明了，但怎么做，還需要小費一番周折。這個信息最容易獲取，如果你還記得RecordAllocation函數(shù)的定義，你會發(fā)現(xiàn)byte_count已經(jīng)作為參數(shù)傳進來了。沒錯，就是這么簡單。你也許已經(jīng)發(fā)現(xiàn)RecordAllocation還有一個參數(shù)是art::mirror::Class*，這是Java里Class在虛擬機里的鏡像，我們知道Java里拿到Class，就能直接調(diào)用getName方法知道這個類是什么。然鵝，在虛擬機的源碼里，GetName函數(shù)有是有，但是是內(nèi)聯(lián)函數(shù)，我們沒有辦法拿到這個函數(shù)的地址。
這個咋整？不要方，我們繼續(xù)看源碼，就在不遠處，有一個叫個GetDescriptor的函數(shù)。
可以說是業(yè)界良心了，我們通過dlsym就可以拿到這個函數(shù)的地址，然后調(diào)用它，傳入我們已經(jīng)拿到的art::mirror::Class*和一個std::string，就可以拿到類名(實際上是類的描述)。要知道一個對象是怎么分配的，我們需要拿到它的調(diào)用棧，Ok，我們來看看虛擬機里面怎么做的。
這個能模仿實現(xiàn)嗎？多番查探，發(fā)現(xiàn)每個關鍵節(jié)點的實現(xiàn)都是內(nèi)聯(lián)函數(shù)。咋辦呢？古人說“山重水復疑無路，柳暗花明又一村”。既然源碼層面不能給我們更多的啟示了，那回頭想想平時會怎么做。是的，我們在寫Java代碼的時候，如果要獲得當前的調(diào)用棧，一般就直接Thread.currentThread().getStackTrace()。既然這么容易，那我們直接在native層通過jni調(diào)用java的方法不就可以拿到調(diào)用棧了嗎？事實也正是如此。于是，整個流程順下來就是這樣的。
找到了合適的時機，又收集到了需要的數(shù)據(jù)，跟蹤發(fā)現(xiàn)不合理的對象分配就很容易了。我們可以發(fā)現(xiàn)某一次分配的大對象，也可以按照類名或者分類統(tǒng)計對象分配的頻率等等，還可以做更多定制化的監(jiān)控~前面提到的方案已在Android5.x版本上驗證OK，指定機型跑自動化是可以的，但目前主流的開發(fā)設備是Android7.x甚至更高的版本，如果要在開發(fā)階段就能自動發(fā)現(xiàn)內(nèi)存分配的問題，顯然不夠的。是否可以把前面的方案直接應用在Android 6.x-9.x呢？答案是沒那么容易。我們先來看下后續(xù)版本虛擬機里的一些改動。
| | | | RecordAllocation函數(shù)新增一個參數(shù)Thread* | |
| 2. RecordAllocation傳入的mirro::Class*變成了mirror::Object** | 1. 應用無法通過dlsym查詢函數(shù)地址2. mirror::Object無法與mirror::Class對應 |
| RecordAllocation傳入的mirror::Object**變成了ObjPtr* | |
對于我們的方案來講，主要的挑戰(zhàn)集中在Android7.x及以上版本，我們來看看這些問題如何各個擊破。Android7.0開始，要想動態(tài)鏈接非NDK公開的so需要System或者Root權限，普通的app是做不到的。如果嘗試鏈接或者通過dlopen去打開，要么看到Permission Denied的錯誤提示，要么直接Crash。1.1 獲得so基址
我們知道，Android是基于Linux的操作系統(tǒng)，Linux操作系統(tǒng)每個進程都有一個maps文件記錄了所有模塊在內(nèi)存里起始地址，路徑是/proc//maps，這里pid就是進程的pid，訪問自己進程用別名/proc/self/maps也可以。這個文件很關鍵，我們看看它里面是什么。
libart.so是虛擬機的so，可以看到這里它的起始地址是0xeaf18000。函數(shù)的地址就是基址+偏移，現(xiàn)在基址已有，就差偏移了，偏移怎么拿？因為每個ROM的so多少都有差別，這個偏移肯定不能是hardcode的，我們要想辦法查到函數(shù)的偏移。一般來說有兩種辦法，第一種是無腦搜函數(shù)特征。1.2 搜索函數(shù)地址 之 函數(shù)特征
這圖IDA打開一個Android7.1的libart.so查到的RecordAllocation函數(shù)的二進制。這個二進制的前8個或16個字節(jié)就可以用來作為這個函數(shù)的特征，我們在libart.so的內(nèi)存區(qū)域內(nèi)匹配這個特征就可以定位到這個函數(shù)了。
這個方法有個明顯的缺點，因為ROM廠家很有可能會修改虛擬機的代碼，或者修改編譯參數(shù)，這種通過函數(shù)特征去定位函數(shù)的辦法最多只能作為特殊機型的兼容邏輯。我們應該用一種更通用的方法，那就是直接解析ELF1.3 搜索函數(shù)地址 之 解析ELF
so是一種ELF格式的文件，在Android系統(tǒng)里由linker加載到內(nèi)存。關于ELF的格式，網(wǎng)上很容易找到，各種結構貼出來很長，這里不贅述。 雖然Android限制了我們dlopen打開NDK非公開的so，但本質(zhì)上，這些so對我們的進程來說是有可讀權限的，所以解析ELF格式來查找函數(shù)的偏移是可行的，按照ELF的格式去解析就可以了，代碼沒有特別值得拎出來說的，但在實現(xiàn)的時候仍然有一些細節(jié)。如果只是參考ELF的結構，我們能想到的直觀的辦法就是：遍歷字符串表，找到目標函數(shù)名的偏移；然后遍歷符號表，找到目標函數(shù)的偏移地址。這樣的做法沒毛病，但效率不夠高，因為是遍歷，所以復雜度為O(n)。事實上，如果看過linker的源碼，我們會發(fā)現(xiàn)，還有一個更高效的O(1)的查詢辦法。so里有一個section名字是.hash(有的是.gnu_hash，只是hash函數(shù)不同，但基本邏輯是一樣的)，它里面存儲的其實是函數(shù)符號的索引。我們參考linker的實現(xiàn)，把函數(shù)名(符號名)做一個hash，就可以在這個hash setion里面找到目標函數(shù)在符號表的索引，進而拿到函數(shù)的偏移地址。解析ELF這種方案更通用，也是我最終采用的主要的方案。解決了獲取函數(shù)地址的問題，運行時發(fā)現(xiàn)Hook了搜索出來的函數(shù)就Crash了，系統(tǒng)拋了一個SIGILL的信號結束了我的進程。SIGILL表示Illegal Instruction，這很有可能是我們的函數(shù)地址有問題。不過基址是系統(tǒng)加載so時記錄的，這個應該不會有錯；搜索出來的函數(shù)偏移和用IDA查看的函數(shù)偏移也是一致的。問題到底在哪？此時，我想到雖然NDK限制了對非公開so的權限，但我自己的so，就可以用dlsym來查找函數(shù)地址。于是寫了一個demo，發(fā)現(xiàn)一個“不可思議”的事實：dlsym查到的函數(shù)地址 比 我搜索出來的函數(shù)地址 剛好大了1。這有點觸及到知識盲區(qū)了，翻閱了不少講解ARM匯編的文章，終于找到了答案。原來ARM匯編編譯時有ARM指令和THUMB指令兩種，ARM指令為4字節(jié)，支持按條件執(zhí)行；而THUMB指令為2字節(jié)，不支持按條件執(zhí)行。由于大部分場景都無需按條件執(zhí)行，所以編譯成THUMB指令，so更加緊湊。由于4字節(jié)和2字節(jié)都是偶數(shù)，地址的最低位實際上是用不上的，ARM設計時就巧妙的將地址的最低位置1來表示要按照THUMB指令來解析了。這就是剛好大1的原因。我們看到IDA反編譯出來的RecordAllocation函數(shù)也可以清楚的看到，確實一條指令是2個字節(jié)，所以我們在實現(xiàn)的時候，要把搜索出來的地址做加1的修正。
3.通過art::mirror::Object獲取類名
關于mirror::Object無法獲取類名的問題，主要是因為它里面所有跟mirror::Class相關的函數(shù)全部是內(nèi)聯(lián)函數(shù)，我們在實現(xiàn)的時候很難突破。還是那句話，既然往里走不行，那就試著走出來。我們可以拿到調(diào)用棧，那是否可以通過解析調(diào)用棧來獲取當前分配的是什么對象呢？答案是否定的。一方面是因為解析調(diào)用棧涉及字符串匹配操作，頻繁的字符串匹配操作，對性能的損耗是不太能接受的；另一方面是因為解析堆棧無法覆蓋所有的對象分配(并非所有的對象分配都會經(jīng)過方法，例如 byte[])。mirror::Object是Java里Object在虛擬機的鏡像，那我們是否有辦法通過mirror::Object拿到Java的Object的引用呢？通過搜索以mirror::Object作為參數(shù)的函數(shù)，我找到了突破口。
這是JNI的一個函數(shù)，可以把mirror::Object轉(zhuǎn)成jobject，而jobject就是Java里Object在JNI層的表示。到了這一步，要獲取類名就非常簡單了，obj.getClass().getName()即可。關于Android8.x及以上系統(tǒng)，把mirror::Object**改成ObjPtr*的處理，就比較簡單了，ObjPtr類定義比較簡單，我們照著源碼里的ObjPtr實現(xiàn)一個結構一樣的class，就可以訪問到里面包裹的mirror::Object*了。到此，關于“怎么自動識別Android不合理的內(nèi)存分配”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
當前文章：怎么自動識別Android不合理的內(nèi)存分配
標題鏈接：http://weahome.cn/article/ihijsi.html
重慶分公司
重慶分公司
