ios - Objective-C 中方法混用的危险是什么？

Question

我听说人们说方法混合是一种危险的做法。甚至名称 swizzling 也暗示它有点作弊。

Method Swizzling正在修改映射，以便调用选择器 A 将实际调用实现 B。它的一种用途是扩展封闭源类的行为。

我们能否将风险形式化，以便决定是否使用 swizzling 的任何人都可以做出明智的决定，是否值得他们尝试做的事情。

例如

命名冲突：如果该类后来扩展其功能以包含您添加的方法名称，则会导致大量问题。通过合理命名混合方法来降低风险。

score 447 · Accepted Answer

我认为这是一个非常好的问题，但遗憾的是，大多数答案都没有解决真正的问题，而是绕开了这个问题，只是说不要使用 swizzling。

使用方法咝咝作响就像在厨房里使用锋利的刀。有些人害怕锋利的刀，因为他们认为他们会严重割伤自己，但事实是锋利的刀更安全。

方法调配可用于编写更好、更高效、更可维护的代码。它也可能被滥用并导致可怕的错误。

背景

与所有设计模式一样，如果我们完全了解该模式的后果，我们就能够就是否使用它做出更明智的决定。单例是一个很有争议的例子，并且有充分的理由——它们真的很难正确实现。不过，许多人仍然选择使用单例。关于调酒也可以这样说。一旦你充分了解了好的和坏的，你应该形成自己的意见。

讨论

以下是方法调配的一些陷阱：

方法调配不是原子的
更改未拥有代码的行为
可能的命名冲突
Swizzling 改变方法的参数
调酒的顺序很重要
难以理解（看起来是递归的）
难以调试

这些点都是有效的，在解决它们时，我们可以提高我们对方法混合的理解以及用于实现结果的方法。我会一次接一个。

方法调配不是原子的

我还没有看到可以安全地同时使用的方法调配的实现¹。这实际上在 95% 的情况下都不是问题，您希望使用方法调配。通常，您只是想替换一个方法的实现，并且希望该实现在程序的整个生命周期中都使用。这意味着您应该在+(void)load. load类方法在您的应用程序开始时串行执行。如果您在这里进行调配，您将不会遇到任何并发问题。但是，如果您要混入+(void)initialize.

更改未拥有代码的行为

这是调酒的问题，但它是重点。目标是能够更改该代码。人们指出这很重要的原因是因为您不仅NSButton要更改要更改的单个实例，还要更改NSButton应用程序中的所有实例。出于这个原因，你在调酒时应该小心，但你不需要完全避免它。

这么想……如果你在一个类中重写了一个方法，而你没有调用超类的方法，你可能会导致问题出现。在大多数情况下，超类期望调用该方法（除非另有说明）。如果你将同样的想法应用到 swizzling 上，你已经涵盖了大多数问题。始终调用原始实现。如果你不这样做，你可能会改变太多以保证安全。

可能的命名冲突

命名冲突是整个 Cocoa 中的一个问题。我们经常在类别中添加类名和方法名的前缀。不幸的是，命名冲突是我们语言中的瘟疫。但是，在 swizzling 的情况下，它们不必如此。我们只需要稍微改变一下我们对方法混杂的看法。大多数调酒是这样完成的：

@interface NSView : NSObject
- (void)setFrame:(NSRect)frame;
@end

@implementation NSView (MyViewAdditions)

- (void)my_setFrame:(NSRect)frame {
    // do custom work
    [self my_setFrame:frame];
}

+ (void)load {
    [self swizzle:@selector(setFrame:) with:@selector(my_setFrame:)];
}

@end

这工作得很好，但是如果my_setFrame:在其他地方定义会发生什么？这个问题并不是 swizzling 所独有的，但无论如何我们都可以解决它。该解决方法还具有解决其他陷阱的额外好处。这就是我们所做的：

@implementation NSView (MyViewAdditions)

static void MySetFrame(id self, SEL _cmd, NSRect frame);
static void (*SetFrameIMP)(id self, SEL _cmd, NSRect frame);

static void MySetFrame(id self, SEL _cmd, NSRect frame) {
    // do custom work
    SetFrameIMP(self, _cmd, frame);
}

+ (void)load {
    [self swizzle:@selector(setFrame:) with:(IMP)MySetFrame store:(IMP *)&SetFrameIMP];
}

