关于 Method Swizzing方法
?
在沒有一個類的實現源碼的情況下，想改變其中一個方法的實現，除了繼承它重寫、和借助類別重名方法暴力搶先之外，還有更加靈活的方法嗎？在Objective-C編程中，如何實現hook呢？標題有點大，計劃分幾篇來總結。
本文主要介紹針對selector的hook，主角被標題劇透了———— Method Swizzling 。
?
?Method Swizzling 原理
?
在Objective-C中調用一個方法，其實是向一個對象發送消息，查找消息的唯一依據是selector的名字。利用Objective-C的動態特性，可以實現在運行時偷換selector對應的方法實現，達到給方法掛鉤的目的。
每個類都有一個方法列表，存放著selector的名字和方法實現的映射關系。IMP有點類似函數指針，指向具體的Method實現。
?
我們可以利用 method_exchangeImplementations 來交換2個方法中的IMP，
我們可以利用 class_replaceMethod 來修改類，
我們可以利用 method_setImplementation 來直接設置某個方法的IMP，
……
歸根結底，都是偷換了selector的IMP，如下圖所示：
Method Swizzling 實踐
舉個例子好了，我想鉤一下NSArray的lastObject 方法，只需兩個步驟。
第一步：給NSArray加一個我自己的lastObject
乍一看，這不遞歸了么？別忘記這是我們準備調換IMP的selector，[self myLastObject] 將會執行真的 [self lastObject] 。
第二步：調換IMP
控制臺輸出Log：
結果很讓人欣喜，是不是忍不住想給UIWebView的loadRequest: 加 TODO 了呢？?
Method Swizzling 的封裝
之前在github上找到的RNSwizzle，推薦給大家，可以搜一下。
Method Swizzling 危險不危險
針對這個問題，我在stackoverflow上看到了滿意的答案，這里翻譯一下，總結記錄在本文中，以示分享：
使用 Method Swizzling 編程就好比切菜時使用鋒利的刀，一些人因為擔心切到自己所以害怕鋒利的刀具，可是事實上，使用鈍刀往往更容易出事，而利刀更為安全。
Method swizzling 可以幫助我們寫出更好的，更高效的，易維護的代碼。但是如果濫用它，也將會導致難以排查的bug。?
背景
好比設計模式，如果我們摸清了一個模式的門道，使用該模式與否我們自己心里有數。單例模式就是一個很好的例子，它飽受爭議但是許多人依舊使用它。Method Swizzling也是一樣，一旦你真正理解它的優勢和弊端，使用它與否你應該就有你自己的觀點。
討論
這里是一些 Method 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
我將逐一分析這些點，增進對Method Swizzling的理解的同時，并搞懂如何應對。
Method swizzling is not atomic
我所見過的使用method swizzling實現的方法在并發使用時基本都是安全的。95%的情況里這都不會是個問題。通常你替換一個方法的實現，是希望它在整個程序的生命周期里有效的。也就是說，你會把 method swizzling 修改方法實現的操作放在一個加號方法 +(void)load里，并在應用程序的一開始就調用執行。你將不會碰到并發問題。假如你在 +(void)initialize初始化方法中進行swizzle，那么……rumtime可能死于一個詭異的狀態。
Changes behavior of un-owned code
這是swizzling的一個問題。我們的目標是改變某些代碼。swizzling方法是一件灰常灰常重要的事，當你不只是對一個NSButton類的實例進行了修改，而是程序中所有的NSButton實例。因此在swizzling時應該多加小心，但也不用總是去刻意避免。
想象一下，如果你重寫了一個類的方法，而且沒有調用父類的這個方法，這可能會引起問題。大多數情況下，父類方法期望會被調用（至少文檔是這樣說的）。如果你在swizzling實現中也這樣做了，這會避免大部分問題。還是調用原始實現吧，如若不然，你會費很大力氣去考慮代碼的安全問題。
Possible naming conflicts
命名沖突貫穿整個Cocoa的問題. 我們常常在類名和類別方法名前加上前綴。不幸的是，命名沖突仍是個折磨。但是swizzling其實也不必過多考慮這個問題。我們只需要在原始方法命名前做小小的改動來命名就好，比如通常我們這樣命名：
?
這段代碼運行正確，但是如果my_setFrame: 在別處被定義了會發生什么呢？
這個問題不僅僅存在于swizzling，這里有一個替代的變通方法：
看起來不那么Objectice-C了（用了函數指針），這樣避免了selector的命名沖突。?
最后給出一個較完美的swizzle方法的定義：
Swizzling changes the method's arguments
我認為這是最大的問題。想正常調用method swizzling 將會是個問題。
?
直接調用my_setFrame: ， runtime做的是
runtime去尋找my_setFrame:的方法實現, _cmd參數為 my_setFrame: ，但是事實上runtime找到的方法實現是原始的 setFrame: 的。
一個簡單的解決辦法：使用上面介紹的swizzling定義。
The order of swizzles matters
多個swizzle方法的執行順序也需要注意。假設 setFrame: 只定義在NSView中，想像一下按照下面的順序執行：
What happens when the method on NSButton is swizzled? Well most swizzling will ensure that it's not replacing the implementation of setFrame: for all views, so it will pull up the instance method. This will use the existing implementation to re-define setFrame: in the NSButton class 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 NSView implementation).
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 NSControl and NSView swizzled implementations will not be called.
But what if the order were:
Since the view swizzling takes place first, the control swizzling will be able to pull up the right method. Likewise, since the control swizzling was before the button swizzling, the button will pull up the 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?
Again, just use load to swizzle things. If you swizzle in load and you only make changes to the class being loaded, you'll be safe. The load method guarantees that the super class load method will be called before any subclasses. We'll get the exact right order!
這段貼了原文，硬翻譯太拗口……總結一下就是：多個有繼承關系的類的對象swizzle時，從子類對象開始 。 如果先swizzle父類對象，那么后面子類對象swizzle時就無法拿到真正的原始方法實現了。?
?
（感謝評論中?qq373127202?的提醒，在此更正一下，十分感謝）
多個有繼承關系的類的對象swizzle時，先從父對象開始。?這樣才能保證子類方法拿到父類中的被swizzle的實現。在+(void)load中swizzle不會出錯，就是因為load類方法會默認從父類開始調用。
?
?
Difficult to understand (looks recursive)
（新方法的實現）看起來像遞歸，但是看看上面已經給出的 swizzling 封裝方法, 使用起來就很易讀懂.
這個問題是已完全解決的了！
Difficult to debug
debug時打出的backtrace，其中摻雜著被swizzle的方法名，一團糟啊！上面介紹的swizzle方案，使backtrace中打印出的方法名還是很清晰的。但仍然很難去debug，因為很難記住swizzling影響過什么。給你的代碼寫好文檔（即使只有你一個人會看到）。養成一個好習慣，不會比調試多線程問題還難的。
結論
如果使用恰當，Method swizzling 還是很安全的.一個簡單安全的方法是，僅在load中swizzle。 和許多其他東西一樣，它也是有危險性的，但理解它了也就可以正確恰當的使用它了。
轉載于:https://www.cnblogs.com/zhonghuaxiaodangjia/p/4528405.html
總結
以上是生活随笔為你收集整理的关于 Method Swizzing方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android 状态栏、标题栏、屏幕高度
- 下一篇： 十进制转化为m进制（mlt;=16）