autorelease探究

本文深入探讨了Autorelease机制的工作原理,包括如何通过自动释放池管理内存,以及在不同线程和NSRunLoop环境下 autorelease 的行为。并通过代码示例验证了 autorelease 的实际效果。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

CocoaChina用户casual0402分享了一篇有关Autorelease的博客文章。以下是博客的原文。

 

  有时候我们需要延迟一个对象的引用计数减一操作,比如:且方法内部使用了alloc,需要对因此产生的引用计数负责。

+ (NSArray *)array {     return [[NSArray alloc] init] autorelease]; }
不过如果直接调用release,将会返回野指针,所以我们需要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 thread at the beginning of every cycle of the event loop, and drains 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 of NSAutoreleasePool objects (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 application or if you detach 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;
}
}

内容概要:本文详细介绍了如何使用STM32微控制器精确控制步进电机,涵盖了从原理到代码实现的全过程。首先,解释了步进电机的工作原理,包括定子、转子的构造及其通过脉冲信号控制转动的方式。接着,介绍了STM32的基本原理及其通过GPIO端口输出控制信号,配合驱动器芯片放大信号以驱动电机运转的方法。文中还详细描述了硬件搭建步骤,包括所需硬件的选择与连接方法。随后提供了基础控制代码示例,演示了如何通过定义控制引脚、编写延时函数和控制电机转动函数来实现步进电机的基本控制。最后,探讨了进阶优化技术,如定时器中断控制、S形或梯形加减速曲线、微步控制及DMA传输等,以提升电机运行的平稳性和精度。 适合人群:具有嵌入式系统基础知识,特别是对STM32和步进电机有一定了解的研发人员和技术爱好者。 使用场景及目标:①学习步进电机与STM32的工作原理及二者结合的具体实现方法;②掌握硬件连接技巧,确保各组件间正确通信;③理解并实践基础控制代码,实现步进电机的基本控制;④通过进阶优化技术的应用,提高电机控制性能,实现更精细和平稳的运动控制。 阅读建议:本文不仅提供了详细的理论讲解,还附带了完整的代码示例,建议读者在学习过程中动手实践,结合实际硬件进行调试,以便更好地理解和掌握步进电机的控制原理和技术细节。同时,对于进阶优化部分,可根据自身需求选择性学习,逐步提升对复杂控制系统的理解。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值