溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
大白（ Baymax），迪士尼動畫《超能陸戰隊》中的健康機器人，是一個體型胖胖的充氣機器人，因呆萌的外表和善良的本質獲得大家的喜愛，被稱為“萌神”。
Baymax項目是為了減少開發人員在開發中一些不規范的代碼編寫造成的內存泄露，界面卡頓，耗電等問題而來的一個監控系統。
現在Baymax迎來了它新的功能：APP運行時Crash自動防護功能，為app的流程順利運行保駕護航！
下面將詳細介紹一下 APP運行時Crash自動修復系統 開發的目的，設計的原理以及使用的方法。
是否存在這樣的夜晚，當剛剛躺下準備美美的睡一覺的時候， 突然來一記奪命電話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的持續運轉保駕護航。
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如下：
可見對應的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 - 實現原理
前面已經提過，目前的安全防護系統可以覆蓋到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的防護的實現的具體原理：
unrecognized selector類型的crash在app眾多的crash類型中占著比較大的成分，通常是因為一個對象調用了一個不屬于它方法的方法導致的。
例如調用以下一段代碼就會產生crash
//test code
UIButton * testObj = [[UIButton alloc] init];
[testObj performSelector:@selector(someMethod:)];
具體crash時的表現見下圖：
要解決這中類型的crash，我們需要先了解清楚它產生的具體原因和流程。
讓我們看一下方法調用在運行時的過程。
runtime中具體的方法調用流程大致如下：
1.首先，在相應操作的對象中的緩存方法列表中找調用的方法，如果找到，轉向相應實現并執行。
2.如果沒找到，在相應操作的對象中的方法列表中找調用的方法，如果找到，轉向相應實現執行
3.如果沒找到，去父類指針所指向的對象中執行1，2.
4.以此類推，如果一直到根類還沒找到，轉向攔截調用，走消息轉發機制。
5.如果沒有重寫攔截調用的方法，程序報錯。
在方法調用中說到了，如果沒有找到方法就會轉向攔截調用。
那么什么是攔截調用呢？
攔截調用就是，在找不到調用的方法程序崩潰之前，你有機會通過重寫NSObject的四個方法來處理:
+ (BOOL)resolveClassMethod:(SEL)sel;
+ (BOOL)resolveInstanceMethod:(SEL)sel;
//后兩個方法需要轉發到其他的類處理
- (id)forwardingTargetForSelector:(SEL)aSelector;
- (void)forwardInvocation:(NSInvocation *)anInvocation;
攔截調用的整個流程即Objective——C的消息轉發機制。其具體流程如下圖：
由上圖可見，在一個函數找不到時，runtime提供了三種方式去補救：
1、調用resolveInstanceMethod給個機會讓類添加這個實現這個函數
2、調用forwardingTargetForSelector讓別的對象去執行這個函數
3、調用forwardInvocation（函數執行器）靈活的將目標函數以其他形式執行。
如果都不中，調用doesNotRecognizeSelector拋出異常。
既然可以補救，我們完全也可以利用消息轉發機制來做文章。那么問題來了，在這三個步驟里面，選擇哪一步去改造比較合適呢。
這里我們選擇了第二步forwardingTargetForSelector來做文章。原因如下：
resolveInstanceMethod 需要在類的本身上動態添加它本身不存在的方法，這些方法對于該類本身來說冗余的
forwardInvocation可以通過NSInvocation的形式將消息轉發給多個對象，但是其開銷較大，需要創建新的NSInvocation對象，并且forwardInvocation的函數經常被使用者調用，來做多層消息轉發選擇機制，不適合多次重寫
forwardingTargetForSelector可以將消息轉發給一個對象，開銷較小，并且被重寫的概率較低，適合重寫
選擇了forwardingTargetForSelector之后，可以將NSObject的該方法重寫，做以下幾步的處理：
1.動態創建一個樁類
2.動態為樁類添加對應的Selector，用一個通用的返回0的函數來實現該SEL的IMP
3.將消息直接轉發到這個樁類對象上。
流程圖如下：
注意如果對象的類本事如果重寫了forwardInvocation方法的話，就不應該對forwardingTargetForSelector進行重寫了，否則會影響到該類型的對象原本的消息轉發流程。
通過重寫NSObject的forwardingTargetForSelector方法，我們就可以將無法識別的方法進行攔截并且將消息轉發到安全的 樁類對象中，從而可以使app繼續正常運行。
KVO,即：Key-Value Observing，它提供一種機制，當指定的對象的屬性被修改后，則對象就會接受收到通知。簡單的說就是每次指定的被觀察的對象的屬性被修改后，KVO就會自動通知相應的觀察者了。
KVO機制在iOS的很多開發場景中都會被使用到。不過如果一不小心使用不當的話，會導致大量的crash問題。所以如果能找到一種方法能夠自動抓取這些由于開發者粗心所導致的KVO Crash問題的話，是有一定的價值的。
首先我們來看看通過會導致KVO Crash的兩種情形：
通常一個對象的KVO關系圖如下：
一個被觀察的對象(Observed Object)上有若干個觀察者(Observer),每個觀察者又觀察若干條KeyPath。
如果觀察者和keypath的數量一多，很容易理不清楚被觀察對象整個KVO關系，導致被觀察者在dealloc的時候，還殘存著一些關系沒有被注銷。 同時還會導致KVO注冊觀察者與移除觀察者不匹配的情況發生。
筆者曾經還遇到過在多線程的情況下，導致KVO重復添加觀察者或移除觀察者的情況。這類問題通常多數發生的比較隱蔽，不容易從代碼的層面去排查。
由上可見多數由于KVO而導致的crash原因是由于被觀察對象的KVO關系圖混亂導致。那么如何來管理混亂的KVO關系呢。可以讓被觀察對象持有一個KVO的delegate，所有和KVO相關的操作均通過delegate來進行管理，delegate通過建立一張map來維護KVO整個關系。如下圖：
這樣做的好處有兩個：
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
方法改造流程如下圖：
通過上面的流程，將observerd對象的所有kvo相關的observer信息全部轉移到KVOdelegate上，并且避免了相同kvoinfo被重復添加多次的可能性。
關于
- (void)removeObserver:(NSObject *)observer
forKeyPath:(NSString *)keyPath
context:(void *)context
方法改造流程如下圖：
移除一個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 *,id> *)change
context:(void *)context
方法改造流程如下圖：
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
當一個對象添加了notification之后，如果dealloc的時候，仍然持有notification，就會出現NSNotification類型的crash。
NSNotification類型的crash多產生于程序員寫代碼時候犯疏忽，在NSNotificationCenter添加一個對象為observer之后，忘記了在對象dealloc的時候移除它。
所幸的是，蘋果在iOS9之后專門針對于這種情況做了處理，所以在iOS9之后，即使開發者沒有移除observer，Notification crash也不會再產生了。
不過針對于iOS9之前的用戶，我們還是有必要做一下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函數了。
在程序開發過程中，大家會經常使用定時任務，但使用NSTimer的 scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: 接口做重復性的定時任務時存在一個問題：NSTimer會 強引用 target實例，所以需要在合適的時機invalidate 定時器，否則就會由于定時器timer強引用target的關系導致 target不能被釋放，造成內存泄露，甚至在定時任務觸發時導致crash。 crash的展現形式和具體的target執行的selector有關。
與此同時，如果NSTimer是無限重復的執行一個任務的話，也有可能導致target的selector一直被重復調用且處于無效狀態，對app的CPU，內存等性能方面均是沒有必要的浪費。
所以，很有必要設計出一種方案，可以有效的防護NSTimer的濫用問題。
上面的分析可見，NSTimer所產生的問題的主要原因是因為其沒有再一個合適的時機invalidate，同時還有NSTimer對target的強引用導致的內存泄漏問題。
那么解決NSTimer的問題的關鍵點在于以下兩點：
NSTimer對其target是否可以不強引用
是否找到一個合適的時機，在確定NSTimer已經失效的情況下，讓NSTimer自動invalidate
關于第一個問題，target的強引用問題。 可以用如下圖的方案來解決：
在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：，流程如下圖：
step 2. 通過stubTarget的fireProxyTimer：來具體處理回調函數selector的處理和分發，流程如下圖：
因為stubTarget的介入，原有的target已經可以不受NSTimer強引用的牽制，而自由的釋放。
由上圖流程可知，當NSTimer的回調函數fireProxyTimer：被執行的時候，會自動判斷原target是否已經被釋放，如果釋放了，意味著NSTimer已經無效，此時如果還繼續調用原有target的selector很有可能會導致crash，而且是沒有必要的。所以此時需要將NSTimer invalidate，然后統計上報錯誤數據。如此一來就做到了NSTimer在合適的時機自動invalidate。
Container 類型的crash 指的是容器類的crash，常見的有NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的crash。 一些常見的越界，插入nil，等錯誤操作均會導致此類crash發生。 由于產生的原因比較簡單，就不展開來描述了。
該類crash雖然比較容易排查，但是其在app crash概率總比還是挺高，所以有必要對其進行防護。
Container crash 類型的防護方案也比較簡單，針對于NSArray／NSMutableArray／NSDictionary／NSMutableDictionary／NSCache的一些常用的會導致崩潰的API進行method swizzling，然后在swizzle的新方法中加入一些條件限制和判斷，從而讓這些API變的安全，這里就不展開來具體描述了。
NSString／NSMutableString 類型的crash的產生原因和防護方案與Container crash很相像，這里也不展開來描述了。
在App的所有Crash中，訪問野指針導致的Crash占了很大一部分，野指針類型crash的表現為：Exception Type:SIGSEGV，Exception Codes: SEGV_ACCERR 或者 如下圖：
解決野指針導致的crash往往是一件棘手的事情，一來產生crash 的場景不好復現，二來crash之后console的信息提供的幫助有限。 XCode本身為了便于開放調試時發現野指針問題，提供了Zombie機制，能夠在發生野指針時提示出現野指針的類，從而解決了開發階段出現野指針的問題。然而針對于線上產生的野指針問題，依舊沒有一個比較好的辦法來定位問題。
所以，因為野指針出現概率高而且難定位問題，非常有必要針對于野指針專門做一層防護措施。
野指針問題的解決思路方向其實很容易確定，XCode提供了Zombie的機制來排查野指針的問題，那么我們這邊可以實現一個類似于Zombie的機制，加上對zombie實例的全部方法攔截機制 和 消息轉發機制，那么就可以做到在野指針訪問時不Crash而只是crash時相關的信息。
同時還需要注意一點：因為zombie的機制需要在對象釋放時保留其指針和相關內存占用，隨著app的進行，越來越多的對象被創建和釋放，這會導致內存占用越來越大，這樣顯然對于一個正常運行的app的性能有影響。所以需要一個合適的zombie對象釋放機制，確定zombie機制對內存的影響是有限度的。
improve版的zombie機制的實現主要分為以下四個環節：
step 1. method swizzling替換NSObject的allocWithZone方法，在新的方法中判斷該類型對象是否需要加入野指針防護，如果需要，則通過objc_setAssociatedObject為該對象設置flag標記，被標記的對象后續會進入zombie流程
流程圖如下：
做flag標記是因為很多系統類，比如NSString，UIView等創建，釋放非常頻繁，而這些實例發生野指針概率非常低。基本都是我們自己寫的類才會有野指針的相關問題，所以通過在創建時 設置一個標記用來過濾不必要做野指針防護的實例，提高方案的效率。
同時做判斷是否要加入標記的條件里面，我們加入了黑名單機制，是因為一些特定的類是不適用于添加到zombie機制的，會發生崩潰（例如：NSBundle），而且所以和zombie機制相關的類也不能加入標記，否則會在釋放過程中循環引用和調用，導致內存泄漏甚至棧溢出。
step 2. method swizzling替換NSObject的dealloc方法，對flag標記的對象實例調用objc_destructInstance，釋放該實例引用的相關屬性，然后將實例的isa修改為HTZombieObject。通過objc_setAssociatedObject 保存將原始類名保存在該實例中。
流程圖如下：
調用objc_destructInstance的原因：
這里參考了系統在Object-C Runtime 中NSZombies實現，dealloc最后會調到 objectdispose函數，在這個函數里面 其實也做了三件事情，
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 獲取之前保存該實例對應的原始類名，統計錯誤數據。
流程圖如下：
HTZombieObject的處理和unrecognized selector crash的處理是一樣，主要的目的就是攔截所有傳給HTZombieObject的函數，用一個返回為空的函數來替換，從而達到程序不崩潰的目的。
step 4. 當退到后臺或者達到未釋放實例的上限時，則在ht_freeSomeMemory方法中調用原有dealloc方法釋放所有被zombie化的實例
綜上所述，可以用下圖總結一下bad access類型crash的防護流程：
1.做了野指針防護，通過動態插入一個空實現的方法來防止出現Crash，但是業務層面的表現難以確定，可能會進入業務異常的狀態。需要擬定一下如何展現該問題給用戶的方案
2.由于做了延時釋放若干實例，對系統總內存會產生一定影響，目前將內存的緩沖區開到2M左右，所以應該沒有很大的影響，但還是可能潛在一些風險。
3.延時釋放實例是根據相關功能代碼會聚焦在某一個時間段調用的假設前提下，所以野指針的zombie保護機制只能在其實例對象仍然緩存在zombie的緩存機制時才有效，若在實例真正釋放之后，再調用野指針還是會出現Crash。
在非主線程刷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，感覺略笨拙而且不高效。
所以作者依舊在尋找，看是否有更好的方案來解決該問題。
目前sdk實現了以下的功能和配置：
可以根據自身需要，選擇一定的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
可以根據自己項目的需求自行選擇需要防護的類型。
配置完畢之后，需要調用- (void)start;來開啟防護，防護的開關是實時的（無需重啟app），可以在任意的時刻選擇 開啟／關閉 防護功能。
通過 - (BOOL)isWorking 接口可以獲取當前防護功能的狀態。
通過 - (void)start 接口實時開啟防護功能
通過 - (void)stop 接口實時關閉防護功能
由于不同類實現的特殊性，考慮到可能某些類并不需要開啟防護功能。 所以提供了黑名單的功能。 在黑名單里面的類本身以及其子類，都不會進入防護的范圍。
白名單的出現是因為作者在開發的時候發現一些系統自帶的類是沒有必要進入防護范圍的，所以將整體防護的范圍調整到所有用戶自定義的類里面。 但是之后又發現絕大多數的crash和一些常用的系統的類（例如NSString，NSDictionary，UIView等等）有很強的聯系，針對于這些常用的系統類還是很有必要開啟防護的。所以針對這些需要防護的系統類，專門提供了白名單的功能。
注意：野指針類型的防護，由于其特殊性，不適用于這套白名單和黑名單。 其自身會維護一套新的黑白名單，詳見： 3.7 野指針類型Crash防護
出現了crash，并且被我們的系統捕捉到加以處理之后，用戶可能還需要進一步的處理，例如上傳埋點等。這時可以通過設置一個handler來實現， HTExceptionHandler會將crash的信息通過HTCrashInfo的形式來返回。
HTCrashInfo內包含了:
導致crash的類型：crashType
crash線程的調用棧：callStackSymbols
crash的具體描述信息：crashDescription
擴展信息：userinfo
以上接口具體詳細的信息均可以在（HTSafetyGuardService.h）中找到。(注意HTSafetyGuardService是單例)
面試題持續整理更新中，如果你想一起進階，不妨添加一下交流群 1012951431
面試題資料或者相關學習資料都在群文件中 進群即可下載！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
