发表于 2019-04-28 · 更新于 2025-03-10

内存-③内存泄漏定位

未整合的文章：

# 目录 * [重要文章](#重要文章) * [一、Analyze—静态分析](#Analyze)

1、常见的三种泄露情形
(1)、创建了一个对象，但是并没有使用。Xcode提示信息：Value Stored to 'number' is never read。翻译一下：存储在'number'里的值从未被读取过。
(2)、创建了一个（指针可变的）对象，且初始化了，但是初始化的值一直没读取过。Xcode提示信息：Value Stored to 'str' during its initialization is never read
(3)、调用了让某个对象引用计数加1的函数，但没有调用相应让其引用计数减1的函数。Xcode提示信息：Potential leak of an object stored into 'subImageRef'。 翻译一下：subImageRef对象的内存单元有潜在的泄露风险。ARC中常见于CGxxxRef未release。

2、.....

二、Leaks—内存泄露
三、ARC下的dealloc

1、ARC下dealloc的使用
ARC下,系统可以帮我们释放该对象,及其包含的对象;但是却无法释放不属于该对象的一些东西,如:
(1)、通知的观察者,或KVO的观察者；
(2)、对象强委托/引用的解除；
(3)、做一些其他的注销之类的操作,如一个ViewController在销毁之前有可能需要和server打交道。

2、controller 不能释放，不走dealloc方法的几种可能

常见笔试/面试题
END

以下内容摘自：iOS性能优化之内存管理：Analyze、Leaks、Allocations的使用和案例代码

前言

内存空间的划分: 我们知道，一个进程占用的内存空间，包含5种不同的数据区：

（1）BSS段：通常是存放未初始化的全局变量；
（2）数据段：通常是存放已初始化的全局变量。
（3）代码段：通常是存放程序执行代码。
（4）堆：通常是用于存放进程运行中被动态分配的内存段，OC对象（所有继承自NSObject的对象）就存放在堆里。
（5）栈：由编译器自动分配释放，存放函数的参数值，局部变量等值。

栈内存是系统来管理的，因此我们常说的内存管理，指的是堆内存的管理，也就是所有OC对象的创建和销毁的管理。

伴随着iOS5的到来，苹果推出了ARC（自动引用计数）技术，此模式下编译器会自动在合适的地方插入retain、release、autorelease语句，也就是说编译器会自动生成内存管理的代码，解放了广大程序猿的双手，也基本上避免了内存泄露问题，但是呢…

内存泄露的定义是：用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束。（其实说白了就是该内存空间使用完毕之后未回收）。

在iOS应用中的内存泄露，原因一般有循环引用、错用Strong/copy等。

## 重要文章 * [iOS检测内存泄漏的方法](https://blog.csdn.net/clovejq/article/details/78689759) * [iOS 内存泄漏的查找](https://www.jianshu.com/p/b72d0a442342) * [iOS 内存泄漏监测自动化](https://www.jianshu.com/p/33bda0eed3aa?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation)

## 一、Analyze—静态分析 > [< 返回目录](#目录)

顾名思义，静态分析不需要运行程序，就能检查到存在内存泄露的地方。

使用方法：打开Xcode，command + shift + B；或者Xcode - Product - Analyze；

1、常见的三种泄露情形：

（1）创建了一个对象，但是并没有使用。Xcode提示信息：Value Stored to ‘number’ is never read。翻译一下：存储在’number’里的值从未被读取过。

（2）创建了一个（指针可变的）对象，且初始化了，但是初始化的值一直没读取过。Xcode提示信息：Value Stored to ‘str’ during its initialization is never read

（3）调用了让某个对象引用计数加1的函数，但没有调用相应让其引用计数减1的函数。Xcode提示信息：Potential leak of an object stored into ‘subImageRef’。翻译一下：subImageRef对象的内存单元有潜在的泄露风险。ARC中常见于CGxxxRef未release。

贴上三种常见情形的Demo代码，如下：

 /**
 * 情 形 一：创建了一个对象，但是并没有使用。
 * 提示信息：Value Stored to 'number' is never read
 * 翻译一下：存储在'number'里的值从未被读取过，
 */
- (void)leakOne {
    NSString *str1 = [NSString string];
    NSNumber *number;
    number = @(str1.length);
    /*
     说我们没有读取过它，那就读取一下，比如打开下面这句代码，对它发送class消息，就不再会有这个提示了。
     当然最好的方法还是将有关number的代码都删掉，因为，你只对number赋值，又不使用，那干嘛创建出来呢。
     这是一个比较常见和典型的错误，也很容易检查出来
     */
    // [number class];
}
 
/**
 * 情 形 二：创建了一个（指针可变的）对象，且初始化了，但是初始化的值一直没读取过。
 * 提示信息：Value Stored to 'str' during its initialization is never read
 */
