內存泄漏的高效檢測方法 - MLeaksFinder
對於iOS開發者而言，內存泄漏是一個老生常談的問題，包括平常開發和麪試過程當中，都會涉及到這方面的知識。 固然Xcode提供了Instrument工具，咱們通常都會用Leaks / Allocations來排查內存泄漏，網上也有一些開源庫來進行內存泄漏的排查git
MLeaksFinder - 簡介
MLeaksFinder 是 WeRead 團隊開源的iOS內存泄漏檢測工具，wereadteam博客，GitHub。github
MLeaksFinder 提供了內存泄露檢測更好的解決方案。引進 MLeaksFinder 後，就能夠在平常的開發，調試業務邏輯的過程當中自動地發現並警告內存泄漏。開發者無需打開 Instrument 等工具，也無需爲了找內存泄漏而去跑額外的流程。而且，因爲開發者是在修改代碼以後一跑業務邏輯就能發現內存泄漏的，這使得開發者能很快地意識到是哪裏的代碼寫得問題。這種及時的內存泄漏的發如今很大的程度上下降了修復內存泄漏的成本。面試
當發生內存泄漏時，MLeaksFinder會用彈窗alert的形式告訴開發者內存泄漏的對象，開發者能夠把alert關掉，並繼續調試業務邏輯。數組
MLeaksFinder - 使用方式
把 MLeaksFinder 目錄下的文件添加到你的項目中，就能夠在運行時（debug 模式下）幫助你檢測項目裏的內存泄露了，無需修改任何業務邏輯代碼，並且只在 debug 下開啓，徹底不影響你的 release 包。bash
引入MLeaksFinder可選擇用CocoaPods安裝，安裝時注意有沒有warnings，特別是 OTHER_LDFLAGS 相關的 warnings。若是有 warnings，能夠在主工程的 Build Settings -> Other Linker Flags 加上 -ObjC。app
亦可手動引入，直接把 MLeaksFinder 的代碼放到項目裏即生效。若是把 MLeaksFinder 作爲子工程，須要在主工程的 Build Settings -> Other Linker Flags 加上 -ObjC。異步
引入後，先驗證引入是否成功，在UIViewController+MemoryLeak.m的+ (void)load方法中添加斷點，app啓用時進入該方法便引入成功。async
引進 MLeaksFinder 的代碼後便可檢測內存泄漏，但查找循環引用的功能還未生效。能夠再手動加入 FBRetainCycleDetector 代碼，而後把 MLeaksFinder.h 裏的 //#define MEMORY_LEAKS_FINDER_RETAIN_CYCLE_ENABLED 1 打開。ide
MLeaksFinder 默認只在 debug 下生效，固然也能夠經過 MLeaksFinder.h 裏的 //#define MEMORY_LEAKS_FINDER_ENABLED 0 來手動控制開關。函數
MLeaksFinder - 原理
從UIViewController入手，當一個UIViewController被pop或者dismiss後，該VC包括它的子View，或者子view的子view等等都會很快的被釋放（除非設計成單例，或者持有它的強引用，但通常不多這樣作）。因而，咱們只需在一個ViewController被pop或者dismiss一小段時間後，看看該VC，它的subViews等是否還存在。
經過UIViewController+MemoryLeak.h的load方法能夠看出，交換了viewDidDisappear:、viewWillAppear:、dismissViewControllerAnimated:completion:三個方法。
下面分析一下方法viewDidDisappear：
- (void)swizzled_viewDidDisappear:(BOOL)animated {
[self swizzled_viewDidDisappear:animated];
if ([objc_getAssociatedObject(self, kHasBeenPoppedKey) boolValue]) {
[self willDealloc];
}
}
複製代碼
調用了當前類的-willDealloc方法，
- (BOOL)willDealloc {
if (![super willDealloc]) {
return NO;
}
[self willReleaseChildren:self.childViewControllers];
[self willReleaseChild:self.presentedViewController];
if (self.isViewLoaded) {
[self willReleaseChild:self.view];
}
return YES;
}
複製代碼
經過super調用父類的-willDealloc，重點說明一下該方法
- (BOOL)willDealloc {
NSString *className = NSStringFromClass([self class]);
if ([[NSObject classNamesWhitelist] containsObject:className])
return NO;
NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
if ([senderPtr isEqualToNumber:@((uintptr_t)self)])
return NO;
__weak id weakSelf = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
__strong id strongSelf = weakSelf;
[strongSelf assertNotDealloc];
});
return YES;
}
複製代碼
- 第一步：首先經過
classNamesWhitelist檢測白名單，若是對象在白名單之中，便return NO，即不是內存泄漏。
構建基礎白名單時，使用了單例，確保只有一個，這個方法是私有的。
+ (NSMutableSet *)classNamesWhitelist {
static NSMutableSet *whitelist = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
whitelist = [NSMutableSet setWithObjects:
@"UIFieldEditor", // UIAlertControllerTextField
@"UINavigationBar",
@"_UIAlertControllerActionView",
@"_UIVisualEffectBackdropView",
nil];
// System's bug since iOS 10 and not fixed yet up to this ci. NSString *systemVersion = [UIDevice currentDevice].systemVersion; if ([systemVersion compare:@"10.0" options:NSNumericSearch] != NSOrderedAscending) { [whitelist addObject:@"UISwitch"]; } }); return whitelist; } 複製代碼
同時，在NSObject+MemoryLeak.h文件中提供了一個方法，使得咱們能夠自定義白名單
+ (void)addClassNamesToWhitelist:(NSArray *)classNames {
[[self classNamesWhitelist] addObjectsFromArray:classNames];
}
複製代碼
- 第二步：判斷該對象是不是上一次發送action的對象，是的話，不進行內存檢測
NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
if ([senderPtr isEqualToNumber:@((uintptr_t)self)])
return NO;
複製代碼
- 第三步：弱指針指向self，2s延遲，而後經過這個弱指針調用
-assertNotDealloc，若被釋放，給nil發消息直接返回，不觸發-assertNotDealloc方法，認爲已經釋放；若是它沒有被釋放（泄漏了），-assertNotDealloc就會被調用
__weak id weakSelf = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
__strong id strongSelf = weakSelf;
[strongSelf assertNotDealloc];
});
複製代碼
assertNotDealloc方法放在最後再談
接着會調用-willReleaseChildren、-willReleaseChild遍歷該對象的子對象，判斷是否釋放
- (void)willReleaseChild:(id)child {
if (!child) {
return;
}
[self willReleaseChildren:@[ child ]];
}
- (void)willReleaseChildren:(NSArray *)children {
NSArray *viewStack = [self viewStack];
NSSet *parentPtrs = [self parentPtrs];
for (id child in children) {
NSString *className = NSStringFromClass([child class]);
[child setViewStack:[viewStack arrayByAddingObject:className]];
[child setParentPtrs:[parentPtrs setByAddingObject:@((uintptr_t)child)]];
[child willDealloc];
}
}
複製代碼
經過代碼能夠看出，-willReleaseChildren拿到當前對象的viewStack和parentPtrs，而後遍歷children，爲每一個子對象設置viewStack和parentPtrs。 而後會執行[child willDealloc]，去檢測子類。
這裏結合源碼看下viewStack與parentPtrs的get和set實現方法
- (NSArray *)viewStack {
NSArray *viewStack = objc_getAssociatedObject(self, kViewStackKey);
if (viewStack) {
return viewStack;
}
NSString *className = NSStringFromClass([self class]);
return @[ className ];
}
- (void)setViewStack:(NSArray *)viewStack {
objc_setAssociatedObject(self, kViewStackKey, viewStack, OBJC_ASSOCIATION_RETAIN);
}
- (NSSet *)parentPtrs {
NSSet *parentPtrs = objc_getAssociatedObject(self, kParentPtrsKey);
if (!parentPtrs) {
parentPtrs = [[NSSet alloc] initWithObjects:@((uintptr_t)self), nil];
}
return parentPtrs;
}
- (void)setParentPtrs:(NSSet *)parentPtrs {
objc_setAssociatedObject(self, kParentPtrsKey, parentPtrs, OBJC_ASSOCIATION_RETAIN);
}
複製代碼
二者實現方法相似，經過運行時機制，即利用關聯對象給一個類添加屬性信息，只不過前者是一個數組，後者是一個集合。
關聯對象parentPtrs，會在-assertNotDealloc中，會判斷當前對象是否與父節點集合有交集。下面仔細看下-assertNotDealloc方法
- (void)assertNotDealloc {
if ([MLeakedObjectProxy isAnyObjectLeakedAtPtrs:[self parentPtrs]]) {
return;
}
[MLeakedObjectProxy addLeakedObject:self];
NSString *className = NSStringFromClass([self class]);
NSLog(@"Possibly Memory Leak.\nIn case that %@ should not be dealloced, override -willDealloc in %@ by returning NO.\nView-ViewController stack: %@", className, className, [self viewStack]);
}
複製代碼
這裏調用了MLeakedObjectProxy類中的+isAnyObjectLeakedAtPtrs
+ (BOOL)isAnyObjectLeakedAtPtrs:(NSSet *)ptrs {
NSAssert([NSThread isMainThread], @"Must be in main thread.");
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
leakedObjectPtrs = [[NSMutableSet alloc] init];
});
if (!ptrs.count) {
return NO;
}
if ([leakedObjectPtrs intersectsSet:ptrs]) {
return YES;
} else {
return NO;
}
}
複製代碼
該方法中初始化了一個單例對象leakedObjectPtrs，經過leakedObjectPtrs與傳入的參數[self parentPtrs]檢測他們的交集，傳入的 ptrs 中是不是泄露的對象。
若是上述方法返回的是NO，則繼續調用下面方法+addLeakedObject
+ (void)addLeakedObject:(id)object {
NSAssert([NSThread isMainThread], @"Must be in main thread.");
MLeakedObjectProxy *proxy = [[MLeakedObjectProxy alloc] init];
proxy.object = object;
proxy.objectPtr = @((uintptr_t)object);
proxy.viewStack = [object viewStack];
static const void *const kLeakedObjectProxyKey = &kLeakedObjectProxyKey;
objc_setAssociatedObject(object, kLeakedObjectProxyKey, proxy, OBJC_ASSOCIATION_RETAIN);
[leakedObjectPtrs addObject:proxy.objectPtr];
#if _INTERNAL_MLF_RC_ENABLED
[MLeaksMessenger alertWithTitle:@"Memory Leak"
message:[NSString stringWithFormat:@"%@", proxy.viewStack]
delegate:proxy
additionalButtonTitle:@"Retain Cycle"];
#else
[MLeaksMessenger alertWithTitle:@"Memory Leak"
message:[NSString stringWithFormat:@"%@", proxy.viewStack]];
#endif
}
複製代碼
第一步：構造MLeakedObjectProxy對象，給傳入的泄漏對象 object 關聯一個代理即 proxy
第二步：經過objc_setAssociatedObject(object, kLeakedObjectProxyKey, proxy, OBJC_ASSOCIATION_RETAIN)方法，object強持有proxy， proxy若持有object，若是object釋放，proxy也會釋放
第三步：存儲 proxy.objectPtr（實際是對象地址）到集合 leakedObjectPtrs 裏邊
第四步：彈框 AlertView若 _INTERNAL_MLF_RC_ENABLED == 1，則彈框會增長檢測循環引用的選項；若 _INTERNAL_MLF_RC_ENABLED == 0，則僅展現堆棧信息。
對於MLeakedObjectProxy類而言，是檢測到內存泄漏才產生的，做爲泄漏對象的屬性存在的，若是泄漏的對象被釋放，那麼MLeakedObjectProxy也會被釋放，則調用-dealloc函數
集合leakedObjectPtrs中移除該對象地址，同時再次彈窗，提示該對象已經釋放了
- (void)dealloc {
NSNumber *objectPtr = _objectPtr;
NSArray *viewStack = _viewStack;
dispatch_async(dispatch_get_main_queue(), ^{
[leakedObjectPtrs removeObject:objectPtr];
[MLeaksMessenger alertWithTitle:@"Object Deallocated"
message:[NSString stringWithFormat:@"%@", viewStack]];
});
}
複製代碼
當點擊彈框中的檢測循環引用按鈕時，相關的操做都在下面 AlertView 的代理方法裏邊，即異步地經過 FBRetainCycleDetector 檢測循環引用，而後回到主線程，利用彈框提示用戶檢測結果。
同時控制檯會有相關輸出
另外，針對一些特殊狀況：
- 有時候即便調了pop，dismiss，也不會被釋放，好比單例。若是某個特別的對象不會被釋放，開發者能夠重寫
willDealloc，return NO - 部分系統的view是不會被釋放的，須要創建白名單
MLeaksFinder支持手動擴展，經過MLCheck()宏來檢測其餘類型的對象的內存泄露，爲傳進來的對象創建View-ViewController stack信息- 結合
FBRetainCycleDetector一塊兒使用時：- 內存泄漏不必定是循環引用形成的
- 有的循環引用
FBRetainCycleDetector不必定能找出
參考資料：
- 1. MLeaksFinder檢查iOS APP內存泄漏
- 2. iOS檢測內存泄漏
- 3. iOS開發中內存泄漏檢測工具－－MLeaksFinder
- 4. iOS開發自動檢測內存泄漏神器MLeaksFinder
- 5. 內存泄漏檢測方法
- 6. C++ 內存泄漏檢測方法
- 7. valgrind 檢測內存泄漏
- 8. 內存泄漏檢測
- 9. C++檢測內存泄漏
- 10. C++內存泄漏檢測
- 更多相關文章...
- • Redis內存回收策略 - Redis教程
- • Hibernate的5種檢索方式 - Hibernate教程
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
- • 常用的分佈式事務解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Duang!超快Wi-Fi來襲
- 2. 機器學習-補充03 神經網絡之**函數(Activation Function)
- 3. git上開源maven項目部署 多module maven項目（多module maven+redis+tomcat+mysql）後臺部署流程學習記錄
- 4. ecliple-tomcat部署maven項目方式之一
- 5. eclipse新導入的項目經常可以看到「XX cannot be resolved to a type」的報錯信息
- 6. Spark RDD的依賴於DAG的工作原理
- 7. VMware安裝CentOS-8教程詳解
- 8. YDOOK：Java 項目 Spring 項目導入基本四大 jar 包 導入依賴，怎樣在 IDEA 的項目結構中導入 jar 包 導入依賴
- 9. 簡單方法使得putty（windows10上）可以免密登錄樹莓派
- 10. idea怎麼用本地maven
- 1. MLeaksFinder檢查iOS APP內存泄漏
- 2. iOS檢測內存泄漏
- 3. iOS開發中內存泄漏檢測工具－－MLeaksFinder
- 4. iOS開發自動檢測內存泄漏神器MLeaksFinder
- 5. 內存泄漏檢測方法
- 6. C++ 內存泄漏檢測方法
- 7. valgrind 檢測內存泄漏
- 8. 內存泄漏檢測
- 9. C++檢測內存泄漏
- 10. C++內存泄漏檢測