ios 在 Objective-C 中方法 Swizzling 的危险是什么？

What are the Dangers of Method Swizzling in Objective-C?

提问by Robert

I have heard people state that method swizzling is a dangerous practice. Even the name swizzling suggests that it is a bit of a cheat.

我听说有人说方法调配是一种危险的做法。甚至名称 swizzling 也表明它有点作弊。

Method Swizzlingis modifying the mapping so that calling selector A will actually invoke implementation B. One use of this is to extend behavior of closed source classes.

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

Can we formalise the risks so that anyone who is deciding whether to use swizzling can make an informed decision whether it is worth it for what they are trying to do.

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

E.g.

例如

• Naming Collisions: If the class later extends its functionality to include the method name that you have added, it will cause a huge manner of problems. Reduce the risk by sensibly naming swizzled methods.

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

回答by wbyoung

I think this is a really great question, and it's a shame that rather than tackling the real question, most answers have skirted the issue and simply said not to use swizzling.

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

Using method sizzling is like using sharp knives in the kitchen. Some people are scared of sharp knives because they think they'll cut themselves badly, but the truth is that sharp knives are safer.

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

Method swizzling can be used to write better, more efficient, more maintainable code. It can also be abused and lead to horrible bugs.

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

Background

背景

As with all design patterns, if we are fully aware of the consequences of the pattern, we are able to make more informed decisions about whether or not to use it. Singletons are a good example of something that's pretty controversial, and for good reason — they're really hard to implement properly. Many people still choose to use singletons, though. The same can be said about swizzling. You should form your own opinion once you fully understand both the good and the bad.

与所有设计模式一样，如果我们完全了解该模式的后果，我们就能够就是否使用它做出更明智的决定。单例是一个很好的例子，它非常有争议，并且有充分的理由 - 它们真的很难正确实现。尽管如此，许多人仍然选择使用单例。关于 swizzling 也是如此。一旦你完全理解了好与坏，你就应该形成自己的观点。

Discussion

讨论

Here are some of the pitfalls of method swizzling:

以下是方法 swizzling 的一些陷阱：

• Method swizzling is not atomic
• Changes behavior of un-owned code
• Possible naming conflicts
• Swizzling changes the method's arguments
• The order of swizzles matters
• Difficult to understand (looks recursive)
• Difficult to debug

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

These points are all valid, and in addressing them we can improve both our understanding of method swizzling as well as the methodology used to achieve the result. I'll take each one at a time.

这些观点都是有效的，通过解决它们，我们可以提高我们对方法调配以及用于实现结果的方法的理解。我会一个一个地拿走。

Method swizzling is not atomic

方法调配不是原子的

I have yet to see an implementation of method swizzling that is safe to use concurrently¹. This is actually not a problem in 95% of cases that you'd want to use method swizzling. Usually, you simply want to replace the implementation of a method, and you want that implementation to be used for the entire lifetime of your program. This means that you should do your method swizzling in +(void)load. The loadclass method is executed serially at the start of your application. You won't have any issues with concurrency if you do your swizzling here. If you were to swizzle in +(void)initialize, however, you could end up with a race condition in your swizzling implementation and the runtime could end up in a weird state.

我还没有看到可以安全地同时使用的方法 swizzling 的实现¹。在 95% 的情况下，这实际上不是问题，您希望使用方法 swizzling。通常，您只想替换方法的实现，并且希望该实现在程序的整个生命周期中使用。这意味着您应该在+(void)load. 将load在您的应用程序的启动串行执行类方法。如果您在这里进行 swizzling，您将不会遇到任何并发问题。+(void)initialize然而，如果你在 swizzle 中，你可能会在你的 swizzling 实现中遇到竞争条件，并且运行时可能会以一种奇怪的状态结束。

Changes behavior of un-owned code

改变非拥有代码的行为

This is an issue with swizzling, but it's kind of the whole point. The goal is to be able to change that code. The reason that people point this out as being a big deal is because you're not just changing things for the one instance of NSButtonthat you want to change things for, but instead for all NSButtoninstances in your application. For this reason, you should be cautious when you swizzle, but you don't need to avoid it altogether.

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

Think of it this way... if you override a method in a class and you don't call the super class method, you may cause problems to arise. In most cases, the super class is expecting that method to be called (unless documented otherwise). If you apply this same thought to swizzling, you've covered most issues. Always call the original implementation. If you don't, you're probably changing too much to be safe.

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

Possible naming conflicts

可能的命名冲突

