内存管理剖析（二）——定时器问题

时间  2021-08-13
标签 markdown app 框架 oop 布局 post atom spa 线程 栏目 Markdown 繁體版
原文   原文链接

内存管理传送门🦋🦋🦋

内存管理剖析（一）—MRC时代的手动内存管理markdown

内存管理剖析（三）——iOS程序的内存布局app

内存管理剖析（四）——autorelease原理分析框架

内存管理剖析（五）—— weak指针实现原理oop

CADisplayLink、NSTimer的循环引用问题

CADisplayLink 是QuartzCore框架下的的一种定时器，用在跟画图相关的处理当中。NSTimer 你们应该很熟悉，是咱们最经常使用的定时器。这两种定时器分别提供以下两个API布局

+ (CADisplayLink *)displayLinkWithTarget:(id)target selector:(SEL)sel;
复制代码
+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo;
复制代码

这两个API里面都有target参数，该target会被CADisplayLink/NSTimer强引用。若是CADisplayLink或者NSTimer做为属性被一个视图控制器VC强引用，当咱们在调用上述两个API的时候，target参数传VC，这样VC和CADisplayLink/NSTimer之间便会造成引用循环，没法释放，形成内存泄漏。图示以下NSTimer/CADisplayLink产生循环引用post

NSTimer的解决方案1 经过使用别的API来添加NSTimer，如ui

(NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;
复制代码

而且将self经过__weak typeof(self) weakSelf == self;包装成弱指针，传入其中便可。atom

NSTimer的解决方案2 经过增长一个中间代理对象来打破引用循环。请看下图 如上图所示，在timer和VC之间增长一个代理对象otherObject，timer的强指针target指向otherObject，otherObject的弱指针target指向VC，这样就成功打破了引用循环。咱们之因此须要借助第三者来破环，是由于NSTimer并不是开源，咱们没法修改其内部target的强弱性。所以只能经过一个自定义的代理对象来作一层引用中转，最终打破引用循环。spa

如今还有一个细节须要处理，增长代理对象otherObject以前，是由timer经过target直接调用VC里面的定时器方法的。如今中间多了一层otherObject，该如何实现定时器方法的调用呢？其实方法蛮多的，相信你们都能想出一些解决方案。这里就直接推荐一种比较巧妙的方法——经过消息转发。以下图代理对象的消息转发 由于代理对象的本质目的，就是打破引用循环，而且传递方法，了解OC消息机制的原理前提下，你应该很好理解消息转发的做用，正好能够巧妙的用在这个场景下。请好好体会一下。线程

下面是一份代码案例

#import "ViewController.h"
#import "CLProxy.h"

@interface ViewController ()
//@property (nonatomic, strong) CADisplayLink *link;
@property (nonatomic, strong) NSTimer *timer;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];

    //CADisplayLink用来保证调用频率和屏幕的刷帧频率一致，60FPS
// self.link = [CADisplayLink displayLinkWithTarget:[CLProxy proxyWithTarget:self] selector:@selector(linkTest)];
// [self.link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
    
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:[CLProxy proxyWithTarget:self] selector:@selector(timerTest) userInfo:nil repeats:YES];
}

//- (void)linkTest {
// NSLog(@"%s",__func__);
//}

- (void)timerTest {
    NSLog(@"%s",__func__);
}

-(void)dealloc {
    NSLog(@"%s",__func__);
}

@end

****************🥝🥝🥝🥝代理类CLProxy🥝🥝🥝
**************** CLProxy.h  ****************
#import <Foundation/Foundation.h>

@interface CLProxy : NSObject
+(instancetype)proxyWithTarget: (id)target;
@property (weak, nonatomic) id target;

@end

**************** CLProxy.m  ****************
#import "CLProxy.h"
@implementation CLProxy

+(instancetype)proxyWithTarget: (id)target {
    CLProxy *proxy = [[CLProxy alloc] init];
    proxy.target = target;
    return proxy;
}


-(id)forwardingTargetForSelector:(SEL)aSelector {
    return self.target;
}
@end
复制代码

该方案一样适用于CADisplayLink，再也不赘述。

认识NSProxy

你们可能看到过一个类叫NSProxy，但应该不多能用到，这是一个很是特殊的类。咱们来对比一下它和NSObject的定义的对比

@interface NSProxy <NSObject> {
    Class	isa;
}

@interface NSObject <NSObject> {
    Class isa  ;
}
复制代码

你能够看到，NSProxy和NSObject是同一层级的，所以也能够吧NSProxy理解成一个基类。他们都遵照<NSObject>协议，他们都没有父类。

那么NSProxy是干吗用的呢？其实它就是专门用来解决经过中间对象转发消息的问题的。

这里先贴出案例代码

#import "ViewController.h"
#import "CLProxy2.h"

@interface ViewController ()
@property (nonatomic, strong) NSTimer *timer;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
   
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:[CLProxy2 proxyWithTarget:self] selector:@selector(timerTest) userInfo:nil repeats:YES];
}

- (void)timerTest {
    NSLog(@"%s",__func__);
}

-(void)dealloc {
    NSLog(@"%s",__func__);
    [self.timer invalidate];
}
@end

****************🥝🥝🥝🥝代理类CLProxy🥝🥝🥝
**************** CLProxy2.h  ****************
#import <Foundation/Foundation.h>

@interface CLProxy2 : NSProxy
+(instancetype)proxyWithTarget: (id)target;
@property (weak, nonatomic) id target;
@end

**************** CLProxy2.m  ****************

#import "CLProxy2.h"

@implementation CLProxy2

+(instancetype)proxyWithTarget: (id)target {
//NSProxy对象不须要调用init，由于它原本就没有init方法，直接alloc以后就可使用
    CLProxy2 *proxy = [CLProxy2 alloc];
    proxy.target = target;
    return proxy;
    
}

