APP性能监控之FOOM检测实践

原文:橘子不酸丶
转载:https://juejin.im/post/5e154ad35188253aad5c7c37

前言

iOS开发中 随着应用在版本迭代过程中,APP大小逐渐增大,APP占用内存也随着功能的增加而越来越多,因此APP在线上发生FOOM(Foreground Out Of Memory)的频率也会越来越高。

一般对于用户而言,发生FOOM时和crash表现一样,然而在通常在线上crash收集过程中FOOM却并不能被收集到,所以如何收集应用在线上FOOM发生的频率,以及FOOM发生时内存占用情况也是我们的一个重要的监控指标。

原理

Facebook早在2015年8月提出FOOM检测办法,大致原理是排除各种情况后,剩余的情况是FOOM,Reducing FOOMs in the Facebook iOS app。
本文则基于这种检测办法来具体分析和实现一次OOM发生后的区分以及上报。

image

怎么判断一次OOM

  1. APP版本升级
  2. 调用Exit()或者Abort()退出应用
  3. APP发生Crash
  4. 用户通过Home键强制退出APP
  5. 手机系统升级引起的重启
  6. APP在后台BOOM!
  7. APP在前台FOOM!

实现

1.启动检测

当APP启动时,我们需要尽可能早的在application:didFinishLaunchingWithOptions:之后开启我们的OOM检测。

typedef void (^MJYPOutOfMemoryEventHandler)(BOOL wasInForeground);
- (void)beginMonitoringMemoryEventsWithHandler:(nonnull MJYPOutOfMemoryEventHandler)handler;

2.APPVersion以及OSVersion记录

获取当前APP版本号并取出上次存储的APP版本号进行对比

  NSDictionary *infoDictionary = [[NSBundle mainBundle] infoDictionary];
  NSString *majorVersion = infoDictionary[@"CFBundleShortVersionString"];
  NSString *minorVersion = infoDictionary[@"CFBundleVersion"];
  return [NSString stringWithFormat:@"%@.%@", majorVersion, minorVersion];

获取当前OSVersion并取出上次存储的OSVersion进行对比

  [NSString stringWithFormat:@"%@.%@.%@", @(version.majorVersion), @(version.minorVersion), @(version.patchVersion)]

3.Terminate以及前后台切换监听

监听terminate和前后台切换之后,我们需要处理用户强制退出程序也就是terminate的情况,以及还需要来记录和区分前后台的状态,当发生OOM时我们则可以通过此状态来区分FOOM。

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationWillTerminate:) name:UIApplicationWillTerminateNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationDidEnterBackground:) name:UIApplicationDidEnterBackgroundNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationWillEnterForeground:) name:UIApplicationWillEnterForegroundNotification object:nil];

4.Hook exit()以及abort()方法监听程序退出

abort() : 立即结束,不做任何操作。

exit() : 释放所有静态全局的对象、缓存,关掉所有的I/O通道,然后终止程序。如果有函数通过atexit来注册,还会调用注册的函数,如果atexit函数抛出异常就会直接调用terminate。

atexit() : 注册程序正常终止时要被调用的函数,一个进程可以登记多达32个函数,这些函数将由exit自动调用,通常这32个函数被称为终止处理程序,并调用atexit函数来登记这些函数。

我们可以通过fishhook来hook C中的这两个退出程序的函数。

fishhook是Facebook提供的一个动态修改链接mach-O文件的工具。利用MachO文件加载原理,通过修改懒加载表(Lazy Symbol Pointers)和非懒加载表(Non-Lazy Symbol Pointers)这两个表的指针达到C函数HOOK的目的。fishhook的具体原理可以参考Github源码以及简介。

具体做法如下:

static void (*orig_exit)(int);
static void (*_orig_exit)(int);
static void (*orig_abort)(void);
void my_exit(int value) {
    [[MJYPOutOfMemoryMonitor sharedInstance] appDidExit];
    orig_exit(value);
}
void _my_exit(int value) {
    [[MJYPOutOfMemoryMonitor sharedInstance] appDidExit];
    _orig_exit(value);
}
void my_abort(void) {
    [[MJYPOutOfMemoryMonitor sharedInstance] appDidExit];
    orig_abort();
}
+ (void)load {
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
      rebind_symbols((struct rebinding[1]){
          {"_exit", (void *)_my_exit, (void *)&_orig_exit}
      }, 1);
      rebind_symbols((struct rebinding[1]){
          {"exit", (void *)my_exit, (void **)&orig_exit}
      }, 1);
      rebind_symbols((struct rebinding[1]){
          {"abort", (void *)my_abort, (void **)&orig_abort}
      }, 1);
  });
}

5.用户Crash过滤

一般情况下,我们可以在收集到用户Crash发生时,来处理过滤Crash的情景。
比如说我们使用Tencent的Bugly库时,我们可以在Bugly回调attachmentForException:时进行调用过滤。
[[MJYPOutOfMemoryMonitor sharedInstance] appDidCrash];//OOM监控调用

6.记录OOM上报

当APP启动时,对上述情况进行判断,排除以上情况之后,我们则认为APP在上一次运行过程中发生了FOOM。此时则上报上一次发生FOOM时的页面信息场景以及内存对象分配。

其他误判情况

前台卡死引起系统watchdog强杀,通常原因是前台线程过多或者发生死锁,或CPU使用率持续过高等,这类强杀无法被App捕获,需要结合卡顿监控来加以区分。

后续

单独的知道我们上一次APP运行过程中发生FOOM后,我们可以知道我们应用的线上运行内存稳定性,后续则需要完善在FOOM场景发生时的内存堆栈数据和内存对象分配,以及页面信息记录。附FOOM Report Demo

参考资料

iOS微信内存监控 - 杨津

OOMDetector组件 - 手Q团队

FBRetainCycleDetector
FBMemoryProfiler
FBAllocationTracker

Reducing FOOMs in the Facebook iOS app

你可能感兴趣的:(APP性能监控之FOOM检测实践)