原文:橘子不酸丶
轉(zhuǎn)載:https://juejin.im/post/5e154ad35188253aad5c7c37
前言
iOS開發(fā)中 隨著應(yīng)用在版本迭代過程中,APP大小逐漸增大烤送,APP占用內(nèi)存也隨著功能的增加而越來越多,因此APP在線上發(fā)生FOOM(Foreground Out Of Memory)的頻率也會(huì)越來越高谨履。
一般對(duì)于用戶而言俱箱,發(fā)生FOOM時(shí)和crash表現(xiàn)一樣陡厘,然而在通常在線上crash收集過程中FOOM卻并不能被收集到,所以如何收集應(yīng)用在線上FOOM發(fā)生的頻率扶歪,以及FOOM發(fā)生時(shí)內(nèi)存占用情況也是我們的一個(gè)重要的監(jiān)控指標(biāo)理肺。
原理
Facebook早在2015年8月提出FOOM檢測(cè)辦法,大致原理是排除各種情況后善镰,剩余的情況是FOOM妹萨,Reducing FOOMs in the Facebook iOS app。
本文則基于這種檢測(cè)辦法來具體分析和實(shí)現(xiàn)一次OOM發(fā)生后的區(qū)分以及上報(bào)炫欺。
怎么判斷一次OOM
- APP版本升級(jí)
- 調(diào)用Exit()或者Abort()退出應(yīng)用
- APP發(fā)生Crash
- 用戶通過Home鍵強(qiáng)制退出APP
- 手機(jī)系統(tǒng)升級(jí)引起的重啟
- APP在后臺(tái)BOOM!
- APP在前臺(tái)FOOM!
實(shí)現(xiàn)
1.啟動(dòng)檢測(cè)
當(dāng)APP啟動(dòng)時(shí)乎完,我們需要盡可能早的在application:didFinishLaunchingWithOptions:之后開啟我們的OOM檢測(cè)。
typedef void (^MJYPOutOfMemoryEventHandler)(BOOL wasInForeground);
- (void)beginMonitoringMemoryEventsWithHandler:(nonnull MJYPOutOfMemoryEventHandler)handler;
2.APPVersion以及OSVersion記錄
獲取當(dāng)前APP版本號(hào)并取出上次存儲(chǔ)的APP版本號(hào)進(jìn)行對(duì)比
NSDictionary *infoDictionary = [[NSBundle mainBundle] infoDictionary];
NSString *majorVersion = infoDictionary[@"CFBundleShortVersionString"];
NSString *minorVersion = infoDictionary[@"CFBundleVersion"];
return [NSString stringWithFormat:@"%@.%@", majorVersion, minorVersion];
獲取當(dāng)前OSVersion并取出上次存儲(chǔ)的OSVersion進(jìn)行對(duì)比
[NSString stringWithFormat:@"%@.%@.%@", @(version.majorVersion), @(version.minorVersion), @(version.patchVersion)]
3.Terminate以及前后臺(tái)切換監(jiān)聽
監(jiān)聽terminate和前后臺(tái)切換之后品洛,我們需要處理用戶強(qiáng)制退出程序也就是terminate的情況树姨,以及還需要來記錄和區(qū)分前后臺(tái)的狀態(tài)摩桶,當(dāng)發(fā)生OOM時(shí)我們則可以通過此狀態(tài)來區(qū)分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()方法監(jiān)聽程序退出
abort() : 立即結(jié)束帽揪,不做任何操作屡江。
exit() : 釋放所有靜態(tài)全局的對(duì)象筑煮、緩存褐隆,關(guān)掉所有的I/O通道肥败,然后終止程序拘领。如果有函數(shù)通過atexit來注冊(cè)掀潮,還會(huì)調(diào)用注冊(cè)的函數(shù)移盆,如果atexit函數(shù)拋出異常就會(huì)直接調(diào)用terminate所意。
atexit() : 注冊(cè)程序正常終止時(shí)要被調(diào)用的函數(shù)变汪,一個(gè)進(jìn)程可以登記多達(dá)32個(gè)函數(shù)侠坎,這些函數(shù)將由exit自動(dòng)調(diào)用,通常這32個(gè)函數(shù)被稱為終止處理程序裙盾,并調(diào)用atexit函數(shù)來登記這些函數(shù)实胸。
我們可以通過fishhook來hook C中的這兩個(gè)退出程序的函數(shù)。
fishhook是Facebook提供的一個(gè)動(dòng)態(tài)修改鏈接mach-O文件的工具番官。利用MachO文件加載原理庐完,通過修改懶加載表(Lazy Symbol Pointers)和非懶加載表(Non-Lazy Symbol Pointers)這兩個(gè)表的指針達(dá)到C函數(shù)HOOK的目的。fishhook的具體原理可以參考Github源碼以及簡(jiǎn)介徘熔。
具體做法如下:
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發(fā)生時(shí),來處理過濾Crash的情景酷师。
比如說我們使用Tencent的Bugly庫(kù)時(shí)讶凉,我們可以在Bugly回調(diào)attachmentForException:時(shí)進(jìn)行調(diào)用過濾。
[[MJYPOutOfMemoryMonitor sharedInstance] appDidCrash];//OOM監(jiān)控調(diào)用
6.記錄OOM上報(bào)
當(dāng)APP啟動(dòng)時(shí)山孔,對(duì)上述情況進(jìn)行判斷懂讯,排除以上情況之后,我們則認(rèn)為APP在上一次運(yùn)行過程中發(fā)生了FOOM台颠。此時(shí)則上報(bào)上一次發(fā)生FOOM時(shí)的頁(yè)面信息場(chǎng)景以及內(nèi)存對(duì)象分配褐望。
其他誤判情況
前臺(tái)卡死引起系統(tǒng)watchdog強(qiáng)殺,通常原因是前臺(tái)線程過多或者發(fā)生死鎖串前,或CPU使用率持續(xù)過高等瘫里,這類強(qiáng)殺無法被App捕獲,需要結(jié)合卡頓監(jiān)控來加以區(qū)分荡碾。
后續(xù)
單獨(dú)的知道我們上一次APP運(yùn)行過程中發(fā)生FOOM后减宣,我們可以知道我們應(yīng)用的線上運(yùn)行內(nèi)存穩(wěn)定性,后續(xù)則需要完善在FOOM場(chǎng)景發(fā)生時(shí)的內(nèi)存堆棧數(shù)據(jù)和內(nèi)存對(duì)象分配玩荠,以及頁(yè)面信息記錄漆腌。附FOOM Report Demo
參考資料
OOMDetector組件 - 手Q團(tuán)隊(duì)