轉自http://www.lxweimin.com/p/af485c916df1
1.概要
? ? ? ? ? 對于Runtime系統(tǒng)，相信大部分iOS開發(fā)工程師都有著或多或少的了解。對于Objective-C，Runtime系統(tǒng)是至關重要的，可以說是Runtime系統(tǒng)讓Objective-C成為了區(qū)分于C語言，C++之外的一門獨立開發(fā)語言，讓OC在擁有了自己的面向對象的特性以及消息發(fā)送機制。并且因為其強大的消息發(fā)送機制，也讓很多人認為Objective-C是一門動態(tài)語言(實際上每種語言都具有一定的動態(tài)性，只是OC的Runtime更加強大，但它仍比不上Python,Lua等動態(tài)語言)。
? ? ? ? ? 而Runtime系統(tǒng)的核心就是一個用C,C++，以及在最核心的消息發(fā)送部分甚至使用匯編語言而編寫的一套底層API庫。它是OC面向對象和動態(tài)發(fā)送消息的基石，它把很多編譯時做的決定推遲到運行時。而且研究Runtime源碼能知道很多底層知識，比如類是什么，分類是怎么實現(xiàn)的，方法是什么等。所以準備寫一系列文章，詳細分析一下Runtime的源碼以及設計機制。
2.面向對象特性 —— 類與對象的實現(xiàn)
（一）類的實現(xiàn)
? ? ? ? ? 在C++中，類和結構體就已經(jīng)非常相似了。只是屬性的默認訪問權限有些區(qū)別。而OC中的Class究竟是什么呢？很幸運，蘋果已經(jīng)把Runtime庫開源,可以去蘋果的openSource上下載。打開Runtime工程，OC中的Class定義即可在Object.mm源碼中初見端倪:
typedef struct objc_class *Class;
? ? ? ? ? 我們使用的Class其實就是一個指向objc_class結構體的指針，那么探尋類的構成其實就是弄清楚objc_class結構體的組成。在objc-runtime-new.h中，可以找到objc_class的定義，源碼過長，我截取了關鍵部分，代碼如下:
struct objc_class : objc_object {
// Class ISA;
Class superclass;
cache_t cache;? ? ? ? ? ? // formerly cache pointer and vtable
class_data_bits_t bits;? ? // class_rw_t * plus custom rr/alloc flags
class_rw_t *data() {
return bits.data();
}
}
在分析結構體內的屬性之前，還能發(fā)現(xiàn)objc_class繼承于objc_object結構體。從名字上就能看出來，objc_object是對象的結構體。這也說明了類本身其實也是一個對象。關于objc_object的問題留到后面再談,回到類結構體。
類結構體有三個屬性，superclass，cache,以及bit屬性。
(1)superclass，從名字上就能看出來，它保存了自己的父類。如果本身已經(jīng)是根類NSObject，則為空。
(2) cache，從名字上也能看出來，它跟緩存相關。但是它究竟緩存了什么東西，還需要進入cache_t結構體一探究竟，代碼如下:
struct cache_t {
struct bucket_t *_buckets;
mask_t _mask; //在find方法中可知
mask_t _occupied; //occupied：一個整數(shù)，指定實際占用的緩存bucket的總數(shù)。
public:
struct bucket_t *buckets();
mask_t mask();
mask_t occupied();
void incrementOccupied();
void setBucketsAndMask(struct bucket_t *newBuckets, mask_t newMask);
void initializeToEmpty();
mask_t capacity();
bool isConstantEmptyCache();
bool canBeFreed();
static size_t bytesForCapacity(uint32_t cap);
static struct bucket_t * endMarker(struct bucket_t *b, uint32_t cap);
void expand();
void reallocate(mask_t oldCapacity, mask_t newCapacity);
struct bucket_t * find(cache_key_t key, id receiver);
static void bad_cache(id receiver, SEL sel, Class isa) __attribute__((noreturn));
};
有幾個需要重點關注的點:bucket_t結構體的數(shù)組*_buckets，mask_t結構體的_mask和_occupied屬性，以及返回類型為bucket_t類型的find(cache_key_t,id receiver)方法。
看起來有好幾處都指向了bucket_t結構體，那我們先來看看這個結構體的組成內容:
struct bucket_t {
private:
cache_key_t _key;
IMP _imp;
public:
inline cache_key_t key() const { return _key; }
inline IMP imp() const { return (IMP)_imp; }
inline void setKey(cache_key_t newKey) { _key = newKey; }
inline void setImp(IMP newImp) { _imp = newImp; }
void set(cache_key_t newKey, IMP newImp);
};
bucket_t結構體有兩個屬性，cache_key_t（unsighed long）型的key，以及方法指針I(yè)MP。大概知道了這個結構體存了一個key與方法指針的對應關系，再結合cache_t結構體里的find()方法(在消息發(fā)送的章節(jié)中會重點介紹)，不難推測出cache_t緩存的是一個bucket鏈表，即近期調用過的方法的緩存區(qū)，目的是加快方法調用的速度。不過究竟是如何加快，查找的規(guī)則又是如何，將在消息發(fā)送的章節(jié)中進行詳解。
(3)class_data_bits_t結構體的bits，這是類結構中最重要的一環(huán)，它存儲了類最基本的信息，如方法,成員變量，遵循的protocal列表等等。而我們要的數(shù)據(jù)都存在class_rw_t結構體中，這點在objc_class中的注釋也能看出來:
class_data_bits_t bits;? ? // class_rw_t * plus custom rr/alloc flags
class_data_bits_t其實就是class_rw_t加上了自定義的rr/alloc標志位。而最核心的數(shù)據(jù)都在class_rw_t中。所以這個結構體的源碼是我們重點關注的，做了一些精簡之后如下:
struct class_rw_t {
uint32_t flags;
uint32_t version;
const class_ro_t *ro;
method_array_t methods;
property_array_t properties;
protocol_array_t protocols;
}
首先映入眼簾，幾個令人興奮的關鍵字:method!property!protocals!
看來終于找到重點了，從名字就能看出來它保存了Method,Property,protocol列表。不過需要注意的是，因為在新版的Xcode提供了property自動合成成員變量的功能，很多人對property和Ivar的認知出現(xiàn)了混淆，需知道property本身不包括成員變量。而另外的methods和protocols，一目了然，就是我們要找的方法和遵循的協(xié)議列表。而flags與version標志位則是標志了該類是否是metaClass(下文會講解)，是否被實現(xiàn)等等。
但是新的問題隨之產(chǎn)生，這些array是怎么被生成的，又是按照什么規(guī)則生成的，category里的方法是什么時候添進去的呢？而且還有一個class_ro_t常量指針，它有什么作用，又指向了什么內容呢？讓我們刨根問底吧！首先先解答第二個問題，class_ro_t結構體的內容如下:
struct class_ro_t {
uint32_t flags;
uint32_t instanceStart;
uint32_t instanceSize;
#ifdef __LP64__
uint32_t reserved;
#endif
const uint8_t * ivarLayout;
const char * name;
method_list_t * baseMethodList;
protocol_list_t * baseProtocols;
const ivar_list_t * ivars;
const uint8_t * weakIvarLayout;
property_list_t *baseProperties;
method_list_t *baseMethods() const {
return baseMethodList;
}
};
事實上，class_ro_t保存了類在編譯期就確定的method list，Ivar list等。關于這點我們可以在_read_images方法中的readClass方法中求證，Runtime系統(tǒng)從image文件中拿到類的定義，然后將這個類的data()數(shù)據(jù)，賦給了新生成的類的rw數(shù)據(jù)中的ro，這里說的比較晦澀，因為它更底層，以后會專門用一篇文章來講這部分的內容。
最后把這一個個根據(jù)image文件中類定義生成出來的新類進行實現(xiàn)，即realizeClass方法。我們現(xiàn)在就來看看類的方法，協(xié)議和分類的方法，協(xié)議是如何串起來的。
進入realizeClass()方法，會發(fā)現(xiàn)它會先realize自己的superClass，metaClass，以及設置標志位。在方法快結束的時候，有一句代碼:
// Attach categories
methodizeClass(cls);
看注釋就能明白，在這個地方會把類和分類串起來，生成最終的類。那跳進去看看具體做了什么事情。首先它將ro中保存的baseMethod,baseProperty,baseProtocols等添加進class_rw_t中的methods,propertys，protocols。然后再開始加載category，關鍵代碼:
// Attach categories.
category_list *cats = unattachedCategoriesForClass(cls, true /*realizing*/);
attachCategories(cls, cats, false /*don't flush caches*/);
首先拿到尚未attach到class的category列表，然后進入attachCategories方法，這里面就做了真正添加分類屬性的工作。這部分代碼不是很難，就是把方法數(shù)組等的第一個元素地址添加進Array。唯一需要注意的是，添加category的順序是按照category的load順序，最先被load的category首先被加載。
（二）對象的實現(xiàn)
? ? ? ? ? 相比于類的實現(xiàn)，對象的實現(xiàn)要簡單的多。在上文中，我們能看到類結構體是繼承于對象結構體objc_object的?？芍惼鋵嵰彩莻€對象，那我們順著追進去，看看對象結構體里究竟存了些啥。
struct objc_object {
private:
isa_t isa;
public:
........
}
截取了部分代碼，發(fā)現(xiàn)objc_object有一個唯一的私有變量:isa。相信很多有研究過Runtime的同學都知道，isa是一個指向自己類的指針。而實際上，在ISA()方法中，我們可以知道在64位CPU上，isa已經(jīng)不再是一個指針，而是non-pointer isa。
那什么是non-pointer isa?我們都知道在64位的機器上，一個指針會占8個字節(jié)，即64位。但是我們的地址空間并不需要那么多位數(shù)來表示，如果把這64位的一部分用來存儲實際地址，而另外一部分存一些標志位，如這個對象是不是有弱引用的對象，它有沒有關聯(lián)對象，這個對象是否正在被銷毀等等。那么我們就可以更好的利用起來這64位空間。那么基于這個思想，isa就步入了non-pointer isa時代，它提升了內存的使用效率，降低了64位系統(tǒng)上的內存消耗。
那么non-pointer isa的每一位究竟表示什么呢？這個跟處理器指令集有關。越靠近底層就關注機器本身的特性，一般在iOS開發(fā)中能接觸到的指令集有四種:arm架構的v7和64，inter架構上的i386和x86_64，一般在手機上我們會用到前兩種架構，而在PC模擬器上會用到后兩種。手機型號與CPU架構對應關系如下:
以arm64架構為例，定義如下:
# if __arm64__
#? define ISA_MASK? ? ? ? 0x0000000ffffffff8ULL
#? define ISA_MAGIC_MASK? 0x000003f000000001ULL
#? define ISA_MAGIC_VALUE 0x000001a000000001ULL
struct {
uintptr_t indexed? ? ? ? ? : 1;
uintptr_t has_assoc? ? ? ? : 1;
uintptr_t has_cxx_dtor? ? ? : 1;
uintptr_t shiftcls? ? ? ? ? : 33; // MACH_VM_MAX_ADDRESS 0x1000000000
uintptr_t magic? ? ? ? ? ? : 6;
uintptr_t weakly_referenced : 1;
uintptr_t deallocating? ? ? : 1;
uintptr_t has_sidetable_rc? : 1;
uintptr_t extra_rc? ? ? ? ? : 19;
#? ? ? define RC_ONE? (1ULL<<45)
#? ? ? define RC_HALF? (1ULL<<18)
};
它的non-pointer isa中包括第4位往后的33位是表示真實的isa地址，而其它都是一些相關標志位。有些一目了然就能知道是什么意思，比如has_assoc，weakly_referenced,deallocating，但是其余的標志位相對就比較晦澀，這部分將在以后的文章中進行詳解。
有了前面的講解，那么我們也就知道了，如果是為了拿到一個對象的類，直接訪問它的isa是很危險的，因為它并不是一個真實的地址，所以要使用[obj class]或者是objc_getClass的方式，Runtime會幫我們做這一層轉換。
3.NSTaggedPointer
在看isa部分的源碼時，發(fā)現(xiàn)了很奇怪的一點,附源碼:
inline Class
objc_object::getIsa()
{
if (isTaggedPointer()) {
uintptr_t slot = ((uintptr_t)this >> TAG_SLOT_SHIFT) & TAG_SLOT_MASK;
return objc_tag_classes[slot];
}
return ISA();
}
在獲得isa的過程中，會先進行isTaggedPointer的判斷，若不是TaggedPointer才會返回ISA。而判斷是不是TaggedPointer則是很簡單的用non-pointer isa與TAG_MASK做一個按位與的操作，事實上上文中的indexed標志位，即isa第一位就標志了該對象是不是一個NSTaggedPointer，若為0則是普通的isa，若為1則表示是支持NSTaggedPointer的isa。
那什么情況下支持NSTaggedPointer，它又有什么作用呢？在objc_config.h中，找到了以下定義:
// Define SUPPORT_NONPOINTER_ISA=1 to enable extra data in the isa field.
#if !__LP64__? ||? TARGET_OS_WIN32? ||? TARGET_IPHONE_SIMULATOR
#? define SUPPORT_NONPOINTER_ISA 0
#else
#? define SUPPORT_NONPOINTER_ISA 1
#endif
可以看出在蘋果是在64位平臺上開始支持NSTaggedPointer，那我們就可以合理猜測NSTaggedPointer的設計原理以及功效與non-pointer isa是差不多的。
在WWDC2013中，蘋果介紹了NSTaggedPointer，在32位時代，一個指針占4個字節(jié)，即32位。到了64位時代，一個指針被擴大到了8個字節(jié)，即64位。也就是說就算什么都不干，僅僅是把以前的代碼放到64位系統(tǒng)上運行，內存占用也會擴大一倍。而在絕大多數(shù)情況下，我們并不需要64位去存儲指針的地址，我們完全可以像non-pointer isa一樣，去存點別的東西，比如說小對象本身的值，即對象的"指針"本身就已經(jīng)帶了值，不僅充分利用了內存空間，而且更美妙的是還不用去二次查找，這也加快了值的訪問速度，還減去了開辟內存，銷毀的開銷，這就是NSTaggedPointer的設計思想。
大家可以去WWDC2013的官方pdf中找到詳細的定義,在此就要點做一下簡單翻譯:
(1)NSTaggedPointer是在64位系統(tǒng)中被加入的，它專門用于存儲一些小的對象，如NSNumber,NSDate。
(2)NSTaggedPointer把對象的值本身存在了pointer里面，沒有malloc和free的消耗(也不會存在堆中)。
(3)在性能上，它有三倍的內存使用效率，以及106倍的生成和銷毀效率。
(附原文地址:http://devstreaming.apple.com/videos/wwdc/2013/404xbx2xvp1eaaqonr8zokm/404/404.pdf)
現(xiàn)在我們也可以理解，為什么在獲取isa的時候會先去判斷一下是不是NSTaggedPointer，因為它根本不是一個真正的對象，它的pointer本身就已經(jīng)存儲了它的值，當然它也就不會有isa指針了。不過由此也可以得出一個結論，對內存的優(yōu)化，性能的追求是無止境的！
4.小結
本章講述了類和對象的實現(xiàn)，以及蘋果在64位系統(tǒng)上針對對象指針做的優(yōu)化細節(jié)。下章將會繼續(xù)從源碼的角度去分析消息發(fā)送以及轉發(fā)的流程究竟是怎么實現(xiàn)的，蘋果為此又做了什么關鍵的優(yōu)化。
