丨臨近oom如何詳細內(nèi)存分配信息分析問題

接下來，我就跟你介紹一下如何獲取內(nèi)存上限值，以及如何到App因為占用內(nèi)存過大JetsamEvent想要了解不同機器在不同系統(tǒng)版本的情況下，對App的內(nèi)存限制是怎樣的，有法就是查看中以JetsamEvent開頭的系統(tǒng)日志（我們可以從設置->隱私->分析中看到這在這些系統(tǒng)日志中，查找原因時我們需要關注per-process-limit部分的rpages。rpagesApp；per-process-limitApp存超過了系統(tǒng)對單個App的內(nèi)存限制。1"rpages":2"reason":"per-process-rpages89600，只要再知道內(nèi)存頁大小的值，就可以計算出系統(tǒng)對單個App限制的內(nèi)存是多少了?？梢钥吹?，內(nèi)存頁大小pageSize的值是16384。接下來，我們就可以計算出當前App的內(nèi)存限制值：pageSize*rpages/1024/1024=16384*89600/1024/1024得到的值是1400MB，即1.4G。這些JetsamEvent日志，都是系統(tǒng)在殺掉App后留在里的。在查看這些日志時，我們就會發(fā)現(xiàn)，很多日志都是iOS系統(tǒng)內(nèi)核強殺掉那些優(yōu)先級不高，并且占用的內(nèi)存超過限制的App后留下的。 Xcode獲取到這部分日志。獲取到Jetsam后，就能夠算出系統(tǒng)對App那么，iOS系統(tǒng)是怎么發(fā)現(xiàn)JetsamiOS系統(tǒng)會開啟優(yōu)先級最高的線程vm_pressure_monitor來系統(tǒng)的內(nèi)存壓力情況，并通過一個堆棧來所有App的進程。另外，iOS系統(tǒng)還會一個內(nèi)存快照表，用于保當系統(tǒng)內(nèi)存的線程發(fā)現(xiàn)某App內(nèi)存有壓力了，就發(fā)出通知，內(nèi)存有壓力的App就會去執(zhí)行對應的，也就是你所熟悉的didReceiveMemoryWarning。通過這個代你的App被系統(tǒng)強殺。系統(tǒng)在強殺App前，會先做優(yōu)先級判斷。那么，這個iOS系統(tǒng)內(nèi)核里有一個數(shù)組，專門用于線程的優(yōu)先級。這個優(yōu)先級規(guī)定就是：內(nèi)核用線程的優(yōu)先級是最高的，操作系統(tǒng)的優(yōu)先級其次，App的優(yōu)先級排在最后。并且，前臺App程序的優(yōu)先級是高于運行App的；線程使用優(yōu)先級時，CPU占用多的線程的優(yōu)先級會被iOSApp6斷。同時，JetSamEvent日志也是在這6秒內(nèi)生成的。除了JetSamEventXNU通過XNU在XNU中，有專門用于獲取內(nèi)存上限值的函數(shù)和宏。我們可以通過memorystatus_priority_entrytypedefstructmemorystatus_priority_entrypid_tint32_tuint64_tint32_tuint32_t}在這個結構體中，prioritylimit通過XNU的宏獲取內(nèi)存限制，需要有root權限，而App內(nèi)的權限是不夠的，所以正常情況下，作為App開發(fā)者你是看不到這個信息的。那么，如果你不想去獲取這個權限的話，還可以利用didReceiveMemoryWarning這個內(nèi)存壓力來動態(tài)地獲取內(nèi)存限制值iOS系統(tǒng)在強殺掉App之前還有6秒鐘的時間，足夠你去獲取記錄內(nèi)存信息了。那么，如iOStask_infostructmach_task_basic_infomach_msg_type_number_tsize=kern_return_tkl=task_info(mach_task_self(),MACH_TASK_BASIC_INFO,代碼中，task_info_tresident_size這樣，我們就可以獲取到發(fā)生內(nèi)存警告時，當前App占用了多少內(nèi)存。代碼如下：floatused_mem=NSLog(@"使用了%fMB內(nèi)存",used_mem/1024.0f/要想精確地定位問題，我們就需要dump出完整的內(nèi)存信息，包括所有對象及其內(nèi)存占用malloccalloc是nano_zone。nano_zone是256B以下小內(nèi)存的分配，大于256B的時候會使用scalable_zone來分配。在這里，我主要是針對大內(nèi)存的分配，所以只針對s_zoe進行分，同時也可以過濾掉很多小內(nèi)存分配。比malloc函數(shù)用的是ocmaocmaocec。scalable_zonemalloc_loggermalloc_zone_malloc函數(shù)的實現(xiàn)，代碼如下：void*malloc_zone_malloc(malloc_zone_t*zone,size_t{MALLOC_TRACE(TRACE_malloc|DBG_FUNC_START,(uintptr_t)zone,size,0,voidif(malloc_check_start&&(malloc_check_counter++>=malloc_check_start)) if(size>MALLOC_ABSOLUTE_MAX_SIZE)return ptr=zone->malloc(zone,//在zonemalloc_loggerif(malloc_logger)malloc_logger(MALLOC_LOG_TYPE_ALLOCATE|MALLOC_LOG_TYPE_HAS_ZONE, MALLOC_TRACE(TRACE_malloc|DBG_FUNC_END,(uintptr_t)zone,size,return18s_zoemalloc_ogger函數(shù)。這樣的話，問題就好解決了，你可fishhook去k出現(xiàn)時，存分錄的撈上你就致內(nèi)合理的原為了達到內(nèi)存的目的，我們需要做兩件事情：一是，能夠根據(jù)不同機器和系統(tǒng)獲取到內(nèi)存有問題的那個時間點；二是，到了出現(xiàn)內(nèi)存問題的那個時間點時，還能要取到足夠多的可以分析內(nèi)存問題的信息。針對這兩件事，我在今天這篇文章里和你了在JetsamEvent日志里、在XNU代碼task_info值時，怎么通過內(nèi)存分配時都會經(jīng)過的malloc_logger函數(shù)來掌握內(nèi)存分配的詳細信息，從說到這里你可能會回過頭來想，為什么用于占用內(nèi)存過大時會被系統(tǒng)強殺呢？macOS打開一堆應用也會遠超物理內(nèi)存，怎么沒見系統(tǒng)去強殺macOS的應用呢？iOS系統(tǒng)里去掉了交換空間，這樣虛擬內(nèi)存就沒有辦法記錄到外部的上。于是，蘋果公司引入了MemoryStatus機制。iOSmacOS系統(tǒng)里，MemoryStatus只會強殺掉標記為空閑退出的進程。線程，和內(nèi)存壓力監(jiān)測線程vm_pressure_monitor沒有聯(lián)系，只負責強殺應用和記錄日志，XNU會報EXC_BAD_ACCESSSIGSEGVSignal。沒有遵守權限內(nèi)存：內(nèi)存頁面的權限標準類似UNIX文件權限。如果去寫只讀權限的內(nèi)存頁面就會出現(xiàn)錯誤，XNU會發(fā)出SIGBUSSignal#7信號。天提定位問題獲取的信比如分配么，來根們今hookmalloc_ogger的方法，來實現(xiàn)一個記錄內(nèi)存分配的小工具吧。 售賣。頁面已增加防盜追蹤，將依法其上一 13|如何利用RunLoop原理去卡頓下一 15|日志：怎樣獲取App中的全量日志言言白開了杯 6鼠 我唔知點死 1關于fishhookmalloc_logger，在libmalloc中找到malloc_logger是一個結構體：typedefvoid(malloc_logger_t)(uint32_ttype,uintptr_targ1,uintptr_targ2,…徐秀 Geek