nslog
(@"%d",[
[nsobject class] iskindofclass:
[nsobject class]])
;//這裡最終比較的是nsobject類物件的metaclass是不是與其類物件是不是相同,結合類圖所以結果不同
nslog
(@"%d",[
[nsobject class] ismemberofclass:
[nsobject class]])
;nslog
(@"---------");
//首先左邊lymperson類物件的metaclass與右邊lymperson類物件比較,如果不同繼續比較左邊lymperson類物件的metaclass的父類;結合類圖結果不相同
nslog
(@"%d",[
[lymperson class] iskindofclass:
[lymperson class]])
;// lymperson類物件的metaclass與其類物件比較,結合類圖結果不相同
nslog
(@"%d",[
[lymperson class] ismemberofclass:
[lymperson class]])
;nslog
(@"---------");
// lymperson類物件的metaclass與nsobject比較,不同則繼續比較 lymperson`類物件的metaclass的父類`,因為lymperson的最終父類就是nsobject, 結合類圖因此結果相同
nslog
(@"%d",[
[lymperson class] iskindofclass:
[nsobject class]])
;// lymperson類物件的metaclass與nsobject比較,結合類圖結果不相同
想要研究上述問題得先看下下圖:
先來開一下在objc的nsobject部分開源**裡這部分的實現:
+
(bool)ismemberofclass:
(class)cls
-(bool)ismemberofclass:
(class)cls
+(bool)iskindofclass:
(class)cls
return no;}-
(bool)iskindofclass:
(class)cls
return no;}+
(bool)issubclassofclass:
(class)cls
return no;
}
從原始碼裡可知:
綜上所述。如果需要全部輸出正確,上述**修改為:
#import
intmain
(int argc,
const
char
* ar**)
return0;
}
修改後的輸出如下圖:
上述面試題的每個輸出結果的分析,在每行**的上面注釋部分說明
推薦乙個很好的部落格:神經病院 objective-c runtime 入院第一天—— isa 和 class
#import "lymperson.h"
@implementation lymperson-(
void
)showname
@end
#import "viewcontroller.h"
#import "lymperson.h"
@inte***ce viewcontroller (
)@end
@implementation viewcontroller-(
void
)viewdidload
@end
最終輸出:
下面從兩個方面分析
先看一下記憶體分布:
記憶體中最高位的是viewcontroller,lymperson在相對最低位;
增加nsstring 後的記憶體分布:
記憶體中大致圖:
首先使用iphoneos clang -arch arm64 -rewrite-objc -fobjc-arc -fobjc-runtime=ios-12.0.0 lymperson.m
重寫成c++**:
struct nsobject_impl
;struct lymperson_impl
;
總結:這道面試題知識點:objc類的底層實現、區域性變數在棧中的分布、方法呼叫的底層原理、 ios中執行時學習筆記
1.什麼是執行時?1 執行時是一套純c語言的api 純c語言庫 2 編譯器最終都會將oc 轉化 為執行時 clang rewrite objc m 3 利用執行時,可以做很多底層的操作,比如 動態新增物件的成員變數和成員方法 動態交換兩個方法的實現 特別是交換系統自帶的方法 獲得某個類的所有成員方法...
簡單的實用iOS執行時
objective c語言盡可能許多決定推遲時間執行時編譯時間和鏈結。只要有可能,它動態地事情。這意味著語言需要的不僅僅是乙個編譯器,但也乙個執行時系統來執行編譯後的 執行時系統作為一種作業系統的objective c語言 這就是使語言文字工作。本文著眼於nsobject類和objective c程...
MF研究 TinyCLR執行時原理
net micro framework系統架構如下圖所示,其中移植工作主要在平台抽象層 pal 和硬體抽象層 hal 大部分常用的pal層的程式已經寫好,基本上不需要什麼修改,只有hal會根據特定的硬體進行微調。不過如果新增新的裝置驅動,則hal和pal層都需要定義和重寫,假設clr層不支援類似的裝...