iOS 内存泄漏场景与解决方案

时间  2020-02-24 标签 ios 内存 泄漏 场景 解决 方案

欢迎访问个人博客原文javascript

内存泄漏指的是程序中已动态分配的堆内存（程序员本身管理的空间）因为某些缘由未能释放或没法释放，形成系统内存的浪费，致使程序运行速度变慢甚至系统崩溃。html

在 iOS 开发中会遇到的内存泄漏场景能够分为几类：java

循环引用

当对象 A 强引用对象 B，而对象 B 又强引用对象 A，或者多个对象互相强引用造成一个闭环，这就是循环引用。ios

Block

Block 会对其内部的对象强引用，所以使用的时候须要确保不会造成循环引用。git

举个例子，看下面这段代码：程序员

self.block = ^{
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", self.name);
    });
};
self.block();
复制代码

block 是 self 的属性，所以 self 强引用了 block，而 block 内部又调用了 self，所以 block 也强引用了 self。要解决这个循环引用的问题，有两种思路。github

使用 Weak-Strong Dance

先用 __weak 将 self 置为弱引用，打破“循环”关系，可是 weakSelf 在 block 中可能被提早释放，所以还须要在 block 内部，用 __strong 对 weakSelf 进行强引用，这样能够确保 strongSelf 在 block 结束后才会被释放。macos

__weak typeof(self) weakSelf = self;
self.block = ^{
    __strong typeof(self) strongSelf = weakSelf;
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", strongSelf.name);
    });
};
self.block();
复制代码

断开持有关系

使用 __block 关键字设置一个指针 vc 指向 self，从新造成一个 self → block → vc → self 的循环持有链。在调用结束后，将 vc 置为 nil，就能断开循环持有链，从而令 self 正常释放。json

__block UIViewController *vc = self;
self.block = ^{
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", vc.name);
        vc = nil;
    });
};
self.block();
复制代码

这里还要补充一个问题，为何要用 __block 修饰 vc？设计模式

首先，block 自己不容许修改外部变量的值。但被 __block 修饰的变量会被存在了一个栈的结构体当中，成为结构体指针。当这个对象被 block 持有，就将“外部变量”在栈中的内存地址放到堆中，进而能够在 block 内部修改外部变量的值。

还有一种方式能够断开持有关系。就是将 self 以传参的形式传入 block 内部，这样 self 就不会被 block 持用，也就不会造成循环持有链。

self.block = ^(UIViewController *vc){
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", vc.name);
    });
};
self.block(self);
复制代码

NSTimer

咱们知道 NSTimer 对象是采用 target-action 方式建立的，一般 target 就是类自己，而咱们为了方便又常把 NSTimer 声明为属性，像这样：

// 第一种建立方式，timer 默认添加进 runloop
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:self selector:@selector(timeFire) userInfo:nil repeats:YES];
// 第二种建立方式，须要手动将 timer 添加进 runloop
self.timer = [NSTimer timerWithTimeInterval:1.0f target:self selector:@selector(timeFire) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];
复制代码

这就造成了 self → timer → self(target) 的循环持有链。只要 self 不释放，dealloc 就不会执行，timer 就没法在 dealloc 中销毁，self 始终被强引用，永远得不到释放，循环矛盾，最终形成内存泄漏。

那么若是只把 timer 做为局部变量，而不是属性呢？

NSTimer *timer = [NSTimer timerWithTimeInterval:1.0f target:self selector:@selector(timeFire) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
复制代码

self 一样释放不了。

由于在加入 runloop 的操做中，timer 被强引用，这就造成了一条 runloop → timer → self(target) 的持有链。而 timer 做为局部变量，没法执行 invalidate，因此在 timer 被销毁以前，self 也不会被释放。

因此只要申请了 timer，加入了 runloop，而且 target 是 self，就算不是循环引用，也会形成内存泄漏，由于 self 没有释放的时机。

解决这个问题有好几种方式，开发者能够自行选择。

在合适的时机销毁 NSTimer

当 NSTimer 初始化以后，加入 runloop 会致使被当前的页面强引用，所以不会执行 dealloc。因此须要在合适的时机销毁 _timer，断开 _timer、runloop 和当前页面之间的强引用关系。

[_timer invalidate];
_timer = nil;
复制代码

ViewController 中的时机能够选择 didMoveToParentViewController、viewDidDisappear，View 中能够选择 removeFromSuperview 等，但这种方案并必定是正确可行的。

好比在注册页面中加了一个倒计时，若是在 viewDidDisappear 中销毁了 _timer，当用户点击跳转到用户协议页面时，倒计时就会被提早销毁，这是不合逻辑的。所以须要结合具体业务的需求场景来考虑。

使用 GCD 的定时器

GCD 不基于 runloop，能够用 GCD 的计时器代替 NSTimer 实现计时任务。但须要注意的是，GCD 内部 block 中的循环引用问题仍是须要解决的。

__weak typeof(self) weakSelf = self;
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue);
dispatch_source_set_timer(_timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0);
dispatch_source_set_event_handler(_timer, ^{
    [weakSelf timeFire];
});
// 开启计时器
dispatch_resume(_timer);
// 销毁计时器
// dispatch_source_cancel(_timer);
复制代码

