iOS NSRunloop 详解
2016-04-10 22:11
507 查看
概念
Runloop就像它的名字一样,就是跑环.我的理解就是一个死循环.是一个可以随时睡眠,随时唤醒的死循环
大家可以想一下,手机app为什么会一直运行?而且在接收到用户点击等等操作时就会有所反映.这个离不开runloop.
iOS app启动时就会启动一个runloop,而且这种模式应该Android也有,所以才会有了app能一直运行
每个线程都有一个runloop,但是只有主线程的runloop是默认开启的,其他子线程需要调用
一个线程可以创建多个runloop,但是只能是嵌套模式.也就是一个线程只有一个根runloop
使程序一直运行,并且接收用户输入等事件
决定程序什么时候处理什么事件
调用方面 解耦(比如用户划一下屏幕,会产生N个event事件,但是用户不可能等着被调方全部执行完再进行下一步的动作,也就是会将此系列事件扔到一个消息队列里,每次再从消息队列里面取,主调方与被调方实现解耦)
节省CPU(因为runloop在没事干的时候是休眠状态,只有接收到信号的时候才会唤醒,执行相应的操作)
runloop是由事件驱动的
这里区分下命令式驱动跟事件驱动
举个栗子,就像一个人活着就是个大runloop
NSRunloop是对CFRunloop的封装
与CFRunloop相关的有GCD,mach kernel是苹果内核的东西,还有block,pthread等
与咱们平时敲代码比较近一层有以下这些
NSTimer 计时器完全依赖于runloop
UIEvent 事件的产生到分发给代码都是通过runloop
Autorelease 自动释放也是在runloop跑完一圈后
NSObject(NSDelayedPerforming) performSelector,cancel
NSObject(NSThreadPerformAddition) performSelectorOnMainThread,performSelectorOnBackgroundThread
CA层的CADisplayLink(每画一帧会有一个回调),CATransition,CAAnimation
dispatch_get_main_queue()
NSURLConnection
AFNetworking,它的delegate跟网络传输数据都是在它的runloop里面执行的
NSPort 描述通讯信道的抽象类
等等..
如图所示:APP启动,start-->main.m进入-->Graphics Services(处理硬件交互的服务,比如用户点击屏幕)-->RunLoop(CFRunLoop开头的)-->Handle event
在runloop中定义了以下6种函数
几乎所有的函数都是从以上6中函数中调起.比如上图中就是调用的static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__();static void __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__()
然后开始调用event
RunLoop跟Thread是一一绑定的(也就是之前说的一个Thread里只有一个根runloop但是可以嵌套N个)
CFRunLoopMode:RunLoop必须在系统定义的几种模式下运行
下边几种是在RunLoopMode里面的
比较抽象,继续往下走
source是RunLoop的数据源(输入源)的抽象类(protocol)
RunLoop定义了两个version的Source:
1.source0:处理App内部事件,App自己负责管理(出发),如UIEvent、CFSocket
2.source1:由RunLoop和内核管理,Mach Port(进程间通讯端口)驱动,如CFMachPort、CFMessagePort
如果有需要,可从中选择一种实现自己的source(基本不会发生)
大家面试的时候可以问问面试者这个问题,autorelease的对象到底在什么时候释放?
根据孙源大神测试,AutoreleasePool通常在RunLoop两次Sleep之间释放
RunLoop在同一时间只能且必须在一种特定的Mode下Run
更换Mode时,需要停止当前RunLoop,然后重启新的RunLoop
Mode是iOS App流畅滑动的关键(因为在滑动时的Mode跟平时运行的Mode是不一样,从而避免干扰)
也可以基于系统的Mode创建自己的Mode(也是基本不会发生的)
系统定义的Mode有以下几种:
CFRunLoopDefaultMode: 这个是默认 Mode,也是空闲状态。主线程通常在这个 Mode 下运行的。
UITrackingRunLoopMode: ScrollView滚动时候的模式。
UIInitializationRunLoopMode: 在刚启动程序时进入的第一个 Mode,私有,启动完成后就不再使用。
GSEventReceiveRunLoopMode: 接受系统事件的内部的Mode,这个Mode由GraphicsServices调用在CFRunLoopRunSpecific前面。通常用不到。
CFRunLoopCommonModes: 这是一个数组,默认包括了第1和第2种模式,可以添加自己的Mode。
下面的方法Timer被添加到NSDefaultRunLoopMode,在滑动Scrollview的时候系统会切换至UITrackingRunLoopMode,Timer就会暂时停止
若不希望Timer被滑动影响,需添加到NSRunLoopCommonMode
下图表示App在滑动时的Mode切换
前面有说到GCD跟RunLoop有关系,其实本身GCD跟RunLoop是没有关系的,但是如果把queue填成main_queue就有关系了,关系只在于调起的过程是在RunLoop
GCD的主线程就是App的主线程,所以在GCD牵扯的主线程会转交给RunLoop去调起
在App运行时,在Debug栏里按下暂停,会出现以下堆栈
这就是RunLoop的睡眠状态,与刚刚说的MachPort有关系,图片里面上边的两个mach_msg会指定一个端口发给内核一个消息,这会儿就是正在等待接收信息的状态,也就是等待唤醒,内核此刻将其挂起(不是传统意义的挂起,还在内存里,其实就是睡眠状态,等个闹钟,或者有人叫醒)
指定用于唤醒的mach_port端口
调用mach_msg监听唤醒端口,被唤醒前,系统内核将此线程挂起,停留在mach_msg_trap状态
由另一个线程(或另一个进程中的某个线程)向内核发送这个端口的msg后,trap状态被唤醒,RunLoop继续运行
其中var wakeUpPort = SleepAndWaitForWakingUpPorts();这句伪代码可以看作是RunLoop的核心。内部实现简化为这样:先调用__CFRunLoopServiceMachPort() ——> 里面会调用mach_msg()函数 然后会卡在这里,等待接收消息来唤醒RunLoop。直到下面的某个条件被触发才被唤醒:
time_out 超时时间到了
有一个Source事件
timer的时间到了
RunLoop 调用mach_msg()函数去接收消息,如果没有其他 mach_port 发送消息过来,内核就会将线程置于等待状态,直到接收到msg。就好比我们在一个函数中,调用了scanf()函数来接收输入一样,只有收到了输入信息,代码才能继续向下执行,否则会一直卡在那里。
这段代码在AFURLConnectionOperation.m的157到174行
添加一个port监听以达到常驻服务。比如,当我们的程序要提供语音服务的时候,就可以创建一个专门为语音功能服务的线程,当需要语音服务的时候,这个线程就可以来执行。下图是AFNetWorking的进程堆栈
这个问题是有的TableView有大量图片(比如头像)加载,在滑动的时候,请求网络,下载完图片之后设置的时候会卡,往常的解决方案一般是添加delegate之类的,检测什么时候滑动结束什么时候去设置图片
在知道RunLoop之后,可以采用下面的方案,在DefaultMode去做,这样滑动的时候就不会调用设置图片方法
App崩溃的发生分两种情况:
program received signal:SIGABRT SIGABRT 一般是过度release 或者 发送 unrecogized selector导致。
EXC_BAD_ACCESS 是访问已被释放的内存导致,野指针错误。
由 SIGABRT 引起的Crash 是系统发这个signal给App,程序收到这个signal后,就会把主线程的RunLoop杀死,程序就Crash了 该例只针对 SIGABRT引起的Crash有效
接到Crash的Signal后手动重启RunLoop
Runloop就像它的名字一样,就是跑环.我的理解就是一个死循环.是一个可以随时睡眠,随时唤醒的死循环
大家可以想一下,手机app为什么会一直运行?而且在接收到用户点击等等操作时就会有所反映.这个离不开runloop.
iOS app启动时就会启动一个runloop,而且这种模式应该Android也有,所以才会有了app能一直运行
每个线程都有一个runloop,但是只有主线程的runloop是默认开启的,其他子线程需要调用
NSRunLoop *runloop = [NSRunLoop currentRunLoop];获取runloop的同时就会创建runloop
一个线程可以创建多个runloop,但是只能是嵌套模式.也就是一个线程只有一个根runloop
作用
使程序一直运行,并且接收用户输入等事件决定程序什么时候处理什么事件
调用方面 解耦(比如用户划一下屏幕,会产生N个event事件,但是用户不可能等着被调方全部执行完再进行下一步的动作,也就是会将此系列事件扔到一个消息队列里,每次再从消息队列里面取,主调方与被调方实现解耦)
节省CPU(因为runloop在没事干的时候是休眠状态,只有接收到信号的时候才会唤醒,执行相应的操作)
runloop是由事件驱动的
这里区分下命令式驱动跟事件驱动
命令式驱动
event驱动(伪代码)
与CFRunloop相关的有GCD,mach kernel是苹果内核的东西,还有block,pthread等
与咱们平时敲代码比较近一层有以下这些
NSTimer 计时器完全依赖于runloop
UIEvent 事件的产生到分发给代码都是通过runloop
Autorelease 自动释放也是在runloop跑完一圈后
NSObject(NSDelayedPerforming) performSelector,cancel
NSObject(NSThreadPerformAddition) performSelectorOnMainThread,performSelectorOnBackgroundThread
CA层的CADisplayLink(每画一帧会有一个回调),CATransition,CAAnimation
dispatch_get_main_queue()
NSURLConnection
AFNetworking,它的delegate跟网络传输数据都是在它的runloop里面执行的
NSPort 描述通讯信道的抽象类
等等..
如图所示:APP启动,start-->main.m进入-->Graphics Services(处理硬件交互的服务,比如用户点击屏幕)-->RunLoop(CFRunLoop开头的)-->Handle event
在runloop中定义了以下6种函数
然后开始调用event
RunLoop机制
RunLoop跟Thread是一一绑定的(也就是之前说的一个Thread里只有一个根runloop但是可以嵌套N个)
CFRunLoopMode:RunLoop必须在系统定义的几种模式下运行
下边几种是在RunLoopMode里面的
比较抽象,继续往下走
CFRunLoopTimer包括以下几种常见方法的封装
CFRunLoopSource
source是RunLoop的数据源(输入源)的抽象类(protocol)RunLoop定义了两个version的Source:
1.source0:处理App内部事件,App自己负责管理(出发),如UIEvent、CFSocket
2.source1:由RunLoop和内核管理,Mach Port(进程间通讯端口)驱动,如CFMachPort、CFMessagePort
如果有需要,可从中选择一种实现自己的source(基本不会发生)
CFRunLoopObserver:告知外界当前状态
RunLoopObserver与Autorelease Pool
大家面试的时候可以问问面试者这个问题,autorelease的对象到底在什么时候释放?根据孙源大神测试,AutoreleasePool通常在RunLoop两次Sleep之间释放
CFRunLoopMode
RunLoop在同一时间只能且必须在一种特定的Mode下Run更换Mode时,需要停止当前RunLoop,然后重启新的RunLoop
Mode是iOS App流畅滑动的关键(因为在滑动时的Mode跟平时运行的Mode是不一样,从而避免干扰)
也可以基于系统的Mode创建自己的Mode(也是基本不会发生的)
系统定义的Mode有以下几种:
CFRunLoopDefaultMode: 这个是默认 Mode,也是空闲状态。主线程通常在这个 Mode 下运行的。
UITrackingRunLoopMode: ScrollView滚动时候的模式。
UIInitializationRunLoopMode: 在刚启动程序时进入的第一个 Mode,私有,启动完成后就不再使用。
GSEventReceiveRunLoopMode: 接受系统事件的内部的Mode,这个Mode由GraphicsServices调用在CFRunLoopRunSpecific前面。通常用不到。
CFRunLoopCommonModes: 这是一个数组,默认包括了第1和第2种模式,可以添加自己的Mode。
UITrackingRunLoopMode与NSTimer
下面的方法Timer被添加到NSDefaultRunLoopMode,在滑动Scrollview的时候系统会切换至UITrackingRunLoopMode,Timer就会暂时停止
RunLoop与dispatch_get_main_queue()
前面有说到GCD跟RunLoop有关系,其实本身GCD跟RunLoop是没有关系的,但是如果把queue填成main_queue就有关系了,关系只在于调起的过程是在RunLoopGCD的主线程就是App的主线程,所以在GCD牵扯的主线程会转交给RunLoop去调起
RunLoop的挂起与唤醒
在App运行时,在Debug栏里按下暂停,会出现以下堆栈这就是RunLoop的睡眠状态,与刚刚说的MachPort有关系,图片里面上边的两个mach_msg会指定一个端口发给内核一个消息,这会儿就是正在等待接收信息的状态,也就是等待唤醒,内核此刻将其挂起(不是传统意义的挂起,还在内存里,其实就是睡眠状态,等个闹钟,或者有人叫醒)
等待到唤醒的过程:(类似于NSNotificationCenter,在收到Post时唤醒进行处理)
指定用于唤醒的mach_port端口调用mach_msg监听唤醒端口,被唤醒前,系统内核将此线程挂起,停留在mach_msg_trap状态
由另一个线程(或另一个进程中的某个线程)向内核发送这个端口的msg后,trap状态被唤醒,RunLoop继续运行
RunLoop迭代执行顺序(伪代码)
time_out 超时时间到了
有一个Source事件
timer的时间到了
RunLoop 调用mach_msg()函数去接收消息,如果没有其他 mach_port 发送消息过来,内核就会将线程置于等待状态,直到接收到msg。就好比我们在一个函数中,调用了scanf()函数来接收输入一样,只有收到了输入信息,代码才能继续向下执行,否则会一直卡在那里。
AFNetworking中RunLoop的创建
这段代码在AFURLConnectionOperation.m的157到174行添加一个port监听以达到常驻服务。比如,当我们的程序要提供语音服务的时候,就可以创建一个专门为语音功能服务的线程,当需要语音服务的时候,这个线程就可以来执行。下图是AFNetWorking的进程堆栈
一个TableView延迟加载图片的新思维
这个问题是有的TableView有大量图片(比如头像)加载,在滑动的时候,请求网络,下载完图片之后设置的时候会卡,往常的解决方案一般是添加delegate之类的,检测什么时候滑动结束什么时候去设置图片在知道RunLoop之后,可以采用下面的方案,在DefaultMode去做,这样滑动的时候就不会调用设置图片方法
让Crash的App回光返照
App崩溃的发生分两种情况:program received signal:SIGABRT SIGABRT 一般是过度release 或者 发送 unrecogized selector导致。
EXC_BAD_ACCESS 是访问已被释放的内存导致,野指针错误。
由 SIGABRT 引起的Crash 是系统发这个signal给App,程序收到这个signal后,就会把主线程的RunLoop杀死,程序就Crash了 该例只针对 SIGABRT引起的Crash有效
相关文章推荐
- iOS开发之 用第三方类库实现ScrollView
- iOS微博授权登录及获取用户数据的方法
- 关于TextView的一个demo
- iOS学习路线图上
- iOS 单例模式范例
- iOS 属性修饰符记录 --不定时更新
- iOS typedef NS_ENUM 与 NSString
- ios程序后台继续运行
- CALyer
- ios拨打电话
- ios开发去掉首位空格
- iOS SDk开发之二
- iOS多线程开发系列之(三)Grand Central Dispatch(GCD)
- IOS开发 应用程序图标数字角标
- 数据存储封装—支持内存和本地缓存
- iOS开发-支付宝
- 【iOS】3D Touch
- iOS内存管理机制解析之MRC手动引用计数机制
- iOS 设置圆角
- 仿iOS底部弹出popUpWindow