淺談iOS Crash(一)

一、僵尸對象(Zombie Objects)

1、概述

• 僵尸對象：已經被釋放掉的對象。一般來說，訪問已經釋放的對象或向它發消息會引起錯誤。因為指針指向的內存塊認為你無權訪問或它無法執行該消息，這時候內核會拋出一個異常( EXC )，表明你不能訪問該存儲區域(BAD ACCESS)。(EXC_BAD_ACCESS類型錯誤)
• 調試解決該類問題一般采用NSZombieEnabled(開啟僵尸模式)。

2、使用NSZombieEnabled

• Xcode提供的NSZombieEnabled，通過生成僵尸對象來替換dealloc的實現，當對象引用計數為0的時候，將需要dealloc的對象轉化為僵尸對象。如果之后再給這個僵尸對象發消息，則拋出異常。先選中Product -> Scheme -> Edit Scheme -> Diagnostics -> 勾選Zombie Objects 項，顯示如下：

設置NSZombieEnabled.png

• 然后在Product -> Scheme -> Edit Scheme -> Arguments設置NSZombieEnabled、MallocStackLoggingNoCompact兩個變量，且值均為YES。顯示如下： 

設置NSZombieEnabled和MallocStackLoggingNoCompact.png

• 僅設置Zombie Objects的話，如果Crash發生在當前調用棧，系統可以把崩潰原因定位到具體代碼中;但是如果Crash不是發生在當前調用棧，系統僅僅告知崩潰地址，所以我們需要添加變量MallocStackLoggingNoCompact，讓Xcode記錄每個地址alloc的歷史，然后通過命令將地址還原出來。
• Xcode 6之前還可以使用gdb，可以使用info malloc-history address命令來將發生崩潰的地址還原成具體的代碼行，Xcode 7之后只能使用lldb，使用命令bt來打印調用堆棧。下面是某Crash通過僵尸模式調試，使用bt查看的效果。

bt效果.png

說明：發版前要將僵尸對象檢測這些設置都去掉，否則每次通過指針訪問對象時，都去檢查指針指向的對象是否為僵尸對象，這就影響效率了。

3、代碼中的注意事項

在ARC時代，避免訪問釋放掉的內存，代碼需要注意的地方有：

• 檢查代碼1 ：不能使用assgin或 unsafe_unretained修飾指向OC對象的指針

assgin和unsafe_unretained表示不持對象，是弱引用。如果指針指向的對象被釋放了，它們就變成了野指針，很有可能發生Crash。

建議1： assign僅用于修飾NSInteger等OC基礎類型，以及short、int、double、結構體等C數據類型，不修飾對象指針;

建議2： OC對象屬性一般使用strong關鍵字(默認)修飾。

建議3： 如果需要弱引用OC對象，建議使用weak關鍵字，因為被weak指針所引用的對象被回收后，weak指針會被賦為nil(空指針)，給nil發任何消息都不會出問題。使用weak修飾代理對象屬性就是很好的例子。

• 檢查代碼2 ：Core Foundation等底層操作

Core Foundation等底層操作它們不支持ARC，還需要手動內存管理。

建議： 注意CF對象的創建和釋放。

二、野指針(Wild pointer)

1、概述

• 野指針是指向一個已刪除的對象 或 未申請訪問受限內存區域的指針。而這里的野指針主要是對象釋放后，指針未置空導致的野指針。該類Crash發生比較隨機，找出來比較費勁，比較常見的做法是，在開發階段，提高這類Crash的復現率，盡可能得將其發現并解決。
• 向OC對象發出release消息，只是標記對象占用的那塊內存可以被釋放，系統并沒有立即收回內存;如果此時還向該對象發送其他消息，可能會發生Crash，也可能沒有問題。下圖是 訪問野指針(指向已刪除對象的指針)可能發生的情況。

訪問野指針可能發生的情況圖.png

• 從上圖可以知道，野指針造成的Crash的隨機性比較大，但是被隨機填入的數據是不可訪問的情況下，Crash是必現的。我們的思路是：想辦法給 野指針指向的內存填寫不可訪問的數據，讓隨機的Crash變成必現的Crash。

2、設置Malloc Scribble

Xcode提供的Malloc Scribble，可以將對象釋放后在內存上填上不可訪問的數據，將隨機發生變成不隨機發生的事情，選中Product->Scheme->Edit Scheme ->Diagnostics – >勾選 Malloc Scribble項，結果如下：

設置Malloc Scribble.png

設置了Enable Scribble，在對象申請內存后在申請的內存上填0xaa，內存釋放后在釋放的內存上填0x55;如果內存未被初始化就被訪問，或者釋放后被訪問，Crash必現。