借助中介者销毁

中介者指的是用别的对象代替 target 里的 self，中介者绑定 selector 以后，再在 dealloc 中释放 timer。

这里介绍两种中介者，一种是 NSObject 对象，一种是 NSProxy 的子类。它们的存在是为了断开对 self 的强引用，使之能够被释放。

以一个 NSObject 对象做为中介者

新建一个 NSObject 对象 _target，为它动态添加一个方法，方法的地址指向 self 方法列表中的 timeFire 的 IMP。这样 _target 与 self 之间没有直接的引用关系，又能引用 self 里的方法，就不会出现循环引用。

_target = [NSObject new];
class_addMethod([_target class], @selector(timeFire), class_getMethodImplementation([self class], @selector(timeFire)), "v@:");
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:_target selector:@selector(timeFire) userInfo:nil repeats:YES];
复制代码
以 NSProxy 的子类做为中介者

建立一个继承自 NSProxy 的子类 WeakProxy，将 timer 的 target 设置为 WeakProxy 实例，利用完整的消息转发机制实现执行 self 中的计时方法，解决循环引用。

// WeakProxy.h
@property (nonatomic, weak, readonly) id weakTarget;

+ (instancetype)proxyWithTarget:(id)target;
- (instancetype)initWithTarget:(id)target;

// WeakProxy.m
@implementation WeakProxy

+ (instancetype)proxyWithTarget:(id)target {
    return [[self alloc] initWithTarget:target];
}

- (instancetype)initWithTarget:(id)target {
    _weakTarget = target;
    return self;
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    SEL sel = [invocation selector];
    if ([self.weakTarget respondsToSelector:sel]) {
        [invocation invokeWithTarget:self.weakTarget];
    }
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [self.weakTarget methodSignatureForSelector:sel];
}

- (BOOL)respondsToSelector:(SEL)aSelector {
    return [self.weakTarget respondsToSelector:aSelector];
}
@end
复制代码

而后这样建立 timer：

self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:[WeakProxy proxyWithTarget:self] selector:@selector(timeFire) userInfo:nil repeats:YES];
复制代码

这时候的循环持有链是这样的：

因为 WeakProxy 与 self 之间是弱引用关系，self 最终是能够被销毁的。

带 block 的 timer

iOS 10 以后，Apple 提供了一种 block 的方式来解决循环引用的问题。

+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0));
复制代码

为了兼容 iOS 10 以前的方法，能够写成 NSTimer 分类的形式，将 block 做为 SEL 传入初始化方法中，统一以 block 的形式处理回调。

// NSTimer+WeakTimer.m
#import "NSTimer+WeakTimer.h"
 
@implementation NSTimer (WeakTimer)
 
+ (NSTimer *)ht_scheduledTimerWithTimeInterval:(NSTimeInterval)interval
                                       repeats:(BOOL)repeats
                                         block:(void(^)(void))block {
    return [self scheduledTimerWithTimeInterval:interval
                                         target:self
                                       selector:@selector(ht_blockInvoke:)
                                       userInfo:[block copy]
                                        repeats:repeats];
}
 
+ (void)ht_blockInvoke:(NSTimer *)timer {
    void (^block)(void) = timer.userInfo;
    if(block) {
        block();
    }
}

@end
复制代码

而后在须要的类中建立 timer。

__weak typeof(self) weakSelf = self;
self.timer = [NSTimer ht_scheduledTimerWithTimeInterval:1.0f repeats:YES block:^{
    [weakSelf timeFire];
}];
复制代码

委托模式

委托模式，是对象之间通讯的一种设计模式。该模式的主旨是：定义一套接口，某对象若想接受另外一个对象的委托，则需听从此接口，以便成为其“委托对象”。

UITableView 的 delegate

咱们经常使用的 tableView 与 ViewController 就是委托方和代理方的关系。

须要在控制器中加入列表时，一般咱们会将 tableView 设为 ViewController 中 view 的子视图，UIViewController 的源码是这样定义 view 的：

@property(null_resettable, nonatomic, strong) UIView *view;
复制代码

