iOS 源码分析(三):MLeaksFinder

简介: iOS 源码分析(三):MLeaksFinder

主要分析MLeaksFinder的原理和具体实现


Leaks


从苹果官方文档可知,一个app的内存主要分3类


  • Leaked memory: Memory unreferenced by your application that cannot be used again or freed (also detectable by using the Leaks instrument).
  • Abandoned memory: Memory still referenced by your application that has no useful purpose.
  • Cached memory: Memory still referenced by your application that might be used again for better performance.
    其中 Leaked memory 和 Abandoned memory 都属于应该释放而没释放的内存,都是内存泄露,而 Leaks 工具只负责检测 Leaked memory,而不管 Abandoned memory。在 MRC 时代 Leaked memory 很常见,因为很容易忘了调用 release,但在 ARC 时代更常见的内存泄露是循环引用导致的 Abandoned memory,Leaks 工具查不出这类内存泄露,应用有限。
  • 对于 Abandoned memory,可以用 Instrument 的 Allocations 检测出来。检测方法是用 Mark Generation 的方式,当你每次点击 Mark Generation 时,Allocations 会生成当前 App 的内存快照,而且 Allocations 会记录从上回内存快照到这次内存快照这个时间段内,新分配的内存信息。缺点是需要重复操作,其无法及时得知泄漏
  • 对于 Leaked memory,可以使用Leaks 工具检测,适用于运行时的检测


介绍


MLeaksFinder 提供了内存泄露检测更好的解决方案。只需要引入 MLeaksFinder,就可以自动在 App 运行过程检测到内存泄露的对象并立即提醒,无需打开额外的工具,也无需为了检测内存泄露而一个个场景去重复地操作。MLeaksFinder 目前能自动检测 UIViewController 和 UIView 对象的内存泄露,而且也可以扩展以检测其它类型的对象。


当发生内存泄露时,MLeaksFinder 会中断言,并准确的告诉你哪个对象泄露了。这里设计为中断言而不是打日志让程序继续跑,是因为很多人不会去看日志,断言则能强制开发者注意到并去修改,而不是犯拖延症。


优势


从 MLeaksFinder 的使用方法可以看出,MLeaksFinder 具备以下优点:

  • 使用简单,不侵入业务逻辑代码,不用打开 Instrument
  • 不需要额外的操作,你只需开发你的业务逻辑,在你运行调试时就能帮你检测
  • 内存泄露发现及时,更改完代码后一运行即能发现(这点很重要,你马上就能意识到哪里写错了)
  • 精准,能准确地告诉你哪个对象没被释放


原理


  • 其本质也是采用 category + runtime 实现,主要是通过AOP切面编程思想来添加额外的功能,实现代码无侵入的内存泄漏检测
  • 其类的结构图示如下所示

image.png

类的结构图示.jpg


具体实现


  • 1、寻找释放点


这里主要是通过AOP思想,通过method swizzling替换了几个释放方法

image.png

2、追踪泄漏

从上面Hook的方法的具体实现,我们发现一个共通点,最后都会调用 willDealloc 方法,说明当追踪到页面需要释放时,会调用此方法,以 UIViewController+MemoryLeak 分类中的 dismissViewControllerAnimated:completion: 方法为例,查看其具体实现

//load方法中hook dissmiss方法
[self swizzleSEL:@selector(dismissViewControllerAnimated:completion:) withSEL:@selector(swizzled_dismissViewControllerAnimated:completion:)];
//swizzled_dismissViewControllerAnimated:completion:的具体实现
- (void)swizzled_dismissViewControllerAnimated:(BOOL)flag completion:(void (^)(void))completion {
  [self swizzled_dismissViewControllerAnimated:flag completion:completion];
  UIViewController *dismissedViewController = self.presentedViewController;
  if (!dismissedViewController && self.presentingViewController) {
    dismissedViewController = self;
  }
  if (!dismissedViewController) return;
   //视图控制器即将被释放时调用 willDealloc 方法
  [dismissedViewController willDealloc];
}

查看 willDealloc 的具体实现

- (BOOL)willDealloc {
  //调用父类的 willDealloc 方法
  if (![super willDealloc]) {
    return NO;
  }
  //构建堆栈信息
  [self willReleaseChildren:self.childViewControllers];
  [self willReleaseChild:self.presentedViewController];
  if (self.isViewLoaded) {
    [self willReleaseChild:self.view];
  }
  return YES;
}

3、报告泄漏


上述调用父类的 willDealloc,其实就是调用 NSObject分类中的 willDealloc 方法,其中主要做了以下几件事


  • 首先判断这个class是否在白名单中,如果在则忽略 ==> 白名单机制
  • 如果当前对象在发送action则忽略它(因为 willDealloc)总会先于他们调用)
  • 设置一个weak指针,在调用 dispatch_after 在2秒后调用 assertNotDealloc 方法,如果还没释放,那么会进入这个方法,如果已经释放了,那么这个方法是进不去的。