- (void)leakTwo {
    NSString *str = [NSString string]; // 创建并初始化str，此时已经有一个内存单元保存str初始化的值
    // NSString *str; // 这样就内存不泄露，因为str是可变的，只需要先声明就行。
    // printf("str前 = %p\n",str);
    str = @"ceshi";             // str被改变了，指向了"ceshi"所在的地址，指针改变了，但之前保存初始化值的内存空间还未释放，保存str初始化值的内存单元泄露了。
    // printf("str后 = %p\n",str); // 指针改变了
    [str class];
     
    // 再举两个例子，同理
     
    NSArray *arr = [NSArray array];
    // printf("arr前 = %p\n",arr);
    // NSArray *arr;            // 这样就内存不泄露
    arr = @[@"1",@"2"];
    // printf("arr后 = %p\n",arr); // 指针改变了
    [arr class];
     
    CGRect rect = self.view.frame;
    // CGRect rect = CGRectZero; // 这样就内存不泄露
    rect = CGRectMake(0, 0, 0, 0);
    NSLog(@"rect = %@",NSStringFromCGRect(rect));
}
 
/**
 * 情 形 三：调用了让某个对象引用计数加1的函数，但没有调用相应让其引用计数减1的函数。
 * 提示信息：Potential leak of an object stored into 'subImageRef'
 * 翻译一下：subImageRef对象的内存单元有潜在的泄露风险
 */
- (void)leakThree {
    CGRect rect = CGRectMake(0, 0, 50, 50);
    UIImage *image;
    CGImageRef subImageRef = CGImageCreateWithImageInRect(image.CGImage, rect); // subImageRef 引用计数 + 1;
     
    UIImage* smallImage = [UIImage imageWithCGImage:subImageRef];
     
    // 应该调用对应的函数，让subImageRef的引用计数减1,就不会泄露了
    // CGImageRelease(subImageRef);
     
    [smallImage class];
    UIGraphicsEndImageContext();
}

自己遇到的实例:

情形2：静态检测内存泄露Analyze－－Value stored to ‘dataArr’ during its initialization is never read
即初始化的时候开辟了一块内存，却始终没用到，导致该块内存泄漏

NSMutableArray *tempMutArr = [NSMutableArray arrayWithCapacity:0];
   if ([self.clickedButtonTpye isEqualToString:KClickedButtonTypeLast]) {
       tempMutArr = self.lastDataSourceArr;
   }else{
       tempMutArr = self.hotDataSourceArr;
   }

二、Leaks—内存泄露

< 返回目录

MLeaksFinder：精准 iOS 内存泄露检测工具

项目 UIViewController+MemoryLeak.m NSObject+MemoryLeak.m

原理：MLeaksFinder 一开始从 UIViewController 入手。我们知道，当一个 UIViewController 被 pop 或 dismiss 后，该 UIViewController 包括它的 view，view 的 subviews 等等将很快被释放（除非你把它设计成单例，或者持有它的强引用，但一般很少这样做）。于是，我们只需在一个 ViewController 被 pop 或 dismiss 一小段时间后，看看该 UIViewController，它的 view，view 的 subviews 等等是否还存在。

即我们hook viewDidDisappear: 和 dismissViewControllerAnimated: completion: 都去执行NSObject的willDealloc方法。

在NSObject的willDealloc方法中，隔2秒后再去尝试调用另一个方法assertNotDealloc。如果UIViewController已经被成功释放，则肯定是 nil 执行 assertNotDealloc，即assertNotDealloc不会被执行，也就不会弹出内存泄露的弹窗。反之，若UIViewController没有释放，则会弹出内存泄露的弹窗。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// UIViewController+MemoryLeak.m
- (void)swizzled_viewDidDisappear:(BOOL)animated {
    [self swizzled_viewDidDisappear:animated];
    
    if ([objc_getAssociatedObject(self, kHasBeenPoppedKey) boolValue]) {
        [self willDealloc];
    }
}

- (void)swizzled_dismissViewControllerAnimated:(BOOL)flag completion:(void (^)(void))completion {
    [self swizzled_dismissViewControllerAnimated:flag completion:completion];
    ......
    
    [dismissedViewController willDealloc];
}

// NSObject+MemoryLeak.m
- (BOOL)willDealloc {
    ......
    
    __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;
}

- (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]);
}

自动化内存泄漏检测项目 https://github.com/liujiakuoyx/leak_detector/blob/main/lib/src/leak_navigator_observer.dart#L121

///Such as WebSocket is delay close connect.
const int _defaultCheckLeakDelay = 500;

typedef ShouldAddedRoute = bool Function(Route route);

///NavigatorObserver
class LeakNavigatorObserver extends NavigatorObserver {
  final ShouldAddedRoute? shouldCheck;
  final int checkLeakDelay;

  ///[callback] if 'null',the all route can added to LeakDetector.
  ///if not 'null', returns ‘true’, then this route will be added to the LeakDetector.
  LeakNavigatorObserver(
      {this.checkLeakDelay = _defaultCheckLeakDelay, this.shouldCheck});

  @override
  void didPop(Route route, Route? previousRoute) {
    _remove(route);
  }

  @override
  void didPush(Route route, Route? previousRoute) {
    _add(route);
  }