所以 ViewController 强引用了 tableView。而 tableView 又要委托 ViewController 帮它实现几个代理方法和数据源方法。若是此时 dataSource 和 delegate 属性用 strong 来修饰，就会出现 UITableView 与 ViewController 互相强引用，造成循环引用。

那么看一下 UITableView 的实现源码，咱们会发现其中定义 dataSource 和 delegate 属性时是用 weak 修饰的。

@property (nonatomic, weak, nullable) id <UITableViewDataSource> dataSource;
@property (nonatomic, weak, nullable) id <UITableViewDelegate> delegate;
复制代码

因此 tableView 的 dataSource 和 delegate 只是 weak 指针，指向了 ViewController，它们之间的关系是这样的：

这也就避免了循环引用的发生。

NSURLSession 的 delegate

那么 delegate 必定被 weak 修饰吗？

也不必定，须要看具体的场景。好比 NSURLSession 类中的 delegate 就是用 retain 修饰的。

@property (nullable, readonly, retain) id <NSURLSessionDelegate> delegate;
复制代码

它这么作，是由于了确保网络请求回调以前，delegate 不被释放。

这也间接引发了 AFNetworking 中循环引用的出现。咱们看 AFURLSessionManager 类中声明的 session 是 strong 类型的。

/** The managed session. */
@property (readonly, nonatomic, strong) NSURLSession *session;
复制代码

在构造 session 对象时，也将 delegate 设为了 self，也就是 AFURLSessionManager 类。

- (NSURLSession *)session {
    @synchronized (self) {
        if (!_session) {
            _session = [NSURLSession sessionWithConfiguration:self.sessionConfiguration delegate:self delegateQueue:self.operationQueue];
        }
    }
    return _session;
}
复制代码

如此三者就造成了这样循环持有关系。

要解决这个问题，有两种解决思路：

方式一：将 AFHTTPSessionManager 对象设为单例

对于客户端来讲，大多数状况下都是对应同一个后台服务，因此能够将 AFHTTPSessionManager 对象设为单例来处理。

- (AFHTTPSessionManager *)sharedManager {
    static dispatch_once_t onceToken;
    static AFHTTPSessionManager *_manager = nil;
    dispatch_once(&onceToken, ^{
        _manager = [AFHTTPSessionManager manager];
        _manager.requestSerializer = [AFHTTPRequestSerializer serializer];
        _manager.responseSerializer.acceptableContentTypes = [NSSet setWithObjects:@"application/json", @"text/html",@"text/json", @"text/plain", @"text/javascript",@"text/xml", nil];
        _manager.responseSerializer = [AFHTTPResponseSerializer serializer];
    });
    return _manager;
}
复制代码

若是要设定固定请求头， 以这种 key-value 形式加入到 dispatch_once 中。

[_manager.requestSerializer setValue:@"application/json;charset=utf-8" forHTTPHeaderField:@"Content-Type"];
复制代码

缺点：由于请求的 header 是由 AFHTTPSessionManager的 requestSerializer.mutableHTTPRequestHeaders 字典持有的，因此这种单例模式会致使全局共享一个 header，若是要处理不一样自定义 header 的请求就会变得很麻烦。

方式二：在请求结束时，手动销毁 session 对象

因为 session 对象对 delegate 强持有，要打破循环引用，须要在请求结束后手动调用 AFHTTPSessionManager 对象销毁的方法。

- (AFHTTPSessionManager *)getSessionManager{
    AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
    manager.requestSerializer = [AFHTTPRequestSerializer serializer];
    manager.responseSerializer.acceptableContentTypes = [NSSet setWithObjects:@"application/json", @"text/html",@"text/json", @"text/plain", @"text/javascript",@"text/xml", nil];
    manager.responseSerializer = [AFHTTPResponseSerializer serializer];
    return manager;
}

- (void)sendRequest{
    AFHTTPSessionManager *manager = [self getSessionManager];
    __weak typeof(manager)weakManager = manager;
    [manager GET:@"https://blog.fiteen.top" parameters:nil progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
         __strong typeof (weakManager)strongManager = weakManager;
        NSLog(@"success 回调");
        [strongManager invalidateSessionCancelingTasks:YES];
    } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
        __strong typeof (weakManager)strongManager = weakManager;
        NSLog(@"error 回调");
        [strongManager invalidateSessionCancelingTasks:YES];
    }];
}
复制代码

非 OC 对象内存处理

虽然如今已经普及了 ARC 模式，但它仅对 OC 对象进行自动内存管理。对于非 OC 对象，好比 CoreFoundation 框架下的 CI、CG、CF 等开头的类的对象，在使用完毕后仍需咱们手动释放。

