autorelease探究

本文深入探讨了Objective-C与Swift在iOS开发领域的应用与对比,包括其语法特点、优缺点及实际项目中的使用场景。通过具体案例分析,揭示了这两种语言在不同情境下的适用性。

有时候我们需要延迟一个对象的引用计数减一操作,比如:

+ (NSArray *)array
{
    return [[NSArray alloc] init] autorelease];
}

由于方法名并不以alloc, new, copy, mutableCopy开头,并且方法内部使用了alloc,需要对因此产生的引用计数负责。

不过如果直接调用release,将会返回野指针,所以我们需要autorelease机制来延迟释放。


我们需要先创建一个autorelease pool,才能有效地实现autorelease机制,否则会导致内存泄露。

当向一个对象obj发送autorelease消息时,会发生如下过程:

  1. 获取当前autorelease pool,即离事件发生处最近的(inner-most)自动释放池,NSAutoreleasePool实例。
  2. NSAutoreleasePool实例将obj添加到内部维护的数组中,记录起来。
  3. 当发送drain消息给自动释放池时,它会遍历内部维护的数组,向每个元素发送一个release消息。


除了我们显式创建的NSAutoreleasePool实例,系统会默认为我们在主线程创建一个:

@autoreleasepool {
    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}

从可见代码来看,这个自动释放池建立在main函数中,对于我们编码过程中创建的自动释放对象有什么帮助呢?

等到结束UIApplicationMain才释放,跟不释放基本没差别,因为程序运行即将结束。

所以,如果事实真相如此,那么是不合理的。


苹果官方文档有这么一段话:

The Application Kit creates an autorelease pool on the main threadat the beginning of every cycle of the event loop, anddrains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.

可见,在主线程中每个event loop开始的时候会创建一个autorelease pool,在循环结束时清空自动释放池。

当然,如果在某个局部地方创建很多临时对象,最好也显式创建autorelease pool降低内存峰值。

用代码来求证:

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    TestObject *testObject = [[[TestObject alloc] init] autorelease];
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    NSLog(@"Touches Ended\n");
    [NSAutoreleasePool showPools];
}

通过在TestObject的release方法中输出日志信息,可以看到testObject是在touchesEnded事件前被释放的,即event loop结束前。


这是对主线程而言,那么对其它线程呢?

下面又有一段说明:

Each thread (including the main thread) maintains its own stack ofNSAutoreleasePoolobjects (see“Threads”). As new pools are created, they get added to the top of the stack. When pools are deallocated, they are removed from the stack. Autoreleased objects are placed into the top autorelease pool for the current thread. When a thread terminates, it automatically drains all of the autorelease pools associated with itself.

从上面这段话可以得知每个线程都维护着与自己对应的NSAutoreleasePool对象,将其放在线程栈的栈顶。当线程结束时,会清空自动释放池。

同样地可以用代码来说明:

[NSThread detachNewThreadSelector:@selector(onNewThread:) toTarget:self withObject:nil];

- (void)onNewThread:(id)info
{
    TestObject *testObject = [[[TestObjectalloc] init] autorelease];
}

通过输出结果也可以得知线程结束时,testObject得到释放。


不过,紧接着的一段说明说明了些例外情况:

If you are making Cocoa calls outside of the Application Kit’s main thread—for example if you create a Foundation-only applicationor if youdetach a thread—you need to create your own autorelease pool.

不过当我detach了多个线程出来,发现每个线程仍然有维护autorelease pool。是不是上面这段话我哪里没理解对?幸好在没有autorelease pool存在时,我们向对象发送autorelease消息会有警告输出。


最后,探讨下NSRunLoop和autorelease的关系。

当我们分离了个线程,并且让runloop跑起来,我们可以发现与主线程类似:每个runloop循环结束时会drain下autorelease pool。

通过观察runloop状态可以验证:

#pragma mark - RunLoop Observer

- (void)onNewThread:(id)info
{
    NSRunLoop *runloop = [NSRunLoop currentRunLoop];
    if (!runloop) {
        return ;
    }
    
    NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:5.0f target:self selector:@selector(onTimerFired:) userInfo:nil repeats:NO];
    [runloop addTimer:timer forMode:NSRunLoopCommonModes];
    
    CFRunLoopObserverContext context = {
        0,
        self,
        NULL,
        NULL,
        NULL
    };
    
    CFRunLoopObserverRef observerRef = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &runloopObserverCallback, &context);
    CFRunLoopAddObserver([runloop getCFRunLoop], observerRef, kCFRunLoopCommonModes);
    
    [runloop run];
    
    CFRunLoopRemoveObserver([runloop getCFRunLoop], observerRef, kCFRunLoopCommonModes);
    CFRelease(observerRef);
}

static void runloopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)
{
    CFRunLoopActivity currentActivity = activity;
    switch (currentActivity) {
        casekCFRunLoopEntry:
            NSLog(@"kCFRunLoopEntry \n");
            break;
            
        casekCFRunLoopBeforeTimers:
            NSLog(@"kCFRunLoopBeforeTimers \n");
            break;
            
        casekCFRunLoopBeforeSources:
            NSLog(@"kCFRunLoopBeforeSources \n");
            break;
            
        casekCFRunLoopBeforeWaiting:
            NSLog(@"kCFRunLoopBeforeWaiting \n");
            break;
            
        casekCFRunLoopAfterWaiting:
            NSLog(@"kCFRunLoopAfterWaiting \n");
            break;
            
        casekCFRunLoopExit:
            NSLog(@"kCFRunLoopExit \n");
            break;
            
        default:
            NSLog(@"Activity not recognized!\n");
            break;
    }
}

--------------------------------------------------

Jason Lee @ Hangzhou

2012.08.15


基于数据驱动的 Koopman 算子的递归神经网络模型线性化,用于纳米定位系统的预测控制研究(Matlab代码实现)内容概要:本文围绕“基于数据驱动的Koopman算子的递归神经网络模型线性化”展开,旨在研究纳米定位系统的预测控制方法。通过结合数据驱动技术与Koopman算子理论,将非线性系统动态近似为高维线性系统,进而利用递归神经网络(RNN)建模并实现系统行为的精确预测。文中详细阐述了模型构建流程、线性化策略及在预测控制中的集成应用,并提供了完整的Matlab代码实现,便于科研人员复现实验、优化算法并拓展至其他精密控制系统。该方法有效提升了纳米级定位系统的控制精度与动态响应性能。; 适合人群:具备自动控制、机器学习或信号处理背景,熟悉Matlab编程,从事精密仪器控制、智能制造或先进控制算法研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①实现非线性动态系统的数据驱动线性化建模;②提升纳米定位平台的轨迹跟踪与预测控制性能;③为高精度控制系统提供可复现的Koopman-RNN融合解决方案; 阅读建议:建议结合Matlab代码逐段理解算法实现细节,重点关注Koopman观测矩阵构造、RNN训练流程与模型预测控制器(MPC)的集成方式,鼓励在实际硬件平台上验证并调整参数以适应具体应用场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值