nstimer

什么是RunLoop 注释：和ppt上总结的一样 和代码一块去理解 从字面上看 运行循环 跑圈 循环 基本作用 保持程序的持续运行(比如主运行循环) 处理App中的各种事件（比如触摸事件、定时器事件、Selector事件） 节省CPU资源，提高程序性能：该做事时做事，该休息时休息 存在价值 没有RunLoop 有RunLoop main函数中的RunLoop(主运行循环) 主运行循环 第14行代码的UIApplicationMain函数内部就启动了一个RunLoop 所以UIApplicationMain函数一直没有返回，保持了程序的持续运行 这个默认启动的RunLoop是跟主线程相关联的 RunLoop对象 iOS中有2套API来访问和使用RunLoop Foundation NSRunLoop Core Foundation CFRunLoopRef NSRunLoop和CFRunLoopRef都代表着RunLoop对象 NSRunLoop是基于CFRunLoopRef的一层OC包装，所以要了解RunLoop内部结构，需要多研究CFRunLoopRef层面的API（Core Foundation层面） RunLoop资料 苹果官方文档 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual

李洪强经典面试题145-Runloop Runloop 什么是 Runloop？ 从字面上讲就是运行循环。 它内部就是do-while循环，在这个循环内部不断地处理各种任务。 一个线程对应一个RunLoop，主线程的RunLoop默认已经启动，子线程的RunLoop得手动启动（调用run方法） RunLoop只能选择一个Mode启动，如果当前Mode中没有任何Source(Sources0、Sources1)、Timer，那么就直接退出RunLoop 基本的作用就是保持程序的持续运行，处理app中的各种事件。通过runloop，有事运行，没事就休息，可以节省cpu资源，提高程序性能。 Runloop对象 iOS中有2套API来访问和使用RunLoop Foundation：NSRunLoop Core Foundation：CFRunLoopRef NSRunLoop和CFRunLoopRef都代表着RunLoop对象 NSRunLoop是基于CFRunLoopRef的一层OC包装，所以要了解RunLoop内部结构，需要多研究CFRunLoopRef层面的API。 Runloop与线程 每条线程都有唯一的一个与之对应的RunLoop对象 主线程的RunLoop已经自动创建好了，子线程的RunLoop需要主动创建 RunLoop在第一次获取时创建，在线程结束时销毁

ARC已经出来很久了，自动释放内存的确很方便，但是并非绝对安全绝对不会产生内存泄露。导致iOS对象无法按预期释放的一个无形杀手是——循环引用。循环引用可以简单理解为A引用了B，而B又引用了A，双方都同时保持对方的一个引用，导致任何时候引用计数都不为0，始终无法释放。若当前对象是一个ViewController，则在dismiss或者pop之后其dealloc无法被调用，在频繁的push或者present之后内存暴增，然后APP就duang地挂了。下面列举我们变成中比较容易碰到的三种循环引用的情形。 （1）计时器NSTimer 一方面，NSTimer经常会被作为某个类的成员变量，而NSTimer初始化时要指定self为target，容易造成循环引用。 另一方面，若timer一直处于validate的状态，则其引用计数将始终大于0。先看一段NSTimer使用的例子(ARC模式)： 1 #import <Foundation/Foundation.h> 2 @interface Friend : NSObject 3 - (void)cleanTimer; 4 @end 1 #import "Friend.h" 2 @interface Friend () 3 { 4 NSTimer *_timer; 5 } 6 @end 7 8 @implementation Friend 9 -