Naming conflicts are an issue all throughout Cocoa. We frequently prefix class names and method names in categories. Unfortunately, naming conflicts are a plague in our language. In the case of swizzling, though, they don't have to be. We just need to change the way that we think about method swizzling slightly. Most swizzling is done like this:

命名冲突是整个 Cocoa 的一个问题。我们经常在类别中添加类名和方法名的前缀。不幸的是，命名冲突在我们的语言中是一种瘟疫。但是，在 swizzling 的情况下，它们不一定是。我们只需要改变我们思考方法略有交叉混合的方式。大多数 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

This works just fine, but what would happen if my_setFrame:was defined somewhere else? This problem isn't unique to swizzling, but we can work around it anyway. The workaround has an added benefit of addressing other pitfalls as well. Here's what we do instead:

这工作得很好，但是如果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

While this looks a little less like Objective-C (since it's using function pointers), it avoids any naming conflicts. In principle, it's doing the exact same thing as standard swizzling. This may be a bit of a change for people who have been using swizzling as it has been defined for a while, but in the end, I think that it's better. The swizzling method is defined thusly:

虽然这看起来有点不像 Objective-C（因为它使用函数指针），但它避免了任何命名冲突。原则上，它和标准的 swizzling 做的事情完全一样。对于已经使用 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

Swizzling by renaming methods changes the method's arguments

通过重命名方法进行 Swizzling 会更改方法的参数

This is the big one in my mind. This is the reason that standard method swizzling should not be done. You are changing the arguments passed to the original method's implementation. This is where it happens:

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

[self my_setFrame:frame];

What this line does is:

这条线的作用是：

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

Which will use the runtime to look up the implementation of my_setFrame:. Once the implementation is found, it invokes the implementation with the same arguments that were given. The implementation it finds is the original implementation of setFrame:, so it goes ahead and calls that, but the _cmdargument isn't setFrame:like it should be. It's now my_setFrame:. The original implementation is being called with an argument it never expected it would receive. This is no good.

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

There's a simple solution — use the alternative swizzling technique defined above. The arguments will remain unchanged!

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

The order of swizzles matters

调酒的顺序很重要

The order in which methods get swizzled matters. Assuming setFrame:is only defined on NSView, imagine this order of things:

方法被混淆的顺序很重要。假设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:)];

What happens when the method on NSButtonis swizzled? Well most swizzling will ensure that it's not replacing the implementation of setFrame:for all views, so it will pull upthe instance method. This will use the existing implementation to re-define setFrame:in the NSButtonclass so that exchanging implementations doesn't affect all views. The existing implementation is the one defined on NSView. The same thing will happen when swizzling on NSControl(again using the NSViewimplementation).

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

When you call setFrame:on a button, it will therefore call your swizzled method, and then jump straight to the setFrame:method originally defined on NSView. The NSControland NSViewswizzled implementations will not be called.

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

But what if the order were:

但是如果订单是：

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

Since the view swizzling takes place first, the control swizzling will be able to pull upthe right method. Likewise, since the control swizzling was before the button swizzling, the button will pull upthe control's swizzled implementation of setFrame:. This is a bit confusing, but this is the correct order. How can we ensure this order of things?

由于视图混写首先发生，控制混写就能拉起正确的方法。同样，由于控件 swizzling 在按钮 swizzling 之前，按钮将拉起控件的 swizzled 实现setFrame:。这有点令人困惑，但这是正确的顺序。我们怎样才能保证这个顺序呢？

Again, just use loadto swizzle things. If you swizzle in loadand you only make changes to the class being loaded, you'll be safe. The loadmethod guarantees that the super class load method will be called before any subclasses. We'll get the exact right order!

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

Difficult to understand (looks recursive)

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

Looking at a traditionally defined swizzled method, I think it's really hard to tell what's going on. But looking at the alternative way we've done swizzling above, it's pretty easy to understand. This one's already been solved!

看看传统定义的 swizzled 方法，我认为很难说清楚发生了什么。但是看看我们在上面完成 swizzling 的另一种方式，它很容易理解。这个已经解决了！

Difficult to debug

调试困难

