前言
相較于正常的崩潰問題，啟動crash造成的損失要遠遠大得多。正常來說，如果有足夠強健的構建發布系統，大多數時候能在版本上線之前及時發現問題并且修復，但是仍然存在小概率的線上意外。啟動crash一般同時具備損害嚴重以及難以捕獲兩大特點
啟動過程
從應用圖標被用戶點擊開始，直到應用可以開始響應發生了很多事情。正常來說，盡管我們希望crash監控工具啟動的盡可能早，但接入方往往總是等到launch事件之后才能啟動工具，而在這個時間之前發生的崩潰就是啟動crash，下面列出了在應用直到launch時，存在的可能發生啟動crash的階段：
其中initialize的順序可能在更早，但總是會在load和launch之間。從圖中來說，如果我們想要監控啟動crash，那么開始監控的時間點必須要放到load階段，才能保證最好的監控效果
如何監控
最簡單的方式是不管接入方愿不愿意啟動crash監控，我們在load方法中直接啟動監控功能。但是這樣的做法會讓應用面臨四個風險點：
綜合這些風險點，啟動crash監控的方案應該滿足這些條件：
最終得出監控的流程圖：
不依賴類
不依賴類意味著監控工具需要使用C接口來實現功能，雖然比較麻煩，但由于runtime的機制決定了所有方法調用最終要以objc_msgSend函數作為入口，因此如果能夠hook掉這個函數并且實現一個調用棧結構，將所有調用入棧記錄，那么追蹤方法調用就不是難事。fishhook提供了hook掉函數的能力：
__unused static id (*orig_objc_msgSend)(id, SEL, ...);__attribute__((__naked__)) static void hook_Objc_msgSend() { /// save stack data /// push msgSend /// resume stack data /// call origin msgSend /// save stack data /// pop msgSend /// resume stack data}void observe_Objc_msgSend() { struct rebinding msgSend_rebinding = { "objc_msgSend", hook_Objc_msgSend, (void *)&orig_objc_msgSend }; rebind_symbols((struct rebinding[1]){msgSend_rebinding}, 1);}實現msgSend
__naked__修飾的函數告訴編譯器在函數調用的時候不使用棧保存參數信息，同時函數返回地址會被保存到LR寄存器上。由于msgSend本身就是用這個修飾符的，因此在記錄函數調用的出入棧操作中，必須保證能夠保存以及還原寄存器數據。msgSend利用x0 - x9的寄存器存儲參數信息，可以手動使用sp寄存器來存儲和還原這些參數信息：
/// 保存寄存器參數信息#define save() /__asm volatile ( / "stp x8, x9, [sp, #-16]!/n" / "stp x6, x7, [sp, #-16]!/n" / "stp x4, x5, [sp, #-16]!/n" / "stp x2, x3, [sp, #-16]!/n" / "stp x0, x1, [sp, #-16]!/n");/// 還原寄存器參數信息#define resume() /__asm volatile ( / "ldp x0, x1, [sp], #16/n" / "ldp x2, x3, [sp], #16/n" / "ldp x4, x5, [sp], #16/n" / "ldp x6, x7, [sp], #16/n" / "ldp x8, x9, [sp], #16/n" ); /// 函數調用，value傳入函數地址#define call(b, value) / __asm volatile ("stp x8, x9, [sp, #-16]!/n"); / __asm volatile ("mov x12, %0/n" :: "r"(value)); / __asm volatile ("ldp x8, x9, [sp], #16/n"); / __asm volatile (#b " x12/n");/// msgSend必須使用匯編實現__attribute__((__naked__)) static void hook_Objc_msgSend() { save() __asm volatile ("mov x2, lr/n"); __asm volatile ("mov x3, x4/n"); call(blr, &push_msgSend) resume() call(blr, orig_objc_msgSend) save() call(blr, &pop_msgSend) __asm volatile ("mov lr, x0/n"); resume() __asm volatile ("ret/n");}日志記錄
常規的I/O處理不能保證crash發生的數據安全，因此mmap是最適合用于此場景的方案。mmap能保證即便是應用發生了不可抗拒的崩潰時，也能完成將文件寫入IO的工作。另外我們只需記錄class和selector的調用棧信息，在不存在遞歸算法的情況下，只需要很小的內存使用就能記錄這些數據：
time_t ts = time(NULL);const char *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).lastObject stringByAppendingString: [NSString stringWithFormat: @"%d", ts]].UTF8String;unsigned char *buffer = NULL;int fileDescriptor = open(filePath, O_RDWR, 0);buffer = (unsigned char *)mmap(NULL, MB * 4, PROT_READ|PROT_WRITE, MAP_FILE|MAP_SHARED, fileDescriptor, 0);
buffer就是我們寫入數據的緩沖區，為了保證調用棧的信息準確，每次調用函數信息出入棧的時候，都需要更新緩沖區的數據。一個可行的方式是每個調用記錄添加一個@符號前綴，總是保存最后一個調用記錄的此符號下標，出棧時清除該下標之后的所有數據即可
static inline void push_msgSend(id _self, Class _cls, SEL _cmd, uintptr_t lr) { _lastIdx = _length; buffer[_lastIdx] = '@'; ......}static inline void pop_msgSend(id _self, SEL _cmd, uintptr_t lr) { ...... buffer[_lastIdx] = '/0'; _length = _lastIdx; size_t idx = _lastIdx - 1; while (idx >= 0) { if (buffer[idx] == '@') { _lastIdx = idx; break; } idx--; }}清空日志
由于msgSend的調用非常頻繁，這種監控方案并不適合長時間啟動，因此需要在某個時機關閉監控。由于正常的崩潰監控啟動時也可能會存在crash，監聽becomeActive通知來關閉功能是最合適的選擇，因為此時已經過了launch啟動崩潰監控工具的階段，可以保證該工具本身是正常使用的：
[[NSNotificationCenter defaultCenter] addObserver: self selector: @selector(closeMsgSendObserve) name: UIApplicationDidBecomeActiveNotification object: nil];- (void)closeMsgSendObserve { close(fileDescriptor); munmap(buffer, MB * 4); [[NSFileManager defaultManager] removeItemAtPath: _logPath error: nil];}回滾
當需要回滾時，說明已經發生了啟動crash，此時根據日志內容，也有不同的處理方式：
日志文件是空文件
這種情況是最危險的情況，如果日志文件為空，說明文件已經建立，但是還沒有產生任何方法調用。很有可能在fishhook的處理過程中存在crash，此時應該直接關閉監控方案，即便不是它的原因，并且快速增發版本
日志文件不為空
如果日志文件不為空，說明成功的監控到了crash，此時應該同步上傳日志文件，快速反饋到業務方及時止損。首先止損手段都應該采用同步的方式，保證應用能夠繼續運行，根據情況不同，止損的回滾方式包括以下：
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對武林網的支持。
新聞熱點
疑難解答
