iOS监控笔记之启动crash_IOS

前言

相较于正常的崩溃问题，启动crash造成的损失要远远大得多。正常来说，如果有足够强健的构建发布系统，大多数时候能在版本上线之前及时发现问题并且修复，但是仍然存在小概率的线上意外。启动crash一般同时具备损害严重以及难以捕获两大特点

启动过程

从应用图标被用户点击开始，直到应用可以开始响应发生了很多事情。正常来说，尽管我们希望crash监控工具启动的尽可能早，但接入方往往总是等到launch事件之后才能启动工具，而在这个时间之前发生的崩溃就是启动crash，下面列出了在应用直到launch时，存在的可能发生启动crash的阶段：

iOS监控笔记之启动crash

其中initialize的顺序可能在更早，但总是会在load和launch之间。从图中来说，如果我们想要监控启动crash，那么开始监控的时间点必须要放到load阶段，才能保证最好的监控效果

如何监控

最简单的方式是不管接入方愿不愿意启动crash监控，我们在load方法中直接启动监控功能。但是这样的做法会让应用面临四个风险点：

类似a/b的线上开关方案失去了对监控工具的控制能力
crash监控启动存在崩溃问题，这将导致应用完全瘫痪
load阶段类未加载完毕，启动工具过程的递归加载引发的崩溃无法监控

综合这些风险点，启动crash监控的方案应该满足这些条件：

启动过程不依赖类，避免递归加载造成的crash
一旦过程发生crash，能够保证日志记录的安全性

最终得出监控的流程图：

iOS监控笔记之启动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];

									}