One of the confusions during debugging is seeing a strange backtrace where the swizzled names are mixed up and everything gets jumbled in your head. Again, the alternative implementation addresses this. You'll see clearly named functions in backtraces. Still, swizzling can be difficult to debug because it's hard to remember what impact the swizzling is having. Document your code well (even if you think you're the only one who will ever see it). Follow good practices, and you'll be alright. It's not harder to debug than multi-threaded code.

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

Conclusion

结论

Method swizzling is safe if used properly. A simple safety measure you can take is to only swizzle in load. Like many things in programming, it can be dangerous, but understanding the consequences will allow you use it properly.

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

---

---

¹Using the above defined swizzling method, you could make things thread safe if you were to use trampolines. You would need two trampolines. At the start of the method, you would have to assign the function pointer, store, to a function that spun until the address to which storepointed to changed. This would avoid any race condition in which the swizzled method was called before you were able to set the storefunction pointer. You would then need to use a trampoline in the case where the implementation isn't already defined in the class and have the trampoline lookup and call the super class method properly. Defining the method so it dynamically looks up the super implementation will ensure that the order of swizzling calls does not matter.

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

回答by Robert

First I will define exactly what I mean by method swizzling:

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

• Re-routing all calls that were originally sent to a method (called A) to a new method (called B).
• We own Method B
• We dont own method A
• Method B does some work then calls method A.

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

Method swizzling is more general than this, but this is the case I am interested in.

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

Dangers:

危险：

• Changes in the original class. We dont own the class that we are swizzling. If the class changes our swizzle may stop working.

• Hard to maintain. Not only have you got to write and maintain the swizzled method. you have to write and maintain the code that preforms the swizzle

• Hard to debug. It is hard to follow the flow of a swizzle, some people may not even realise the swizzle has been preformed. If there are bugs introduced from the swizzle (perhaps dues to changes in the original class) they will be hard to resolve.

• 原有类的变化。我们不拥有我们正在调配的班级。如果类发生变化，我们的 swizzle 可能会停止工作。

• 难以维护。您不仅要编写和维护 swizzled 方法。您必须编写和维护执行 swizzle 的代码

• 很难调试。很难跟随 swizzle 的流程，有些人甚至可能没有意识到 swizzle 已经预先形成。如果有从 swizzle 引入的错误（可能是由于原始类的变化），它们将很难解决。

In summary, you should keep swizzling to a minimum and consider how changes in the original class might effect your swizzle. Also you should clearly comment and document what you are doing (or just avoid it entirely).

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

回答by Caleb

It's not the swizzling itself that's really dangerous. The problem is, as you say, that it's often used to modify the behavior of framework classes. It's assuming that you know something about how those private classes work that's "dangerous." Even if your modifications work today, there's always a chance that Apple will change the class in the future and cause your modification to break. Also, if many different apps do it, it makes it that much harder for Apple to change the framework without breaking a lot of existing software.

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

回答by Arafangion

Used carefully and wisely, it can lead to elegant code, but usually, it just leads to confusing code.

谨慎和明智地使用它可以产生优雅的代码，但通常，它只会导致代码混乱。

I say that it should be banned, unless you happen to know that it presents a very elegant opportunity for a particular design task, but you need to clearly know why it applies well to the situation, and why alternatives do not work elegantly for the situation.

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

Eg, one good application of method swizzling is isa swizzling, which is how ObjC implements Key Value Observing.

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

A bad example might be relying on method swizzling as a means of extending your classes, which leads to extremely high coupling.

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

回答by user3288724

Although I have used this technique, I would like to point out that:

虽然我已经使用了这种技术，但我想指出：

• It obfuscates your code because it can cause un-documented, though desired, side effects. When one reads the code he/she may be unaware of the side effect behavior that is required unless he/she remembers to search the code base to see if it has been swizzled. I'm not sure how to alleviate this problem because it is not always possible to document every place where the code is dependent upon the side effect swizzled behavior.
• It can make your code less reusable because someone who finds a segment of code which depends upon the swizzled behavior that they would like to use elsewhere cannot simply cut and paste it into some other code base without also finding and copying the swizzled method.

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

回答by quantumpotato

You may end up with odd looking code like

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

- (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];

from actual production code related to some UI magic.

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

回答by A.R.

I feel that the biggest danger is in creating many unwanted side effects, completely by accident. These side effects may present themselves as 'bugs' which in turn lead you down the wrong path to find the solution. In my experience, the danger is illegible, confusing, and frustrating code. Kind of like when someone overuses function pointers in C++.

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

回答by user3288724

Method swizzling can be very helpful is in unit testing.

Method swizzling 在单元测试中非常有用。

It allows you to write a mock object and have that mock object used instead of the real object. Your code to remain clean and your unit test has predictable behavior. Let's say you want to test some code that uses CLLocationManager. Your unit test could swizzle startUpdatingLocation so that it would feed a predetermined set of locations to your delegate and your code would not have to change.

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