abort內(nèi)存相關問題定位

獲取內(nèi)存代碼

#import <mach/mach.h>

- (int64_t)memoryUsage {
    int64_t memoryUsageInByte = 0;
    task_vm_info_data_t vmInfo;
    mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
    kern_return_t kernelReturn = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t) &vmInfo, &count);
    if(kernelReturn == KERN_SUCCESS) {
        memoryUsageInByte = (int64_t) vmInfo.phys_footprint;
        NSLog(@"Memory in use (in bytes): %lld", memoryUsageInByte);
    } else {
        NSLog(@"Error with task_info(): %s", mach_error_string(kernelReturn));
    }

    return memoryUsageInByte;
}

期騰訊也開源了自己的 OOM 定位方案寺擂，OOMDetector 組件：https://github.com/Tencent/OOMDetector 趾断。這種方案通過利用 libmalloc 中的 malloc_logger 函數(shù)指針，可以通過堆棧來幫助開發(fā)定位大內(nèi)存。但是也存在一些缺陷，就是頻繁的 dump 堆棧對 App 性能造成了影響高镐，只能灰度一小部分用戶來進行數(shù)據(jù)統(tǒng)計和定位

iphone設備的RAM上限

device: (crash amount/total amount/percentage of total)

iPad1: 127MB/256MB/49%
iPad2: 275MB/512MB/53%
iPad3: 645MB/1024MB/62%
iPad4: 585MB/1024MB/57% (iOS 8.1)
iPad Mini 1st Generation: 297MB/512MB/58%
iPad Mini retina: 696MB/1024MB/68% (iOS 7.1)
iPad Air: 697MB/1024MB/68%
iPad Air 2: 1383MB/2048MB/68% (iOS 10.2.1)
iPad Pro 9.7": 1395MB/1971MB/71% (iOS 10.0.2 (14A456))
iPad Pro 10.5”: 3057/4000/76% (iOS 11 beta4)
iPad Pro 12.9” (2015): 3058/3999/76% (iOS 11.2.1)
iPad Pro 12.9” (2017): 3057/3974/77% (iOS 11 beta4)
iPad Pro 11.0” (2018): 2858/3769/76% (iOS 12.1)
iPad Pro 12.9” (2018, 1TB): 4598/5650/81% (iOS 12.1)
iPad 10.2: 1844/2998/62% (iOS 13.2.3)
iPod touch 4th gen: 130MB/256MB/51% (iOS 6.1.1)
iPod touch 5th gen: 286MB/512MB/56% (iOS 7.0)
iPhone4: 325MB/512MB/63%
iPhone4s: 286MB/512MB/56%
iPhone5: 645MB/1024MB/62%
iPhone5s: 646MB/1024MB/63%
iPhone6: 645MB/1024MB/62% (iOS 8.x)
iPhone6+: 645MB/1024MB/62% (iOS 8.x)
iPhone6s: 1396MB/2048MB/68% (iOS 9.2)
iPhone6s+: 1392MB/2048MB/68% (iOS 10.2.1)
iPhoneSE: 1395MB/2048MB/69% (iOS 9.3)
iPhone7: 1395/2048MB/68% (iOS 10.2)
iPhone7+: 2040MB/3072MB/66% (iOS 10.2.1)
iPhone8: 1364/1990MB/70% (iOS 12.1)
iPhone X: 1392/2785/50% (iOS 11.2.1)
iPhone XS: 2040/3754/54% (iOS 12.1)
iPhone XS Max: 2039/3735/55% (iOS 12.1)
iPhone XR: 1792/2813/63% (iOS 12.1)
iPhone 11: 2068/3844/54% (iOS 13.1.3)
iPhone 11 Pro Max: 2067/3740/55% (iOS 13.2.3)

查看app最大占用
https://stackoverflow.com/questions/5887248/ios-app-maximum-memory-budget/15200855#15200855

Jetsam 一詞最初是一個航海術語提揍，指船只將不想要的東西扔進海里啤月，以減輕船的重量。在 iOS 中碳锈，Jetsam 是將當前應用從內(nèi)存中彈出以滿足當前最重要應用需求的系統(tǒng)顽冶。

image.png

iOS中的崩潰類型

在這里了解一下XCode用來表示各種崩潰類型的術語欺抗，補充一些這方面的各知識售碳。崩潰通常是指操作系統(tǒng)向正在運行的程序發(fā)送的信號，所以我們在查看崩潰日志時绞呈，常趁橙耍看到如下錯誤摘要：Application received signal SIGSEGV。一般來說佃声，常見的崩潰類型有以下幾種：

1艺智、 EXC_BAD_ACCESS

在訪問一個已經(jīng)釋放的對象或向它發(fā)送消息時，EXC_BAD_ACCESS就會出現(xiàn)圾亏。造成EXC_BAD_ACCESS最常見的原因是十拣，在初始化方法中初始化變量時用錯了所有權(quán)修飾符，這會導致對象過早地被釋放志鹃。舉個例子夭问，在viewDidLoad方法中為UIViewController創(chuàng)建了一個包含元素的NSArray，卻將該數(shù)組的所有權(quán)修飾符設成了assign而不是strong〔芰澹現(xiàn)在在viewWillAppear中缰趋，若要訪問已經(jīng)釋放掉的對象時，就會得到名為EXC_BAD_ACCESS的崩潰陕见。

這個崩潰發(fā)生時秘血，查看崩潰日志，卻往往得不到有用的棧信息评甜。還好灰粮，有一個方法用來解決這個問題：NSZombieEnabled。

