ARC:如何在对象中注入自定义dealloc IMP,后者又调用原始dealloc而不会导致malloc错误

Sal*_*rtz 8 cocoa cocoa-touch objective-c ios

我正在尝试执行以下操作:

  1. 得到一个类'dealloc IMP
  2. 向所述类注入一个自定义IMP,它基本上称为原始dealloc IMP
  3. 当所述类的实例被释放时,两个IMP都应该运行.

这是我的尝试:

@implementation ClassB

- (void)dealloc
{
    NSLog(@"\n%@ | %@", self, NSStringFromSelector(_cmd));
}

@end


@implementation ClassC

- (void)swizzleMe:(id)target
{
    SEL originalDeallocSelector = NSSelectorFromString(@"dealloc");
    __block IMP callerDealloc = [target methodForSelector:originalDeallocSelector];
    const char *deallocMethodTypeEncoding = method_getTypeEncoding(class_getInstanceMethod([target class], originalDeallocSelector));
    IMP newCallerDealloc = imp_implementationWithBlock(^(id _caller) {
        NSLog(@"\n new dealloc | calling block %p for %@", callerDealloc, _caller);
        callerDealloc(_caller, originalDeallocSelector);
    });

    NSLog(@"\nswapping %p for %p", newCallerDealloc, callerDealloc);

    class_replaceMethod([target class],
                        originalDeallocSelector,
                        newCallerDealloc,
                        deallocMethodTypeEncoding);

}

@end
Run Code Online (Sandbox Code Playgroud)

要像这样使用:

ClassB *b = [[ClassB alloc] init];
ClassC *c = [[ClassC alloc] init];
[c swizzleMe:b];
Run Code Online (Sandbox Code Playgroud)

但结果是:

禁用僵尸对象:

2013-07-03 13:24:58.368 runtimeTest[38626:11303] 
swapping 0x96df020 for 0x2840
2013-07-03 13:24:58.369 runtimeTest[38626:11303] 
 new dealloc | calling block 0x2840 for <ClassB: 0x93282f0>
2013-07-03 13:24:58.370 runtimeTest[38626:11303] 
<ClassB: 0x93282f0> | dealloc
2013-07-03 13:24:58.370 runtimeTest[38626:11303] 
 new dealloc | calling block 0x2840 for <ClassB: 0x93282f0>
2013-07-03 13:24:58.371 runtimeTest[38626:11303] 
<ClassB: 0x93282f0> | dealloc
runtimeTest(38626,0xac55f2c0) malloc: *** error for object 0x93282f0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
2013-07-03 13:24:58.371 runtimeTest[38626:11303] 
 new dealloc | calling block 0x2840 for <ClassB: 0x93282f0>
2013-07-03 13:24:58.372 runtimeTest[38626:11303] 
<ClassB: 0x93282f0> | dealloc
Run Code Online (Sandbox Code Playgroud)

启用僵尸对象(第11行是图片中的EXC_BAD_ACCESS)

2013-07-03 13:34:37.466 runtimeTest[38723:11303] 
swapping 0x97df020 for 0x2840
2013-07-03 13:34:37.467 runtimeTest[38723:11303] 
 new dealloc | calling block 0x2840 for <ClassB: 0x715a920>
2013-07-03 13:34:37.468 runtimeTest[38723:11303] 
<ClassB: 0x715a920> | dealloc
Run Code Online (Sandbox Code Playgroud)

关于我做错了什么的任何想法?

第11行是EXC_BAD_ACCESS

bbu*_*bum 9

如果您真的想知道何时取消分配对象,则使用关联对象.

具体而言,将对象与要观察的对象相关联,使得被观察的对象具有唯一的强引用 - 唯一保留引用 - 对象.然后,您可以覆盖dealloc并知道在调用它时,被观察的对象已经(或者即将被)释放.

不要乱解被解除分配的对象,尽管!! 它已经dealloc调用了所有方法(通过继承),因此内部状态将完全未定义.

请注意,如果您的目标是尝试清理系统框架中的某些内容,那么......不要.沿着这条路走下去并不是不稳定和痛苦.


就像我在对nielsbot的评论中提到的那样,我并不想知道对象何时被释放.

了解注入的dealloc实现中的确切内容将会很有帮助.从表面上看,我能想到的唯一原因是无法通过使用相关对象来检测解除分配,这正是因为你试图改变一个类的行为dealloc,这是一件非常糟糕的事情. .

  • 这不仅仅是知道对象何时被释放有用 - 你还可以添加在`dealloc`时间运行的代码. (3认同)

Sal*_*rtz 2

一段时间后我终于找到了问题的真正原因:我忽略了IMP类型的签名。来自 Apple 的 Objective-C 运行时参考:

IMP 指向方法实现开始的指针。

id (*IMP)(id, SEL, ...)

特别是,IMP 有一个返回类型 id,因此在 ARCLandia ARC 中尝试管理此 id,从而导致崩溃objc_retain。因此,假设您有一个 IMP to -dealloc,显式地将其转换为具有返回类型的 C 函数指针,void使得 ARC 不再尝试管理返回值:

void (*deallocImp)(id, SEL) = (void(*)(id, SEL))_originalDeallocIMP;
deallocImp(self,NSSelectorFromString(@"dealloc"));
Run Code Online (Sandbox Code Playgroud)

  • 是的,正确的解决方案是**根本不注入代码**。以这种方式混合方法和注入行为是非常脆弱的。您正在创建一个系统,使其保持*工作*状态将要求您注入代码的所有类继续按现在的方式工作;这些类中的任何一个转向某种回收模型或共享某些配置的实例(la NSNumber)都会破坏您的代码。(别误会我的意思——这是一个出色的黑客……它只是在生产环境中带来了巨大的维护风险。去过那里。完成了。哎哟。) (4认同)