Runtime是近年來面試遇到的一個高頻方向，也是我們平時開發中或多或少接觸的一個領域，那么什么是runtime呢？它又可以用來做什么呢？
什么是Runtime？平時項目中有用過么？
OC是一門動態性比較強的編程語言，允許很多操作推遲到程序運行時再進行
OC的動態性就是由Runtime來支撐和實現的，Runtime是一套C語言的API，封裝了很多動 態性相關的函數
平時編寫的OC代碼，底層都是轉換成了Runtime API進行調用
具體應用
利用關聯對象（AssociatedObject）給分類添加屬性
遍歷類的所有成員變量（修改textfield的占位文字顏色、字典轉模型、自動歸檔解檔）
交換方法實現（交換系統的方法）
利用消息轉發機制解決方法找不到的異常問題
1、詳解isa
我們在研究對象的本質的時候提到過isa，當時說的是isa是個指針，存儲的是個類對象或者元類對象的地址，實例對象的isa指向類對象，類對象的isa指向元類對象。確實，在arm64架構(真機環境)前，isa單純的就是一個指針，里面存儲着類對象或者元類對象地址，但是arm64架構后，系統對isa指針進行了優化，我們在源碼中可以探其結構：
可以看到，isa是個isa_t類型的數據，我們在點進去看一下isa_t是什么數據：
isa_t是個union結構，里面包含了一個結構體，結構體里面是個宏ISA_BITFIELD，我們看看這個宏是什么？
也就是這個機構體里面包含很多東西，但是究竟是什么東西要根據系統來確定。
那么在arm64架構下，isa指針的真實結構是：
在我們具體分析isa內部各個參數分別代表什么之前，我們需要弄清楚這個union是什么呢？我們看着這個union和結構體的結構很像，這兩者的區別如下↓↓
union：共用體，顧名思義，就是多個成員共用一塊內存。在編譯時會選取成員中長度最長的來聲明。 共用體內存=MAX（各變量） struct：結構體，每個成員都是獨立的一塊內存。 結構的內存=sizeof（各變量之和）+內存對齊
也就是說，union共用體內所有的變量，都用同一塊內存，而struct結構體內的變量是各個變量有各個變量自己的內存，舉例說明：
我們分別定義了一個共用體test1和一個結構體test2，里面都各自有八個char變量，打印出來各自占用內存我們發現共用體只占用了1個內存，而結構體占用了8個內存，
其實結構體占用8個內存很好理解，8個char變量，每個char占用一個，所以是8；而union共用體為什么只占用一個呢？這是因為他們共享同一個內存存儲東西，他們的內存結構是這樣的：
我們看到te就一個內存空間，也就是所有的公用體成員公用一個空間，並且同一時間只能存儲其中一個成員變量的值，這一點我們可以打斷點或打印進行確認：
我們發現，第一次打印的時候，bdf這些值都是1的打印出來都是0，這是因為當te.g = '0'，執行完后，這個內存存儲的是g的值0，所以訪問的時候打印結果都是0。第二次打印同理，te.h執行完內存中存儲的是1，再訪問這塊內存那么得到的結果都會是1。所以我們從這也可以看出，union共用體就是系統分配一個內存供里面的成員共同使用，某一時間只能存儲其中某一個變量的值，這樣做相比結構體而言可以很大程度的節省內存空間。
既然我們已經知道isa_t使用共用體的原因是為了最大限度節省內存空間，那么各個成員后面的數字代表什么呢？這就涉及到了位域.
我們看到union共用體為了節省空間是不斷的進行值覆蓋操作，也就是新值覆蓋舊值，結合位域的話可以更大限度的節約內存空間還不用覆蓋舊值。我們都知道一個字節是8個bit位，所以位域的作用就是將字節這個內存單位縮小為bit位來存儲東西。我們把上面這個union共用體加上位域：
上面這段代碼的意思就是，abcdefgh這八個char變量不再是不停地覆蓋舊值操作了，而是將一個字節分成8個bit位，每個變量一個bit位，按照順序從右到左一次排列。
我們都知道char變量占用一個字節，一個字節有8個bit位，也就是char變量有8位，那么te和te2的內存結構如下所示：
這個結構我們也可以通過打印來驗證：te占用一個字節位置，內存地址對應的值是0xaa，轉換成二進制正好是10101010，也就是a~h存儲的值。
我們可以看到，現在是將一個字節中的8個bit位分別讓給8個char變量存儲數據，所以這些char變量存儲的數據不是0就是1，可以看出來這種方式非常省內存空間，將一個字節分成8個bit位存儲東西，物盡其用。所以我們根據isa_t結構體中的所占用bit位加起來=64可以得知isa指針占用8個字節空間。
雖然位域極大限度的節省了內存空間，但是現在面臨着一個問題，那就是如何給這些變量賦值或者取值呢?普通結構體中因為每個變量都有自己的內存地址，所以直接根據地址讀取值即可， 但是union共用體中是大家共用同一個內存地址，只是分布在不同的bit位上，所以是沒有辦法通過內存地址讀取值的，那么這就用到了位運算符，我們需要知道以下幾個概念：
&：按位與，同真為真，其余為假
|：按位或，有真則真，全假則假
<<：左移，表示左移動一位 （默認是00000001 那么1<<1 則變成了00000010 1<<2就是00000100）
~：按位取反
掩碼 : 一般把用來進行按位與(&)運算來取出相應的值的值稱之為掩碼(Mask)。如 #define TallMask 0b00000100 ：TallMask就是用來取出右邊第三個bit位數據的掩碼
好，那么我們來看下這些運算符是怎么可以做到取值賦值的呢？比如說我們上面的te共用體內有8個char，要是我們想出去char b的值怎么取呢？這就用到了&：
按位與上1<<1 就可以取出b位的值了，b是1那么結果就是1，b是0那么結果就是0；
同理，當我們為f設置值的時候，也是類似的操作，就是在改變f的值的同時不影響其他值,這里我們要看賦的值是0還是1，不同值操作不同:
所以，這就是共同體中取值賦值的操作流程，那么我們接下來回到isa指針這個結構體中，看一下它里面的各個成員以及怎么取賦值的↓↓
/*nonpointer 0，代表普通的指針，存儲着Class、Meta-Class對象的內存地址 1，代表優化過，使用位域存儲更多的信息 */ uintptr_t nonpointer : 1; \ /*has_assoc:是否有設置過關聯對象，如果沒有，釋放時會更快*/ uintptr_t has_assoc : 1; \ /*是否有C++的析構函數（.cxx_destruct），如果沒有，釋放時會更快*/ uintptr_t has_cxx_dtor : 1; \ /*存儲着Class、Meta-Class對象的內存地址信息*/ uintptr_t shiftcls : 33; /*MACH_VM_MAX_ADDRESS 0x1000000000*/ \ /*用於在調試時分辨對象是否未完成初始化*/ uintptr_t magic : 6; \ /*是否有被弱引用指向過，如果沒有，釋放時會更快*/ uintptr_t weakly_referenced : 1; \ /*對象是否正在釋放*/ uintptr_t deallocating : 1; \ /*里面存儲的值是引用計數器減1*/ uintptr_t has_sidetable_rc : 1; \ /* 引用計數器是否過大無法存儲在isa中 如果為1，那么引用計數會存儲在一個叫SideTable的類的屬性中 */ uintptr_t extra_rc : 19;
我們看到，isa指針確實做了很大的優化，同樣是占用8個字節，優化后的共用體不僅存放這類對象或元類對象地址，還存放了很多額外屬性，接下來我們對這個結構進行驗證：需要注意的是因為是arm64架構 所以這個驗證需要是ios項目且需要運行在真機上 這樣才會得出准確的結果
首先，我們來驗證這個shiftcls是否就是類對象內存地址。
我們定義了一個dog對象，我們打印它的isa是0x000001a102a48de1
從上面的分析我們得知，要取出shiftcls的值需要isa的值&ISA_MASK(這個isa_mask在源碼中有定義)，得出$1 = 0x000001a102a48de0
而$1的地址值正是我們上面打印出來Dog類對象的地址值，所以這也驗證了isa_t的結構。
我們還可以來看一下其他一些成員，比如說是否被弱指針指向過？我們先將上面沒有被__weak指向過的數據保存一下，其中紅色框中的就是這個屬性，0表示沒有被指向過
然后我們修改代碼，添加弱指針指向dog：__weak Dog *weaKDog = dog;
注意：只要設置過關聯對象或者弱引用引用過對象，has_assoc或weakly_referenced的值就會變成1，不論之后是否將關聯對象置為nil或斷開弱引用。
發現確實由0變成了1，所以可以驗證isa_t的結構，這個實驗要確保程序運行在真機才能出現這個結果。所以arm64后確實對isa指針做了優化處理，不在單純的存放類對象或者元類對象的內存地址，而是除此之外存儲了更多內容。
2、class的具體結構
我們之前在講分類的時候講到了類的大體結構，如下圖所示：
就如我們之前講到的，當我們調用方法的時候是從bits中的methods中查找方法，分類的方法是排在主類方法前面的，所以調用同名方法是先調用分類的，而且究竟調用哪個分類的方法要取決於編譯的先后順序等等：
那么這個rw_t中的methods和ro_t中的methods有什么不一樣呢？
首先，ro_t中methods，是只包含原始類的方法，不包括分類的，而rw_t中的methods即包含原始類的也包含分類的；
其次，ro_t中的methods只能讀取不能修改，而rw_t中的methods既可以讀取也可以修改，所以我們今后在動態添加方法修改方法的時候是在rw_t中的methods去操作的；
然后，ro_t中的methods是個一維數組，里面存放着method_t(對方法/函數的封裝，即一個method_t代表一個方法或函數)，而rw_t中的methods是個二維數組，里面存放着各個分類和原始類的數組，分類和原始類的數組中存放着method_t。即：
我們也可以在源碼中找到rw_t和ro_t的關系，
static Class realizeClass(Class cls) { runtimeLock.assertLocked(); const class_ro_t *ro; class_rw_t *rw; Class supercls; Class metacls; bool isMeta; if (!cls) return nil; if (cls->isRealized()) return cls; assert(cls == remapClass(cls)); // 最開始cls->data是指向ro的 ro = (const class_ro_t *)cls->data(); if (ro->flags & RO_FUTURE) { // rw已經初始化並且分配內存空間 rw = cls->data(); // cls->data指向rw ro = cls->data()->ro; // cls->data()->ro指向ro 即rw中的ro指向ro cls->changeInfo(RW_REALIZED|RW_REALIZING, RW_FUTURE); } else { // 如果rw並不存在，則為rw分配空間 rw = (class_rw_t *)calloc(sizeof(class_rw_t), 1);// 分配空間 rw->ro = ro;// rw->ro重新指向ro rw->flags = RW_REALIZED|RW_REALIZING; // 將rw傳入setData函數，等於cls->data()重新指向rw cls->setData(rw); } }
首先，cls->data(即bits)是指向存儲類初始化信息的ro_t的，然后在運行過程中創建了class_rw_t，等rw_t分配好內存空間后，開始將cls->data指向了rw_t並將rw_t中的ro指向了存儲初始化信息的ro_t。
那么ro_t和rw_t中存儲的這個method_t是個什么結構呢？我們閱讀源碼發現結構如下，我們發現有三個成員：name、types、imp，我們一一來看：
name，表示方法的名稱，一般叫做選擇器，可以通過@selector()和sel_registerName()獲得。
/* 比如test方法，它的SEL就是@selector(test);或者sel_registerName("test");需要注意的一點就是不同類中的同名方法，它們的方法選擇器是相同的，比如A、B兩個類中都有test方法，那么這兩個test方法的名稱都是@selector(test);或者sel_registerName("test"); */
types，表示方法的編碼，即返回值、參數的類型，通過字符串拼接的方式將返回值和參數拼接成一個字符串，來代表函數返回值及參數。
/* 比如ViewDidload方法，我們都知道它的返回值是void，參數轉為底層語言后是self和_cmd，即一個id類型和一個方法選擇器，那么encode后就是v16@0:8(它所表示的意思是:返回值是void類型，參數一共占用16個字節,第一個參數是@類型，內存空間從0開始，第二個參數是:類型，內存空間從8開始)，當然這里的數字可以不寫，簡寫成V@: */
關於更多encode規則，可以查看下面這個表：
當然除了自己手寫外，iOS提供了@encode的指令，可以將具體的類型轉化成字符串編碼。
NSLog(@"%s",@encode(int)); NSLog(@"%s",@encode(float)); NSLog(@"%s",@encode(id)); NSLog(@"%s",@encode(SEL)); // 打印內容 Runtime-test[25275:9144176] i Runtime-test[25275:9144176] f Runtime-test[25275:9144176] @ Runtime-test[25275:9144176] :
imp，表示指向函數的指針(函數地址)，即方法的具體實現，我們調用的方法實際上最后都是通過這個imp去進行最終操作的。
3、方法緩存
我們在分析清楚方法列表和方法的結構后，我們再來看一下方法的調用是怎么一個流程呢？是直接去方法列表里面遍歷查找對應的方法嗎？
其實不然，我們在分析類的結構的時候，除了bits(指向類的具體信息，包括rw_t、ro_t等等一些內容）外，還有一個方法緩存:cache,用來緩存曾經調用過的方法
所以系統查找對應方法不是通過遍歷rw_t這個二維數組來尋找方法的，這樣做太慢，效率太低，系統是先從方法緩存中找有沒有對應的方法，有的話就直接調用緩存里的方法，根據imp去調用方法，沒有的話，就再去方法數組中遍歷查找，找到后調用並保存到方法緩存里，流程如下：
那么方法是怎么緩存到cache中的呢？系統又是怎么查找緩存中的方法的呢？我們通過源碼來看一下cache的結構：
散列表（Hash table，也叫哈希表），是根據關鍵碼值(Key value)而直接進行訪問的數據結構。也就是說，它通過把關鍵碼值映射到表中一個位置來訪問記錄，以加快查找的速度。這個映射函數叫做散列函數，存放記錄的數組叫做散列表。
我們可以看到，cache_t里面就三個成員，后兩個代表長度和數量，是int類型，肯定不是存儲方法的地方，所以方法應該是存儲在_buckets這個散列表中。散列存儲的是一個個的bucket_t的結構體，那么這個bucket_t又是個什么結構呢？
所以cache_t底部結構是這樣的：
我們看到，bucket_t就兩個值，一個key一個imp，key的話就是方法名，也就是SEL，而imp就是Value，也就是當我們調用一個方法是來到方法緩存中查找，通過比對方法名是不是一致，一致的話就返回對應的imp，也就是方法地址，從而可以調用方法，那么這個散列表是怎么查找的呢？難道也是通過遍歷嗎？
我們通過閱讀源碼來一探究竟：
通過上面代碼的閱讀，我們可以知道系統在cache_t中查找方法並不是通過遍歷，而是通過方法名SEL&mask得到一個索引，直接去讀數組索引中的方法，如果該方法的SEL與我們調用的方法名SEL一直，那么就返回這個方法，否則就一直向下尋找直到找完為止。
好，既然取值的時候不是遍歷，而是直接讀的索引，那么講方法存儲到緩存中也肯定是通過這種方式了，直接方法名&mask拿到索引，然后將_key和_imp存儲到對應的索引上，這一點我們通過源碼也可以確認：
我們看到無論是存還是讀，都是調用了find函數，查看SEL&mask對應的索引的方法，不合適的話再向下尋找直到找到合適的位置。
那么這里有兩個疑問，為什么SEL&mask會出現不是該方法名(讀)或者不為空(寫)的情況呢？散列表擴容后方法還在嗎？
首先，SEL&mask這個問題，是因為不同的方法名&mask可能出現同一個結果，比如test方法的SEL是011，run方法的SEL是010，mask是010，那么無論是test的SEL&mask還是run的SEL&mask 記過都是010，如果大家都存在這個索引里面是會出問題的，所以為了解決這個索引重復的問題需要先做判斷，即拿到索引后先判斷這個索引對應的值是不是你想要的，是的話你拿走用，不是的話向下繼續找，方法緩存也是同樣的道理。我們先調用test方法，緩存到010索引，再調用run方法，發現010位置不為空了，那就判斷010下面的索引是否為空，為空的話就將run方法緩存到這個位置。
關於散列表擴容后，緩存方法在不在的問題，通過源碼就可以知道，舊散列表已經釋放掉了，所以是不存在的，再次調用的時候就得重新去rw_t中遍歷找方法然后重新緩存到散列表中，比如下面這個例子:
更正更正更正
我們前面講到當SEL&mask出來一個索引發現被占用或者不是我想要的時候，系統是向索引下一位再次尋找，這個地方失誤了，不是向下是向上尋找，這個地方看源碼的時候忽略了條件，在x86或者i386架構中是向下尋找，在arm64架構中是向上尋找：(因為上面圖片資源都已經刪掉了就沒有再更改，這里需要注意一下)
到現在我們清楚了，那就是散列表中並不是按照索引依次排序或者遍歷索引依次讀取，那么就會出現個問題，因為SEL&mask是個小於mask的隨機值且散列表存儲空間超過3/4的時候就要擴容，那就會導致散列表中有一部分空間始終被限制。確實，散列表當分配內存后，每個地方最初都是null的，當某個位置的索引被用到時，對應的位置才會存儲方法，其余位置仍處於空閑狀態，但是這樣做可以極大提高查找速度(比遍歷快很多)，所以這是一種空間換時間的方式。
4、方法的傳遞過程
我們現在已經清楚方法的調用順序了，實現從緩存中找沒有的話再去rw_t中找，那么在沒有的話就去其父類中找，父類中查找也是如此，先去父類中的cache中查找，沒有的話再去父類的rw_t中找，以此類推。如果查找到基類還沒有呢？難道就直接報unrecognized selector sent to instance 這個經典錯誤嗎？
其實不是，方法的傳遞主要涉及到三個部分，這也是我們平時用得最多以及面試中經常出現的問題：
我們都知道，當我們調用一個方法是，其實底層是將這個方法轉換成了objc_msgSend函數來進行調用，objc_msgSend的執行流程可以分為3大階段：
消息發送->動態方法解析->消息轉發
這個流程我們是可以從源碼中得到確認，以下是源碼：
1 /*********************************************************************** 2 * _class_lookupMethodAndLoadCache. 3 * Method lookup for dispatchers ONLY. OTHER CODE SHOULD USE lookUpImp(). 4 * This lookup avoids optimistic cache scan because the dispatcher 5 * already tried that. 6 **********************************************************************/ 7 IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls) 8 { 9 return lookUpImpOrForward(cls, sel, obj, 10 YES/*initialize*/, NO/*cache*/, YES/*resolver*/); 11 } 12 13 14 /*********************************************************************** 15 * lookUpImpOrForward. 16 * The standard IMP lookup. 17 * initialize==NO tries to avoid +initialize (but sometimes fails) 18 * cache==NO skips optimistic unlocked lookup (but uses cache elsewhere) 19 * Most callers should use initialize==YES and cache==YES. 20 * inst is an instance of cls or a subclass thereof, or nil if none is known. 21 * If cls is an un-initialized metaclass then a non-nil inst is faster. 22 * May return _objc_msgForward_impcache. IMPs destined for external use 23 * must be converted to _objc_msgForward or _objc_msgForward_stret. 24 * If you don't want forwarding at all, use lookUpImpOrNil() instead. 25 **********************************************************************/ 26 //這個函數是方法調用流程的函數 即消息發送->動態方法解析->消息轉發 27 IMP lookUpImpOrForward(Class cls, SEL sel, id inst, 28 bool initialize, bool cache, bool resolver) 29 { 30 IMP imp = nil; 31 bool triedResolver = NO; 32 33 runtimeLock.assertUnlocked(); 34 35 // Optimistic cache lookup 36 if (cache) { 37 imp = cache_getImp(cls, sel); 38 if (imp) return imp; 39 } 40 41 // runtimeLock is held during isRealized and isInitialized checking 42 // to prevent races against concurrent realization. 43 44 // runtimeLock is held during method search to make 45 // method-lookup + cache-fill atomic with respect to method addition. 46 // Otherwise, a category could be added but ignored indefinitely because 47 // the cache was re-filled with the old value after the cache flush on 48 // behalf of the category. 49 50 runtimeLock.lock(); 51 checkIsKnownClass(cls); 52 53 if (!cls->isRealized()) { 54 realizeClass(cls); 55 } 56 57 if (initialize && !cls->isInitialized()) { 58 runtimeLock.unlock(); 59 _class_initialize (_class_getNonMetaClass(cls, inst)); 60 runtimeLock.lock(); 61 // If sel == initialize, _class_initialize will send +initialize and 62 // then the messenger will send +initialize again after this 63 // procedure finishes. Of course, if this is not being called 64 // from the messenger then it won't happen. 2778172 65 } 66 67 68 retry: 69 runtimeLock.assertLocked(); 70 71 // Try this class's cache. 72 //先從當前類對象的方法緩存中查看有沒有對應方法 73 imp = cache_getImp(cls, sel); 74 if (imp) goto done; 75 76 // Try this class's method lists. 77 //沒有的話再從類對象的方法列表中尋找 78 { 79 Method meth = getMethodNoSuper_nolock(cls, sel); 80 if (meth) { 81 log_and_fill_cache(cls, meth->imp, sel, inst, cls); 82 imp = meth->imp; 83 goto done; 84 } 85 } 86 87 // Try superclass caches and method lists. 88 { 89 unsigned attempts = unreasonableClassCount(); 90 //遍歷所有父類 知道其父類為空 91 for (Class curClass = cls->superclass; 92 curClass != nil; 93 curClass = curClass->superclass) 94 { 95 // Halt if there is a cycle in the superclass chain. 96 if (--attempts == 0) { 97 _objc_fatal("Memory corruption in class list."); 98 } 99 100 // Superclass cache. 101 //先查找父類的方法緩存 102 imp = cache_getImp(curClass, sel); 103 if (imp) { 104 if (imp != (IMP)_objc_msgForward_impcache) { 105 // Found the method in a superclass. Cache it in this class. 106 log_and_fill_cache(cls, imp, sel, inst, curClass); 107 goto done; 108 } 109 else { 110 // Found a forward:: entry in a superclass. 111 // Stop searching, but don't cache yet; call method 112 // resolver for this class first. 113 break; 114 } 115 } 116 117 // Superclass method list. 118 //再查找父類的方法列表 119 Method meth = getMethodNoSuper_nolock(curClass, sel); 120 if (meth) { 121 log_and_fill_cache(cls, meth->imp, sel, inst, curClass); 122 imp = meth->imp; 123 goto done; 124 } 125 } 126 } 127 128 // No implementation found. Try method resolver once. 129 //消息發送階段沒找到imp 嘗試進行一次動態方法解析 130 if (resolver && !triedResolver) { 131 runtimeLock.unlock(); 132 _class_resolveMethod(cls, sel, inst); 133 runtimeLock.lock(); 134 // Don't cache the result; we don't hold the lock so it may have 135 // changed already. Re-do the search from scratch instead. 136 triedResolver = YES; 137 //跳轉到retry入口 retry入口就在上面,也就是x消息發送過程即找緩存找rw_t 138 goto retry; 139 } 140 141 // No implementation found, and method resolver didn't help. 142 // Use forwarding. 143 //消息發送階段沒找到imp而且執行動態方法解析也沒有幫助 那么就執行方法轉發 144 imp = (IMP)_objc_msgForward_impcache; 145 cache_fill(cls, sel, imp, inst); 146 147 done: 148 runtimeLock.unlock(); 149 150 return imp; 151 }
首先，消息發送，就是我們剛才提到的系統會先去cache_t中查找，有的話調用，沒有的話去類對象的rw_t中查找，有的話調用並緩存到cache_t中，沒有的話根據supperclass指針去父類中查找。父類查找也是如此，先去父類的cache_t中查找，有的話進行調用並添加到自己的cache_t中而不是父類的cache_t中，沒有的話再去父類的rw_t中查找，有的話調用並緩存到自己的cache_t中，沒有的話以此類推。流程如下：
當消息發送找到最后一個父類還沒有找到對應的方法時，就會來到動態方法解析。動態解析，就是意味着開發者可以在這里動態的往rw_t中添加方法實現，這樣的話系統再次遍歷rw_t就會找到對應的方法進行調用了。
動態方法解析的流程示意圖如下：
主要涉及到了兩個方法：
+resolveInstanceMethod://添加對象方法 也就是-開頭的方法 +resolveClassMethod://添加類方法 也就是+開頭的方法
我們在實際項目中進行驗證：
動態添加類方法也是如此，只不過是添加到元類對象中（此時run方法已經改成了個類方法）
而且我們也發現，動態添加方法的話其實無非就是找到方法實現，添加到類對象或元類對象中，至於這個方法實現是什么形式都沒有關系，比如說我們再給對象方法添加方法實現時，這個實現方法可以是個類方法，同樣給類方法動態添加方法實現時也可以是對象方法。也就是說系統根本沒有區分類方法和對象方法，只要把imp添加到元類對象的rw_t中就是類方法，添加到類對象中就是對象方法。
當我們在消息發送和動態消息解析階段都沒有找到對應的imp的時候，系統回來到最后一個消息轉發階段。所謂消息轉發，就是你這個消息處理不了后可以找其他人或者其他方法來代替，消息轉發的流程示意圖如下：
即分為兩步，第一步是看能不能找其他人代你處理這方法，可以的話直接調用這個人的這個方法，這一步不行的話就來到第二部，這個方法沒有的話有沒有可以替代的方法，有的話就執行替代方法。我們通過代碼來驗證：
我們調用dog的run方法是，因為dog本身沒有實現這個方法，所以不能處理。正好cat實現了這個方法，所以我們就將這個方法轉發給cat處理：
我們發現，確實調用了小貓run方法，但是只轉發方法執行者太局限了，要求接收方法對象必須實現了同樣的方法才行，否則還是無法處理，所以實用性不強。這時候，我們可以通過methodSignatureForSelector來進行更大限度的轉發。
需要注意的是要想來到methodSignatureForSelector這一步需要將forwardingTargetForSelector返回nil（即默認狀態）否則系統找到目標執行者后就不會再往下轉發了。
開發者可以在forwardInvocation:方法中自定義任何邏輯。
////為方法重新轉發一個目標執行 //- (id)forwardingTargetForSelector:(SEL)aSelector{ // if (aSelector == @selector(run)) { // //dog的run方法沒有實現 所以我們將此方法轉發到cat對象上去實現 也就是相當於將[dog run]轉換成[cat run] // return [[Cat alloc] init]; // } // return [super forwardingTargetForSelector:aSelector]; //} //方法簽名 - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector{ if (aSelector == @selector(run)) { //注意:這里返回的是我們要轉發的方法的簽名 比如我們現在是轉發run方法 那就是返回的就是run方法的簽名 //1.可以使用methodSignatureForSelector:方法從實例中請求實例方法簽名，或者從類中請求類方法簽名。 //2.也可以使用instanceMethodSignatureForSelector:方法從一個類中獲取實例方法簽名 //這里使用self的話會進入死循環 所以不可以使用 如果其他方法中有同名方法可以將self換成其他類 // return [self methodSignatureForSelector:aSelector]; // return [NSMethodSignature instanceMethodSignatureForSelector:aSelector]; //3.直接輸入字符串 return [NSMethodSignature signatureWithObjCTypes:"v@:"]; } return [super methodSignatureForSelector:aSelector]; } //當返回方法簽名后 就會轉發到這個方法 所以我們可以在這里做想要實現的功能 可操作空間很大 //這個anInvocation里面有轉發方法的信息,比如方法調用者/SEL/types/參數等等信息 - (void)forwardInvocation:(NSInvocation *)anInvocation{ //這樣寫不安全 可以導致cat被過早釋放掉引發懷內存訪問 // anInvocation.target = [[Cat alloc] init]; Cat *ca = [[Cat alloc] init]; //指定target anInvocation.target = ca; //對anInvocation做出修改后要執行invoke方法保存修改 [anInvocation invoke]; //或者干脆一行代碼搞定 [anInvocation invokeWithTarget:[[Cat alloc] init]]; //上面這段代碼相當於- (id)forwardingTargetForSelector:(SEL)aSelector{}中的操作 //當然 轉發到這里的話可操作性更大 也可以什么都不寫 相當於轉發到的這個方法是個空方法 也不會報方法找不到的錯誤 //也可以在這里將報錯信息提交給后台統計 比如說某個方法找不到提交給后台 方便線上錯誤收集 //...很多用處 }
當然我們也可以訪問修改anInvocation的參數，比如現在run有個age參數，
// 參數順序：receiver、selector、other arguments int age; //索引為2的參數已經放到了&age的內存中，我們可以通過age來訪問 [anInvocation getArgument:&age atIndex:2]; NSLog(@"%d", age + 10);
我們發現，消息轉發有兩種情況，一種是forwardingTargetForSelector，一種是methodSignatureForSelector+forwardInvocation：
其實，第一種也稱快速轉發，特點就是簡單方便，缺點就是能做的事情有限，只能轉發消息調用者；第二種也稱標准轉發，缺點就是寫起來麻煩點，需要寫方法簽名等信息，但是好處就是可以很大成都的自定義方法的轉發，可以在找不到方法imp的時候做任何邏輯。
當然，我們上面的例子都是通過對象方法來演示消息轉發的，類方法同樣存在消息轉發，只不過對應的方法都是類方法，也就是-變+
所以，以上關於消息傳遞過程可以用下面這個流程圖進一步總結：
關於源碼閱讀指南：
5、super的相關內容
首先我們來看一下這段代碼：
我們發現最終的打印結果和我們預期的不一樣，按我們的思路Super就是指的的Dog的父類Animal，Animal調用class方法應該返回Animal 但是結果卻不是這樣，這是為什么？首先我們先將這段代碼轉換成c++底層代碼來一探究竟：
static instancetype _I_Dog_init(Dog * self, SEL _cmd) { self = ((Dog *(*)(__rw_objc_super *, SEL))(void *)objc_msgSendSuper)((__rw_objc_super){(id)self, (id)class_getSuperclass(objc_getClass("Dog"))}, sel_registerName("init")); if (self) { // NSLog(@"%@",[self class]); NSLog((NSString *)&__NSConstantStringImpl__var_folders_f1_q0392lf551qfbg1b5sy48qb80000gn_T_Dog_db6ed5_mi_0,((Class (*)(id, SEL))(void *)objc_msgSend)((id)self, sel_registerName("class"))); //NSLog(@"%@",[self superclass]); NSLog((NSString *)&__NSConstantStringImpl__var_folders_f1_q0392lf551qfbg1b5sy48qb80000gn_T_Dog_db6ed5_mi_1,((Class (*)(id, SEL))(void *)objc_msgSend)((id)self, sel_registerName("superclass"))); //NSLog(@"%@",[super class]); NSLog((NSString *)&__NSConstantStringImpl__var_folders_f1_q0392lf551qfbg1b5sy48qb80000gn_T_Dog_db6ed5_mi_2,((Class (*)(__rw_objc_super *, SEL))(void *)objc_msgSendSuper)((__rw_objc_super){(id)self, (id)class_getSuperclass(objc_getClass("Dog"))}, sel_registerName("class"))); //NSLog(@"%@",[super superclass]); NSLog((NSString *)&__NSConstantStringImpl__var_folders_f1_q0392lf551qfbg1b5sy48qb80000gn_T_Dog_db6ed5_mi_3,((Class (*)(__rw_objc_super *, SEL))(void *)objc_msgSendSuper)((__rw_objc_super){(id)self, (id)class_getSuperclass(objc_getClass("Dog"))}, sel_registerName("superclass"))); } return self; }
將上述代碼簡化后得到下面的結果：
我們發現，當self調用class方法時，是執行的objc_msdSend(self,@selector(class))函數，消息的接收者是當前所在類的實例對象(Dog) , 這個時候就會去self所在類 Dog去查找class方法 , 如果當前類Dog沒有class方法會向其父類Animal類找 class 方法, 如果Animal類也沒有找到class方法,最終會找到最頂級父類NSObject的class方法, 最終找到NSObject的class方法 ,並調用了object_getClass(self) ,由於消息接收者是 self 當前類實例對象, 所以最終 [self class]輸出Dog（class方法是返回方法調用者的類型，superclass方法是返回方法調用者的父類）
[self superclass] 也是同理，找到superclass方法，然后返回調用者的父類，即Animal；
但是當我們調用super的class方法時，底層不是轉換成objc_msdSend而是變成了objc_msgSendSuper函數。這個函數有兩個參數，第一個參數是個結構體，結構體中有兩個成員：方法調用者和調用者的父類，第二個參數就是方法名，也就是class方法的SEL。
[super class] -> objc_msgSendSuper( //第一個參數:結構體 {self,//方法調用者 class_getSuperclass(objc_getClass("Dog"))//當前類的父類 }, //第二個參數:方法名 sel_registerName("class")));
所以，我們看到[self class]和[super class]，他們轉換成的底層實現都不一致。objc_msgSendSuper函數的作用是告訴方法調用者去其父類中查找該方法，也就是相比objc_msdSend函數而言少了去自己類中查找方法這一步，而是直接去父類中找class方法，但是方法調用者還是沒變，都是Dog。class方法和superclass它們都是返回方法調用者的類型或父類，所以[super class]和[super superclass]還是返回的Dog的類型和父類，所以打印結果是Dog和Animal，與[self class]和[self superclass]結果一致。
所以，總結起來就是，super方法底層會轉換為objc_msgSendSuper函數的調用，這個函數的作用是告訴方法調用者去父類中查找方法。
6、runtime的常見API與應用案例
最后，我們再來總結一下runtime中常見的API：
動態創建一個類（參數：父類，類名，額外的內存空間） Class objc_allocateClassPair(Class superclass, const char *name, size_t extraBytes) 注冊一個類（要在類注冊之前添加成員變量） void objc_registerClassPair(Class cls) 銷毀一個類 void objc_disposeClassPair(Class cls) 獲取isa指向的Class Class object_getClass(id obj) 設置isa指向的Class Class object_setClass(id obj, Class cls) 判斷一個OC對象是否為Class BOOL object_isClass(id obj) 判斷一個Class是否為元類 BOOL class_isMetaClass(Class cls) 獲取父類 Class class_getSuperclass(Class cls) 獲取一個實例變量信息 Ivar class_getInstanceVariable(Class cls, const char *name) 拷貝實例變量列表（最后需要調用free釋放） Ivar *class_copyIvarList(Class cls, unsigned int *outCount) 設置和獲取成員變量的值 void object_setIvar(id obj, Ivar ivar, id value) id object_getIvar(id obj, Ivar ivar) 動態添加成員變量（已經注冊的類是不能動態添加成員變量的） BOOL class_addIvar(Class cls, const char * name, size_t size, uint8_t alignment, const char * types) 獲取成員變量的相關信息 const char *ivar_getName(Ivar v) const char *ivar_getTypeEncoding(Ivar v) 獲取一個屬性 objc_property_t class_getProperty(Class cls, const char *name) 拷貝屬性列表（最后需要調用free釋放） objc_property_t *class_copyPropertyList(Class cls, unsigned int *outCount) 動態添加屬性 BOOL class_addProperty(Class cls, const char *name, const objc_property_attribute_t *attributes, unsigned int attributeCount) 動態替換屬性 void class_replaceProperty(Class cls, const char *name, const objc_property_attribute_t *attributes, unsigned int attributeCount) 獲取屬性的一些信息 const char *property_getName(objc_property_t property) const char *property_getAttributes(objc_property_t property) 獲得一個實例方法、類方法 Method class_getInstanceMethod(Class cls, SEL name) Method class_getClassMethod(Class cls, SEL name) 方法實現相關操作 IMP class_getMethodImplementation(Class cls, SEL name) IMP method_setImplementation(Method m, IMP imp) void method_exchangeImplementations(Method m1, Method m2) 拷貝方法列表（最后需要調用free釋放） Method *class_copyMethodList(Class cls, unsigned int *outCount) 動態添加方法 BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types) 動態替換方法 IMP class_replaceMethod(Class cls, SEL name, IMP imp, const char *types) 獲取方法的相關信息（帶有copy的需要調用free去釋放） SEL method_getName(Method m) IMP method_getImplementation(Method m) const char *method_getTypeEncoding(Method m) unsigned int method_getNumberOfArguments(Method m) char *method_copyReturnType(Method m) char *method_copyArgumentType(Method m, unsigned int index) 選擇器相關 const char *sel_getName(SEL sel) SEL sel_registerName(const char *str) 用block作為方法實現 IMP imp_implementationWithBlock(id block) id imp_getBlock(IMP anImp) BOOL imp_removeBlock(IMP anImp)
這些api中有些我們用的比較少，有的比較常用，比如我們在修改UITextField的占位文字顏色的話，可以通過獲取UITextField的成員列表，發現其中占位文字的顯示其實是個placeholderLabel，所以我們直接可以通過kvo修改這個label的顏色：
還有比如經常用的字典轉模型框架MJExtension中，也是通過runtime函數遍歷所有的屬性或者成員變量，然后利用KVO去設值等等。
另外需要注意的一點是，我們一般將動態添加方法、方法交換等等這些運行時操作放在load方法里面實現，我們在之前講解分類的時候提到了：
當類被引用進項目的時候就會執行load函數(在main函數開始執行之前）,與這個類是否被用到無關,每個類的load函數只會自動調用一次.也就是load函數是系統自動加載的，load方法會在runtime加載類、分類時調用。
方法交換一般用在將系統的某個方法交換成我們自己寫的方法從而實現相應功能，這里也有兩點需要注意：
①避免死循環：
方法交換交換的只是兩個方法的實現，也就是imp的交換，所以原理如下：
用代碼來演示，比如我們現在要攔截所有按鈕的點擊事件，在做出點擊相應之前打印出相關信息，UIButton繼承自UIControl，button的addTarget: action: forControlEvents:方法底層也是調用了UIControl的sendAction:to:forEvent:方法，所以我們需要將sendAction:to:forEvent:來進行方法交換，交換成我們自己的方法：
#import "UIControl+Extension.h" #import <objc/runtime.h> @implementation UIControl (Extension) + (void)load { //這里最好加上一個dispatch_once 雖然load方法原則上只會調用一次,但是萬一開發者手動再調用一次的話,那么兩個方法交換了兩次就相當於沒交換 static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Method method1 = class_getInstanceMethod(self, @selector(sendAction:to:forEvent:)); Method method2 = class_getInstanceMethod(self, @selector(my_sendAction:to:forEvent:)); method_exchangeImplementations(method1, method2); }); } //我們自己實現的方法 - (void)my_sendAction:(SEL)action to:(id)target forEvent:(UIEvent *)event { NSLog(@"%@-%@-%@", self, target, NSStringFromSelector(action)); // 調用系統原來的實現 //調用sendAction:會出現死循環 因為sendAction:方法的實現是my_sendAction: //[self sendAction:action to:target forEvent:event]; //所以需要調用my_sendAction:方法來實現系統原來的實現 因為my_sendAction:方法實現就是系統的sendAction:方法實現 [self my_sendAction:action to:target forEvent:event]; }
②需要注意類簇，確保交換的是正確的類
比如我們在使用NSMutableArray添加數據的時候，如果添加nil會出錯，所以我們要將系統的這個方法交換成我們自己的方法從而可以進行判斷，我們也知道
addObject：方法底層是調用的insertObject:atIndex:方法，所以：
#import "NSMutableArray+Extension.h" #import <objc/runtime.h> @implementation NSMutableArray (Extension) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Method method1 = class_getInstanceMethod(self, @selector(insertObject:atIndex:)); Method method2 = class_getInstanceMethod(self, @selector(my_insertObject:atIndex:)); method_exchangeImplementations(method1, method2); }); } - (void)my_insertObject:(id)anObject atIndex:(NSUInteger)index { if (anObject == nil) return; [self my_insertObject:anObject atIndex:index]; }
但是我們發現，這樣做還是不行，根本進不去我們自己的my_insertObject：方法就會出錯：
//reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
這是因為我們交換的類不對，在出錯信息我們可以看到這個insertObject:atIndex:是存在__NSArrayM中的，所以我們應該交換__NSArrayM的方法而不是NSMutableArray的方法：
#import "NSMutableArray+Extension.h" #import <objc/runtime.h> @implementation NSMutableArray (Extension) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ //這里要是交換方法的真實類 Class cls = NSClassFromString(@"__NSArrayM"); Method method1 = class_getInstanceMethod(cls, @selector(insertObject:atIndex:)); Method method2 = class_getInstanceMethod(cls, @selector(mj_insertObject:atIndex:)); method_exchangeImplementations(method1, method2); }); } - (void)mj_insertObject:(id)anObject atIndex:(NSUInteger)index { if (anObject == nil) return; [self mj_insertObject:anObject atIndex:index]; }
幾種常見類的真實類型：
method swizzling（俗稱黑魔法）,簡單說就是進行方法交換,可以通過以下幾種方式實現：
- 利用 method_exchangeImplementations 交換兩個方法的實現
- 利用 class_replaceMethod 替換方法的實現
- 利用 method_setImplementation 來直接設置某個方法的IMP
8、weak的底層實現
weak使我們開發中常見的修飾符，它是一種“非擁有關系”的指針(即弱引用)。通過weak修飾的指針變量，都不會改變被引用對象的引用計數,最主要的作用是為了防止引用循環(retained cycle)，經常用於block和delegate。
weak、assign以及unsafe_unretained都是弱引用，這三者有什么區別嗎？
①在一個對象被釋放后，weak會自動將指針指向nil，而assign和unsafe_unretained則不會。在iOS中，向nil發送消息時不會導致崩潰的，所以assign和unsafe_unretained會導致野指針的錯誤unrecognized selector sent to instance。
② weak 只可以修飾對象。如果修飾基本數據類型，編譯器會報錯-“Property with ‘weak’ attribute must be of object type”。
assign 可修飾對象，和基本數據類型。unsafe_unretained也是只可修飾對象，所以用assign修飾對象和unsafe_unretained修飾對象其實是一樣的。
weak不論是用作property修飾符還是用來修飾一個變量的聲明其作用是一樣的，就是不增加新對象的引用計數，被釋放時也不會減少新對象的引用計數，同時在新對象被銷毀時，weak修飾的屬性或變量均會被設置為nil，這樣可以防止野指針錯誤，那么runtime如何將weak修飾的變量的對象在銷毀時自動置為nil？weak底層實現原理是什么？
//用作property修飾符 @property(weak,nonatomic) NSObject *weakObj; //修飾變量的聲明 NSObject *obj = [[NSObject alloc]init]; __weak typeof(obj)weakObj = obj;
runtime對注冊的類會進行布局，對於weak修飾的對象會放入一個hash表中。用weak指向的對象內存地址作為key，當此對象的引用計數為0的時候會dealloc，假如weak指向的對象內存地址是a，那么就會以a為鍵在這個weak表中搜索，找到所有以a為鍵的weak對象，從而設置為nil。
比如我們上面__weak typeof(obj)weakObj = obj;這個例子：
當為weakObj這一weak類型的對象賦值時，編譯器會根據obj的地址為key去查找weak哈希表，這個表可以理解成一個數組，將weakObj對象的地址(&weakObj)加入到數組中。當obj引用計數為0時，會執行dealloc函數，在執行該函數時，編譯器會以obj變量的地址去查找weak哈希表的值，並將數組里所有 weak對象全部賦值為nil。
也就是,系統會創建一個全局的weak表(其實是一個hash（哈希）表），Key是所指對象的地址，Value是weak指針的地址數組
NSObject *obj = [[NSObject alloc]init]; __weak typeof(obj)weakObj = obj; __weak typeof(obj)weakTest = obj; PeopleClass *perple = [[PeopleClass alloc]init]; __weak typeof(perple)weakTeacher = perple; AnimalClass *animal = [[AnimalClass alloc]init]; __weak typeof(animal)weakCat = animal; __weak typeof(animal)weakDog= animal; __weak typeof(animal)weakPig = animal;
接下來我們在源碼中去查看weak的實現：
property中使用weak修飾
@property (nonatomic,weak) NSObject *referent; // 底層實現函數入口 id objc_storeWeak(id *location, id newObj) { return storeWeak<DoHaveOld, DoHaveNew, DoCrashIfDeallocating> (location, (objc_object *)newObj); }
使用__weak修飾對象：
__weak NSObject *referent // 底層實現函數入口 id objc_initWeak(id *location, id newObj) { if (!newObj) { *location = nil; return nil; } return storeWeak<DontHaveOld, DoHaveNew, DoCrashIfDeallocating> (location, (objc_object*)newObj); }
不論是使用weak還是__weak底層都是調用storeWeak這個函數,區別在於模板的第一個參數HaveOld，這個參數用來表示這個弱指針是否有值。
Runtime維護了一個weak表，用於存儲指向某個對象的所有weak指針。weak表其實是一個hash（哈希）表，Key是所指對象的地址，Value是weak指針的地址（這個地址的值是所指對象的地址）數組。
weak 的實現原理可以概括一下三步：
1、初始化時：runtime會調用objc_initWeak函數，初始化一個新的weak指針指向對象的地址。【property中使用weak修飾不存在這一步】
2、添加引用時：objc_initWeak函數會調用 objc_storeWeak() 函數， objc_storeWeak() 的作用是更新指針指向，創建對應的弱引用表。
3、釋放時，調用clearDeallocating函數。clearDeallocating函數首先根據對象地址獲取所有weak指針地址的數組，然后遍歷這個數組把其中的數據設為nil，最后把這個entry從weak表中刪除，最后清理對象的記錄。
接下來用偽代碼說明一下具體流程：
//weak對象創建 static id storeWeak(id *location, objc_object *newObj){ //首先，我們可以拿到兩個值：一個是弱指針指向的對象obj，一個是弱指針對象weakObj if（全局weak表中存在一個key為&obj的鍵值對）{ 1、取出&obj這個key對應的value，這個value是個數組array; 2、將&weakObj插入到這個數組中 [weak_entry_insert(weak_table, &new_entry);] }else{//--如果weak表中沒有一個key為&obj的鍵值對 那么說明這個對象從來沒有被弱指針對象指向過 所以就需要在weak表中創建一個新的鍵值對存儲了 1、創建這樣一個鍵值對 NSArry *value = @[&weakObj]; NSDictory *dic = @{&obj:value}; 2、查看weak剩余存儲空間還多不多 if(weak表使用空間不足3/4) 將鍵值對dic插入到weak表中 }else{//如果剩余空間不如1/4了 那么就進行擴容 /* Grow if at least 3/4 full. if (weak_table->num_entries >= old_size * 3 / 4) { weak_resize(weak_table, old_size ? old_size*2 : 64); } */ 將weak表的存儲空間擴展其兩倍大; 將舊表中的數據通過for循環 全部copy到新表中 將舊表內存空間釋放 將將鍵值對dic插入到weak表中 } } //這個weak表很像我們之前講方法緩存中的那個cache_t,其實都一樣,weak表中插入數據也不是按照索引去插入的,而是由&obj&mask得到一個索引,如果這個索引有數據的話那就向下再找空間存儲 size_t begin = hash_pointer(new_entry->referent) & (weak_table->mask); size_t index = begin; size_t hash_displacement = 0; while (weak_entries[index].referent != nil) { index = (index+1) & weak_table->mask; if (index == begin) bad_weak_table(weak_entries); hash_displacement++; }
//weak的釋放 weak_clear_no_lock(weak_table_t *weak_table, id referent_id){ 1.從weak表中取出這個以&obj為key的鍵值對 2.取出鍵值對的value 存放弱指針的數組,weakAry for(int i = 0,i<weakAry.count,i++){ 將weakAry中的指針指向的內容全部置為nil } 3.從weak表中刪除這個鍵值對 weak_entry_remove(weak_table, entry); }
詳細介紹及源碼解析：
iOS 底層解析weak的實現原理（包含weak對象的初始化，引用，釋放的分析）