說明：該方法必須連接Xcode運行代碼才發現，不適合測試人員使用。可以基于fishhook ，選擇hook對象釋放的接口(C的free函數)，達到和設置Enable Scribble一樣的效果。詳情參考如何定位Obj-C野指針隨機Crash(一)：先提高野指針Crash率、如何定位Obj-C野指針隨機Crash(二)：讓非必現Crash變成必現 和如何定位Obj-C野指針隨機Crash(三)：加點黑科技讓Crash自報家門

3、代碼中的注意事項

檢查使用assgin或 unsafe_unretained 修飾指向OC對象的指針 和 Core Foundation等底層操作。

三、內存泄漏(Memory Leak)

1、概述

• 內存泄漏是指沒有釋放掉不再引用對象的內存。即便ARC幫我們解決很多麻煩，但是內存泄漏問題依然比較多;一般開發結束后，都要做一些基本的內存泄漏排查工作。
• 內存泄漏排查，一般采用Analyzer(靜態分析) + Leaks + MLeaksFinder (第三方工具)

2-1、排查之靜態分析(Analyzer)

• Xcode提供的 Analyzer可以在程序沒運行的時候，通過分析代碼上下文的語法結構和內存情況，找出代碼中潛在錯誤，如內存泄露、未使用函數和變量等。選中Product->Analyze(快捷鍵command+shift+B)可以使用了。
• Analyzer主要分析四種問題：

1) 邏輯錯誤：訪問空指針或未初始化的變量等;

2) 內存管理錯誤：如內存泄漏等;Core Foundation不支持ARC

3) 聲明錯誤：從未使用過的變量;

4) API調用錯誤：未包含使用的庫和框架。

• Analyzer執行后，常見的警告類型有：

1)內存警告(Memory)

eg：

- (UIImage *)clipImageWithRect:(CGRect)rect{ 
 
  
 
  CGFloat scale = self.scale; 
 
  CGImageRef clipImageRef = CGImageCreateWithImageInRect(self.CGImage, 
 
                                                    CGRectMake(rect.origin.x * scale, 
 
                                                               rect.origin.y  * scale, 
 
                                                               rect.size.width * scale, 
 
                                                               rect.size.height * scale)); 
 
  
 
  CGRect smallBounds = CGRectMake(0, 0, CGImageGetWidth(clipImageRef)/scale, CGImageGetHeight(clipImageRef)/scale); 
 
  UIGraphicsBeginImageContextWithOptions(smallBounds.size, YES, scale); 
 
  CGContextRef context = UIGraphicsGetCurrentContext(); 
 
  
 
  CGContextTranslateCTM(context, 0, smallBounds.size.height); 
 
  CGContextScaleCTM(context, 1.0, -1.0); 
 
  CGContextDrawImage(context, CGRectMake(0, 0, smallBounds.size.width, smallBounds.size.height), clipImageRef); 
 
  
 
  UIImage* clipImage = UIGraphicsGetImageFromCurrentImageContext(); 
 
  
 
  UIGraphicsEndImageContext(); 
 
  CGImageRelease(clipImageRef);  //不添加，內存泄漏，會警告：Potential leak of an object stored into 'clipImageRef' 
 
  return clipImage; 
 
}  

分析：Analyzer檢查出來內存泄漏，比較常見的就是CG、CF開頭的內存泄漏，內存申請，忘記釋放了。還有一種是，C申請的內存，沒有配對使用new delete， malloc free。

2)無效數據警告(Dead store)

eg：

//錯誤做法，Analyzer分析后會告知：Value stored to ‘dataArray’ during its initialization is never read 
 
NSMutableArray *dataArray = [[NSMutableArray alloc] init]; 
 
dataArray = _otherDataArray; 
 
  
 
//正確做法 
 
NSMutableArray *dataArray = nil; 
 
dataArray = _otherDataArray;  

分析： dataArray已經被初始化分配了內存，然后被另一個可變數組賦值，導致一個數據源卻申請了兩塊內存，造成了內存泄露。

3)邏輯錯誤監測(Logic error)

eg：

//錯誤做法，Analyzer分析后會告知：Property of mutable type ’NSMutableArray’ has ‘copy’ attribute,an immutable object will be stored instead 
 
@property (nonatomic, copy) NSMutableArray *dataArr;   
 
  
 
//正確做法 
 
@property (nonatomic, strong) NSMutableArray *dataArr;  

分析： NSMutableArray是可變數據類型，應該用strong來修飾其對象。

說明： Analyzer由于是編譯器根據代碼進行的判斷, 做出的判斷不一定會準確, 因此如果遇到提示, 應該去結合代碼上文檢查一下;還有某些造成內存泄漏的循環引用通過Analyzer分析不出來。