好比这段获取 UUID 的代码：

CFUUIDRef puuid = CFUUIDCreate( kCFAllocatorDefault );
CFStringRef uuidString = CFUUIDCreateString( kCFAllocatorDefault, puuid );
NSString *uuid = [(NSString *)CFBridgingRelease(CFStringCreateCopy(NULL, uuidString)) uppercaseString];
// 使用完后释放 puuid 和 uuidString 对象
CFRelease(puuid);
CFRelease(uuidString);
复制代码

还有 C 语言中，若是用 malloc 动态分配内存后，须要用 free 去释放，不然会出现内存泄漏。好比：

person *p = (person *)malloc(sizeof(person));
strcpy(p->name,"fiteen");
p->age = 18;
// 使用完释放内存
free(p);
// 防止野指针
p = NULL;
复制代码

循环加载引发内存峰值

先看下面这段代码，看似没有内存泄漏的问题，可是在实际运行时，for 循环内部产生了大量的临时对象，会出现 CPU 暴增。

for (int i = 0; i < 1000000; i++) {
    NSString *str = @"Abc";
    str = [str lowercaseString];
    str = [str stringByAppendingString:@"xyz"];
    NSLog(@"%@", str);
}
复制代码

这是由于循环内产生大量的临时对象，直至循环结束才释放，可能致使内存泄漏。

解决方案：

在循环中建立本身的 autoreleasepool，及时释放占用内存大的临时变量，减小内存占用峰值。

for (int i = 0; i < 100000; i++) {
    @autoreleasepool {
        NSString *str = @"Abc";
        str = [str lowercaseString];
        str = [str stringByAppendingString:@"xyz"];
        NSLog(@"%@", str);
    }
}
复制代码

在没有手加自动释放池的状况下，autorelease 对象是在当前的 runloop 迭代结束时释放的，而它可以释放的缘由是系统在每一个 runloop 迭代中都会先销毁并从新建立自动释放池。

下面举个特殊的例子，使用容器 block 版本的枚举器时，内部会自动添加一个自动释放池，好比：

[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    // 这里被一个局部 @autoreleasepool 包围着
}];
复制代码

野指针与僵尸对象

指针指向的对象已经被释放/回收，这个指针就叫作野指针。这个被释放的对象就是僵尸对象。

若是用野指针去访问僵尸对象，或者说向野指针发送消息，会发生 EXC_BAD_ACCESS 崩溃，出现内存泄漏。

// MRC 下
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Student *stu = [[Student alloc] init];
        [stu setAge:18];
        [stu release];      // stu 在 release 以后，内存空间被释放并回收，stu 变成野指针
        // [stu setAge:20]; // set 再调用 setAge 就会崩溃
    }
    return 0;
}
复制代码

解决方案：当对象释放后，应该将其置为 nil。

内存泄漏检查工具

Instruments

Instruments 是 Xcode 自带的工具集合，为开发者提供强大的程序性能分析和测试能力。

它打开方式为：Xcode → Open Developer Tool → Instruments。其中的 Allocations 和 Leaks 功能能够协助咱们进行内存泄漏检查。

  • Leaks：动态检查泄漏的内存，若是检查过程时出现了红色叉叉，就说明存在内存泄漏，能够定位到泄漏的位置，去解决问题。此外，Xcode 中还提供静态监测方法 Analyze，能够直接经过 Product → Analyze 打开，若是出现泄漏，会出现“蓝色分支图标”提示。

  • Allocations：用来检查内存使用/分配状况。好比出现“循环加载引发内存峰值”的状况，就能够经过这个工具检查出来。

  • Zombies：检查是否访问了僵尸对象。

Instruments 的使用相对来讲比较复杂，你也能够经过在工程中引入一些第三方框架进行检测。

MLeaksFinder

MLeaksFinder 是 WeRead 团队开源的 iOS 内存泄漏检测工具。

它的使用很是简单，只要在工程引入框架，就能够在 App 运行过程当中监测到内存泄漏的对象并当即提醒。MLeaksFinder 也不具有侵入性，使用时无需在 release 版本移除，由于它只会在 debug 版本生效。

不过 MLeaksFinder 的只能定位到内存泄漏的对象，若是你想要检查该对象是否存在循环引用。就结合 FBRetainCycleDetector 一块儿使用。

FBRetainCycleDetector

FBRetainCycleDetector 是 Facebook 开源的一个循环引用检测工具。它会递归遍历传入内存的 OC 对象的全部强引用的对象，检测以该对象为根结点的强引用树有没有出现循环引用。

联系我们 沪ICP备2021010478号-7