這是一個環(huán)境變量忍坷，用來調(diào)試與內(nèi)存相關的問題粘舟，跟蹤對象的釋放過程。啟用了NSZombieEnabled的話承匣，它會用一個僵尸實現(xiàn)來去你的默認的dealloc實現(xiàn)蓖乘，也就是在引用計數(shù)降到0時，該僵尸實現(xiàn)會將該對象轉(zhuǎn)換成僵尸對象韧骗。僵尸對象的作用是在你向它發(fā)送消息時嘉抒，它會顯示一段日志并自動跳入調(diào)試器。

所以袍暴，當在應用中啟用NSZombie而不是讓應用直接崩潰時些侍，一個錯誤的內(nèi)存訪問就會變成一條無法識別的消息發(fā)送給僵尸對象隶症。僵尸對象會顯示接收到的消息，然后跳入調(diào)試器岗宣，這樣你就可以查看到底哪時出了問題蚂会。

可以在Xcode的scheme頁面中設置NSZombieEnabled環(huán)境變量。點擊Product-àEdit Scheme打開該頁面耗式，然后勾選Enable Zombie Objects復選框胁住，如圖所示：

[圖片上傳失敗...(image-4c3fb1-1615194621223)]

僵尸在RAC出現(xiàn)以前作用很大。但自從有了ARC刊咳，如果你在對象的所有權(quán)方面比較注意彪见，那么通常不會碰到內(nèi)存相關的崩潰。

2娱挨、 SIGSEGV

段錯誤信息（SIGSEGV）是操作系統(tǒng)產(chǎn)生的一個更嚴重的問題余指。當硬件出現(xiàn)錯誤、訪問不可讀的內(nèi)存地址或向受保護的內(nèi)存地址寫入數(shù)據(jù)時跷坝，就會發(fā)生這個錯誤酵镜。

硬件錯誤這一情況并不常見。當要讀取保存在RAM中的數(shù)據(jù)柴钻，而該位置的RAM硬件有問題時淮韭，你會收到SIGSEGV。SIGSEGV更多是出現(xiàn)在后兩種情況顿颅。默認情況下缸濒，代碼頁不允許進行寫操作，而數(shù)據(jù)而不允許進行執(zhí)行操作粱腻。當應用中的某個指針指向代碼頁并試圖修改指向位置的值時庇配，你會收到SIGSEGV。當要讀取一個指針的值绍些，而它被初始化成指向無效內(nèi)存地址的垃圾值時捞慌，你也會收到SIGSEGV。

SIGSEGV錯誤調(diào)試起來更困難柬批，而導致SIGSEGV的最常見原因是不正確的類型轉(zhuǎn)換啸澡。要避免過度使用指針或嘗試手動修改指針來讀取私有數(shù)據(jù)結(jié)構(gòu)。如果你那樣做了氮帐，而在修改指針時沒有注意內(nèi)存對齊和填充問題嗅虏，就會收到SIGSEGV。

3上沐、 SIGBUS

總線錯誤信號（SIGBUG）代表無效內(nèi)存訪問皮服，即訪問的內(nèi)存是一個無效的內(nèi)存地址。也就是說，那個地址指向的位置根本不是物理內(nèi)存地址（它可能是某個硬件芯片的地址）龄广。SIGSEGV和SIGBUS都羽毛球EXC_BAD_ACCESS的子類型硫眯。

4、 SIGTRAP

SIGTRAP代表陷阱信號择同。它并不是一個真正的崩潰信號两入。它會在處理器執(zhí)行trap指令發(fā)送。LLDB調(diào)試器通常會處理此信號敲才，并在指定的斷點處停止運行裹纳。如果你收到了原因不明的SIGTRAP，先清除上次的輸出归斤，然后重新進行構(gòu)建通常能解決這個問題痊夭。

5、 EXC_ARITHETIC

當要除零時脏里，應用會收到EXC_ARITHMETIC信號。這個錯誤應該很容易解決虹曙。

6迫横、 SIGILL

SIGILL代表signal illegal instruction(非法指令信號)。當在處理器上執(zhí)行非法指令時酝碳，它就會發(fā)生矾踱。執(zhí)行非法指令是指，將函數(shù)指針會給另外一個函數(shù)時疏哗，該函數(shù)指針由于某種原因是壞的呛讲，指向了一段已經(jīng)釋放的內(nèi)存或是一個數(shù)據(jù)段。有時你收到的是EXC_BAD_INSTRUCTION而不是SIGILL返奉，雖然它們是一回事贝搁，不過EXC_*等同于此信號不依賴體系結(jié)構(gòu)。

7芽偏、SIGABRT

SIGABRT代表SIGNAL ABORT（中止信號）雷逆。當操作系統(tǒng)發(fā)現(xiàn)不安全的情況時，它能夠?qū)@種情況進行更多的控制污尉；必要的話膀哲，它能要求進程進行清理工作。在調(diào)試造成此信號的底層錯誤時被碗，并沒有什么妙招某宪。Cocos2d或UIKit等框架通常會在特定的前提條件沒有滿足或一些糟糕的情況出現(xiàn)時調(diào)用C函數(shù)abort（由它來發(fā)送此信號）。當SIGABRT出現(xiàn)時锐朴，控制臺通常會輸出大量的信息兴喂，說明具體哪里出錯了。由于它是可控制的崩潰，所以可以在LLDB控制臺上鍵入bt命令打印出回溯信息瞻想。

8压真、看門狗超時

這種崩潰通常比較容易分辨，因為錯誤碼是固定的0x8badf00d蘑险。（程序員也有幽默的一面滴肿，他們把它讀作Ate Bad Food。）在iOS上佃迄，它經(jīng)常出現(xiàn)在執(zhí)行一個同步網(wǎng)絡調(diào)用而阻塞主線程的情況泼差。因此，永遠不要進行同步網(wǎng)絡調(diào)用呵俏。