## 前言

大白（*Baymax*），迪士尼動畫《超能陸戰隊》中的健康機器人，是一個體型胖胖的充氣機器人，因呆萌的外表和善良的本質獲得大家的喜愛，被稱為“萌神”。

*Baymax*專案是為了減少開發人員在開發中一些不規範的程式碼編寫造成的記憶體洩露，介面卡頓，耗電等問題而來的一個監控系統。

現在Baymax迎來了它新的功能：APP執行時Crash自動防護功能，為app的流程順利執行保駕護航！

下面將詳細介紹一下 APP執行時Crash自動修復系統 開發的目的，設計的原理以及使用的方法。

# APP執行時Crash自動修復系統

## Chapter 1 - 開發目的

是否存在這樣的夜晚，當剛剛躺下準備美美的睡一覺的時候， 突然來一記奪命電話Call，一接起來發現是你老闆！！！“小王啊，剛剛上線的X.X.X版本出問題了啊，怎麼樣操作會crash啊，導致新功能都無法使用了，快定位一下是什麼原因，抓緊hotpatch修復一下啊！”。心裡一萬頭草泥馬呼嘯而過，瞬間已經滿頭大汗的你卻還要故作鎮靜地回答：“嗯，老闆我馬上去看看，一定努力解決問題！” 急忙開啟電腦的你，知道今夜註定無眠了。

是否又存在這樣的情形，你老闆把大家都聚起來開了一個年初KPI目標制定會議，說到：“作為一個資深的技術團隊，app效能是我們技術團隊首抓的目標，其中很最要的一項就是app的崩潰率，去年我們app統計出來的崩潰率是千分之五，而我們的競爭對手的崩潰率只有萬分之五，相差了10倍！今年我們要趕超他們，最起碼也要和他們持平。” 你甚是贊同，但是你心裡卻又有點懷疑，對方的開發資源是我們的好幾倍而且個個都是資深老司機，我們團隊裡卻大多都是應屆生小鮮肉，這KPI能完成麼？

如果你遇到過以上的情況並且對此深表頭痛的話，那麼 大白健康系統--APP執行時Crash自動修復系統 將會是你的不二選擇！

APP執行時Crash自動修復+捕獲系統 的設計初衷，就是為了降低app的crash率。利用Objective-C語言的動態特性，採用*AOP*(Aspect Oriented Programming) 面向切面程式設計的設計思想，做到無痕植入。能夠**自動在app執行時實時捕獲導致app崩潰的破環因子，然後透過特定的技術手段去化解這些破壞因子，使app免於崩潰，照樣可以繼續正常執行，為app的持續運轉保駕護航**。

## Chapter 2 - 功能簡介

APP執行時Crash自動修復系統 的主要功能，可以用一句話來簡單的概括：**對業務程式碼的零侵入性地將原本會導致app崩潰的crash抓取住，消滅掉，保證app繼續正常地執行，再將crash的具體資訊提取出來，實時返回給使用者**。

透過下面的一個小例子就可以很直觀的體現出來系統的作用：

呼叫以下的一段程式碼

```
//test code

UIButton * testObj = [[UIButton alloc] init];
[testObj performSelector:@selector(someMethod:)];
```

結果肯定會導致app的崩潰，因為testObj是一個UIButton物件，而UIButton並沒有實現 someMethod： 這個方法，所以向testObj傳送someMethod：這個方法的時候，將會導致該方法無法在相關的方法列表裡找到，最終導致app的crash。