@end
复制代码

CLProxy2继承自NSProxy，首先仍是按照跟以前的案例的套路同样，将VC，timer和CLProxy2连接起来，咱们先不在CLProxy2对消息作任何处理，看一下会有什么状况，结果是报错信息

2019-08-26 11:26:13.486949+0800 内存管理[3407:219430] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSProxy methodSignatureForSelector:] called!'`
复制代码

能够看出，向CLProxy2对象发送一个它没有实现的方法（消息），最后会调用methodSignatureForSelector 方法。若是你很熟悉 【OC消息机制】 的话，对继承自NSObject的类的实例对象发送消息，若是该对象没有实现对应的方法的话，出现的报错将是

2019-08-26 11:31:01.254135+0800 内存管理[3456:222524] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[CLProxy timerTest]: unrecognized selector sent to instance 0x600000d64210'
复制代码

也就是经典的unrecognized selector sent to instance。 这是怎么回事呢？其实NSProxy接受到消息以后的处理流程以下

  • [proxyObj message]
  • （1）到proxyObj的类对象里面寻找对应的方法，找到就调用
  • （2）尝试进入父类对象递归查找方法（省略该步骤）
  • （3）找不到方法，尝试进行方法动态解析(省略该步骤)
  • （4）尝试调用forwardingTargetForSelector进行消息转发`(省略该步骤)
  • （5）尝试调用methodSignatureForSelector+forwardInvocation进行消息转发。

所以能够发现，相比较完整的消息机制流程，NSProxy的处理过程当中，省略了 （2）、（3）、（4） 步骤。因此它相比于NSObject，效率更高，咱们的今天所讨论的代理对象传递消息问题，正好能够经过NSProxy来解决，提高效率。根绝第 （5） 步骤，咱们只须要在子类里面实现methodSignatureForSelector+forwardInvocation这两个方法便可，上面的CLProxy2.m代码修改以下便可

#import "CLProxy2.h"

@implementation CLProxy2

+(instancetype)proxyWithTarget: (id)target {
//NSProxy对象不须要调用init，由于它原本就没有init方法，直接alloc以后就可使用
    CLProxy2 *proxy = [CLProxy2 alloc];
    proxy.target = target;
    return proxy;
    
}


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

-(void)forwardInvocation:(NSInvocation *)invocation {
    invocation.target = self.target;
    [invocation invoke];
}

@end
复制代码

之后碰到相似的经过中间对象传递消息的场景，最为推荐的就是利用NSProxy来实现。

若是别人问你CADisplayLink、NSTimer是否准时？

相信答案你们都会说：不许时。可是不许时的缘由未必每一个人都清楚。那这里就来简单梳理一下。 CADisplayLink、NSTimer底层都是靠RunLoop来实现的，也就是能够把它们理解成RunLoop所须要处理的事件。咱们知道RunLoop能够拿来刷新UI，处理定时器（CADisplayLink、NSTimer），处理点击滑动事件等很是多的事情。这里，就须要来了解一下RunLoop是如何触发NSTimer任务的。RunLoop每循环一圈，都会处理必定的事件，会消耗必定的时间，可是具体耗时多少这个是没法肯定的。 假如你开启一个timer，隔1秒触发定时器事件，RunLoop会开始累计每一圈循环的用时，当时间累计够1秒，就会触发定时器事件。你有兴趣的话，是能够在RunLoop的源码里面找到时间累加相关代码的。能够借助下图来加深理解NSTimer的准时触发 若是RunLoop在某一圈任务过于繁重，就可能出现以下状况NSTimer不许时状况

因此CADisplayLink、NSTimer是没法保证准时性的。

GCD定时器

GCD的定时器是直接跟系统内核挂钩，不依赖于RunLoop机制，因此时间是至关精准的。GCD定时器的使用很是简单，以下所示

@interface ViewController ()
@property (nonatomic, strong) dispatch_source_t timer;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    //初始化定时器
    self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
    //开始时间
    dispatch_time_t startTime = dispatch_time(DISPATCH_TIME_NOW, 3.0*NSEC_PER_SEC);
    //间隔时间
    uint64_t intervalTime = 1.0;
    //偏差时间
    uint64_t leewayTime = 0;
    //设置定时器时间
    dispatch_source_set_timer(self.timer, startTime, 1.0 * NSEC_PER_SEC, 0 * NSEC_PER_SEC);
    //设置定时器回调事件
    dispatch_source_set_event_handler(self.timer, ^{
        //定时器事件代码
        NSLog(@"GCD定时器事件");
        //若是定时器不须要重复，能够在这里取消定时器
        dispatch_source_cancel(self.timer);
    });
    //运行定时器
    dispatch_resume(self.timer);
    
}
复制代码

GCD计时器细节：咱们以前在RunLoop一章中讨论过使用NSTimer被界面滑动事件阻塞的问题，置于相同的场景下（GCD定时器放主线程），GCD定时器是不会受到UI界面滑动的印象的，其根本缘由就是在于GCD定时器跟RunLoop是没有关系的,它们是两套独立的机制，所以GCD的定时器不会受到RunLoopMode的约束。你们能够本身经过代码体会一下。

另外须要注意一下，ARC环境下，GCD里面的建立的一些对象都是不须要销毁的。GCD已经帮咱们作好了内存管理相关的事情。

内存管理传送门🦋🦋🦋

内存管理剖析（一）—MRC时代的手动内存管理

内存管理剖析（三）——iOS程序的内存布局

内存管理剖析（四）——autorelease原理分析

内存管理剖析（五）—— weak指针实现原理

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程