博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
iOS开发 AutoreleasePool是什么时候销毁的?
阅读量:6810 次
发布时间:2019-06-26

本文共 4986 字,大约阅读时间需要 16 分钟。

在面试中经常会遇到面试官问这样的问题。 AutoreleasePool是什么时候销毁的? 这个问题能回答上来的话,肯定要对AutoreleasePool和RunLoop有所了解才行。

AutoreleasePool是在什么时候创建的,又是在什么时候被销毁? 这里我们再简单的回顾一下AutoreleasePool的作用。 AutoreleasePool被称为自动释放池,在释放池中的调用了autorelease方法的对象都会被压在该池的顶部(以栈的形式管理对象)。当自动释放池被销毁的时候,在该池中的对象会自动调用release方法来释放资源,销毁对象。以此来达到自动管理内存的目的。 其实我们在开发中很少主动去创建AutoreleasePool对象,这是为什么呢?不是说用它来自动管理内存吗?其实系统在运行的时候就帮我们创建了AutoreleasePool对象,只是我们不知道而已。那么它是在什么时候被创建的呢?来看看官方源码:

CFRunLoop {    current mode = kCFRunLoopDefaultMode    common modes = {        UITrackingRunLoopMode        kCFRunLoopDefaultMode }    common mode items = {        // source0 (manual)        CFRunLoopSource {order =-1, {            callout = _UIApplicationHandleEventQueue}}        CFRunLoopSource {order =-1, {            callout = PurpleEventSignalCallback }}        CFRunLoopSource {order = 0, {            callout = FBSSerialQueueRunLoopSourceHandler}}        // source1 (mach port)        CFRunLoopSource {order = 0,  {port = 17923}}        CFRunLoopSource {order = 0,  {port = 12039}}        CFRunLoopSource {order = 0,  {port = 16647}}        CFRunLoopSource {order =-1, {            callout = PurpleEventCallback}}        CFRunLoopSource {order = 0, {port = 2407,            callout = _ZL20notify_port_callbackP12__CFMachPortPvlS1_}}        CFRunLoopSource {order = 0, {port = 1c03,            callout = __IOHIDEventSystemClientAvailabilityCallback}}        CFRunLoopSource {order = 0, {port = 1b03,            callout = __IOHIDEventSystemClientQueueCallback}}        CFRunLoopSource {order = 1, {port = 1903,            callout = __IOMIGMachPortPortCallback}}        // Ovserver //注意这里// Entry 进入的时候        CFRunLoopObserver {order = -2147483647, activities = 0x1,             callout = _wrapRunLoopWithAutoreleasePoolHandler}        // BeforeWaiting        CFRunLoopObserver {order = 0, activities = 0x20,                     callout = _UIGestureRecognizerUpdateObserver}       // BeforeWaiting | Exit        CFRunLoopObserver {order = 1999000, activities = 0xa0,              callout = _afterCACommitHandler}      // BeforeWaiting | Exit        CFRunLoopObserver {order = 2000000, activities = 0xa0,                callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}       // BeforeWaiting | Exit        //注意这里 进入休眠或者退出 优先级别最低,       //在保证其释放池子发生在其他所有回调之后        CFRunLoopObserver {order = 2147483647, activities = 0xa0,             callout = _wrapRunLoopWithAutoreleasePoolHandler}        // Timer        CFRunLoopTimer {firing = No, interval = 3.1536e+09, tolerance = 0,            next fire date = 453098071 (-4421.76019 @ 96223387169499),            callout = _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv (QuartzCore.framework)}    },    modes = {        CFRunLoopMode {            sources0 =  { /* same as 'common mode items' */ },            sources1 =  { /* same as 'common mode items' */ },            observers = { /* same as 'common mode items' */ },            timers =    { /* same as 'common mode items' */ },        },        CFRunLoopMode {            sources0 =  { /* same as 'common mode items' */ },            sources1 =  { /* same as 'common mode items' */ },            observers = { /* same as 'common mode items' */ },            timers =    { /* same as 'common mode items' */ },        },        CFRunLoopMode {            sources0 = {                CFRunLoopSource {order = 0, {                    callout = FBSSerialQueueRunLoopSourceHandler}}            },            sources1 = (null),            observers = {                CFRunLoopObserver >{activities = 0xa0, order = 2000000,                    callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}            )},            timers = (null),        },        CFRunLoopMode {            sources0 = {                CFRunLoopSource {order = -1, {                    callout = PurpleEventSignalCallback}}            },            sources1 = {                CFRunLoopSource {order = -1, {                    callout = PurpleEventCallback}}            },            observers = (null),            timers = (null),        },                CFRunLoopMode {            sources0 = (null),            sources1 = (null),            observers = (null),            timers = (null),        }    }}复制代码

App启动后,系统在主线程RunLoop 里注册两个Observser,其回调都是_wrapRunLoopWithAutoreleasePoolHandler()。

第一个 Observer 监视的事件 是 Entry(即将进入Loop),其回调内会调用 _objc_autoreleasePoolPush() 创建自动释放池。其优先级最高,保证创建释放池发生在其他所有回调之前。

第二个 Observer 监视了两个事件

  • _BeforeWaiting(准备进入休眠) 时 _ 调用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 释放旧的池并创建新池;

  • _Exit(即将退出Loop) 时 _ 调用 _objc_autoreleasePoolPop() 来释放自动释放池。这个 Observer 优先级最低,保证其释放池子发生在其他所有回调之后。

在主线程执行的代码,通常是写在诸如事件回调、Timer回调内的。这些回调会被 RunLoop 创建好的 AutoreleasePool 环绕着,所以不会出现内存泄漏,开发者也不必显示创建 Pool 了。

现在我们知道了AutoreleasePool是在RunLoop即将进入RunLoop和准备进入休眠这两种状态的时候被创建和销毁的。

所以AutoreleasePool的释放有如下两种情况。 一是Autorelease对象是在当前的runloop迭代结束时释放的,而它能够释放的原因是系统在每个runloop迭代中都加入了自动释放池Push和Pop。 二是手动调用AutoreleasePool的释放方法(drain方法)来销毁AutoreleasePool

转载地址:http://rmqwl.baihongyu.com/

你可能感兴趣的文章
Context 使用不当造成内存泄露
查看>>
C#双缓冲机制
查看>>
12.17 Nginx负载均衡;12.18 ssl原理;12.19 生产ssl密钥对;12.20 N
查看>>
P2P概览与原理解析
查看>>
zabbix监控端口状态
查看>>
php检测函数是否存在函数 function_exists
查看>>
登陆界面上下左右居中自适应屏幕显示的简单实现
查看>>
【解决】Windows Mobile 6 Professional SDK Refresh.msi 在xp上一直卡死
查看>>
RH124 Chapter 2 Managing Files From the Command Line
查看>>
内核里面writel(readl)是如何实现的
查看>>
python--multiprocessing多进程总结
查看>>
tomcat lb cluster
查看>>
小米2系列板砖自救行动
查看>>
登录亿邮网关windows脚本
查看>>
UML 类图
查看>>
研究:窗口映射
查看>>
假回溯-uva140带宽
查看>>
JAVA调用shell脚本利用ansible修改多节点上的redis参数
查看>>
时间复杂度问题
查看>>
工作一年 离职
查看>>