但是透過我們的crash防護系統，呼叫這段程式碼時app並不會崩潰，同時XCode的Console如下： ![image](https://upload-images.jianshu.io/upload_images/22877992-6498f3db12a17bed?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

可見對應的crash的資訊（crash型別，原因，呼叫棧資訊）均可以完整的列印在XCode的Console中。

說明我們的大白系統已經捕捉到了這個crash，將該crash消滅掉並且吐出來該crash的完整資訊。

當然目前系統的功能並沒有強大到可以把所有的crash都處理掉，不過一些常見的高頻次發生的crash，系統均會針對他們一一處理。目前可以處理掉的crash型別具體有以下幾種：

*   unrecognized selector crash

*   KVO crash

*   NSNotification crash

*   NSTimer crash

*   Container crash（陣列越界，插nil等）

*   NSString crash （字串操作的crash）

*   Bad Access crash （野指標）

*   UI not on Main Thread Crash (非主執行緒刷UI(機制待改善))

對於每種型別的crash，安全系統都採取不同的方式，進行了對應的處理。 具體的處理細節詳見下章：**Chapter 3 - 實現原理**

## Chapter 3 - 實現原理

前面已經提過，目前的安全防護系統可以覆蓋到8中型別的Crash，分別為：

*   unrecognized selector crash

*   KVO crash

*   NSNotification crash

*   NSTimer crash

*   Container crash（陣列越界，插nil等）

*   NSString crash （字串操作的crash）

*   Bad Access crash （野指標）

*   UI not on Main Thread Crash (非主執行緒刷UI (機制待改善))

接下來將一一詳細介紹這8種型別的Crash的防護的實現的具體原理：

### 3.1 Unrecognized Selector型別crash防護（Unrecognized Selector）

#### 3.1.1 unrecognized selector crash 產生原因

unrecognized selector型別的crash在app眾多的crash型別中佔著比較大的成分，通常是因為一個物件呼叫了一個不屬於它方法的方法導致的。

例如呼叫以下一段程式碼就會產生crash

```
//test code

UIButton * testObj = [[UIButton alloc] init];
[testObj performSelector:@selector(someMethod:)];
```

具體crash時的表現見下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-eddd08671a128c46?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

要解決這中型別的crash，我們需要先了解清楚它產生的具體原因和流程。

#### 3.1.2 方法呼叫流程

讓我們看一下方法呼叫在執行時的過程。

runtime中具體的方法呼叫流程大致如下：

**1.首先，在相應操作的物件中的快取方法列表中找呼叫的方法，如果找到，轉向相應實現並執行。**

**2.如果沒找到，在相應操作的物件中的方法列表中找呼叫的方法，如果找到，轉向相應實現執行**

**3.如果沒找到，去父類指標所指向的物件中執行1，2.**

**4.以此類推，如果一直到根類還沒找到，轉向攔截呼叫，走訊息轉發機制。**

**5.如果沒有重寫攔截呼叫的方法，程式報錯。**

#### 3.1.3 攔截呼叫

在方法呼叫中說到了，如果沒有找到方法就會轉向攔截呼叫。

那麼什麼是攔截呼叫呢？

攔截呼叫就是，在找不到呼叫的方法程式崩潰之前，你有機會透過重寫NSObject的四個方法來處理:

```
+ (BOOL)resolveClassMethod:(SEL)sel;

+ (BOOL)resolveInstanceMethod:(SEL)sel;

//後兩個方法需要轉發到其他的類處理

- (id)forwardingTargetForSelector:(SEL)aSelector;

- (void)forwardInvocation:(NSInvocation *)anInvocation;
```

攔截呼叫的整個流程即Objective——C的訊息轉發機制。其具體流程如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-127579934e04e8c8?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

由上圖可見，在一個函式找不到時，runtime提供了三種方式去補救：

**1、呼叫resolveInstanceMethod給個機會讓類新增這個實現這個函式**

**2、呼叫forwardingTargetForSelector讓別的物件去執行這個函式**

**3、呼叫forwardInvocation（函式執行器）靈活的將目標函式以其他形式執行。**

**如果都不中，呼叫doesNotRecognizeSelector丟擲異常。**

#### 3.1.4 unrecognized selector crash 防護方案

既然可以補救，我們完全也可以利用訊息轉發機制來做文章。那麼問題來了，在這三個步驟裡面，選擇哪一步去改造比較合適呢。

這裡我們選擇了第二步forwardingTargetForSelector來做文章。原因如下：

1.  resolveInstanceMethod 需要在類的本身上動態新增它本身不存在的方法，這些方法對於該類本身來說冗餘的

2.  forwardInvocation可以透過NSInvocation的形式將訊息轉發給多個物件，但是其開銷較大，需要建立新的NSInvocation物件，並且forwardInvocation的函式經常被使用者呼叫，來做多層訊息轉發選擇機制，不適合多次重寫

3.  forwardingTargetForSelector可以將訊息轉發給一個物件，開銷較小，並且被重寫的機率較低，適合重寫

選擇了forwardingTargetForSelector之後，可以將NSObject的該方法重寫，做以下幾步的處理：

**1.動態建立一個樁類**

**2.動態為樁類新增對應的Selector，用一個通用的返回0的函式來實現該SEL的IMP**

**3.將訊息直接轉發到這個樁類物件上。**

流程圖如下：

![image](https://upload-images.jianshu.io/upload_images/22877992-b5d87af2a3fda168?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

注意如果物件的類本事如果重寫了forwardInvocation方法的話，就不應該對forwardingTargetForSelector進行重寫了，否則會影響到該型別的物件原本的訊息轉發流程。

透過重寫NSObject的forwardingTargetForSelector方法，我們就可以將無法識別的方法進行攔截並且將訊息轉發到安全的*樁類*物件中，從而可以使app繼續正常執行。

### 3.2 KVO型別crash防護（KVO）

#### 3.2.1 KVO crash 產生原因

KVO,即：Key-Value Observing，它提供一種機制，當指定的物件的屬性被修改後，則物件就會接受收到通知。簡單的說就是每次指定的被觀察的物件的屬性被修改後，KVO就會自動通知相應的觀察者了。

KVO機制在iOS的很多開發場景中都會被使用到。不過如果一不小心使用不當的話，會導致大量的crash問題。所以如果能找到一種方法能夠自動抓取這些由於開發者粗心所導致的KVO Crash問題的話，是有一定的價值的。

首先我們來看看透過會導致KVO Crash的兩種情形：

1.  KVO的被觀察者dealloc時仍然註冊著KVO導致的crash，見下圖

![image](https://upload-images.jianshu.io/upload_images/22877992-4099e4ffa538a647?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

1.  新增KVO重複新增觀察者或重複移除觀察者（KVO註冊觀察者與移除觀察者不匹配）導致的crash，見下圖

![image](https://upload-images.jianshu.io/upload_images/22877992-426e27b6c86e58d1?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

#### 3.2.2 KVO crash 防護方案

通常一個物件的KVO關係圖如下：

![image](https://upload-images.jianshu.io/upload_images/22877992-c6d555259f846c3e?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

一個被觀察的物件(Observed Object)上有若干個觀察者(Observer),每個觀察者又觀察若干條KeyPath。

如果觀察者和keypath的數量一多，很容易理不清楚被觀察物件整個KVO關係，導致被觀察者在dealloc的時候，還殘存著一些關係沒有被登出。 同時還會導致KVO註冊觀察者與移除觀察者不匹配的情況發生。

筆者曾經還遇到過在多執行緒的情況下，導致KVO重複新增觀察者或移除觀察者的情況。這類問題通常多數發生的比較隱蔽，不容易從程式碼的層面去排查。

由上可見多數由於KVO而導致的crash原因是由於被觀察物件的KVO關係圖混亂導致。那麼如何來管理混亂的KVO關係呢。可以讓被觀察物件持有一個KVO的delegate，所有和KVO相關的操作均透過delegate來進行管理，delegate透過建立一張map來維護KVO整個關係。如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-cbf2f3120bf54ef6?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

這樣做的好處有兩個：

1.如果出現KVO重複新增觀察者或重複移除觀察者（KVO註冊觀察者與移除觀察者不匹配）的情況，delegate可以直接阻止這些非正常的操作。

2.被觀察物件dealloc之前，可以透過delegate自動將與自己有關的KVO關係都登出掉，避免了KVO的被觀察者dealloc時仍然註冊著KVO導致的crash。

被swizzle的方法分別是：

```
- (void)addObserver:(NSObject *)observer 
            forKeyPath:(NSString *)keyPath
                options:(NSKeyValueObservingOptions)options 
                context:(nullable void *)context;

- (void)removeObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath;

- (void)observeValueForKeyPath:(nullable NSString *)keyPath ofObject:(nullable id)object change:(nullable NSDictionary<nskeyvaluechangekey id=""> *)change context:(nullable void *)context;
```

關於

```
- (void)addObserver:(NSObject *)observer
         forKeyPath:(NSString *)keyPath
            options:(NSKeyValueObservingOptions)options
            context:(void *)context
```

方法改造流程如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-1f36e63bb832eaf5?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

透過上面的流程，將observerd物件的所有kvo相關的observer資訊全部轉移到KVOdelegate上，並且避免了相同kvoinfo被重複新增多次的可能性。

關於

```
- (void)removeObserver:(NSObject *)observer
            forKeyPath:(NSString *)keyPath
               context:(void *)context
```

方法改造流程如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-0f59bf74a2efc1d7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

移除一個keypath的Observer時，當delegate的kvoInfoMap中找不到key為該keypath的時候，說明此時delegate並沒有持有對應keypath的observer，即說明移除了一個不匹配的觀察者，此時如果再繼續操作會導致app崩潰，所以應該及時中斷流程，然後統計異常資訊。

當keypath對應的KVOInfo列表（infoArray）為空的時候，說明此時delegate已經不再持有任何和keypath相關的observer了。這時應該呼叫原有removeObserver的方法將delegate對應的觀察者移除。

注意到在檢查遍歷infoArray的時侯，除了要刪除對應的info資訊，還多了一步檢查info.observer == nil的過程，是因為如果observer為nil，那麼此時如果keypath對應的值變化的話，也會因為找不到observer而崩潰，所以需要做這一步來阻止該種情況的發生。

關於

```
- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(NSDictionary<nsstring> *)change
                       context:(void *)context
```

方法改造流程如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-f342011a21cb123f?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

delegate對於observeValueForKeyPath方法的修改最主要的地法規，在於將對應的響應方法轉移給真正的KVO Observer，透過keyInfoMap找到keypath對應的KVOInfo裡面預先儲存好的observer，然後呼叫observer原本的響應方法

同時在遍歷InfoArray的時候，發現info.observerw == nil的時候，需要及時將其清除掉，避免KVO的觀察者observer被釋放後value變化導致的crash

最後，針對 **KVO的被觀察者dealloc時仍然註冊著KVO導致的crash** 的情況

可以將NSObject的dealloc swizzle， 在object dealloc的時候自動將其對應的kvodelegate所有和kvo相關的資料清空，然後將kvodelegate也置空。避免出現KVO的被觀察者dealloc時仍然註冊著KVO而產生的crash

### 3.3 NSNotification型別crash防護（NSNotification）

#### 3.3.1 NSNotification crash 產生原因

當一個物件新增了notification之後，如果dealloc的時候，仍然持有notification，就會出現NSNotification型別的crash。

NSNotification型別的crash多產生於程式設計師寫程式碼時候犯疏忽，在NSNotificationCenter新增一個物件為observer之後，忘記了在物件dealloc的時候移除它。

所幸的是，蘋果在iOS9之後專門針對於這種情況做了處理，所以在iOS9之後，即使開發者沒有移除observer，Notification crash也不會再產生了。

不過針對於iOS9之前的使用者，我們還是有必要做一下NSNotification Crash的防護的。

#### 3.3.2 NSNotification crash 防護方案

NSNotification Crash的防護原理很簡單， 利用method swizzling hook NSObject的dealloc函式，再物件真正dealloc之前先呼叫一下
[[NSNotificationCenter defaultCenter] removeObserver:self] 即可。

注意到並不是所有的物件都需要做以上的操作，如果一個物件從來沒有被NSNotificationCenter 新增為observer的話，在其dealloc之前呼叫removeObserver完全是多此一舉。 所以我們hook了NSNotificationCenter的 **addObserver:(id)observer selector:(SEL)aSelector name:(NSString *)aName object:(id)anObject**

函式，在其新增observer的時候，對observer動態新增標記flag。這樣在observer dealloc的時候，就可以透過flag標記來判斷其是否有必要呼叫removeObserver函式了。

### 3.4 NSTimer型別crash防護（NSTimer）

#### 3.4.1 NSTimer crash 產生原因

在程式開發過程中，大家會經常使用定時任務，但使用NSTimer的 scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: 介面做重複性的定時任務時存在一個問題：NSTimer會 強引用 target例項，所以需要在合適的時機invalidate 定時器，否則就會由於定時器timer強引用target的關係導致 target不能被釋放，造成記憶體洩露，甚至在定時任務觸發時導致crash。 crash的展現形式和具體的target執行的selector有關。

與此同時，如果NSTimer是無限重複的執行一個任務的話，也有可能導致target的selector一直被重複呼叫且處於無效狀態，對app的CPU，記憶體等效能方面均是沒有必要的浪費。

所以，很有必要設計出一種方案，可以有效的防護NSTimer的濫用問題。

#### 3.4.2 NSTimer crash 防護方案

上面的分析可見，NSTimer所產生的問題的主要原因是因為其沒有再一個合適的時機invalidate，同時還有NSTimer對target的強引用導致的記憶體洩漏問題。

那麼解決NSTimer的問題的關鍵點在於以下兩點：

1.  NSTimer對其target是否可以不強引用

2.  是否找到一個合適的時機，在確定NSTimer已經失效的情況下，讓NSTimer自動invalidate

關於第一個問題，target的強引用問題。 可以用如下圖的方案來解決：

![image](https://upload-images.jianshu.io/upload_images/22877992-d8536eb902828998?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在NSTimer和target之間加入一層stubTarget，stubTarget主要做為一個橋接層，負責NSTimer和target之間的通訊。

同時NSTimer強引用stubTarget，而stubTarget弱引用target，這樣target和NSTimer之間的關係也就是弱引用了，意味著target可以自由的釋放，從而解決了迴圈引用的問題。

上文提到了stubTarget負責NSTimer和target的通訊，其具體的實現過程又細分為兩大步：

**step 1.** swizzle NSTimer中scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: 相關的方法，在新方法中動態建立stubTarget物件，stubTarget物件弱引用持有原有的target，selector，timer，targetClass等properties。然後將原target分發stubTarget上，selector回撥函式為stubTarget的fireProxyTimer：，流程如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-94ab1b478b6d336e?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

**step 2.** 透過stubTarget的fireProxyTimer：來具體處理回撥函式selector的處理和分發，流程如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-9fe808c515a7b6a4?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

因為stubTarget的介入，原有的target已經可以不受NSTimer強引用的牽制，而自由的釋放。

由上圖流程可知，當NSTimer的回撥函式fireProxyTimer：被執行的時候，會自動判斷原target是否已經被釋放，如果釋放了，意味著NSTimer已經無效，此時如果還繼續呼叫原有target的selector很有可能會導致crash，而且是沒有必要的。所以此時需要將NSTimer invalidate，然後統計上報錯誤資料。如此一來就做到了NSTimer在合適的時機自動invalidate。

### 3.5 Container型別crash防護（Container）

#### 3.5.1 Container crash 產生原因

Container 型別的crash 指的是容器類的crash，常見的有NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的crash。 一些常見的越界，插入nil，等錯誤操作均會導致此類crash發生。 由於產生的原因比較簡單，就不展開來描述了。

該類crash雖然比較容易排查，但是其在app crash機率總比還是挺高，所以有必要對其進行防護。

#### 3.5.2 Container crash 防護方案

Container crash 型別的防護方案也比較簡單，針對於NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的一些常用的會導致崩潰的API進行method swizzling，然後在swizzle的新方法中加入一些條件限制和判斷，從而讓這些API變的安全，這裡就不展開來具體描述了。

### 3.6 NSString型別crash防護（NSString）

NSString／NSMutableString 型別的crash的產生原因和防護方案與Container crash很相像，這裡也不展開來描述了。

### 3.7 野指標型別crash防護（Bad Access）

#### 3.7.1 野指標crash 產生原因

在App的所有Crash中，訪問野指標導致的Crash佔了很大一部分，野指標型別crash的表現為：Exception Type:SIGSEGV，Exception Codes: SEGV_ACCERR 或者 如下圖：

![image](https://upload-images.jianshu.io/upload_images/22877992-9121cefe5a645bc3?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

解決野指標導致的crash往往是一件棘手的事情，一來產生crash 的場景不好復現，二來crash之後console的資訊提供的幫助有限。 XCode本身為了便於開放除錯時發現野指標問題，提供了Zombie機制，能夠在發生野指標時提示出現野指標的類，從而解決了開發階段出現野指標的問題。然而針對於線上產生的野指標問題，依舊沒有一個比較好的辦法來定位問題。

所以，因為野指標出現機率高而且難定位問題，非常有必要針對於野指標專門做一層防護措施。

#### 3.7.2 野指標crash 防護方案

野指標問題的解決思路方向其實很容易確定，XCode提供了Zombie的機制來排查野指標的問題，那麼我們這邊可以實現一個類似於Zombie的機制，加上對zombie例項的全部方法攔截機制 和 訊息轉發機制，那麼就可以做到在野指標訪問時不Crash而只是crash時相關的資訊。

同時還需要注意一點：因為zombie的機制需要在物件釋放時保留其指標和相關記憶體佔用，隨著app的進行，越來越多的物件被建立和釋放，這會導致記憶體佔用越來越大，這樣顯然對於一個正常執行的app的效能有影響。所以需要一個合適的zombie物件釋放機制，確定zombie機制對記憶體的影響是有限度的。

improve版的zombie機制的實現主要分為以下四個環節：

**step 1.** method swizzling替換NSObject的allocWithZone方法，在新的方法中判斷該型別物件是否需要加入野指標防護，如果需要，則透過objc_setAssociatedObject為該物件設定flag標記，被標記的物件後續會進入zombie流程

流程圖如下：

![image](https://upload-images.jianshu.io/upload_images/22877992-2c4a13c9f9888360?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

做flag標記是因為很多系統類，比如NSString，UIView等建立，釋放非常頻繁，而這些例項發生野指標機率非常低。基本都是我們自己寫的類才會有野指標的相關問題，所以透過在建立時 設定一個標記用來過濾不必要做野指標防護的例項，提高方案的效率。

同時做判斷是否要加入標記的條件裡面，我們加入了黑名單機制，是因為一些特定的類是不適用於新增到zombie機制的，會發生崩潰（例如：NSBundle），而且所以和zombie機制相關的類也不能加入標記，否則會在釋放過程中迴圈引用和呼叫，導致記憶體洩漏甚至棧溢位。

**step 2.** method swizzling替換NSObject的dealloc方法，對flag標記的物件例項呼叫objc_destructInstance，釋放該例項引用的相關屬性，然後將例項的isa修改為HTZombieObject。透過objc_setAssociatedObject 儲存將原始類名儲存在該例項中。

流程圖如下：

![image](https://upload-images.jianshu.io/upload_images/22877992-1ecb7622eb98e63f?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

**呼叫objc_destructInstance的原因：**

這裡參考了系統在Object-C Runtime 中NSZombies實現，dealloc最後會調到*object*dispose函式，在這個函式里面 其實也做了三件事情，

1）呼叫objc_destructInstance釋放該例項引用的相關例項

2）將該例項的isa修改為stubClass，接受任意方法呼叫

3）釋放該記憶體

官方文件對objc_destructInstance的解釋為：

**Destroys an instance of a class without freeing memory and removes any associated references this instance might have had.**

說明objc_destructInstance會釋放與例項相關聯的引用，但是並不釋放該例項等記憶體。

**step 3.** 在HTZombieObject 透過訊息轉發機制forwardingTargetForSelector處理所有攔截的方法，根據selector動態新增能夠處理方法的響應者HTStubObject 例項，然後透過 objc_getAssociatedObject 獲取之前儲存該例項對應的原始類名，統計錯誤資料。

流程圖如下：

![image](https://upload-images.jianshu.io/upload_images/22877992-aeac28cb1e4377d5?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

HTZombieObject的處理和unrecognized selector crash的處理是一樣，主要的目的就是攔截所有傳給HTZombieObject的函式，用一個返回為空的函式來替換，從而達到程式不崩潰的目的。

**step 4.** 當退到後臺或者達到未釋放例項的上限時，則在ht_freeSomeMemory方法中呼叫原有dealloc方法釋放所有被zombie化的例項

綜上所述，可以用下圖總結一下bad access型別crash的防護流程：

![image](https://upload-images.jianshu.io/upload_images/22877992-6c373e7785d762f7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

#### 3.7.3 相關的風險

**1.做了野指標防護，透過動態插入一個空實現的方法來防止出現Crash，但是業務層面的表現難以確定，可能會進入業務異常的狀態。需要擬定一下如何展現該問題給使用者的方案**

**2.由於做了延時釋放若干例項，對系統總記憶體會產生一定影響，目前將記憶體的緩衝區開到2M左右，所以應該沒有很大的影響，但還是可能潛在一些風險。**

**3.延時釋放例項是根據相關功能程式碼會聚焦在某一個時間段呼叫的假設前提下，所以野指標的zombie保護機制只能在其例項物件仍然快取在zombie的快取機制時才有效，若在例項真正釋放之後，再呼叫野指標還是會出現Crash。**

### 3.8 非主執行緒刷UI型別crash防護（UI not on Main Thread）

在非主執行緒刷UI將會導致app執行crash，有必要對其進行處理。

目前初步的處理方案是swizzle UIView類的以下三個方法：

```
- (void)setNeedsLayout;
- (void)setNeedsDisplay;
- (void)setNeedsDisplayInRect:(CGRect)rect;
```

在這三個方法呼叫的時候判斷一下當前的執行緒，如果不是主執行緒的話，直接利用 **dispatch_async(dispatch_get_main_queue(), ^{ //呼叫原本方法 });**

來將對應的刷UI的操作轉移到主執行緒上，同時統計錯誤資訊。

但是真正實施了之後，發現這三個方法並不能完全覆蓋UIView相關的所有刷UI到操作，但是如果要將全部到UIView的刷UI的方法統計起來並且swizzle，感覺略笨拙而且不高效。

所以作者依舊在尋找，看是否有更好的方案來解決該問題。

## Chapter 4 - 使用手冊

目前sdk實現了以下的功能和配置：

##### 1\. 配置需要防護的crash型別

可以根據自身需要，選擇一定的crash防護配置，透過以下的介面進行配置：

```
- (void)configSafetyGuardService:(HTSafetyGuardType)SafetyGuardType;
```

其中可以配置的SafetyGuardType有：

*   HTSafetyGuardType_None

*   HTSafetyGuardType_All

*   HTSafetyGuardType_UnrecognizedSelector

*   HTSafetyGuardType_KVO

*   HTSafetyGuardType_BadAccess

*   HTSafetyGuardType_Notification

*   HTSafetyGuardType_Timer

*   HTSafetyGuardType_Container

*   HTSafetyGuardType_String

*   HTSafetyGuardType_UI

可以根據自己專案的需求自行選擇需要防護的型別。

##### 2\. 實時 開啟／暫停 安全防護功能

配置完畢之後，需要呼叫- (void)start;來開啟防護，防護的開關是實時的（無需重啟app），可以在任意的時刻選擇 開啟／關閉 防護功能。

透過 **- (BOOL)isWorking** 介面可以獲取當前防護功能的狀態。

透過 **- (void)start** 介面實時開啟防護功能

透過 **- (void)stop** 介面實時關閉防護功能

##### 3\. 配置白名單和黑名單，指定對應的想 加上／去掉 安全防護功能的類和物件

由於不同類實現的特殊性，考慮到可能某些類並不需要開啟防護功能。 所以提供了黑名單的功能。 在黑名單裡面的類本身以及其子類，都不會進入防護的範圍。

白名單的出現是因為作者在開發的時候發現一些系統自帶的類是沒有必要進入防護範圍的，所以將整體防護的範圍調整到所有使用者自定義的類裡面。 但是之後又發現絕大多數的crash和一些常用的系統的類（例如NSString，NSDictionary，UIView等等）有很強的聯絡，針對於這些常用的系統類還是很有必要開啟防護的。所以針對這些需要防護的系統類，專門提供了白名單的功能。

注意：野指標型別的防護，由於其特殊性，不適用於這套白名單和黑名單。 其自身會維護一套新的黑白名單，詳見：**3.7 野指標型別Crash防護**

##### 4\. 設定異常處理handler，指定出現crash被抓取情況之後，使用者想自定義的操作

出現了crash，並且被我們的系統捕捉到加以處理之後，使用者可能還需要進一步的處理，例如上傳埋點等。這時可以透過設定一個handler來實現， HTExceptionHandler會將crash的資訊透過HTCrashInfo的形式來返回。

HTCrashInfo內包含了:

*   導致crash的型別：crashType

*   crash執行緒的呼叫棧：callStackSymbols

*   crash的具體描述資訊：crashDescription

*   擴充套件資訊：userinfo

以上介面具體詳細的資訊均可以在（HTSafetyGuardService.h）中找到。(注意HTSafetyGuardService是單例)

# 推薦?：
面試題持續整理更新中，如果你想一起進階，不妨新增一下交流群[**1012951431**](https://links.jianshu.com/go?to=https%3A%2F%2Fjq.qq.com%2F%3F_wv%3D1027%26k%3D5JFjujE)

面試題資料或者相關學習資料都在群檔案中 進群即可下載！
![](https://upload-images.jianshu.io/upload_images/22877992-ebc888ad227a66d7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)</nsstring></nskeyvaluechangekey>

iOS APP執行時Crash自動修復系統

相關文章