@end

虽然这看起来不太像 Objective-C（因为它使用函数指针），但它避免了任何命名冲突。原则上，它的作用与标准调酒完全相同。对于一直使用 swizzling 的人来说，这可能有点改变，因为它已经定义了一段时间，但最后，我认为它更好。swizzling 方法是这样定义的：

typedef IMP *IMPPointer;

BOOL class_swizzleMethodAndStore(Class class, SEL original, IMP replacement, IMPPointer store) {
    IMP imp = NULL;
    Method method = class_getInstanceMethod(class, original);
    if (method) {
        const char *type = method_getTypeEncoding(method);
        imp = class_replaceMethod(class, original, replacement, type);
        if (!imp) {
            imp = method_getImplementation(method);
        }
    }
    if (imp && store) { *store = imp; }
    return (imp != NULL);
}

@implementation NSObject (FRRuntimeAdditions)
+ (BOOL)swizzle:(SEL)original with:(IMP)replacement store:(IMPPointer)store {
    return class_swizzleMethodAndStore(self, original, replacement, store);
}
@end

通过重命名方法来改变方法的参数

这是我心目中的大事。这就是不应该进行标准方法混合的原因。您正在更改传递给原始方法实现的参数。这就是它发生的地方：

[self my_setFrame:frame];

这条线的作用是：

objc_msgSend(self, @selector(my_setFrame:), frame);

它将使用运行时来查找my_setFrame:. 一旦找到实现，它就会使用给定的相同参数调用实现。它找到的实现是的原始实现setFrame:，所以它继续调用它，但_cmd参数并不setFrame:像它应该的那样。现在是my_setFrame:。最初的实现是用一个它从未预料到会收到的参数调用的。这不好。

有一个简单的解决方案——使用上面定义的替代混合技术。论据将保持不变！

调酒的顺序很重要

方法混合的顺序很重要。假设setFrame:仅在上定义NSView，想象一下这样的顺序：

[NSButton swizzle:@selector(setFrame:) with:@selector(my_buttonSetFrame:)];
[NSControl swizzle:@selector(setFrame:) with:@selector(my_controlSetFrame:)];
[NSView swizzle:@selector(setFrame:) with:@selector(my_viewSetFrame:)];

当方法 onNSButton被调配时会发生什么？好吧，大多数 swizzling 将确保它不会替换setFrame:所有视图的实现，因此它将拉起实例方法。setFrame:这将使用现有的实现在类中重新定义，NSButton以便交换实现不会影响所有视图。现有的实现是定义在NSView. swizzling NSControl（再次使用NSView实现）时也会发生同样的事情。

当你调用setFrame:一个按钮时，它会调用你的 swizzled 方法，然后直接跳转到setFrame:最初定义的方法NSView。NSControl和swizzled 实现将NSView不会被调用。

但是如果订单是：

[NSView swizzle:@selector(setFrame:) with:@selector(my_viewSetFrame:)];
[NSControl swizzle:@selector(setFrame:) with:@selector(my_controlSetFrame:)];
[NSButton swizzle:@selector(setFrame:) with:@selector(my_buttonSetFrame:)];

由于view swizzling首先发生，control swizzling将能够调出正确的方法。同样，由于控件混合在按钮混合之前，因此按钮将拉起控件的混合实现setFrame:。这有点令人困惑，但这是正确的顺序。我们如何才能确保这种事情的顺序？

再一次，只是load用来调酒。如果您混入load其中并且只对正在加载的类进行更改，那么您将是安全的。该load方法保证超类加载方法将在任何子类之前被调用。我们会得到完全正确的订单！

难以理解（看起来是递归的）

看看传统定义的混合方法，我认为很难说出发生了什么。但是看看我们在上面进行的调动的另一种方式，它很容易理解。这个已经解决了！

难以调试

调试过程中的一个困惑是看到一个奇怪的回溯，其中混杂的名称混合在一起，一切都在你的脑海中变得混乱。同样，替代实现解决了这个问题。您将在回溯中看到明确命名的函数。尽管如此，调酒可能很难调试，因为很难记住调酒有什么影响。好好记录你的代码（即使你认为你是唯一会看到它的人）。遵循良好的做法，你会没事的。调试并不比多线程代码难。

结论