ARC工程是可以重写dealloc方法并被系统调用的，但不需要手动调用父类的dealloc，手写[super dealloc]方法会报错，事实上系统会自动帮你调用父类的dealloc方法，不需要你实现。可以通过在dealloc方法中打印log查看控制器是否被释放。 控制器在被pop后移出栈后会被释放，但有些时候会发现控制器出栈的时候不会调用dealloc方法，归根结底，是因为当前控制器被某个对象强引用了，控制器的引用计数不为0，系统无法帮你释放这部分内存。 控制器中NSTimer没有被销毁 当控制器中存在NSTimer时，就需要注意，因为当 [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(updateTime:) userInfo:nil repeats:YES]; 时，这个/ target:self / 就增加了VC的RetarnCountr, 如果你不将这个timer invalidate，就别想调用dealloc。需要在viewWillDisappear之前需要把控制器用到的NSTimer销毁。 [timer invalidate]; // 销毁timer timer = nil; // 置nil 控制器中的代理不是weak属性 例如 @property (nonatomic

介绍： 循环引用，指的是多个对象相互引用时，使得引用形成一个环形，导致外部无法真正是否掉这块环形内存。其实有点类似死锁。 举个例子：A->B->C->....->X->B ->表示强引用，这样的B的引用计数就是2，假如A被系统释放了，理论上A会自动减小A所引用的资源，就是B，那么这时候B的引用计数就变成了1，所有B无法被释放，然而A已经被释放了，所有B的内存部分就肯定无法再释放再重新利用这部分内存空间了，导致内存泄漏。 情况一：delegate Delegate是ios中开发中最常遇到的循环引用，一般在声明delegate的时候都要使用弱引用weak或者assign @property (nonatomic, weak, nullable) id <UITableViewDelegate> delegate; 当然怎么选择使用assign还是weak，MRC的话只能用assign，在ARC的情况下最好使用weak，因为weak修饰的变量在是否后自动为指向nil，防止不安全的野指针存在 情况二：Block Block也是比较常见的循环引用问题，在Block中使用了self容易出现循环引用，因此很多人在使用block的时候，加入里面有用到self的操作都会声明一个__weak来修饰self。其实便不是这样的，不是所有使用了Block都会出现Self循环引用问题

// // ViewController.m // NSRunLoop // // Created by JackMeng on 13-11-14. // Copyright (c) 2013 年 JackMeng. All rights reserved. // #import "ViewController.h" @interface ViewController () @end @implementation ViewController - ( void )viewDidLoad { [ super viewDidLoad ]; // 使用 NSTimer 创建定时器 NSTimeInterval timeInterval = 1 ; // 间隔时间 [ NSTimer scheduledTimerWithTimeInterval :timeInterval target : self selector : @selector (timerMethod) userInfo : nil repeats : YES ]; // 使用 RunLoop 创建 NSTimer 对象 NSRunLoop *theRunLoop = [ NSRunLoop currentRunLoop ]; // 获得当前的 RunLoop NSDate *fireDate = [ NSDate

使用NSTimer出现的问题 去年封的一个图片轮播的, 这两天在忙着给重新封装一下, 增加更多的方法, 有更多个性化的设置, 增加了网络请求图片的轮播. 重新封装, 这个过程还算顺利, 但是到计时器那块卡住了. WHImagePlayer图片轮播和图片浏览器: https://github.com/hell03W/WHImagePlayer , 欢迎star支持一下, 如果有任何问题欢迎issue给我. 问题是这样的: 简单来说, 其实就是计时器, 我用的NSTimer, 是在一个自定义view中创建NSTimer的, 如果是在控制器中, 可以在viewWillDisappear:中执行NSTimer的 invalidate 方法, timer对象是可以被正常销毁的, 但是在自定义的view里面没有那样的方法! 有人会说可以将target设置成 __weak 类型的就可以了嘛 ! 我也是那样认为的, 可是试验证明, 那样是不行的(要是那么简单, 也没必要写个blog来记录了). 经过在网上查找资料, 和自己的思考, 最终总结了几种可行方案: 方案一: 如下代码所示, 使用 dispatch_after 可以完美解决, 但是需要注意的是, 在block内部, 使用 self 时候必须使用weakSelf, 如果直接使用self, 还是不会被释放掉的. __weak typeof