Category：從底層原理研究到面試題分析
本文將對category的源碼進行比較全面的整理分析，最後結合一些面試題進行總結，但願對讀者有所裨益。
GitHub Repo：iOSDeepAnalyse
Follow: MisterBooo · GitHub
Source: Category：從底層原理研究到面試題分析
公衆號：五分鐘學算法html
目錄
- 1.Category源碼分析
- 2.load源碼分析
- 3.initialize源碼分析
- 4.load與initialize對比
- 5.面試題分析
源碼分析
1.源碼閱讀前的準備
本節代碼基於如下的代碼進行編譯研究：git
@interface Person : NSObject
- (void)instanceRun;
+ (void)methodRun;
@property(nonatomic, copy) NSString *name;
@end
複製代碼
@interface Person (Eat)
@property(nonatomic, assign) int age;
- (void)instanceEat;
+ (void)methodEat;
@end
複製代碼
@interface Person (Drink)
- (void)instanceEat;
@property(nonatomic, copy) NSString *waters;
@end
複製代碼
2.objc4中的源碼
經過objc4中的源碼進行分析，能夠在objc-runtime-new.h中找到Category的結構以下github
struct category_t {
const char *name;
classref_t cls;
struct method_list_t *instanceMethods;
struct method_list_t *classMethods;
struct protocol_list_t *protocols;
struct property_list_t *instanceProperties;
// Fields below this point are not always present on disk.
struct property_list_t *_classProperties;
method_list_t *methodsForMeta(bool isMeta) {
if (isMeta) return classMethods;
else return instanceMethods;
}
property_list_t *propertiesForMeta(bool isMeta, struct header_info *hi);
};
複製代碼
不難發如今這個結構體重存儲着對象方法、類方法、協議和屬性。接下來咱們來驗證一下咱們剛剛本身編寫的Person+Eat.m這個分類在編譯時是不是這種結構。面試
經過算法
xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc Person+Eat.m數組
命令將Person+Eat.m文件編譯成cpp文件，如下的源碼分析基於Person+Eat.cpp裏面的代碼。下面讓咱們開始窺探Category的底層結構吧~bash
2.Person+Eat.cpp源碼
將Person+Eat.cpp的代碼滑到底部部分，能夠看見一個名爲_category_t的結構體，這就是Category的底層結構數據結構
struct _category_t {
const char *name;
struct _class_t *cls;
const struct _method_list_t *instance_methods; // 對象方法列表
const struct _method_list_t *class_methods;// 類方法列表
const struct _protocol_list_t *protocols;// 協議列表
const struct _prop_list_t *properties;// 屬性列表
};
複製代碼
Person+Eat.m這個分類的結構也是符合_category_t這種形式的app
static struct _category_t _OBJC_$_CATEGORY_Person_$_Eat __attribute__ ((used, section ("__DATA,__objc_const"))) =
{
"Person",
0, // &OBJC_CLASS_$_Person,
(const struct _method_list_t *)&_OBJC_$_CATEGORY_INSTANCE_METHODS_Person_$_Eat, // 對象方法列表
(const struct _method_list_t *)&_OBJC_$_CATEGORY_CLASS_METHODS_Person_$_Eat,// 類方法列表
(const struct _protocol_list_t *)&_OBJC_CATEGORY_PROTOCOLS_$_Person_$_Eat, // 協議列表
(const struct _prop_list_t *)&_OBJC_$_PROP_LIST_Person_$_Eat, // 屬性列表
};
複製代碼
咱們開始來分析上面這個結構體的內部成員，其中Person表示類名iphone
對象方法列表
_OBJC_$_CATEGORY_INSTANCE_METHODS_Person_$_Eat是對象方法列表，在Person+Eat.cpp文件中能夠找到_OBJC_$_CATEGORY_INSTANCE_METHODS_Person_$_Eat具體描述
_OBJC_$_CATEGORY_INSTANCE_METHODS_Person_$_Eat __attribute__ ((used, section ("__DATA,__objc_const"))) = {
sizeof(_objc_method),
1,
{{(struct objc_selector *)"instanceEat", "v16@0:8", (void *)_I_Person_Eat_instanceEat}}
};
複製代碼
instanceEat就是咱們上述實現的Person+Eat分類裏面的實例方法。
類方法列表
_OBJC_$_CATEGORY_CLASS_METHODS_Person_$_Eat是類方法列表，在Person+Eat.cpp中具體描述以下
_OBJC_$_CATEGORY_CLASS_METHODS_Person_$_Eat __attribute__ ((used, section ("__DATA,__objc_const"))) = {
sizeof(_objc_method),
1,
{{(struct objc_selector *)"classEat", "v16@0:8", (void *)_C_Person_Eat_classEat}}
};
複製代碼
協議列表
_OBJC_CATEGORY_PROTOCOLS_$_Person_$_Eat是協議列表，在Person+Eat.cpp中具體描述以下
_OBJC_CATEGORY_PROTOCOLS_$_Person_$_Eat __attribute__ ((used, section ("__DATA,__objc_const"))) = {
2,
&_OBJC_PROTOCOL_NSCopying,
&_OBJC_PROTOCOL_NSCoding
};
複製代碼
屬性列表
_OBJC_$_PROP_LIST_Person_$_Eat是屬性列表，在Person+Eat.cpp中具體描述以下
_OBJC_$_PROP_LIST_Person_$_Eat __attribute__ ((used, section ("__DATA,__objc_const"))) = {
sizeof(_prop_t),
2,
{{"weight","Ti,N"},
{"height","Ti,N"}}
};
複製代碼
3.Category的加載處理過程
經過上面的分析，咱們驗證了編寫一個分類的時候，在編譯期間，這個分類內部的確會有category_t這種數據結構，那麼這種數據結構是如何做用到這個類的呢？分類的方法和類的方法調用的邏輯是怎麼樣的呢？咱們接下來回到objc4源碼中進一步分析Category的加載處理過程來揭曉Category的神祕面紗。
咱們按照以下函數的調用順序，一步一步的研究Category的加載處理過程
void _objc_init(void);
└── void map_images(...);
└── void map_images_nolock(...);
└── void _read_images(...);
└── void _read_images(...);
└── static void remethodizeClass(Class cls);
└──attachCategories(Class cls, category_list *cats, bool flush_caches);
複製代碼
| 文件名 | 方法 |
|---|---|
| objc-os.mm | _objc_init |
| objc-os.mm | map_images |
| objc-os.mm | map_images_nolock |
| objc-runtime-new.mm | _read_images |
| objc-runtime-new.mm | remethodizeClass |
| objc-runtime-new.mm | attachCategories |
| objc-runtime-new.mm | attachLists |
在iOS 程序 main 函數以前發生了什麼 中提到，_objc_init這個函數是runtime的初始化函數，那咱們從_objc_init這個函數開始進行分析。
/***********************************************************************
* _objc_init
* Bootstrap initialization. Registers our image notifier with dyld.
* Called by libSystem BEFORE library initialization time
**********************************************************************/
void _objc_init(void)
{
static bool initialized = false;
if (initialized) return;
initialized = true;
// fixme defer initialization until an objc-using image is found?
environ_init();
tls_init();
static_init();
lock_init();
exception_init();
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
}
複製代碼
接着咱們來到 &map_images讀取資源（images這裏表明資源模塊），來到map_images_nolock函數中找到_read_images函數，在_read_images函數中咱們找到與分類相關的代碼
// Discover categories.
for (EACH_HEADER) {
category_t **catlist =
_getObjc2CategoryList(hi, &count);
bool hasClassProperties = hi->info()->hasCategoryClassProperties();
for (i = 0; i < count; i++) {
category_t *cat = catlist[i];
Class cls = remapClass(cat->cls);
if (!cls) {
catlist[i] = nil;
if (PrintConnecting) {
_objc_inform("CLASS: IGNORING category \?\?\?(%s) %p with "
"missing weak-linked target class",
cat->name, cat);
}
continue;
}
bool classExists = NO;
if (cat->instanceMethods || cat->protocols
|| cat->instanceProperties)
{
addUnattachedCategoryForClass(cat, cls, hi);
if (cls->isRealized()) {
remethodizeClass(cls);
classExists = YES;
}
if (PrintConnecting) {
_objc_inform("CLASS: found category -%s(%s) %s",
cls->nameForLogging(), cat->name,
classExists ? "on existing class" : "");
}
}
if (cat->classMethods || cat->protocols
|| (hasClassProperties && cat->_classProperties))
{
addUnattachedCategoryForClass(cat, cls->ISA(), hi);
if (cls->ISA()->isRealized()) {
remethodizeClass(cls->ISA());
}
if (PrintConnecting) {
_objc_inform("CLASS: found category +%s(%s)",
cls->nameForLogging(), cat->name);
}
}
}
}
複製代碼
在上面的代碼中，主要作了如下的事情
- 1.獲取
category列表list - 2.遍歷
category list中的每個category - 3.獲取
category的cls，若是沒有cls，則跳過(continue)這個繼續獲取下一個 - 4.若是
cat有實例方法、協議、屬性，則調用addUnattachedCategoryForClass，同時若是cls有實現的話，就進一步調用remethodizeClass方法 - 5.若是
cat有類方法、協議，則調用addUnattachedCategoryForClass，同時若是cls的元類有實現的話，就進一步調用remethodizeClass方法
其中4,5兩步的區別主要是cls是類對象仍是元類對象的區別，咱們接下來主要是看在第4步中的addUnattachedCategoryForClass和remethodizeClass方法。
addUnattachedCategoryForClass
static void addUnattachedCategoryForClass(category_t *cat, Class cls,
header_info *catHeader)
{
runtimeLock.assertWriting();
// DO NOT use cat->cls! cls may be cat->cls->isa instead
NXMapTable *cats = unattachedCategories();
category_list *list;
list = (category_list *)NXMapGet(cats, cls);
if (!list) {
list = (category_list *)
calloc(sizeof(*list) + sizeof(list->list[0]), 1);
} else {
list = (category_list *)
realloc(list, sizeof(*list) + sizeof(list->list[0]) * (list->count + 1));
}
list->list[list->count++] = (locstamped_category_t){cat, catHeader};
NXMapInsert(cats, cls, list);
}
static NXMapTable *unattachedCategories(void)
{
runtimeLock.assertWriting();
//全局對象
static NXMapTable *category_map = nil;
if (category_map) return category_map;
// fixme initial map size
category_map = NXCreateMapTable(NXPtrValueMapPrototype, 16);
return category_map;
}
複製代碼
對上面的代碼進行解讀：
- 1.經過
unattachedCategories()函數生成一個全局對象cats - 2.咱們從這個單例對象中查找
cls，獲取一個category_list*list列表 - 3.要是沒有
list指針。那麼咱們就生成一個category_list空間。 - 4.要是有
list指針，那麼就在該指針的基礎上再分配出category_list大小的空間 - 5.在這新分配好的空間，將這個
cat和catHeader寫入。 - 6.將數據插入到
cats中,key是cls, 值是list
remethodizeClass
static void remethodizeClass(Class cls)
{
//分類數組
category_list *cats;
bool isMeta;
runtimeLock.assertWriting();
isMeta = cls->isMetaClass();
// Re-methodizing: check for more categories
if ((cats = unattachedCategoriesForClass(cls, false/*not realizing*/))) {
if (PrintConnecting) {
_objc_inform("CLASS: attaching categories to class '%s' %s",
cls->nameForLogging(), isMeta ? "(meta)" : "");
}
attachCategories(cls, cats, true /*flush caches*/);
free(cats);
}
}
複製代碼
在remethodizeClass函數中將經過attachCategories函數咱們的分類信息附加到該類中。
attachCategories
//cls = [Person class]
//cats = [category_t(Eat),category_t(Drink)]
static void
attachCategories(Class cls, category_list *cats, bool flush_caches)
{
if (!cats) return;
if (PrintReplacedMethods) printReplacements(cls, cats);
bool isMeta = cls->isMetaClass();
// 從新分配內存
method_list_t **mlists = (method_list_t **)
malloc(cats->count * sizeof(*mlists));
property_list_t **proplists = (property_list_t **)
malloc(cats->count * sizeof(*proplists));
protocol_list_t **protolists = (protocol_list_t **)
malloc(cats->count * sizeof(*protolists));
// Count backwards through cats to get newest categories first
int mcount = 0;
int propcount = 0;
int protocount = 0;
int i = cats->count;
bool fromBundle = NO;
while (i--) {
auto& entry = cats->list[i];
method_list_t *mlist = entry.cat->methodsForMeta(isMeta);
if (mlist) {
mlists[mcount++] = mlist;
fromBundle |= entry.hi->isBundle();
}
property_list_t *proplist =
entry.cat->propertiesForMeta(isMeta, entry.hi);
if (proplist) {
proplists[propcount++] = proplist;
}
protocol_list_t *protolist = entry.cat->protocols;
if (protolist) {
protolists[protocount++] = protolist;
}
}
auto rw = cls->data();
prepareMethodLists(cls, mlists, mcount, NO, fromBundle);
rw->methods.attachLists(mlists, mcount);
free(mlists);
if (flush_caches && mcount > 0) flushCaches(cls);
rw->properties.attachLists(proplists, propcount);
free(proplists);
rw->protocols.attachLists(protolists, protocount);
free(protolists);
}
複製代碼
對上面的代碼進行解讀（假設cls是類對象，元類對象分析同理）：
-
1.根據方法列表、屬性列表、協議列表分配內存
-
2.
cats是這種數據結構：[category_t(Eat),category_t(Drink)，。。。]，遍歷cats，而後- 1.獲取一個分類裏面的全部對象方法，存儲在
mlist數組中，而後再將mlist數組添加到二維數組mlists中 - 2.獲取一個分類裏面的全部協議，存儲在
proplist數組中，而後再將proplist數組添加到二維數組proplists中 - 3.獲取一個分類裏面的全部屬性，存儲在
protolist數組中，而後再將protolist數組添加到二維數組protolists中
- 1.獲取一個分類裏面的全部對象方法，存儲在
-
3.獲取
cls的的bits指針class_rw_t,經過attachLists方法，將mlists附加到類對象方法列表中，將proplists附加到類對象的屬性列表中，將protolists附加到類對象的協議列表中
其中mlists的數據結構以下,proplists與protolists同理：
[
[method_t,method_t],
[method_t,method_t]
]
複製代碼
attachLists
void attachLists(List* const * addedLists, uint32_t addedCount) {
if (addedCount == 0) return;
if (hasArray()) {
// many lists -> many lists
uint32_t oldCount = array()->count;
uint32_t newCount = oldCount + addedCount;
setArray((array_t *)realloc(array(), array_t::byteSize(newCount)));
array()->count = newCount;
memmove(array()->lists + addedCount, array()->lists,
oldCount * sizeof(array()->lists[0]));
memcpy(array()->lists, addedLists,
addedCount * sizeof(array()->lists[0]));
}
else if (!list && addedCount == 1) {
// 0 lists -> 1 list
list = addedLists[0];
}
else {
// 1 list -> many lists
List* oldList = list;
uint32_t oldCount = oldList ? 1 : 0;
uint32_t newCount = oldCount + addedCount;
setArray((array_t *)malloc(array_t::byteSize(newCount)));
array()->count = newCount;
if (oldList) array()->lists[addedCount] = oldList;
memcpy(array()->lists, addedLists,
addedCount * sizeof(array()->lists[0]));
}
}
複製代碼
在attachLists方法主要關注兩個變量array()->lists和addedLists
- array()->lists： 類對象原來的方法列表，屬性列表，協議列表，好比Person中的那些方法等
- addedLists：傳入全部分類的方法列表，屬性列表，協議列表，好比Person(Eat)、Person(Drink)中的那些方法等。
上面代碼的做用就是經過memmove將原來的類找那個的方法、屬性、協議列表分別進行後移，而後經過memcpy將傳入的方法、屬性、協議列表填充到開始的位置。
咱們來總結一下這個過程：
-
經過Runtime加載某個類的全部Category數據
-
把全部Category的方法、屬性、協議數據，合併到一個大數組中，後面參與編譯的Category數據，會在數組的前面
-
將合併後的分類數據（方法、屬性、協議），插入到類原來數據的前面
咱們能夠用以下的動畫來表示一下這個過程（更多動畫相關可在公衆號內獲取）
- 1)、category的方法沒有「徹底替換掉」原來類已經有的方法，也就是說若是category和原來類都有methodA，那麼category附加完成以後，類的方法列表裏會有兩個methodA.
- 2)、category的方法被放到了新方法列表的前面，而原來類的方法被放到了新方法列表的後面，這也就是咱們日常所說的category的方法會「覆蓋」掉原來類的同名方法，這是由於運行時在查找方法的時候是順着方法列表的順序查找的，它只要一找到對應名字的方法，就會罷休^_^，卻不知後面可能還有同樣名字的方法。
咱們經過代碼來驗證一下上面兩個注意點是否正確
load與initialize
load方法與initialize方法的調用與通常普通方法的調用有所區別，所以筆者將其放在這一節一併分析進行想對比
load源碼分析
一樣的，咱們按照以下函數的調用順序，一步一步的研究load的加載處理過程
void _objc_init(void);
└── void load_images(...);
└── void call_load_methods(...);
└── void call_class_loads(...);
複製代碼
咱們直接從load_images方法進行分析
void
load_images(const char *path __unused, const struct mach_header *mh)
{
// Return without taking locks if there are no +load methods here.
if (!hasLoadMethods((const headerType *)mh)) return;
recursive_mutex_locker_t lock(loadMethodLock);
// Discover load methods
{
rwlock_writer_t lock2(runtimeLock);
prepare_load_methods((const headerType *)mh);
}
// Call +load methods (without runtimeLock - re-entrant)
call_load_methods();
}
複製代碼
在load_images方法中主要關注prepare_load_methods方法與call_load_methods方法
prepare_load_methods
void prepare_load_methods(header_info *hi)
{
size_t count, i;
rwlock_assert_writing(&runtimeLock);
classref_t *classlist =
_getObjc2NonlazyClassList(hi, &count);
for (i = 0; i < count; i++) {
schedule_class_load(remapClass(classlist[i]));
}
category_t **categorylist = _getObjc2NonlazyCategoryList(hi, &count);
for (i = 0; i < count; i++) {
category_t *cat = categorylist[i];
Class cls = remapClass(cat->cls);
if (!cls) continue; // category for ignored weak-linked class
realizeClass(cls);
assert(cls->ISA()->isRealized());
add_category_to_loadable_list(cat);
}
}
複製代碼
static void schedule_class_load(Class cls)
{
if (!cls) return;
assert(cls->isRealized()); // _read_images should realize
if (cls->data()->flags & RW_LOADED) return;
// 確保父類優先的順序
schedule_class_load(cls->superclass);
add_class_to_loadable_list(cls);
cls->setInfo(RW_LOADED);
}
複製代碼
顧名思義，這個函數的做用就是提早準備好知足 +load 方法調用條件的類和分類，以供接下來的調用。 而後在這個類中調用了schedule_class_load(Class cls)方法，而且在入參時對父類遞歸的調用了，確保父類優先的順序。
call_load_methods
通過prepare_load_methods的準備，接下來call_load_methods就開始大顯身手了。
void call_load_methods(void)
{
static BOOL loading = NO;
BOOL more_categories;
recursive_mutex_assert_locked(&loadMethodLock);
// Re-entrant calls do nothing; the outermost call will finish the job.
if (loading) return;
loading = YES;
void *pool = objc_autoreleasePoolPush();
do {
// 1. Repeatedly call class +loads until there aren't any more while (loadable_classes_used > 0) { call_class_loads(); } // 2. Call category +loads ONCE more_categories = call_category_loads(); // 3. Run more +loads if there are classes OR more untried categories } while (loadable_classes_used > 0 || more_categories); objc_autoreleasePoolPop(pool); loading = NO; } 複製代碼
在call_load_methods中咱們看do循環這個方法，它調用上一步準備好的類和分類中的 +load 方法，而且確保類優先於分類的順序。
call_class_loads
call_class_loads是load方法調用的核心方法
static void call_class_loads(void)
{
int i;
// Detach current loadable list.
struct loadable_class *classes = loadable_classes;
int used = loadable_classes_used;
loadable_classes = nil;
loadable_classes_allocated = 0;
loadable_classes_used = 0;
// Call all +loads for the detached list.
for (i = 0; i < used; i++) {
Class cls = classes[i].cls;
load_method_t load_method = (load_method_t)classes[i].method;
if (!cls) continue;
if (PrintLoading) {
_objc_inform("LOAD: +[%s load]\n", cls->nameForLogging());
}
(*load_method)(cls, SEL_load);
}
// Destroy the detached list.
if (classes) _free_internal(classes);
}
複製代碼
這個函數的做用就是真正負責調用類的 +load 方法了。它從全局變量 loadable_classes 中取出全部可供調用的類，並進行清零操做。
loadable_classes = nil;
loadable_classes_allocated = 0;
loadable_classes_used = 0;
複製代碼
其中 loadable_classes 指向用於保存類信息的內存的首地址，loadable_classes_allocated 標識已分配的內存空間大小，loadable_classes_used 則標識已使用的內存空間大小。
而後，循環調用全部類的 +load 方法。注意，這裏是（調用分類的 +load 方法也是如此）直接使用函數內存地址的方式 (*load_method)(cls, SEL_load); 對 +load 方法進行調用的，而不是使用發送消息 objc_msgSend 的方式。
可是若是咱們寫[Student load]時，這是使用發送消息 objc_msgSend 的方式。
舉個🌰：
@interface Person : NSObject
@end
@implementation Person
+ (void)load{
NSLog(@"%s",__func__);
}
@end
複製代碼
@interface Student : Person
@end
@implementation Student
//+ (void)load{
// NSLog(@"%s",__func__);
//}
@end
複製代碼
int main(int argc, const char * argv[]) {
@autoreleasepool {
[Student load];
}
return 0;
}
複製代碼
輸出以下：
第一句走的是load的加載方式，而第二句走的是objc_msgSend中消息發送機制，isa指針經過superclass在父類中找到類方法。
小總結：
+load方法會在runtime加載類、分類時調用- 每一個類、分類的+load，在程序運行過程當中只調用一次
- 調用順序
1.先調用類的+load
按照編譯前後順序調用（先編譯，先調用）
調用子類的+load以前會先調用父類的+load
2.再調用分類的+load
按照編譯前後順序調用（先編譯，先調用）
initialize源碼分析
一樣的，咱們按照以下函數的調用順序，一步一步的研究initialize的加載處理過程
Method class_getInstanceMethod(Class cls, SEL sel);
└── IMP lookUpImpOrNil(Class cls, SEL sel, id inst, bool initialize, bool cache, bool resolver);
└── IMP lookUpImpOrForward(Class cls, SEL sel, id inst, bool initialize, bool cache, bool resolver);
└── void _class_initialize(Class cls);
└── void callInitialize(Class cls);
複製代碼
咱們直接打開objc-runtime-new.mm文件來研究lookUpImpOrForward這個方法
lookUpImpOrForward
IMP lookUpImpOrForward(Class cls, SEL sel, id inst,
bool initialize, bool cache, bool resolver)
{
...
rwlock_unlock_write(&runtimeLock);
}
if (initialize && !cls->isInitialized()) {
_class_initialize (_class_getNonMetaClass(cls, inst));
// If sel == initialize, _class_initialize will send +initialize and
// then the messenger will send +initialize again after this
// procedure finishes. Of course, if this is not being called
// from the messenger then it won't happen. 2778172 } // The lock is held to make method-lookup + cache-fill atomic // with respect to method addition. Otherwise, a category could ... } 複製代碼
initialize && !cls->isInitialized()判斷代碼代表當一個類須要初始化卻沒有初始化時，會調用_class_initialize進行初始化。
_class_initialize
void _class_initialize(Class cls)
{
...
Class supercls;
BOOL reallyInitialize = NO;
// Make sure super is done initializing BEFORE beginning to initialize cls.
// See note about deadlock above.
supercls = cls->superclass;
if (supercls && !supercls->isInitialized()) {
_class_initialize(supercls);
}
...
callInitialize(cls);
...
}
複製代碼
一樣的supercls && !supercls->isInitialized()代表對入參的父類進行了遞歸調用，以確保父類優先於子類初始化。
callInitialize
void callInitialize(Class cls)
{
((void(*)(Class, SEL))objc_msgSend)(cls, SEL_initialize);
asm("");
}
複製代碼
最後在callInitialize中經過發送消息 objc_msgSend 的方式對 +initialize方法進行調用,也就是說+ initialize與通常普通方法的調用處理是同樣的。 舉個🌰：
@interface Person : NSObject
@end
@implementation Person
+ (void)initialize{
NSLog(@"%s",__func__);
}
@end
@implementation Person (Eat)
+ (void)initialize{
NSLog(@"%s",__func__);
}
@end
複製代碼
@interface Student : Person
@end
@implementation Student
+ (void)initialize{
NSLog(@"%s",__func__);
}
@end
複製代碼
@interface Teacher : Person
@end
@implementation Teacher
@end
複製代碼
int main(int argc, const char * argv[]) {
@autoreleasepool {
[Student alloc];
[Student initialize];
[Person alloc];
[Person alloc];
[Person alloc];
[Person alloc];
[Person alloc];
[Person alloc];
NSLog(@"****分割線***");
[Teacher alloc];
[Teacher initialize];
}
return 0;
}
複製代碼
輸出以下：
小總結：
+initialize方法會在類第一次接收到消息時調用- 調用順序
- 先調用父類的+initialize，再調用子類的+initialize
- 先初始化父類，再初始化子類，每一個類只會初始化1次
load與initialize對比
| 條件 | +load | +initialize |
|---|---|---|
| 關鍵方法 | (*load_method)(cls, SEL_load) |
objc_msgSend |
| 調用時機 | 被添加到 runtime 時 | 收到第一條消息前，可能永遠不調用 |
| 調用順序 | 父類->子類->分類 | 父類->子類 |
| 調用次數 | 1次 | 屢次 |
| 是否須要顯式調用父類實現 | 否 | 否 |
| 是否沿用父類的實現 | 否 | 是 |
| 分類中的實現 | 類和分類都執行 | 覆蓋類中的方法，只執行分類的實現 |
面試題
1.Category的使用場合是什麼？
-
- 給現有的類添加方法
-
- 將一個類的實現拆分紅多個獨立的源文件
-
- 聲明私有的方法
2.Category和Class Extension的區別是什麼？
-
- Class Extension是編譯時決議，在編譯的時候，它的數據就已經包含在類信息中
-
- Category是運行時決議，在運行時，纔會將數據合併到類信息中（可經過上面的動畫進行理解
^_^）
- Category是運行時決議，在運行時，纔會將數據合併到類信息中（可經過上面的動畫進行理解
3.Category的實現原理？
-
- Category編譯以後的底層結構是
struct category_t，裏面存儲着分類的對象方法、類方法、屬性、協議信息
- Category編譯以後的底層結構是
-
- 在程序運行的時候，runtime會將Category的數據，合併到類信息中（類對象、元類對象中）(依舊可經過上面的動畫進行理解
-_-||）)
- 在程序運行的時候，runtime會將Category的數據，合併到類信息中（類對象、元類對象中）(依舊可經過上面的動畫進行理解
4.一個類的有多個分類方法，分類中都含有與原類同名的方法，請問調用改方法時會調用誰的方法？分類會覆蓋原類的方法嗎？
不會覆蓋！全部分類的方法會在運行時將它們的方法都合併到一個大數組中，後面參與編譯的Category數據，會在數組的前面，而後再將該數組合併到類信息中，調用時順着方法列表的順序查找。
5.load與initialize的區別
見load與initialize對比章節的表格
6.Category可否添加成員變量？若是能夠，如何給Category添加成員變量？
不能直接給Category添加成員變量，可是能夠經過關聯對象或者全局字典等方式間接實現Category有成員變量的效果
相關文章
- 1. iOS Category底層原理詳細研究流程
- 2. iOS底層原理之部分面試題分析
- 3. hashMap 底層原理+LinkedHashMap 底層原理+常見面試題
- 4. iOS底層原理(二):Runtime研究(二)
- 5. iOS底層原理總結 -- 利用Runtime源碼 分析Category的底層實現
- 6. 面試_HashMap底層原理
- 7. Java面試底層原理
- 8. 面試題 HashMap底層實現原理
- 9. Kafka底層原理及面試題（三）
- 10. iOS中Category的底層實現原理
- 更多相關文章...
- • Git 分支管理 - Git 教程
- • MyBatis的工作原理 - MyBatis教程
- • ☆技術問答集錦（13）Java Instrument原理
- • Java Agent入門實戰（三）-JVM Attach原理與使用
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
歡迎關注本站公眾號,獲取更多信息