如果使用得当，方法调配是安全的。您可以采取的一个简单的安全措施是仅混入load。就像编程中的许多事情一样，它可能很危险，但了解其后果将使您能够正确使用它。

¹使用上面定义的 swizzling 方法，如果您要使用蹦床，您可以使事情线程安全。你需要两个蹦床。在方法开始时，您必须将函数指针分配store给一个旋转的函数，直到store指向的地址发生变化。这将避免在您能够设置store函数指针之前调用 swizzled 方法的任何竞争条件。然后，您需要在类中尚未定义实现的情况下使用蹦床，并进行蹦床查找并正确调用超类方法。定义方法使其动态查找超级实现将确保调动调用的顺序无关紧要。

score 12 · Accepted Answer

首先，我将准确定义方法混合的含义：

将最初发送到方法（称为 A）的所有调用重新路由到新方法（称为 B）。
我们拥有方法 B
我们不拥有方法 A
方法 B 做了一些工作，然后调用方法 A。

Method swizzling 比这更通用，但这是我感兴趣的情况。

危险：

原有类的变化。我们不拥有我们正在调配的课程。如果班级发生变化，我们的 swizzle 可能会停止工作。
难以维护。您不仅要编写和维护 swizzled 方法。您必须编写和维护执行调酒的代码
很难调试。很难跟随调酒的流程，有些人甚至可能没有意识到调酒已经完成。如果 swizzle 引入了错误（可能是由于原始类的更改），它们将很难解决。

总而言之，您应该将 swizzle 保持在最低限度，并考虑原始类中的更改如何影响您的 swizzle。此外，您应该清楚地评论并记录您在做什么（或完全避免它）。

score 7 · Accepted Answer

真正危险的不是调酒本身。正如您所说，问题在于它通常用于修改框架类的行为。假设您对这些私人课程的工作方式有所了解，这是“危险的”。即使您的修改今天有效，Apple 将来也有可能更改类并导致您的修改中断。此外，如果许多不同的应用程序都这样做，那么 Apple 很难在不破坏大量现有软件的情况下更改框架。

score 5 · Accepted Answer

谨慎而明智地使用它可以带来优雅的代码，但通常只会导致令人困惑的代码。

我说它应该被禁止，除非你碰巧知道它为特定的设计任务提供了一个非常优雅的机会，但是你需要清楚地知道为什么它很好地适用于这种情况，以及为什么替代方案不能很好地适应这种情况.

例如，method swizzling 的一个很好的应用是 isa swizzling，这就是 ObjC 实现 Key Value Observing 的方式。

一个不好的例子可能是依赖方法调配作为扩展类的一种方式，这会导致极高的耦合度。

score 5 · Accepted Answer

尽管我使用了这种技术，但我想指出：

它会混淆您的代码，因为它可能会导致未记录的，但需要的副作用。当一个人阅读代码时，他/她可能不知道所需要的副作用行为，除非他/她记得搜索代码库以查看它是否已被混合。我不确定如何缓解这个问题，因为并不总是可以记录代码依赖于副作用混杂行为的每个地方。
它可以使您的代码的可重用性降低，因为找到一段代码的人取决于他们想在其他地方使用的混合行为，不能简单地将其剪切并粘贴到其他代码库中，而无需找到并复制混合方法。

score 4 · Accepted Answer

我觉得最大的危险是完全意外地产生许多不需要的副作用。这些副作用可能会以“错误”的形式出现，从而导致您走上错误的道路来寻找解决方案。根据我的经验，危险是难以辨认、令人困惑和令人沮丧的代码。有点像有人在 C++ 中过度使用函数指针。

score 4 · Accepted Answer

您最终可能会得到看起来很奇怪的代码，例如

- (void)addSubview:(UIView *)view atIndex:(NSInteger)index {
    //this looks like an infinite loop but we're swizzling so default will get called
    [self addSubview:view atIndex:index];

来自与一些 UI 魔术相关的实际生产代码。

score 3 · Accepted Answer

方法调配在单元测试中非常有用。

它允许您编写一个模拟对象并使用该模拟对象而不是真实对象。您的代码保持干净并且您的单元测试具有可预测的行为。假设您要测试一些使用 CLLocationManager 的代码。您的单元测试可以调动 startUpdatingLocation 以便它将预定的一组位置提供给您的委托，并且您的代码不必更改。