iOS监控笔记之启动crash

前言

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

启动过程

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

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

如何监控

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

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

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

  • 启动过程不依赖类,避免递归加载造成的crash
  • 一旦过程发生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,此时应该同步上传日志文件,快速反馈到业务方及时止损。首先止损手段都应该采用同步的方式,保证应用能够继续运行,根据情况不同,止损的回滚方式包括以下:

  1. 如果crash发生在并不干扰正常业务执行的功能组件中,可以通过A/B线上开关关闭对应的功能,前提是功能组件使用开关控制
  2. 崩溃处代码已经干扰正常业务执行,但是错误代码短,可以尝试通过服务器下发patch包动态修复错误代码,但是patch包要提防引入其他问题
  3. 在A/B Test和patch包都无法解决问题的情况下,假如项目采用了合理的组件化设计,通过路由转发来使用h5完成应用的正常运行
  4. 缺少动态修复的手段且crash不干扰正常业务执行,考虑停止一切插件、辅助组件运行
  5. 缺少动态修复的手段,包括1, 2, 3的方案。可考虑通过第三方越狱市场提供逆向包,提示用户下载安装
  6. 缺少动态修复的手段,包括1, 2, 3的方案。增发版本快速止损,使用Test Flight分批次快速让用户恢复使用

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • iOS Crash常规跟踪方法及Bugly集成运用详细介绍

    iOS Crash常规跟踪方法及Bugly集成运用 当app出现崩溃, 研发阶段一般可以通过以下方式来跟踪crash信息 #1.模拟器运行, 查看xcode错误日志 #2.真机调试, 查看xcode错误日志 #3.真机运行, 查看device系统日志 下面举例说明, 先写一段会Crash的代码crashdemo: - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view

  • iOS中程序异常Crash友好化处理详解

    前言 前两天接到个面试,面试官问到上线的app怎么避免闪退,首先想到的就是在编码的时候进行各种容错,但貌似并不是面试官想要的答案,所以表现的很糟糕.今天有时间就来整理一下,希望有所帮助. 实现效果如图: 效果实现: 用法: 1.将截图的中CatchedHelper文件夹拖到你的项目工程中. 2.在AppDelegate.m中找到以下方法并如下添加代码: - (BOOL)application:(UIApplication *)application didFinishLaunchingWithO

  • iOS开发之WKWebViewJavascriptBridge Xcode9中导致crash的解决

    前言 本文主要给大家介绍了关于iOS WKWebViewJavascriptBridge Xcode9中导致crash的相关解决办法,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. WKWebViewJavascriptBridge 这个第三方还是比较不错的,但是最近Xcode9上,却出现了crash:WKWebViewJavascriptBridge官方github看了大家也都有如此问题,最后终于解决了: 需要在WKWebViewJavascriptBridge类里,如下修改

  • iOS开发笔记之键盘、静态库、动画和Crash定位

    前言 本文主要分享了开发中遇到的问题,和相关的一些思考.分享出来给有需要的朋友们参考学习,下面话不多说了,来一起看看详细的介绍吧. iOS11键盘问题 功能背景: 弹出键盘时,如果有输入框的话,需要输入框的位置跟随键盘大小而变动. 问题描述: 当快速切换键盘之后,容易出现输入框的位置没有紧贴键盘,如下:(以简书键盘为例) 相关实现: 输入框监听系统的UIKeyboardWillShowNotification和UIKeyboardWillHideNotification事件,在回调的过程中用UI

  • 查看iOS Crash logs的方法

    当应用在设备中运行发生崩溃,iOS将记录这些错误日志并且创建了崩溃报告(Crash Report).崩溃报告中包含了iOS的版本.日期.异常类型.堆栈跟踪以及其他信息. ① 在Xcode中查看崩溃报告 当应用还在开发过程中发生了崩溃,则直接可以使用Xcode Organizer来查看崩溃报告.按如下操作: 1.打开Organizer: 2.选择"Devices"选项(界面的顶部): 3.选择左侧菜单栏中的device项: 4.选择"Devices"中的"D

  • 查看iOS已上架App的Crash信息定位、应对处理方式的实例

    完整的App都是经过很多轮测试才能正式上架的,但是没有任何一个开发人员可以保证一定会不出现任何问题.如果已上架App出现奔溃(Crash)情况,对于开发人员来说如何查看Crash信息定位及对应的处理方式尤为重要.以下就是查看Crash信息定位的步骤和处理方式. Crash的来源:分布情况(自发现或者用户发现) 1. 通过对应的苹果开发者账号进入iTunes connect,进入App分析,查看对应的App信息,如:App购买量,使用次数,展示次数等. 2. 进入后找到App奔溃的信息,在这里可以

  • iOS10适配之权限Crash问题的完美解决方案

    升级 iOS 10 之后目测坑还是挺多的,记录一下吧,看看到时候会不会成为一个系列. 直入正题吧 今天在写 Swift 3 相关的一个项目小小练下手,发现调用相机,崩了.试试看调用相册,又特么崩了.然后看到控制台输出了以下信息: This app has crashed because it attempted to access privacy-sensitive data without a usage description.  The app's Info.plist must cont

  • iOS App连续闪退时上报crash日志的方法详解

    前言 当一个iOS应用程序崩溃时,系统会创建一份crash日志保存在设备上.这份crash日志记录着应用程序崩溃时的信息,通常包含着每个执行线程的栈调用信息(低内存闪退日志例外),对于开发人员定位问题很有帮助. 为保障线上 App 的用户体验,我们一般都会对线上 App 的 crash 率做实时监控,一旦检测到 spike,可以即刻调查原因,但这一切的前提是 crash 日志能够准确上报. crash 日志上报有两个难点: crash handler 安装之前的代码要绝对稳定 如果日志采集器还没

  • iOS Crash文件分析方法汇总

    方法一 symbolicatecrash 1.查找symbolicatecrash 不同XCode版本symbolicatecrash的目录不一样 find /Applications/Xcode.app -name symbolicatecrash -type f 2.创建一个crash文件夹 mkdir crash 3.将crash文件.symbolicatecrash.dSYM拷贝到同一个目录下 4.导出DEVELOPER_DIR环境变量 export DEVELOPER_DIR="/Ap

  • iOS监控笔记之启动crash

    前言 相较于正常的崩溃问题,启动crash造成的损失要远远大得多.正常来说,如果有足够强健的构建发布系统,大多数时候能在版本上线之前及时发现问题并且修复,但是仍然存在小概率的线上意外.启动crash一般同时具备损害严重以及难以捕获两大特点 启动过程 从应用图标被用户点击开始,直到应用可以开始响应发生了很多事情.正常来说,尽管我们希望crash监控工具启动的尽可能早,但接入方往往总是等到launch事件之后才能启动工具,而在这个时间之前发生的崩溃就是启动crash,下面列出了在应用直到launch

  • IOS入门笔记之地理位置定位系统

    前言:关于地理位置及定位系统,在iOS开发中也比较常见,比如美团外面的餐饮店铺的搜索,它首先需要用户当前手机的位置,然后在这个位置附近搜索相关的餐饮店铺的位置,并提供相关的餐饮信息,再比如最常见的就是地图导航,地图导航更需要定位服务,然后根据用户的目的地选出一条路线.其实,作为手机用户这么长时间,或多或少会发现在有些app应用首次在你的手机安装成功后,首次启动可能就会提示"是否同意XXx(比如百度浏览器)获取当前位置"等这样一类的信息.可见地理位置及定位系统是企业app开发必不可少的技

  • IOS App图标和启动画面尺寸详细介绍

    iOS App图标和启动画面尺寸   注意:iOS所有图标的圆角效果由系统生成,给到的图标本身不能是圆角的. 1. 桌面图标 (app icon) for iPhone6 plus(@3x) : 180 x 180 for iPhone 6/5s/5/4s/4(@2x) : 120 x 120 2. 系统搜索框图标 (Spotlight search results icon)   for iPhone6 plus(@3x) : 120 x 120 for iPhone6/5s/5/4s/4(@

  • 详解iOS应用程序的启动过程

    关键步骤 一个程序从main函数开始启动. 复制代码 代码如下: int main(int argc, char * argv[]) {     @autoreleasepool {         return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));     } } 可以看到main函数会调用UIApplicationMain函数,它的四个参数的意思是: argc: 代表程序在进入m

  • iOS中的应用启动原理以及嵌套模型开发示例详解

    程序启动原理和UIApplication   一.UIApplication 1.简单介绍 (1)UIApplication对象是应用程序的象征,一个UIApplication对象就代表一个应用程序. (2)每一个应用都有自己的UIApplication对象,而且是单例的,如果试图在程序中新建一个UIApplication对象,那么将报错提示. (3)通过[UIApplicationsharedApplication]可以获得这个单例对象 (4) 一个iOS程序启动后创建的第一个对象就是UIAp

  • IOS代码笔记之网络嗅探功能

    本文实例为大家分享了IOS网络嗅探工具,供大家参考,具体内容如下 一.效果图    二.工程图   三.代码 AppDelegate.h #import <UIKit/UIKit.h> #import "Reachability.h" @interface AppDelegate : UIResponder <UIApplicationDelegate> { Reachability *reachability; BOOL WarningViaWWAN; } @

  • IOS代码笔记之下拉选项cell

    本文介绍了IOS下拉选项cell的使用方法,供大家参考,具体内容如下 一.效果图 二.工程图 三.代码 RootViewController.h #import <UIKit/UIKit.h> //加入头文件 #import "ComboBoxView.h" @interface RootViewController : UIViewController { ComboBoxView *_comboBox; } @end RootViewController.m #impo

  • IOS代码笔记之仿电子书书架效果

    本文实例为大家分享了IOS书架效果的具体实现代码,供大家参考,具体内容如下 一.效果图   二.工程图  三.代码 RootViewController.h #import <UIKit/UIKit.h> @interface RootViewController : UIViewController <UITableViewDataSource,UITableViewDelegate> { NSMutableArray * dataArray; UITableView * myT

随机推荐