Baymax：網(wǎng)易iOS App運行時Crash自動防護實踐
<section style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; color: rgb(63, 63, 63); font-size: 14px; font-family: Avenir, -apple-system-font, 微軟雅黑, sans-serif; text-align: center;">
版權(quán)聲明
本文轉(zhuǎn)自網(wǎng)易杭州前端技術(shù)部公眾號，由作者授權(quán)發(fā)布。
<section class="" style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 20px;">
前言
</section>
大白（Baymax），迪士尼動畫《超能陸戰(zhàn)隊》中的健康機器人，是一個體型胖胖的充氣機器人，因呆萌的外表和善良的本質(zhì)獲得大家的喜愛，被稱為“萌神”。
Baymax項目是為了減少開發(fā)人員在開發(fā)中一些不規(guī)范的代碼編寫造成的內(nèi)存泄露，界面卡頓，耗電等問題而來的一個監(jiān)控系統(tǒng)。
現(xiàn)在Baymax迎來了它新的功能：APP運行時Crash自動防護功能，為app的流程順利運行保駕護航！
下面將詳細介紹一下APP運行時Crash自動修復(fù)系統(tǒng)開發(fā)的目的，設(shè)計的原理以及使用的方法。
<section class="" style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px;">
Chapter 1 - 開發(fā)目的
</section>
是否存在這樣的夜晚，當(dāng)剛剛躺下準備美美的睡一覺的時候， 突然來一記奪命電話Call，一接起來發(fā)現(xiàn)是你老板?。?！“小王啊，剛剛上線的X.X.X版本出問題了啊，怎么樣操作會crash啊，導(dǎo)致新功能都無法使用了，快定位一下是什么原因，抓緊hotpatch修復(fù)一下?。 ?。心里一萬頭草泥馬呼嘯而過，瞬間已經(jīng)滿頭大汗的你卻還要故作鎮(zhèn)靜地回答：“嗯，老板我馬上去看看，一定努力解決問題！” 急忙打開電腦的你，知道今夜注定無眠了。
是否又存在這樣的情形，你老板把大家都聚起來開了一個年初KPI目標制定會議，說到：“作為一個資深的技術(shù)團隊，app性能是我們技術(shù)團隊首抓的目標，其中很最要的一項就是app的崩潰率，去年我們app統(tǒng)計出來的崩潰率是千分之五，而我們的競爭對手的崩潰率只有萬分之五，相差了10倍！今年我們要趕超他們，最起碼也要和他們持平?！?你甚是贊同，但是你心里卻又有點懷疑，對方的開發(fā)資源是我們的好幾倍而且個個都是資深老司機，我們團隊里卻大多都是應(yīng)屆生小鮮肉，這KPI能完成么？
大白健康系統(tǒng)--APP運行時Crash自動修復(fù)系統(tǒng)正是為了應(yīng)對這些狀況，解決問題而誕生的。
APP運行時Crash自動修復(fù)+捕獲系統(tǒng)的設(shè)計初衷，就是為了降低app的crash率。利用Objective-C語言的動態(tài)特性，采用AOP(Aspect Oriented Programming) 面向切面編程的設(shè)計思想，做到無痕植入。能夠自動在app運行時實時捕獲導(dǎo)致app崩潰的破環(huán)因子，然后通過特定的技術(shù)手段去化解這些破壞因子，使app免于崩潰，照樣可以繼續(xù)正常運行，為app的持續(xù)運轉(zhuǎn)保駕護航。
<section class="" style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px;">
Chapter 2 - 功能簡介
</section>
APP運行時Crash自動修復(fù)系統(tǒng) 的主要功能，可以用一句話來簡單的概括：對業(yè)務(wù)代碼的零侵入性地將原本會導(dǎo)致app崩潰的crash抓取住，消滅掉，保證app繼續(xù)正常地運行，再將crash的具體信息提取出來，實時返回給用戶。
通過下面的一個小例子就可以很直觀的體現(xiàn)出來系統(tǒng)的作用：
調(diào)用以下的一段代碼
結(jié)果肯定會導(dǎo)致app的崩潰，因為testObj是一個UIButton對象，而UIButton并沒有實現(xiàn) someMethod： 這個方法，所以向testObj發(fā)送someMethod：這個方法的時候，將會導(dǎo)致該方法無法在相關(guān)的方法列表里找到，最終導(dǎo)致app的crash。
但是通過我們的crash防護系統(tǒng)，調(diào)用這段代碼時app并不會崩潰，同時XCode的Console如下：
可見對應(yīng)的crash的信息（crash類型，原因，調(diào)用棧信息）均可以完整的打印在XCode的Console中。
說明我們的大白系統(tǒng)已經(jīng)捕捉到了這個crash，將該crash消滅掉并且吐出來該crash的完整信息。
當(dāng)然目前系統(tǒng)的功能并沒有強大到可以把所有的crash都處理掉，不過一些常見的高頻次發(fā)生的crash，系統(tǒng)均會針對他們一一處理。目前可以處理掉的crash類型具體有以下幾種：
unrecognized selector crash
KVO crash
NSNotification crash
NSTimer crash
Container crash（數(shù)組越界，插nil等）
NSString crash （字符串操作的crash）
Bad Access crash （野指針）
UI not on Main Thread Crash (非主線程刷UI(機制待改善))
對于每種類型的crash，安全系統(tǒng)都采取不同的方式，進行了對應(yīng)的處理。
<section class="" style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px;">
Chapter 3 - 實現(xiàn)原理
</section>
前面已經(jīng)提過，目前的安全防護系統(tǒng)可以覆蓋到8中類型的Crash，接下來將一一詳細介紹這8種類型的Crash的防護的實現(xiàn)的具體原理：
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.1 Unrecognized Selector類型crash防護</section>
3.1.1 crash產(chǎn)生原因
unrecognized selector類型的crash在app眾多的crash類型中占著比較大的成分，通常是因為一個對象調(diào)用了一個不屬于它方法的方法導(dǎo)致的。
例如調(diào)用以下一段代碼就會產(chǎn)生crash
具體crash時的表現(xiàn)見下圖：
要解決這中類型的crash，我們需要先了解清楚它產(chǎn)生的具體原因和流程。
3.1.2 方法調(diào)用流程
讓我們看一下方法調(diào)用在運行時的過程。
runtime中具體的方法調(diào)用流程大致如下：
首先，在相應(yīng)操作的對象中的緩存方法列表中找調(diào)用的方法，如果找到，轉(zhuǎn)向相應(yīng)實現(xiàn)并執(zhí)行。
如果沒找到，在相應(yīng)操作的對象中的方法列表中找調(diào)用的方法，如果找到，轉(zhuǎn)向相應(yīng)實現(xiàn)執(zhí)行
如果沒找到，去父類指針所指向的對象中執(zhí)行1，2.
以此類推，如果一直到根類還沒找到，轉(zhuǎn)向攔截調(diào)用，走消息轉(zhuǎn)發(fā)機制。
如果沒有重寫攔截調(diào)用的方法，程序報錯。
3.1.3 攔截調(diào)用
在方法調(diào)用中說到了，如果沒有找到方法就會轉(zhuǎn)向攔截調(diào)用。
那么什么是攔截調(diào)用呢？
攔截調(diào)用就是，在找不到調(diào)用的方法程序崩潰之前，你有機會通過重寫NSObject的四個方法來處理:
攔截調(diào)用的整個流程即Objective-C的消息轉(zhuǎn)發(fā)機制。其具體流程如下圖：
由上圖可見，在一個函數(shù)找不到時，runtime提供了三種方式去補救：
調(diào)用resolveInstanceMethod給個機會讓類添加這個實現(xiàn)這個函數(shù)
調(diào)用forwardingTargetForSelector讓別的對象去執(zhí)行這個函數(shù)
調(diào)用forwardInvocation（函數(shù)執(zhí)行器）靈活的將目標函數(shù)以其他形式執(zhí)行。
如果都不中，調(diào)用doesNotRecognizeSelector拋出異常。
3.1.4 unrecognized selector crash 防護方案
既然可以補救，我們完全也可以利用消息轉(zhuǎn)發(fā)機制來做文章。那么問題來了，在這三個步驟里面，選擇哪一步去改造比較合適呢。
這里我們選擇了第二步forwardingTargetForSelector來做文章。原因如下：
resolveInstanceMethod需要在類的本身上動態(tài)添加它本身不存在的方法，這些方法對于該類本身來說冗余的
forwardInvocation可以通過NSInvocation的形式將消息轉(zhuǎn)發(fā)給多個對象，但是其開銷較大，需要創(chuàng)建新的NSInvocation對象，并且forwardInvocation的函數(shù)經(jīng)常被使用者調(diào)用，來做多層消息轉(zhuǎn)發(fā)選擇機制，不適合多次重寫
forwardingTargetForSelector可以將消息轉(zhuǎn)發(fā)給一個對象，開銷較小，并且被重寫的概率較低，適合重寫
選擇了forwardingTargetForSelector之后，可以將NSObject的該方法重寫，做以下幾步的處理：
動態(tài)創(chuàng)建一個樁類
動態(tài)為樁類添加對應(yīng)的Selector，用一個通用的返回0的函數(shù)來實現(xiàn)該SEL的IMP
將消息直接轉(zhuǎn)發(fā)到這個樁類對象上。
流程圖如下：
注意如果對象的類本事如果重寫了forwardInvocation方法的話，就不應(yīng)該對forwardingTargetForSelector進行重寫了，否則會影響到該類型的對象原本的消息轉(zhuǎn)發(fā)流程。
通過重寫NSObject的forwardingTargetForSelector方法，我們就可以將無法識別的方法進行攔截并且將消息轉(zhuǎn)發(fā)到安全的樁類對象中，從而可以使app繼續(xù)正常運行。
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.2 KVO類型crash防護</section>
3.2.1 KVO crash 產(chǎn)生原因
KVO,即：Key-Value Observing，它提供一種機制，當(dāng)指定的對象的屬性被修改后，則對象就會接受收到通知。簡單的說就是每次指定的被觀察的對象的屬性被修改后，KVO就會自動通知相應(yīng)的觀察者了。
KVO機制在iOS的很多開發(fā)場景中都會被使用到。不過如果一不小心使用不當(dāng)?shù)脑?，會?dǎo)致大量的crash問題。所以如果能找到一種方法能夠自動抓取這些由于開發(fā)者粗心所導(dǎo)致的KVO Crash問題的話，是有一定的價值的。
首先我們來看看通過會導(dǎo)致KVO Crash的兩種情形：
KVO的被觀察者dealloc時仍然注冊著KVO導(dǎo)致的crash，見下圖
添加KVO重復(fù)添加觀察者或重復(fù)移除觀察者（KVO注冊觀察者與移除觀察者不匹配）導(dǎo)致的crash，見下圖
3.2.2 KVO crash 防護方案
通常一個對象的KVO關(guān)系圖如下：
一個被觀察的對象(Observed Object)上有若干個觀察者(Observer),每個觀察者又觀察若干條KeyPath。
如果觀察者和keypath的數(shù)量一多，很容易理不清楚被觀察對象整個KVO關(guān)系，導(dǎo)致被觀察者在dealloc的時候，還殘存著一些關(guān)系沒有被注銷。 同時還會導(dǎo)致KVO注冊觀察者與移除觀察者不匹配的情況發(fā)生。
筆者曾經(jīng)還遇到過在多線程的情況下，導(dǎo)致KVO重復(fù)添加觀察者或移除觀察者的情況。這類問題通常多數(shù)發(fā)生的比較隱蔽，不容易從代碼的層面去排查。
由上可見多數(shù)由于KVO而導(dǎo)致的crash原因是由于被觀察對象的KVO關(guān)系圖混亂導(dǎo)致。那么如何來管理混亂的KVO關(guān)系呢?？梢宰尡挥^察對象持有一個KVO的delegate，所有和KVO相關(guān)的操作均通過delegate來進行管理，delegate通過建立一張map來維護KVO整個關(guān)系。如下圖：
這樣做的好處有兩個：
如果出現(xiàn)KVO重復(fù)添加觀察者或重復(fù)移除觀察者（KVO注冊觀察者與移除觀察者不匹配）的情況，delegate可以直接阻止這些非正常的操作。
被觀察對象dealloc之前，可以通過delegate自動將與自己有關(guān)的KVO關(guān)系都注銷掉，避免了KVO的被觀察者dealloc時仍然注冊著KVO導(dǎo)致的crash。
被swizzle的方法分別是：
關(guān)于
方法改造流程如下圖：
通過上面的流程，將observerd對象的所有kvo相關(guān)的observer信息全部轉(zhuǎn)移到KVOdelegate上，并且避免了相同kvoinfo被重復(fù)添加多次的可能性。
關(guān)于
方法改造流程如下圖：
移除一個keypath的Observer時，當(dāng)delegate的kvoInfoMap中找不到key為該keypath的時候，說明此時delegate并沒有持有對應(yīng)keypath的observer，即說明移除了一個不匹配的觀察者，此時如果再繼續(xù)操作會導(dǎo)致app崩潰，所以應(yīng)該及時中斷流程，然后統(tǒng)計異常信息。
當(dāng)keypath對應(yīng)的KVOInfo列表（infoArray）為空的時候，說明此時delegate已經(jīng)不再持有任何和keypath相關(guān)的observer了。這時應(yīng)該調(diào)用原有removeObserver的方法將delegate對應(yīng)的觀察者移除。
注意到在檢查遍歷infoArray的時侯，除了要刪除對應(yīng)的info信息，還多了一步檢查info.observer == nil的過程，是因為如果observer為nil，那么此時如果keypath對應(yīng)的值變化的話，也會因為找不到observer而崩潰，所以需要做這一步來阻止該種情況的發(fā)生。
關(guān)于
方法改造流程如下圖：
delegate對于observeValueForKeyPath方法的修改最主要的地方是，在于將對應(yīng)的響應(yīng)方法轉(zhuǎn)移給真正的KVO Observer，通過keyInfoMap找到keypath對應(yīng)的KVOInfo里面預(yù)先存儲好的observer，然后調(diào)用observer原本的響應(yīng)方法。
同時在遍歷InfoArray的時候，發(fā)現(xiàn)info.observerw == nil的時候，需要及時將其清除掉，避免KVO的觀察者observer被釋放后value變化導(dǎo)致的crash.
最后，針對 KVO的被觀察者dealloc時仍然注冊著KVO導(dǎo)致的crash 的情況，可以將NSObject的dealloc swizzle， 在object dealloc的時候自動將其對應(yīng)的kvodelegate所有和kvo相關(guān)的數(shù)據(jù)清空，然后將kvodelegate也置空。避免出現(xiàn)KVO的被觀察者dealloc時仍然注冊著KVO而產(chǎn)生的crash.
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.3 NSNotification類型crash防護</section>
3.3.1 crash 產(chǎn)生原因
當(dāng)一個對象添加了notification之后，如果dealloc的時候，仍然持有notification，就會出現(xiàn)NSNotification類型的crash。
NSNotification類型的crash多產(chǎn)生于程序員寫代碼時候犯疏忽，在NSNotificationCenter添加一個對象為observer之后，忘記了在對象dealloc的時候移除它。
所幸的是，蘋果在iOS9之后專門針對于這種情況做了處理，所以在iOS9之后，即使開發(fā)者沒有移除observer，Notification crash也不會再產(chǎn)生了。
不過針對于iOS9之前的用戶，我們還是有必要做一下NSNotification Crash的防護的。
3.3.2 NSNotification crash 防護方案
NSNotification Crash的防護原理很簡單， 利用method swizzling hook NSObject的dealloc函數(shù)，再對象真正dealloc之前先調(diào)用一下
[[NSNotificationCenter defaultCenter] removeObserver:self]
即可。
注意到并不是所有的對象都需要做以上的操作，如果一個對象從來沒有被NSNotificationCenter 添加為observer的話，在其dealloc之前調(diào)用removeObserver完全是多此一舉。 所以我們hook了NSNotificationCenter的
addObserver:(id)observer selector:(SEL)aSelector name:(NSString *)aName object:(id)anObject
函數(shù)，在其添加observer的時候，對observer動態(tài)添加標記flag。這樣在observer dealloc的時候，就可以通過flag標記來判斷其是否有必要調(diào)用removeObserver函數(shù)了。
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.4 NSTimer類型crash防護</section>
3.4.1 NSTimer crash 產(chǎn)生原因
在程序開發(fā)過程中，大家會經(jīng)常使用定時任務(wù)，但使用NSTimer的 scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:接口做重復(fù)性的定時任務(wù)時存在一個問題：NSTimer會強引用target實例，所以需要在合適的時機invalidate定時器，否則就會由于定時器timer強引用target的關(guān)系導(dǎo)致target不能被釋放，造成內(nèi)存泄露，甚至在定時任務(wù)觸發(fā)時導(dǎo)致crash。 crash的展現(xiàn)形式和具體的target執(zhí)行的selector有關(guān)。
與此同時，如果NSTimer是無限重復(fù)的執(zhí)行一個任務(wù)的話，也有可能導(dǎo)致target的selector一直被重復(fù)調(diào)用且處于無效狀態(tài)，對app的CPU，內(nèi)存等性能方面均是沒有必要的浪費。
所以，很有必要設(shè)計出一種方案，可以有效的防護NSTimer的濫用問題。
3.4.2 NSTimer crash 防護方案
上面的分析可見，NSTimer所產(chǎn)生的問題的主要原因是因為其沒有再一個合適的時機invalidate，同時還有NSTimer對target的強引用導(dǎo)致的內(nèi)存泄漏問題。
那么解決NSTimer的問題的關(guān)鍵點在于以下兩點：
NSTimer對其target是否可以不強引用
是否找到一個合適的時機，在確定NSTimer已經(jīng)失效的情況下，讓NSTimer自動invalidate
關(guān)于第一個問題，target的強引用問題。 可以用如下圖的方案來解決：
在NSTimer和target之間加入一層stubTarget，stubTarget主要做為一個橋接層，負責(zé)NSTimer和target之間的通信。
同時NSTimer強引用stubTarget，而stubTarget弱引用target，這樣target和NSTimer之間的關(guān)系也就是弱引用了，意味著target可以自由的釋放，從而解決了循環(huán)引用的問題。
上文提到了stubTarget負責(zé)NSTimer和target的通信，其具體的實現(xiàn)過程又細分為兩大步：
Step 1. swizzle NSTimer中scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: 相關(guān)的方法，在新方法中動態(tài)創(chuàng)建stubTarget對象，stubTarget對象弱引用持有原有的target，selector，timer，targetClass等properties。然后將原target分發(fā)stubTarget上，selector回調(diào)函數(shù)為stubTarget的fireProxyTimer，流程如下圖：
Step 2. 通過stubTarget的fireProxyTimer：來具體處理回調(diào)函數(shù)selector的處理和分發(fā)，流程如下圖：
因為stubTarget的介入，原有的target已經(jīng)可以不受NSTimer強引用的牽制，而自由的釋放。
由上圖流程可知，當(dāng)NSTimer的回調(diào)函數(shù)fireProxyTimer:被執(zhí)行的時候，會自動判斷原target是否已經(jīng)被釋放，如果釋放了，意味著NSTimer已經(jīng)無效，此時如果還繼續(xù)調(diào)用原有target的selector很有可能會導(dǎo)致crash，而且是沒有必要的。所以此時需要將NSTimer invalidate，然后統(tǒng)計上報錯誤數(shù)據(jù)。如此一來就做到了NSTimer在合適的時機自動invalidate。
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.5 Container類型crash防護</section>
3.5.1 Container crash 產(chǎn)生原因
Container 類型的crash 指的是容器類的crash，常見的有NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的crash。 一些常見的越界、插入nil等錯誤操作均會導(dǎo)致此類crash發(fā)生。 由于產(chǎn)生的原因比較簡單，就不展開來描述了。
該類crash雖然比較容易排查，但是其在app crash概率總比還是挺高，所以有必要對其進行防護。
3.5.2 Container crash 防護方案
Container crash 類型的防護方案也比較簡單，針對于NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的一些常用的會導(dǎo)致崩潰的API進行method swizzling，然后在swizzle的新方法中加入一些條件限制和判斷，從而讓這些API變的安全，這里就不展開來具體描述了。
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.6 NSString類型crash防護</section>
NSString／NSMutableString 類型的crash的產(chǎn)生原因和防護方案與Container crash很相像，這里也不展開來描述了。
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.7 野指針類型crash防護</section>
3.7.1 野指針crash 產(chǎn)生原因
在App的所有Crash中，訪問野指針導(dǎo)致的Crash占了很大一部分，野指針類型crash的表現(xiàn)為：Exception Type:SIGSEGV，Exception Codes: SEGV_ACCERR 或者 如下圖：
解決野指針導(dǎo)致的crash往往是一件棘手的事情，一來產(chǎn)生crash 的場景不好復(fù)現(xiàn)，二來crash之后console的信息提供的幫助有限。 XCode本身為了便于開放調(diào)試時發(fā)現(xiàn)野指針問題，提供了Zombie機制，能夠在發(fā)生野指針時提示出現(xiàn)野指針的類，從而解決了開發(fā)階段出現(xiàn)野指針的問題。然而針對于線上產(chǎn)生的野指針問題，依舊沒有一個比較好的辦法來定位問題。
所以，因為野指針出現(xiàn)概率高而且難定位問題，非常有必要針對于野指針專門做一層防護措施。
3.7.2 野指針crash 防護方案
野指針問題的解決思路方向其實很容易確定，XCode提供了Zombie的機制來排查野指針的問題，那么我們這邊可以實現(xiàn)一個類似于Zombie的機制，加上對zombie實例的全部方法攔截機制 和 消息轉(zhuǎn)發(fā)機制，那么就可以做到在野指針訪問時不Crash而只是crash時相關(guān)的信息。
同時還需要注意一點：因為zombie的機制需要在對象釋放時保留其指針和相關(guān)內(nèi)存占用，隨著app的進行，越來越多的對象被創(chuàng)建和釋放，這會導(dǎo)致內(nèi)存占用越來越大，這樣顯然對于一個正常運行的app的性能有影響。所以需要一個合適的zombie對象釋放機制，確定zombie機制對內(nèi)存的影響是有限度的。
improve版的zombie機制的實現(xiàn)主要分為以下四個環(huán)節(jié)：
step 1. method swizzling替換NSObject的allocWithZone方法，在新的方法中判斷該類型對象是否需要加入野指針防護，如果需要，則通過objc_setAssociatedObject為該對象設(shè)置flag標記，被標記的對象后續(xù)會進入zombie流程
流程圖如下：
做flag標記是因為很多系統(tǒng)類，比如NSString，UIView等創(chuàng)建，釋放非常頻繁，而這些實例發(fā)生野指針概率非常低?；径际俏覀冏约簩懙念惒艜幸爸羔樀南嚓P(guān)問題，所以通過在創(chuàng)建時 設(shè)置一個標記用來過濾不必要做野指針防護的實例，提高方案的效率。
同時做判斷是否要加入標記的條件里面，我們加入了黑名單機制，是因為一些特定的類是不適用于添加到zombie機制的，會發(fā)生崩潰（例如：NSBundle），而且所以和zombie機制相關(guān)的類也不能加入標記，否則會在釋放過程中循環(huán)引用和調(diào)用，導(dǎo)致內(nèi)存泄漏甚至棧溢出。
step 2. method swizzling替換NSObject的dealloc方法，對flag標記的對象實例調(diào)用objc_destructInstance，釋放該實例引用的相關(guān)屬性，然后將實例的isa修改為HTZombieObject。通過objc_setAssociatedObject 保存將原始類名保存在該實例中。
流程圖如下：
調(diào)用objc_destructInstance的原因：
這里參考了系統(tǒng)在Object-C Runtime 中NSZombies實現(xiàn)，dealloc最后會調(diào)到objectdispose函數(shù)，在這個函數(shù)里面 其實也做了三件事情，
調(diào)用objc_destructInstance釋放該實例引用的相關(guān)實例
將該實例的isa修改為stubClass，接受任意方法調(diào)用
釋放該內(nèi)存
官方文檔對objc_destructInstance的解釋為：
Destroys an instance of a class without freeing memory and removes any associated references this instance might have had.
說明objc_destructInstance會釋放與實例相關(guān)聯(lián)的引用，但是并不釋放該實例等內(nèi)存。
Step 3. 在HTZombieObject 通過消息轉(zhuǎn)發(fā)機制forwardingTargetForSelector處理所有攔截的方法，根據(jù)selector動態(tài)添加能夠處理方法的響應(yīng)者HTStubObject 實例，然后通過 objc_getAssociatedObject 獲取之前保存該實例對應(yīng)的原始類名，統(tǒng)計錯誤數(shù)據(jù)。
流程圖如下：
HTZombieObject的處理和unrecognized selector crash的處理是一樣，主要的目的就是攔截所有傳給HTZombieObject的函數(shù)，用一個返回為空的函數(shù)來替換，從而達到程序不崩潰的目的。
Step 4. 當(dāng)退到后臺或者達到未釋放實例的上限時，則在ht_freeSomeMemory方法中調(diào)用原有dealloc方法釋放所有被zombie化的實例
綜上所述，可以用下圖總結(jié)一下bad access類型crash的防護流程：
3.7.3 相關(guān)的風(fēng)險
做了野指針防護，通過動態(tài)插入一個空實現(xiàn)的方法來防止出現(xiàn)Crash，但是業(yè)務(wù)層面的表現(xiàn)難以確定，可能會進入業(yè)務(wù)異常的狀態(tài)。需要擬定一下如何展現(xiàn)該問題給用戶的方案。
由于做了延時釋放若干實例，對系統(tǒng)總內(nèi)存會產(chǎn)生一定影響，目前將內(nèi)存的緩沖區(qū)開到2M左右，所以應(yīng)該沒有很大的影響，但還是可能潛在一些風(fēng)險。
延時釋放實例是根據(jù)相關(guān)功能代碼會聚焦在某一個時間段調(diào)用的假設(shè)前提下，所以野指針的zombie保護機制只能在其實例對象仍然緩存在zombie的緩存機制時才有效，若在實例真正釋放之后，再調(diào)用野指針還是會出現(xiàn)Crash。
<section class="" style="margin: 30px 0px 0px 8px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px; text-align: left; color: rgb(60, 112, 198);">
3.8 非主線程刷UI類型crash防護（UI not on Main Thread）</section>
在非主線程刷UI將會導(dǎo)致app運行crash，有必要對其進行處理。
目前初步的處理方案是swizzle UIView類的以下三個方法：
- (void)setNeedsLayout;
- (void)setNeedsDisplay;
- (void)setNeedsDisplayInRect:(CGRect)rect;
在這三個方法調(diào)用的時候判斷一下當(dāng)前的線程，如果不是主線程的話，直接利用 dispatch_async(dispatch_get_main_queue(), ^{ //調(diào)用原本方法 });
來將對應(yīng)的刷UI的操作轉(zhuǎn)移到主線程上，同時統(tǒng)計錯誤信息。
但是真正實施了之后，發(fā)現(xiàn)這三個方法并不能完全覆蓋UIView相關(guān)的所有刷UI到操作，但是如果要將全部到UIView的刷UI的方法統(tǒng)計起來并且swizzle，感覺略笨拙而且不高效。
所以作者依舊在尋找，看是否有更好的方案來解決該問題。
<section class="" style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-size: 16px;">
Chapter 4 - 使用手冊
</section>
目前sdk實現(xiàn)了以下的功能和配置：
1. 配置需要防護的crash類型
可以根據(jù)自身需要，選擇一定的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
可以根據(jù)自己項目的需求自行選擇需要防護的類型。
2. 實時 開啟／暫停 安全防護功能
配置完畢之后，需要調(diào)用- (void)start;來開啟防護，防護的開關(guān)是實時的（無需重啟app），可以在任意的時刻選擇 開啟／關(guān)閉 防護功能。
通過- (BOOL)isWorking接口可以獲取當(dāng)前防護功能的狀態(tài)。
通過- (void)start接口實時開啟防護功能
通過- (void)stop接口實時關(guān)閉防護功能
3. 配置白名單和黑名單，指定對應(yīng)的想 加上／去掉 安全防護功能的類和對象
由于不同類實現(xiàn)的特殊性，考慮到可能某些類并不需要開啟防護功能。 所以提供了黑名單的功能。 在黑名單里面的類本身以及其子類，都不會進入防護的范圍。
白名單的出現(xiàn)是因為作者在開發(fā)的時候發(fā)現(xiàn)一些系統(tǒng)自帶的類是沒有必要進入防護范圍的，所以將整體防護的范圍調(diào)整到所有用戶自定義的類里面。 但是之后又發(fā)現(xiàn)絕大多數(shù)的crash和一些常用的系統(tǒng)的類（例如NSString，NSDictionary，UIView等等）有很強的聯(lián)系，針對于這些常用的系統(tǒng)類還是很有必要開啟防護的。所以針對這些需要防護的系統(tǒng)類，專門提供了白名單的功能。
注意：野指針類型的防護，由于其特殊性，不適用于這套白名單和黑名單。 其自身會維護一套新的黑白名單，詳見：3.7 野指針類型Crash防護
4. 設(shè)置異常處理handler，指定出現(xiàn)crash被抓取情況之后，用戶想自定義的操作
出現(xiàn)了crash，并且被我們的系統(tǒng)捕捉到加以處理之后，用戶可能還需要進一步的處理，例如上傳埋點等。這時可以通過設(shè)置一個handler來實現(xiàn)， HTExceptionHandler會將crash的信息通過HTCrashInfo的形式來返回。
HTCrashInfo內(nèi)包含了:
導(dǎo)致crash的類型：crashType
crash線程的調(diào)用棧：callStackSymbols
crash的具體描述信息：crashDescription
擴展信息：userinfo
以上接口具體詳細的信息均可以在（HTSafetyGuardService.h）中找到。(注意HTSafetyGuardService是單例)
由于目前sdk還未經(jīng)過完整的功能測試和性能測試，故暫不開放對應(yīng)的sdk。等作者覺得項目質(zhì)量達到了一定的標準之后，會將項目sdk開放出來。如果對該項目感興趣，可以聯(lián)系 taozeyu890217@126.com ，歡迎一起研究。
</section>