  @override
  void didRemove(Route route, Route? previousRoute) {
    _remove(route);
  }

  @override
  void didReplace({Route? newRoute, Route? oldRoute}) {
    if (newRoute != null) {
      _add(newRoute);
    }
    if (oldRoute != null) {
      _remove(oldRoute);
    }
  }
  ......
}

快手 Flutter 上的内存泄漏监控

Leaks是动态的内存泄露检查工具，需要一边运行程序，一边检测。

先不切换到Call Trees，先看看Statistics(统计数据)下的情况

Allocation中我们主要关注的是Persistent和Persistent Bytes，分别表示当前时间段，申请了但是还没释放的内存数量和大小。

切换到Call Trees后世这样的

项目中遇到过的内存泄漏

这里我们不是去查看Call Tree,而是查看Cycles & Roots。

点击标记4处为黑色，即代表该处会发生内存泄漏，双击进入代码，如图：

果然存在内存泄漏

自己遇到的其他例子：

开始不明白为什么这个变量会内存泄漏后面才能白，其实_priceDetailModel这个本身已经用OrderPriceDetailModel赋值过一次了，而这里你又赋值了一次，导致多了一个。代码情况如下两个图：

又在set方法中生成了一个地址

三、ARC下的dealloc

1、ARC下dealloc的使用

ARC下,系统可以帮我们释放该对象,及其包含的对象;但是却无法释放不属于该对象的一些东西,如:

1
2
3

(1)、通知的观察者,或KVO的观察者；
(2)、对象强委托/引用的解除；
(3)、做一些其他的注销之类的操作,如一个ViewController在销毁之前有可能需要和server打交道。

(1)、通知的观察者,或KVO的观察者；

由于通知中心是系统的一个单例,你在注册通知的观察者时,实际上是在通知中心注册的,

这时,即使ARC下系统帮我们释放了对象,但是在通知中心的观察还是没有移除,那么当有

该通知时,依然会尝试调用该对象的接受通知的方法,这可能会导致一些问题.

(2)、对象强委托/引用的解除；

对于其他的对象来把你当做委托 delegate时,并且是强引用时,即时你自身被释放,但是引用你的对象依然还在,

这时需要在引用你的对象移除该delegate

(3)、做一些其他的注销之类的操作,如一个ViewController在销毁之前有可能需要和server打交道。

一个对象,如一个ViewController在销毁之前有可能需要和server打交道;

这时我们也可以在dealloc中写

2、controller 不能释放，不走dealloc方法的几种可能

主要原因还是循环引用，引起的内存泄漏。

详情参考：controller 不能释放，不走dealloc方法的4种可能

## 四、Time Profile > [< 返回目录](#目录)

详情参考：instrument Time Profiler总结

使用Time Profile前有两点需要注意的地方：

1 2	1、一定要使用真机调试 2、应用程序一定要使用发布配置

图标为黑色头像的就是Time Profiler给我们的提示，有可能存在性能瓶颈的地方

其他

其他参考材料：

问：Xcode 运行程序，左侧memory 不显示内存。。

答：运行程序后，xcode 不显示当前使用的内存情况，问题是打开了僵尸–enable zoombie Objects，关闭即可。
即打开 product—>SCheme–>EditSCheme –>enable zoombie Objects 取消选中 ok

就可以继续显示了

附

1、MLeaksFinder 适配新版本

+ (void)alertWithTitle:(NSString *)title
               message:(NSString *)message
              delegate:(id<UIAlertViewDelegate>)delegate
 additionalButtonTitle:(NSString *)additionalButtonTitle {
    /*
    [alertView dismissWithClickedButtonIndex:0 animated:NO];
    UIAlertView *alertViewTemp = [[UIAlertView alloc] initWithTitle:title
                                                            message:message
                                                           delegate:delegate
                                                  cancelButtonTitle:@"OK"
                                                  otherButtonTitles:additionalButtonTitle, nil];
    [alertViewTemp show];
    alertView = alertViewTemp;
    
    NSLog(@"%@: %@", title, message);
    */
    
    // 获取当前的根视图控制器
    UIViewController *rootViewController = [UIApplication sharedApplication].keyWindow.rootViewController;
    while (rootViewController.presentedViewController) {
        rootViewController = rootViewController.presentedViewController;
    }
    
    UIAlertController *alertController = [UIAlertController alertControllerWithTitle:title message:message preferredStyle:UIAlertControllerStyleAlert];
    UIAlertAction *okAction = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:nil];
    [alertController addAction:okAction];
    if (additionalButtonTitle) {
        UIAlertAction *additionalAction = [UIAlertAction actionWithTitle:additionalButtonTitle style:UIAlertActionStyleDefault handler:nil];
        [alertController addAction:additionalAction];
    }
    [rootViewController presentViewController:alertController animated:YES completion:nil];
    
    NSLog(@"%@: %@", title, message);
}

## 常见笔试/面试题 > [< 返回目录](#目录)

## END > [< 返回目录](#目录)