2-2、排查之內存泄漏工具(Leaks)

• Xcode提供的Leak可以幫助發現運行著的程序內存泄漏的地方。通過選中Product-> Profile(快捷鍵command+i，喚起Instrument工具界面) -> Leaks。切換到Call Tree模式，底部選中Separate by Thread(按線程分開做分析)、Invert Call Tree(反向輸出調用樹)、Hide System Libraries(隱藏系統庫文件)。最后點擊紅色按鈕開始“錄制”，效果如下圖：

Leaks調試界面.png

• 在Leaks調試界面上，1是Allocations 模板，顯示內存分配情況;2是 Leaks 模板，這里可以查看內存泄露情況。如果紅X出現, 表示有內存泄露;主框體區域則會顯示泄露的對象。Call Tree選項介紹如下： 

2-3、排查之MLeaksFinder(強烈推薦)

MLeaksFinder是微信閱讀團隊為了簡化內存泄漏排查工作，推出的第三方工具，也是我們當前項目中內存泄漏的工具之一。

• 特點：集成簡單，主要檢查UI方面(UIView 和 UIViewController)的泄漏。
• 原理：不入侵開發代碼，通過hook 掉 UIViewController 和 UINavigationController 的 pop 跟 dismiss 方法，檢查ViewController對象被 pop 或 dismiss 一小段時間后，看看該ViewController對象的 view，view 的 subviews 等等是否還存在。
• 實現：為基類 NSObject 添加一個方法 -willDealloc 方法，利用weak指針指向自己，并在一小段時間(3秒)后，再次檢測該weak指針是否有效，有效則內存泄漏。
• 集成：通過Cocoapods引入或直接把代碼拖進項目，很方便。發生內存泄漏，會彈出警告框，提示發生內存泄漏的位置。

說明：詳細內容請參考：MLeaksFinder：精準 iOS 內存泄露檢測工具和MLeaksFinder 新特性

3、代碼中的注意事項(ARC下的循環引用是內存泄漏的主要原因)

• 檢查代碼1 ：Core Foundation、Core Graphics等操作

Core Foundation、CoreGraphics等操作不支持ARC，還需要手動內存管理。

建議： 注意CF、CG對象的創建和釋放。

• 檢查代碼2 ：NSTimer/CADisplayLink的使用，因為NSTimer/CADisplayLink對象的target會強引用self，而self又強引用NSTimer/CADisplayLink對象。

建議：使用擴展方法，使用block或 target弱引用目標對象 打破保留環，具體實現參考iOS實錄8：解決NSTimer/CADisplayLink的循環引用

• 檢查代碼3 ：block使用代碼。

建議：成對使用weakSelf和strongSelf來打破block循環引用(對于self沒有引用的block是不會造成循環引用，不需要使用weakSelf和strongSelf)

原理：在block外定義弱引用(weakSelf)，指向的self對象;在block內捕獲的是這個弱引用(weakSelf)，保證了self不會被block所持有;在執行block內方法時，生成強引用(strongSelf)，指向了弱引用(weakSelf)所指向的對象(self對象);在block內部實際是持有了self對象，但是這個強引用(strongSelf) 的生命周期只在這個block執行的過程中，block執行執行完立刻就被釋放了。

四、廢棄內存(Abandoned Memory)

1、概述

• 廢棄內存(Abandoned Memory)指，依然被引用對象的內存，但在程序邏輯中無法再被利用。
• 排查該類問題建議使用Xcode提供的Allocation，Allocation可以跟蹤應用的內存分配情況。

2、使用Allocation

• Xcode提供的Allocation由于可以跟蹤應用的內存分配情況。開發者反復操作App，查看內存基線變化;甚至還可以設置Mark Generation來對比多次Generation之間的內存增長，這部分的增長就是我們沒有及時釋放的內存。通過Product-> Profile(快捷鍵command+i，喚起Instrument工具界面) -> Allocations。最后點擊紅色按鈕開始“錄制”，效果如下圖：

Allocation界面Statistics Detail 下顯示.png

• 上圖是Statistics Detail Type下的界面展示，下面是一些名稱的說明：

• 下圖是切換到Call Tree下的界面展示。 

Allocation界面Call Tree下顯示.png

說明：這些名詞的具體解釋見Instrument-Allocations

• 間隔一段時間(如2分鐘)點擊“Mark Generation”，判斷幾次之間Generation之間的內存增長，而這些增長可能就是未能及時釋放的內存：根據內存占用的比例，找到占用比例最高的那部分，然后找到我們自己的代碼，再來分析并解決問題。

Allocation界面Mark Generation下顯示.png

3、代碼中的注意事項

略，與內存泄漏部分代碼中的注意事項相同。