- (BOOL)willDealloc {
  //获取类名
  NSString *className = NSStringFromClass([self class]);
  //判断这个class是否在白名单中,如果是,则忽略 -- 白名单机制
  if ([[NSObject classNamesWhitelist] containsObject:className])
    return NO;
  //UIControl的target-action机制,如果当前对象在发送action,则忽略(因为willDealloc会先于action调用)
  NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
  if ([senderPtr isEqualToNumber:@((uintptr_t)self)])
    return NO;
  //设置一个weak指针,指向self
  __weak id weakSelf = self;
  //在2s后,如果当前对象还没有释放,则会执行到assertNotDealloc方法。如果已经释放,那么weakSelf则会是nil,不会走到assertNotDealloc方法
  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;
}

4、构建堆栈信息

调用了父类方法的实现后,在显示堆栈信息之前,还需要进行堆栈信息的构造,主要是通过willReleaseChild、willReleaseChildren两个方法,其作用是向这个对象之中的子对象调用willDealloc 释放的方法,如 view 的 subviews, UINavigationController 的 viewcontrollers 等等的子对象。

//向这个对象中的子对象调用释放的方法
- (void)willReleaseChild:(id)child {
  if (!child) {
    return;
  }
  [self willReleaseChildren:@[ child ]];
}
//遍历子对象,然后将父对象的class name加上子对象的class name,一步步构造出一个 视图堆栈,如果出现内存泄漏,直接打印此对象的 视图堆栈即可
- (void)willReleaseChildren:(NSArray *)children {
  NSArray *viewStack = [self viewStack]; //通过关联对象获取值 子视图的 class name
  NSSet *parentPtrs = [self parentPtrs]; //通过关联对象获取 父对象的 class name
  for (id child in children) {
    NSString *className = NSStringFromClass([child class]);
    [child setViewStack:[viewStack arrayByAddingObject:className]];
    [child setParentPtrs:[parentPtrs setByAddingObject:@((uintptr_t)child)]];
    [child willDealloc];
  }
}

其整体的流程图示如下

image.png

相关文章
|
JSON 数据格式 iOS开发
iOS 源码分析(二):YYModel
iOS 源码分析(二):YYModel
546 0
iOS 源码分析(二):YYModel
|
iOS开发
iOS 源码分析(一):CTMediator
iOS 源码分析(一):CTMediator
1202 0
iOS 源码分析(一):CTMediator
|
缓存 算法 安全
iOS-底层原理 06:malloc 源码分析 思路
iOS-底层原理 06:malloc 源码分析 思路
361 0
iOS-底层原理 06:malloc 源码分析 思路
|
iOS开发
iOS-底层原理 04:NSObject的alloc 源码分析
iOS-底层原理 04:NSObject的alloc 源码分析
110 0
iOS-底层原理 04:NSObject的alloc 源码分析
|
存储 算法 安全
iOS-底层原理 02:alloc & init & new 源码分析
iOS-底层原理 02:alloc & init & new 源码分析
116 0
iOS-底层原理 02:alloc & init & new 源码分析
|
2月前
|
API 数据安全/隐私保护 iOS开发
利用uni-app 开发的iOS app 发布到App Store全流程
利用uni-app 开发的iOS app 发布到App Store全流程
106 3
|
4月前
|
存储 iOS开发
iOS 开发,如何进行应用的本地化(Localization)?
iOS 开发,如何进行应用的本地化(Localization)?
123 2
|
2月前
|
API 开发工具 Android开发
iOS 和 Android 平台的开发有哪些主要区别?
iOS与Android开发区别:iOS用Objective-C/Swift,App Store唯一下载渠道;Android用Java/Kotlin,多商店发布(如Google Play、华为市场)。设计上,iOS简洁一致,Android灵活可定制。开发工具,iOS用Xcode,Android用Android Studio。硬件和系统多样性,iOS统一,Android复杂。权限管理、审核流程及API各有特点,开发者需依据目标平台特性进行选择。
38 3
|
12天前
|
前端开发 Android开发 iOS开发
【Flutter前端技术开发专栏】Flutter在Android与iOS上的性能对比
【4月更文挑战第30天】Flutter 框架实现跨平台移动应用,通过一致的 UI 渲染(Skia 引擎)、热重载功能和响应式框架提高开发效率和用户体验。然而,Android 和 iOS 的系统差异、渲染机制及编译过程影响性能。性能对比显示,iOS 可能因硬件优化提供更流畅体验,而 Android 更具灵活性和广泛硬件支持。开发者可采用代码、资源优化和特定平台优化策略,利用性能分析工具提升应用性能。
【Flutter前端技术开发专栏】Flutter在Android与iOS上的性能对比