• 关于内存泄漏，还有哪些是你不知道的？

    前言

    好久没写东西了，因为最近懒了些，且找不到什么好的题材，所以准备对内存泄漏的问题做一篇整理。内存泄漏问题一直是项目开发中的一大问题，本文力求帮助从事过一段时间工作的iOS开发者快速寻找App中的内存泄漏问题。部分内容比较基础，大神可无视勿喷。

    一、从AFNet说起

    对于iOS开发者，网络请求类AFNetWorking是再熟悉不过了，对于AFNetWorking的使用我们通常会对通用参数、网址环境切换、网络状态监测、请求错误信息等进行封装。在封装网络请求类时需注意的是需要将请求队列管理者AFHTTPSessionManager声明为单例创建形式。对于该问题，AFNetWorking的作者在gitHub上也指出建议使用者在相同配置下保证AFHTTPSessionManager只有一个，进行全局管理，因此我们可以通过单例形式进行解决。下方展示部分核心代码：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    + (AFHTTPSessionManager*)defaultNetManager {
        static AFHTTPSessionManager *manager;
        static dispatch_once_t onceToken;
        dispatch_once(&onceToken, ^{
            manager = [[AFHTTPSessionManager alloc]init];
            manager.responseSerializer = [AFHTTPResponseSerializer serializer];
        });
        return manager;
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    + (void)GET:(NSString*)url parameters:(NSDictionary*)parameter returnData:(void (^)(NSData * resultData,NSError * error))returnBlock{
        //请求队列管理者 单例创建形式 防止内存泄漏
        AFHTTPSessionManager * manager = [HttpRequest defaultNetManager];
        [manager GET:url parameters:parameter progress:^(NSProgress * _Nonnull downloadProgress) {
        } success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
            returnBlock(responseObject,nil);
        } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
            returnBlock(nil,error);
        }];
    }

    二、Block循环引用

    Block循环引用的问题已是老经常谈了，至今已有多篇文章详细解释其原理及造成循环引用的原因等，不泛画图或实例列举，这里不一一赘述。总结一句话防止Block循环引用就是要防止对象之间引用的闭环出现。举个开发中的实际例子，就拿很多人在用的MJRefresh说起

    1
    2
    3
    4
    5
    self.tableView.mj_header = [MJRefreshNormalHeader headerWithRefreshingBlock:^{
            self.page = 1;
            [self.dataArr removeAllObjects];
            [self loadData];
    }];

    若在MJRefresh的执行Block中调用当前self或其所属属性，一定要注意循环引用问题。我们简单分析下MJRefresh为什么会造成循环引用问题：

    点击进入headerWithRefreshingBlock对应方法即可

    1
    2
    3
    4
    5
    6
    7
    #pragma mark - 构造方法
    + (instancetype)headerWithRefreshingBlock:(MJRefreshComponentRefreshingBlock)refreshingBlock
    {
        MJRefreshHeader *cmp = [[self alloc] init];
        cmp.refreshingBlock = refreshingBlock;
        return cmp;
    }

    这里仅有三行代码，无非就是创建了下拉刷新部分View然后返回，这里比较重要的是cmp.refreshingBlock = refreshingBlock;这一句，这里的refreshingBlock是属于MJRefreshHeader的强引用属性，最后header会成为我们自己tableView的强引用属性mj_header，也就是说self.tableView强引用header, header强引用refreshingBlock，如果refreshingBlock里面强引用self，就成了循环引用，所以必须使用weakSelf，破掉这个循环。画图表示为：

    1767950-e4fea03eee29eba3.png

    循环引用示意图

    闭环为：

    self--->self.tableView--->self.tableView.mj_header---

    >self.tableView.mj_header.refreshingBlock--->self

    解决方案大家应该也不陌生

    1
    2
    3
    4
    5
    6
    7
    __weak typeof(self) weakself = self; 
    self.tableView.mj_header = [MJRefreshNormalHeader headerWithRefreshingBlock:^{
            __strong typeof(self) strongself = weakself;
            strongself.page = 1;
            [strongself.dataArr removeAllObjects];
            [strongself loadData];
    }];

    【??strongself是为了防止内存提前释放，有兴趣的童鞋可深入了解，这里不做过多解释了。当然也可借助libextobjc库进行解决，书写为@weakify和@strongify会更方便些。】

    相应的对于自定义View中的一些Block传值问题同样需要注意，与上述类似。

    三、delegate循环引用问题

    delegate循环引用问题比较基础，只需注意将代理属性修饰为weak即可

    1
    @property (nonatomic, weak) id delegate;

    下图比较形象的说明了使用weak修饰就是为了防止ViewController和UITableView相互强引用内存无法释放的问题：

    1767950-2d4403294c5b1d4a.jpg

    delegate循环引用

    四、NSTimer循环引用

    对于定时器NSTimer，使用不正确也会造成内存泄漏问题。这里简单举个例子，我们声明了一个类TestNSTimer，在其init方法中创建定时器执行操作。

    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
    #import "TestNSTimer.h"
     
    @interface TestNSTimer ()
    @property (nonatomic, strong) NSTimer *timer;
    @end
    @implementation TestNSTimer
     
    - (instancetype)init {
        if (self = [super init]) {
            _timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(timeRefresh:) userInfo:nil repeats:YES];
        }
        return self;
    }
     
    - (void)timeRefresh:(NSTimer*)timer {
        NSLog(@"TimeRefresh...");
    }
     
    - (void)cleanTimer {
        [_timer invalidate];
        _timer = nil;
    }
     
    - (void)dealloc {
        [super dealloc];
        NSLog(@"销毁");
        [self cleanTimer];
    }
     
    @end

    在外部调用时，将其创建后5秒销毁。

    1
    2
    3
    4
        TestNSTimer *timer = [[TestNSTimer alloc]init];
        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
            [timer release];
        });

    最后的执行结果为

    1767950-62b8e5e44447f4d7.png

    NSTimer打印结果

    可见TestNSTimer对象并没有正常释放，定时器仍然在无限的执行下去。

    我们都知道定时器使用完毕时需要将其停止并滞空，但cleanTimer方法到底何时调用呢？在当前类的dealloc方法中吗？并不是，若将cleanTimer方法调用在dealloc方法中会产生如下问题，当前类销毁执行dealloc的前提是定时器需要停止并滞空，而定时器停止并滞空的时机在当前类调用dealloc方法时，这样就造成了互相等待的场景，从而内存一直无法释放。因此需要注意cleanTimer的调用时机从而避免内存无法释放，如上的解决方案为将cleanTimer方法外漏，在外部调用即可。

    1
    2
    3
    4
    5
    TestNSTimer *timer = [[TestNSTimer alloc]init];
        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
            [timer cleanTimer];
            [timer release];
        });

    打印结果

    五、非OC对象内存处理

    对于iOS开发，ARC模式已发扬光大多年，可能很多人早已忘记当年retain、release的年代，但ARC的出现并不是说我们完全可以忽视内存泄漏的问题。对于一些非OC对象，使用完毕后其内存仍需要我们手动释放。

    举个例子，比如常用的滤镜操作调节图片亮度

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    CIImage *beginImage = [[CIImage alloc]initWithImage:[UIImage imageNamed:@"yourname.jpg"]];
    CIFilter *filter = [CIFilter filterWithName:@"CIColorControls"];
    [filter setValue:beginImage forKey:kCIInputImageKey];
    [filter setValue:[NSNumber numberWithFloat:.5] forKey:@"inputBrightness"];//亮度-1~1
    CIImage *outputImage = [filter outputImage];
    //GPU优化
    EAGLContext * eaglContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES3];
    eaglContext.multiThreaded = YES;
    CIContext *context = [CIContext contextWithEAGLContext:eaglContext];
    [EAGLContext setCurrentContext:eaglContext];
     
    CGImageRef ref = [context createCGImage:outputImage fromRect:outputImage.extent];
    UIImage *endImg = [UIImage imageWithCGImage:ref];
    _imageView.image = endImg;
    CGImageRelease(ref);//非OC对象需要手动内存释放

    在如上代码中的CGImageRef类型变量非OC对象，其需要手动执行释放操作CGImageRelease(ref)，否则会造成大量的内存泄漏导致程序崩溃。其他的对于CoreFoundation框架下的某些对象或变量需要手动释放、C语言代码中的malloc等需要对应free等都需要注意。

    五、地图类处理

    若项目中使用地图相关类，一定要检测内存情况，因为地图是比较耗费App内存的，因此在根据文档实现某地图相关功能的同时，我们需要注意内存的正确释放，大体需要注意的有需在使用完毕时将地图、代理等滞空为nil，注意地图中标注（大头针）的复用，并且在使用完毕时清空标注数组等。

    1
    2
    3
    4
    5
    6
    7
    8
    - (void)clearMapView{
        self.mapView = nil;
        self.mapView.delegate =nil;
        self.mapView.showsUserLocation = NO;
        [self.mapView removeAnnotations:self.annotations];
        [self.mapView removeOverlays:self.overlays];
        [self.mapView setCompassImage:nil];
    }

    六、大次数循环内存暴涨问题

    记得有道比较经典的面试题，查看如下代码有何问题：

    1
    2
    3
    4
    5
    6
    for (int i = 0; i < 100000; i++) {
            NSString *string = @"Abc";
            string = [string lowercaseString];
            string = [string stringByAppendingString:@"xyz"];
            NSLog(@"%@", string);
    }

    该循环内产生大量的临时对象，直至循环结束才释放，可能导致内存泄漏，解决方法为在循环中创建自己的autoReleasePool，及时释放占用内存大的临时变量，减少内存占用峰值。

    1
    2
    3
    4
    5
    6
    7
    8
    for (int i = 0; i < 100000; i++) {
            @autoreleasepool {
                NSString *string = @"Abc";
                string = [string lowercaseString];
                string = [string stringByAppendingString:@"xyz"];
                NSLog(@"%@", string);
            }
        }

    若对autoReleasePool陌生，可查阅相关资料，毕竟不是一两句即可说明的。

    附、如何检测App的内存泄漏问题

    1、借助Xcode自带的Instruments工具（选取真机测试）

    1767950-dd1d8aad0c2e0e2d.png

    Instruments

    2、简单暴力的重写dealloc方法，加入断点或打印判断某类是否正常释放。

    1767950-e4b71f21cd68c854.png

    dealloc

    3、通过Facebook出品的FBMemoryProfiler工具类进行检测，感兴趣的童鞋可进行了解。

    暂时写到这里，未完待续
  • 相关阅读:
    Android为TV端助力 转载：Android绘图Canvas十八般武器之Shader详解及实战篇(下)
    Android为TV端助力 android 在5.0以后不允许使用隐式Intent方式来启动Service
    Android为TV端助力 清除本应用里的各种数据的方法
    Android为TV端助力 计算每个目录剩余空间丶总空间以及SD卡剩余空间
    Android为TV端助力 布局、绘制、内存泄露、响应速度、listview和bitmap、线程优化以及一些优化的建议！
    Android为TV端助力 帧动画
    Android为TV端助力 自定义动画
    Android为TV端助力 自定义通知栏
    Android为TV端助力 转载：android自定义view实战(温度控制表)！
    Android为TV端助力 Canvas 和 Paint用法
  • 原文地址：https://www.cnblogs.com/pioneerMax/p/6794626.html
Copyright © 2020-2023  润新知