ARC下强制retain

迁移老文章到掘金

引子

主要是由于上一篇文章callselector引起的

如果断点调试&＃xff0c;整个call_selector的过程完全走完都不会有事&＃xff0c;但是一旦放开断点&＃xff0c;彻底走完就崩溃。 为啥呢&＃xff1f;因为在使用invocation的时候 invoke的过程中&＃xff0c;如果对象在invoke内被创建初始化了&＃xff0c;invoke结束后&＃xff0c;在下一个autorelease的时间点就会产生zombie的crash&＃xff0c;send release to a dealloc object

为什么会这样&＃xff0c;简单的说下我的理解不细说吧&＃xff0c;invoke和直接函数调用不太一样&＃xff0c;如果发生了alloc对象&＃xff0c;那么这个对象系统会额外多一次autorelease&＃xff0c;所以&＃xff0c;不会立刻崩溃&＃xff0c;但当autoreleasepool释放的时候&＃xff0c;就会发生过度release。

invoke函数会导致ARC下额外的一次autoRelease&＃xff0c;所以在自动释放池释放后就会多一次release&＃xff0c;导致zombie

有点挫的解决办法

就是我在上一篇callselector提到的

因为多了个release&＃xff0c;那我再arc下不能强制retain&＃xff0c;那我就add到一个字典里&＃xff0c;让他被arc retain一下

于是问题是解决了&＃xff0c;但是也产生了一个一直存在的static字典&＃xff0c;并且这个字典里&＃xff0c;这个key所对应的数据已经野指针&＃xff0c;千万不能操作&＃xff0c;一旦操作就野指针crash&＃xff0c;你对字典进行removeall&＃xff0c;也会野指针crash

威武的思路

&＃64;无边的翅膀 在我的简书下留言

针对这个&＃xff0c;我想给出一个建议。在ARC下修改一个对象的引用计数&＃xff0c;可以使用CoreFoundation框架的API&＃xff0c;CFRetain和 CFRelease 函数

这个思路靠谱啊&＃xff0c;于是动手试验

const void* cfobj &＃61; CFBridgingRetain(obj);
CFRetain(cfobj);
CFBridgingRelease(cfobj);


• 将对象的内存管理控制移交给CF
• CFRetain
• 将对象的内存管理移交回ARC&＃xff08;让使用者无感知&＃xff09;

我其实对CF这块并不是很熟悉。初步跑通了一下&＃xff0c;感觉没啥问题

然后&＃64;无边的翅膀 给出了修改意见

不需要这么复杂&＃xff0c;一行代码就好&＃xff0c;CFRetain((__bridge CFTypeRef)(obj));

简直太赞了&＃xff01;

ARC下的MRC

如果实在迫不得已一定得在ARC下进行MRC操作的话。。无论是release&＃xff0c;retain这样也可以有办法了&＃xff0c;但是

慎用啊