前言
最近在群里看到有人發(fā)的一道面試題，題目如下:
@interface Spark : NSObject@property(nonatomic,copy) NSString *name;@end@implementation Spark- (void)speak {NSLog(@"My name is:%@",self.name);}@end@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];id cls = [Spark class];void *obj = &cls;[(__bridge id)obj speak];}
</pre>
問題:上述代碼運(yùn)行起來會: Complieerror?|Runtimecrash?|NSLog?
最終問題就是這段代碼的運(yùn)行結(jié)果奸披。
過程
第一眼看這個問題污茵，我直接就想說，這個東西啊钧忽，肯定是編譯報錯了毯炮、要不就是崩潰啊
所以我就跟著寫了些代碼，結(jié)果發(fā)現(xiàn):
WTF? 怎么能運(yùn)行耸黑，而且結(jié)果竟然還是
相信當(dāng)你看到這個結(jié)果的時候會和我一樣吃驚桃煎，不和邏輯啊，怎么竟然能執(zhí)行成功并且還打印出來當(dāng)前controller了大刊，不符合常理啊为迈。
解析
對于計算機(jī)而言，不存在什么魔法缺菌，如果一段代碼能運(yùn)行必然存在它的原理葫辐。
我們需要做的就是分析為什么能成功。
- 為什么調(diào)用不崩潰 我們需要了解伴郁，
cls的意思耿战。
cls在C語言里，就是一個指針焊傅，這個指針的內(nèi)容指向Spark類
當(dāng)我們通過 void*obj=&cls;這個語句執(zhí)行后剂陡，獲取的就是一個指向這個指針 cls的指針
事實(shí)上在這一步操作實(shí)現(xiàn)后，obj 這個指針就已經(jīng)具有Object-c對象的功能了狐胎，為什么呢鸭栖？接下來我們可以看看runtime實(shí)現(xiàn)原理了，這里我只說一點(diǎn)
//對象struct objc_object {Class isa OBJC_ISA_AVAILABILITY;};//類struct objc_class {Class isa OBJC_ISA_AVAILABILITY;#if !__OBJC2__Class super_class OBJC2_UNAVAILABLE;const char *name OBJC2_UNAVAILABLE;long version OBJC2_UNAVAILABLE;long info OBJC2_UNAVAILABLE;long instance_size OBJC2_UNAVAILABLE;struct objc_ivar_list *ivars OBJC2_UNAVAILABLE;struct objc_method_list **methodLists OBJC2_UNAVAILABLE;struct objc_cache *cache OBJC2_UNAVAILABLE;struct objc_protocol_list *protocols OBJC2_UNAVAILABLE;#endif} OBJC2_UNAVAILABLE;//方法列表struct objc_method_list {struct objc_method_list *obsolete OBJC2_UNAVAILABLE;int method_count OBJC2_UNAVAILABLE;#ifdef __LP64__int space OBJC2_UNAVAILABLE;#endif/* variable length structure */struct objc_method method_list[1] OBJC2_UNAVAILABLE;} OBJC2_UNAVAILABLE;//方法struct objc_method {SEL method_name OBJC2_UNAVAILABLE;char *method_types OBJC2_UNAVAILABLE;IMP method_imp OBJC2_UNAVAILABLE;}
</pre>
引自: iOS Runtime詳解-簡書
可以看到 objc_object這個對象的首字段是isa 指向一個Class
也就是說握巢，我們?nèi)绻幸粋€指向Class的地址的指針晕鹊，相當(dāng)于這個對象就已經(jīng)可以使用了，只是像他的成員變量等等的一系列值都還沒有被初始化暴浦。
所以接下來用 (__bridge id)obj溅话，調(diào)用是不會產(chǎn)生問題的
- 為什么能打印出ViewController對象?
這個問題就是由兩個小部分組成的
1. name 這個屬性是什么時候賦的值?2. ViewController 這個對象是什么時候被傳入的？
</pre>
首先我們需要先了解一下歌焦，一個類對象的數(shù)據(jù)是如何存儲的公荧。
這里我就按照上文一樣引用很多的論證了，我們自己來探究
該上代碼了:
@interface Cls : NSObject@property(nonatomic,strong) NSString *test;@property(nonatomic,strong) NSString *test1;@end@implementation Cls- (void)printPrinter {NSLog(@"self:%p",self);NSLog(@"self.test:%p",&_test);NSLog(@"self.test1:%p",&_test1);}@end
</pre>
接下來調(diào)用 printPrinter,打印一下對象指針地址:
可以發(fā)現(xiàn)同规，指針偏移量成員變量和指針首地址差8個字節(jié)循狰，每個成員變量與上一個成員變量偏移量也是8個字節(jié)窟社。
完成到這一步，我們?nèi)匀粵]有發(fā)現(xiàn)上述兩個問題是應(yīng)該怎么解釋绪钥。但是我們知道了灿里，一個Object-C 對象的指針，和它的成員變量的指針肯定是連續(xù)的程腹。這就為接下來我們的分析提供了一些思路匣吊。
下一步，我在原本的題目中增加一行代碼:
[super viewDidLoad];NSString *str = @"11111";id cls = [Spark class];
</pre>
為啥要增加這行代碼呢寸潦，這步是經(jīng)過深(瞎)思(J)熟(B)慮(試)色鸳，主要是考慮到函數(shù)內(nèi)部的參數(shù)生成必然會需要地方存儲，但這部分存儲地址见转，我們是不知曉的命雀，它的實(shí)現(xiàn)是被系統(tǒng)隱藏的。而我們的代碼又沒有明顯的設(shè)置相關(guān)代碼斩箫，那么必然是由這些條件實(shí)現(xiàn)的吏砂。所以當(dāng)我們增加了這一行代碼后，不出意外的乘客，打印結(jié)果變了
2018-11-29 20:49:39.254021+0800 test[1961:92498] My name is:11111
變成了 我們 上述的值狐血，這一切都和猜想的差不多
于是一個基本設(shè)想就出來了:
因?yàn)闂Ｉ系牡刂方Y(jié)構(gòu)和原本類的需求地址結(jié)構(gòu)高度重合了，同時所有地址都能訪問到對應(yīng)的值易核。我們通過棧的默認(rèn)行為生成了一個Spark對象!
為了驗(yàn)證匈织，我們打印一下 cls和 str的指針堆棧地址
NSLog(@"cls address:%p str address:%p",&cls,&str);
</pre>
2018-11-29 21:03:30.490989+0800 test[2129:122769] cls address:0x7ffeebf4fa00 str address:0x7ffeebf4fa08
我們可以看到他們之間相差也正好是8，而且正好和對象結(jié)構(gòu)體定義的一模一樣牡直。所以這也正好能說明我們上述的打印結(jié)果 Mynameis:11111為什么會發(fā)生报亩。
注:這個存在的原因是因?yàn)楹瘮?shù)內(nèi)部變量采用的小端模式，也就是將參數(shù)地址由棧區(qū)從高地址依次向低地址分配井氢，所以我們打印 cls地址會比 str要小。
由此岳链，第一個小問題就解決了花竞，答案是因?yàn)槲覀冊谏啥褩?shù)的時候，拼湊出了Spark對象的地址數(shù)據(jù)結(jié)構(gòu)格式掸哑，和真正的對象地址數(shù)據(jù)結(jié)構(gòu)一樣约急，所以 self.name就是在生成 cls的那一刻起內(nèi)存地址就已經(jīng)被賦值了。
接下來到下一個問題了ViewController 是什么時候傳入的?
在這一步里我們只能把目光向 cls對象生成前執(zhí)行的操作來看苗分， [superviewDidLoad];我們只執(zhí)行了這一步操作厌蔽，那必然是這個操作產(chǎn)生的結(jié)果。為了驗(yàn)證摔癣，我們可以更改一下調(diào)用順序
id cls = [Cls class];[super viewDidLoad];
</pre>
當(dāng)我們進(jìn)行這部操作后奴饮，會發(fā)現(xiàn)纬向，執(zhí)行speak方法時崩潰了，錯誤是 EXC_BAC_ACCESS戴卜，說明是我們引用野指針了逾条。
由此也可以證實(shí)， [superviewDidLoad];肯定做了一些騷操作投剥，將ViewController的 self壓入了棧區(qū)师脂。
接下來我們就需要探究究竟做了什么操作，我們可以用如下的命令行代碼將ViewController.m重寫成c++代碼江锨，然后觀看發(fā)生了什么吃警。
xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc ViewController.m -o ViewController.cpp
static void _I_ViewController_viewDidLoad(ViewController * self, SEL _cmd) { ((void (*)(__rw_objc_super *, SEL))(void *)objc_msgSendSuper)((__rw_objc_super){(id)self, (id)class_getSuperclass(objc_getClass("ViewController"))}, sel_registerName("viewDidLoad"));
我們可以發(fā)現(xiàn)原本這個方法里面會傳入兩個參數(shù)一個是 self,一個是 _cmd，當(dāng)我們調(diào)用 [superviewDidLoad]時啄育，執(zhí)行的方法中傳入了參數(shù) self酌心，由此將 self做為一個值壓入了棧中，但是 _cmd這個參數(shù)并未被使用灸撰，因此谒府，沒有被壓入棧中。
至此浮毯，這個問題已經(jīng)被解釋出來了完疫。
答案
所有NSObject對象的首地址都是指向這個對象的所屬類。這個條件是充要條件债蓝。反過來說壳鹤，如果一個地址指向某個類，我們就可以把這個地址當(dāng)成對象去用饰迹。所以編譯是會通過的芳誓，也不會報 unrecognized selector的錯誤。
打印結(jié)果會是ViewController對象的原因是因?yàn)?cls在棧上的數(shù)據(jù)結(jié)構(gòu)符合了它作為真實(shí)的類時候的數(shù)據(jù)結(jié)構(gòu)啊鸭， cls.name原本地址正好是棧上ViewController對象地址锹淌，因此NSLog能打印出 <ViewController>
思索
這類問題，考察的東西很深赠制，并且結(jié)合了很多知識點(diǎn)赂摆。但是當(dāng)我們拿到面試題并且能進(jìn)行思索的時候一定要好好的考慮，我對這道題的想法钟些，也是在不斷的試驗(yàn)中逐漸的完善烟号，并且嘗試了很多。其實(shí)找面試題為什么是這個答案的過程和政恍，找代碼找bug的流程都是類似的汪拥，都是排除變量，逐步探索篙耗，最終將探索過程和概念結(jié)合迫筑。
