OC分类底层实现与使⽤场景详解

334次阅读  |  发布于3年以前

OC分类(Category)简介

OC作为⼀⻔⾯向对象的编程语⾔,在封装、继承、多态这三⼤特性上可谓完美传承了C++优点,当我们想对⼀个类的⽅法和成员变量拓展的时候,我们⾸先想到是继承,但是OC还提供给我们另⼀种⽅法去完成对⼀个类的拓展,这种⽅式相⽐于继承更加的灵活⽅便,结合OC的Runtime特性能满⾜更多的开发场景,这种对类的拓展⽅式就是OC的特性之⼀:分类(Category)。

分类(Category)作为开发⼈员在⼯作中再熟悉不过的语法特性,⼀直是我们开发过程中不可或缺的⼀个特性,我们经常利⽤分类的特性解决⼀些实际开发问题,我们对⼀些使⽤分类的开发场景做⼀个简单的总结:

接下来让我从分类(Category)底层实现开始,先对分类有⼀个数据结构上的认知,然后再从源码的⻆度去分析⼀下分类的的加载过程和内存管理与类的区别与联系,来帮助我们理解⼀些分类的特性,最后我们会简单介绍⼀下load和initialize这两个⽐较特殊的⽅法在分类中调⽤时机和顺序,让我们在使⽤分类的时候更加的游刃有余,下⾯让我们⼀起开始吧。

分类(Category)底层实现关于分类的写法和语法规则,相信⼤家都⽐较熟悉了,本⽂不做过多介绍,下⾯以NSObject的⼀个分类NSOBject+JDFunc为例,来分析⼀下分类的底层实现,通过clang命令将OC转为C++代码,如果想看更新更加准确的源码实现建议下载objc源码库查看。

(https://opensource.apple.com/tarballs/objc4/objc4-818.2.tar.gz),本⽂旨在通过分类底层实现原理解决⼀些我们对分类的疑惑,故不做详细的底层实现细节分析。我们可以看到分类的如下代码实现:

//分类的结构定义
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; //包含的属性
};
//声明变量 _OBJC_$_CATEGORY_INSTANCE_METHODS_NSObject_$_JDFunc 并初始化
//类⽅法存储⽅式类似,不重复列举
static struct /*_method_list_t*/ {
unsigned int entsize; // sizeof(struct _objc_method)
unsigned int method_count; //⽅法个数
struct _objc_method method_list[2]; //存储⽅法的数组
} _OBJC_$_CATEGORY_INSTANCE_METHODS_NSObject_$_JDFunc __attribute__ ((used, section ("__DATA,__objc_const")))
sizeof(_objc_method),
2,
{{(struct objc_selector *)"instanceFunctionTest1", "v16@0:8", (void *)_I_NSObject_JDFunc_instanceFunction
{(struct objc_selector *)"instanceFunctionTest2", "v16@0:8", (void *)_I_NSObject_JDFunc_instanceFunctionT
};
//声明变量 _OBJC_CATEGORY_PROTOCOLS_$_NSObject_$_JDFunc 并初始化
static struct /*_protocol_list_t*/ {
long protocol_count; // Note, this is 32/64 bit
struct _protocol_t *super_protocols[2]; //协议个数
} _OBJC_CATEGORY_PROTOCOLS_$_NSObject_$_JDFunc __attribute__ ((used, section ("__DATA,__objc_const"))) = {
2,
&_OBJC_PROTOCOL_NSCopying, //NSCopying 协议
&_OBJC_PROTOCOL_NSCoding //NSCoding 协议
};
//分类的的初始化
static struct _category_t _OBJC_$_CATEGORY_NSObject_$_JDFunc __attribute__ ((used, section ("__DATA,__objc_co

通过上⾯分类实现代码可以知道,和类⼀样,分类也是通过结构体实现的,从上述源码实现中我们可以发现,分类结构体有5个成员变量组成,分别描述了分类所属的类的名称、所属类对象的描述、指向存储实例⽅法列表结构的指针、指向存储类⽅法列表结构的指针、指向存储协议列表结构的指针、指向存储属性列表结构的指针。

需要注意的是在分类添加属性的时候是不会⾃动⽣成成员变量的,从我们的上⾯列举的源码也可以看出,在分类的结构体当中是没有存储属性值的成员变量的,这⼀点我们可以对⽐类的实例的结构体做⼀个⽐较。

//
struct MyNSObject_IMPL {
struct NSObject_IMPL NSObject_IVARS;
int _a;
NSString *_b;
};

从上⾯的代码可以看出类对象的结构体中会⽣成对应的成员变量⽤于存储我们在定义类中添加属性时⽣成的成员变量。

分类(Catergory)加载过程

我们知道,在OC程序的启动过程中,会读取⼆进制⽂件Mach-O的DATA段,找到与objc相关的信息,注册objc类,确保selector的唯⼀性,读取protocol以及category的信息,程序的启动过程本⽂不做详细解析,在此我们只需要要了解在OC类的注册过程中对category的处理。

在程序的启动将Mach-O可执⾏⽂件加载到内存的过程中,有这样⼀个函数。

//
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();
runtime_init();
exception_init();
_imp_implementationWithBlock_init();
//dylb将image镜像⽂件加载到内存时会触发
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
}

我们看⼀下_dyld_objc_notify_register函数的⼊参map_images函数,map_images的主要作⽤是管理⽂件中所有class、protocol、selector、category 等信息,所以我们可以从这个⽅法的实现中窥探到底层对分类(Category)是如何管理的。

//
void map_images(unsigned count, const char * const paths[],
const struct mach_header * const mhdrs[])
{
mutex_locker_t lock(runtimeLock);
//返回map_images_nolock 函数的返回值
/*
{
"NSObject",
0, // &OBJC_CLASS_$_NSObject,
(const struct _method_list_t *)&_OBJC_$_CATEGORY_INSTANCE_METHODS_NSObject_$_JDFunc,
(const struct _method_list_t *)&_OBJC_$_CATEGORY_CLASS_METHODS_NSObject_$_JDFunc,
(const struct _protocol_list_t *)&_OBJC_CATEGORY_PROTOCOLS_$_NSObject_$_JDFunc,
0,
};
count:镜像⽂件的个数
paths:镜像⽂件的路径
mhdrs:镜像⽂件的头信息
*/
return map_images_nolock(count, paths, mhdrs);
}
//
void map_images_nolock(unsigned mhCount, const char * const mhPaths[],
const struct mach_header * const mhdrs[])
{
static bool firstTime = YES;
header_info *hList[mhCount];
uint32_t hCount;
size_t selrefCount = 0;
...
hCount = 0;
int totalClasses = 0;
int unoptimizedTotalClasses = 0;
{...}
if (firstTime) {...}
if (hCount > 0) {
//读取镜像⽂件
_read_images(hList, hCount, totalClasses, unoptimizedTotalClasses);
}
...
for (auto func : loadImageFuncs) {...}
}

从上⾯代码可以看出,关键⾏代码是 _read_images()读取镜像⽂件, 我们继续看⼀下这个函数的实现。

//
void _read_images(header_info **hList, uint32_t hCount, int totalClasses, int unoptimizedTotalClasses)
{
header_info *hi;
uint32_t hIndex;
size_t count;
size_t i;
Class *resolvedFutureClasses = nil;
size_t resolvedFutureClassCount = 0;
static bool doneOnce;
bool launchTime = NO;
TimeLogger ts(PrintImageTimes);
runtimeLock.assertLocked();
#define EACH_HEADER \
hIndex = 0; \
hIndex < hCount && (hi = hList[hIndex]); \
hIndex++
if (!doneOnce) {...}
//
static size_t UnfixedSelectors;
{...}
//
bool hasDyldRoots = dyld_shared_cache_some_image_overridden();
for (EACH_HEADER) {...}
//
if (!noClassesRemapped()) {...}
//
for (EACH_HEADER) {...}
for (EACH_HEADER) {...}
//发现类别。只有在完成初始类别附件之后才可以这样做。对于在启动时出现的类别,发现被推迟到调⽤_dyld_objc_notify_register完成
if (didInitialAttachCategories) {
for (EACH_HEADER) {
load_categories_nolock(hi);
}
}
// Realize non-lazy classes (for +load methods and static instances)

我们可以发现在分类的处理逻辑中有⼀个resolvedFutureClasses字段的判断,早objc源码中全局搜索这个字段,可以发现这个字段是在load_images字段置true的,也就是说这部分逻辑是在完成后的第⼀次load_images调⽤后才可⾛进去的。

接下来我们看下load_categories_nolock函数的实现。

//

static void load_categories_nolock(header_info *hi) {
bool hasClassProperties = hi->info()->hasCategoryClassProperties();
size_t count;
auto processCatlist = [&](category_t * const *catlist) {
//遍历所有分类,⼀个⼀个的添加到本类中

for (unsigned i = 0; i < count; i++) {
category_t *cat = catlist[i];
Class cls = remapClass(cat->cls);
locstamped_category_t lc{cat, hi};
if (!cls) {...}
if (cls->isStubClass()) {...} else {
if (cat->instanceMethods || cat->protocols
|| cat->instanceProperties)
{
//这⾥我们的类假已经完成初始化操作

if (cls->isRealized()) {
attachCategories(cls, &lc, 1, ATTACH_EXISTING);
} else {
objc::unattachedCategories.addForClass(lc, cls);
}
}
//类⽅法的处理

if (cat->classMethods || cat->protocols
|| (hasClassProperties && cat->_classProperties))
{
if (cls->ISA()->isRealized()) {
attachCategories(cls->ISA(), &lc, 1, ATTACH_EXISTING | ATTACH_METACLASS);
} else {
objc::unattachedCategories.addForClass(lc, cls->ISA());
}
}
}
}
};
processCatlist(hi->catlist(&count));
processCatlist(hi->catlist2(&count));
}

这个⽅法⾥的关键代码是attachCategories,关于类的初始化这⾥分许多情况,在此我们不做详细解析,假设现在我们的类已经完成了初始化,接下来我们来看attachCategories函数的具体实现。

for (EACH_HEADER) {
...
}
...
#undef EACH_HEADER

}
//

static void attachCategories(Class cls, const locstamped_category_t *cats_list, uint32_t cats_count, int flag
{
constexpr uint32_t ATTACH_BUFSIZ = 64;
method_list_t *mlists[ATTACH_BUFSIZ];
property_list_t *proplists[ATTACH_BUFSIZ];
protocol_list_t *protolists[ATTACH_BUFSIZ];
uint32_t mcount = 0;
uint32_t propcount = 0;
uint32_t protocount = 0;
bool fromBundle = NO;
bool isMeta = (flags & ATTACH_METACLASS);

我们可以发现在这个⽅法rwe是为了获取本类的bits数据,我们知道类对象⽅法、属性、协议列表是存在这个字段中,然后我们需要对这个字段做⼀些处理;代码中构造了⼀个mlists⼆维数组,我们从分类cat中取出的⽅法类标是放到了数组的最后⾯,其他如proplists(存放属性列表的⼆维数组)、protolists(存放属性列表的⼆维数组)的处理逻辑相同,接下来我们看关键⽅法attachLists,的具体实现。

class property_array_t :
public list_array_tt<property_t, property_list_t, RawPtr>
{
...
};
class protocol_array_t :
public list_array_tt<protocol_ref_t, protocol_list_t, RawPtr>
{
...
};
class method_array_t :
public list_array_tt<method_t, method_list_t, method_list_t_authed_ptr>
{
...
};
emplate <typename Element, typename List, template<typename> class Ptr>
class list_array_tt {
...
void attachLists(List* const * addedLists, uint32_t addedCount) {
if (addedCount == 0) return;
auto rwe = cls->data()->extAllocIfNeeded();
for (uint32_t i = 0; i < cats_count; i++) {
auto& entry = cats_list[i];
//获取分类中⽅法列表

method_list_t *mlist = entry.cat->methodsForMeta(isMeta);
if (mlist) {
...
}
//获取分类中属性列表

property_list_t *proplist =
entry.cat->propertiesForMeta(isMeta, entry.hi);
if (proplist) {
...
}
//获取分类中的协议列表

protocol_list_t *protolist = entry.cat->protocolsForMeta(isMeta);
if (protolist) {
...
}
}
if (mcount > 0) {
prepareMethodLists(cls, mlists + ATTACH_BUFSIZ - mcount, mcount,
NO, fromBundle, __func__);
//添加⽅法列表到本类⽅法列表中

rwe->methods.attachLists(mlists + ATTACH_BUFSIZ - mcount, mcount);
if (flags & ATTACH_EXISTING) {
flushCaches(cls, __func__, [](Class c){
// constant caches have been dealt with in prepareMethodLists

// if the class still is constant here, it's fine to keep

return !c->cache.isConstantOptimizedCache();
});
}
}
//添加属性列表到本类属性列表中

rwe->properties.attachLists(proplists + ATTACH_BUFSIZ - propcount, propcount);
//添加协议列表到本类协议列表中

rwe->protocols.attachLists(protolists + ATTACH_BUFSIZ - protocount, protocount);
}
if (hasArray()) {
//计算旧数组的⼤⼩

uint32_t oldCount = array()->count;
//计算现在所需⼤⼩

uint32_t newCount = oldCount + addedCount;
//初始化⼀个新的数组

array_t *newArray = (array_t *)malloc(array_t::byteSize(newCount));
//设置数组⼤⼩

newArray->count = newCount;
array()->count = newCount;
//将旧数据放到新⼆维数组的末尾

for (int i = oldCount - 1; i >= 0; i--)
newArray->lists[i + addedCount] = array()->lists[i];
//将新数据放到新⼆维数组的⾸部

for (unsigned i = 0; i < addedCount; i++)
newArray->lists[i] = addedLists[i];
free(array());
setArray(newArray);
validate();
}
else if (!list && addedCount == 1) {
// 0 lists -> 1 list

list = addedLists[0];
validate();
}
else {
// 1 list -> many lists

Ptr<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;
//将新数据放到新⼆维数组的⾸部

for (unsigned i = 0; i < addedCount; i++)
array()->lists[i] = addedLists[i];
validate();
}
}
...
}

由上⾯的的代码可以知道,分类中的数据总是放到本类数据列表的前⾯的,由OC⽅法机制中⽅法调⽤查询机制可知当分类和本类中有重名⽅法的时候,总是会调⽤分类的⽅法的,我们从源码的⻆度可以更清楚的认识到分类的这个特性。

接下来我们考虑另⼀个问题,当⼀个本类不同的分类中实现同⼀个⽅法的时候,调⽤的是哪个分类中的⽅法。在上⾯的源码中我们可以看到 processCatlist(hi->catlist(&count)); 其中hi是header_info 类型,在源码中我们知道header_info是Mach-O⽂件的头信息,让我们⼀起看下通过calist⽅法获取分类数据的实现。

category_t * const *header_info::catlist(size_t *outCount) const
{
if (isPreoptimized() && hasPreoptimizedSectionLookups()) {
*outCount = catlist_count;
//

category_t * const *list = (category_t * const *)(((intptr_t)&catlist_offset) + catlist_offset);
#if DEBUG

size_t debugCount;
assert((list == _getObjc2CategoryList(mhdr(), &debugCount)) && (*outCount == debugCount));
#endif

return list;
}
return _getObjc2CategoryList(mhdr(), outCount);
}
type *_getObjc2CategoryList(const headerType *mhdr, size_t *outCount) { \
return getDataSection<category_t * const>(mhdr, "__objc_catlist", nil, outCount); \
} \
type *_getObjc2CategoryList(const header_info *hi, size_t *outCount) { \
return getDataSection<category_t * const>(hi->mhdr(), "__objc_catlist", nil, outCount); \
}
template <typename T>
T* getDataSection(const headerType *mhdr, const char *sectname,
size_t *outBytes, size_t *outCount)
{
unsigned long byteCount = 0;
T* data = (T*)getsectiondata(mhdr, "__DATA", sectname, &byteCount);
if (!data) {
data = (T*)getsectiondata(mhdr, "__DATA_CONST", sectname, &byteCount);
}
if (!data) {
data = (T*)getsectiondata(mhdr, "__DATA_DIRTY", sectname, &byteCount);
}
if (outBytes) *outBytes = byteCount;
if (outCount) *outCount = byteCount / sizeof(T);
return data;
}

从上⾯的代码可知分类的数据是从数据区读取的,也就是说分类的加载顺序与分类的源代码在⽣成可执⾏⽂件时参与编译的顺序相关,这⾥可以记住⼀个结论:越晚参与编译的分类,其相关信息越是在本类的信息(⽅法/属性/协议)列表的的前⾯,越是优先被调⽤。

分类(Category)中load⽅法

上⽂中我们提到加载Mach-O镜像⽂件的时候会调⽤_dyld_objc_notify_register⽅法,在_dyld_objc_notify_register⽅法中第⼆个⼊参传⼊的是load_images⽅法,load_images⽅法的主要作⽤是加载镜像⽂件,我们看下load_images⽅法的源码实现:

void
load_images(const char *path __unused, const struct mach_header *mh)
{
...
// 查找load⽅法

{
mutex_locker_t lock2(runtimeLock);
prepare_load_methods((const headerType *)mh);
}
// 调⽤load⽅法

call_load_methods();
}

从load_images源码中我们发现两⾏关键代码prepare_load_methods和call_load_methods,分别是查找load⽅法和调⽤load⽅法,⾸先我们看下查找load⽅法的函数prepare_load_methods函数实现。

void prepare_load_methods(const headerType *mhdr)
{
size_t count, i;
runtimeLock.assertLocked();
//获取类列表

classref_t const *classlist =
_getObjc2NonlazyClassList(mhdr, &count);
//遍历类列表

for (i = 0; i < count; i++) {
//处理类中的load⽅法

schedule_class_load(remapClass(classlist[i]));
}
//获取分类列表

category_t * const *categorylist = _getObjc2NonlazyCategoryList(mhdr, &count);
//遍历分类列表

for (i = 0; i < count; i++) {
category_t *cat = categorylist[i];
Class cls = remapClass(cat->cls);
if (!cls) continue;
if (cls->isSwiftStable()) {
_objc_fatal("Swift class extensions and categories on Swift "

"classes are not allowed to have +load methods");
}
realizeClassWithoutSwift(cls, nil);
ASSERT(cls->ISA()->isRealized());
//处理分类中的laod⽅法

add_category_to_loadable_list(cat);
}
}
//处理类中的load⽅法

static void schedule_class_load(Class cls)
{
...
schedule_class_load(cls->getSuperclass());
//将类中的load⽅法添加到数组中

add_class_to_loadable_list(cls);
cls->setInfo(RW_LOADED);
}
//将类中的load⽅法添加到数组中

void add_class_to_loadable_list(Class cls)
{
IMP method;
loadMethodLock.assertLocked();
method = cls->getLoadMethod();
...
//添加类load⽅法添加到数组loadable_classes中

loadable_classes[loadable_classes_used].cls = cls;
loadable_classes[loadable_classes_used].method = method;
loadable_classes_used++;
}
//处理分类中的laod⽅法添加到数组中

void add_category_to_loadable_list(Category cat)
{
IMP method;
loadMethodLock.assertLocked();
method = _category_getLoadMethod(cat);
...
//添加分类load⽅法添加到数组loadable_categories中

loadable_categories[loadable_categories_used].cat = cat;
loadable_categories[loadable_categories_used].method = method;
loadable_categories_used++;
}

从上⾯我们对prepare_load_methods函数的实现逻辑中可以看到,最终会像类的load⽅法添加到loadable_classes数组中,⽽将分类中的load⽅法添加到loadable_categories,这是我们对load⽅法的处理过程,其中值得注意的⼀点是,⽆论是在add_category_to_loadable_list函数中还是在add_class_to_loadable_list函数中,我们保存的都是load⽅法IMP,既指向函数结构体的指针,我们可以直接调⽤该函数。

看完了load函数的处理过程,接下来我们看⼀下load⽅法的调⽤逻辑。

void call_load_methods(void)
{
...
do {
//循环调⽤类load⽅法

while (loadable_classes_used > 0) {
call_class_loads();
}
// 调⽤分类load⽅法

more_categories = call_category_loads();
} while (loadable_classes_used > 0 || more_categories);
objc_autoreleasePoolPop(pool);
loading = NO;
}
static void call_class_loads(void)
{
int i;
//调⽤所有load⽅法

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());
}
//调⽤laod⽅法,默认⼊参slef和cmd

(*load_method)(cls, @selector(load));
}
// Destroy the detached list.

if (classes) free(classes);
}
static bool call_category_loads(void)
{
int i, shift;
...
//调⽤所有load⽅法

for (i = 0; i < used; i++) {
Category cat = cats[i].cat;
load_method_t load_method = (load_method_t)cats[i].method;
Class cls;
if (!cat) continue;
cls = _category_getClass(cat);
if (cls && cls->isLoadable()) {
if (PrintLoading) {
_objc_inform("LOAD: +[%s(%s) load]\n",
cls->nameForLogging(),
_category_getName(cat));
}
//调⽤laod⽅法,默认⼊参slef和cmd

(*load_method)(cls, @selector(load));
cats[i].cat = nil;
}
}
...
...
return new_categories_added;
}

上⾯load⽅法的调⽤中我们可以看到call_load_methods会依次调⽤处理load⽅法过程中⽣成的两个存放load⽅法的数组loadable_classes和loadable_categories,从(*load_method)(cls, @selector(load))这句代码可以看出,是直接调⽤的load⽅法。

通过对load⽅法的处理过程和调⽤过程的分析,我们很容得出以下结论:

分类(Category)中initialize⽅法

initialize⽅法的调⽤时机我们从官⽅⽂档可以得知是在类⾸次接收到消息的时候进⾏调⽤,当我们给⼀个类通过objc_msgSend发送消息的时候,肯定会去查找类的⽅法列表,我们可以暂时猜测在查找的⽅法的过程中可能有关于initialize⽅法的处理,⾸先我们看下⽅法查找函数class_getInstanceMethod 的实现。

Method class_getInstanceMethod(Class cls, SEL sel)
{
if (!cls || !sel) return nil;

Method meth;
//如果⽅法存在缓存列表中,直接返回⽅法
meth = _cache_getMethod(cls, sel, _objc_msgForward_impcache);
if (meth == (Method)1) {
return nil;
} else if (meth) {
return meth;
}
//查找⽅法
lookUpImpOrForward(nil, sel, cls, LOOKUP_INITIALIZE | LOOKUP_RESOLVER);
//如果⽅法存在缓存列表中,直接返回⽅法
meth = _cache_getMethod(cls, sel, _objc_msgForward_impcache);
if (meth == (Method)1) {
// Cache contains forward:: . Stop searching.
return nil;
} else if (meth) {
return meth;
}
//从类的⽅法列表中获取⽅法
return _class_getMethod(cls, sel);
}
//关键代码lookUpImpOrForward(nil, sel, cls, LOOKUP_INITIALIZE | LOOKUP_RESOLVER);
IMP lookUpImpOrForward(id inst, SEL sel, Class cls, int behavior)
{
const IMP forward_imp = (IMP)_objc_msgForward_impcache;
IMP imp = nil;
Class curClass;
...
//判断是否initialize
cls = realizeAndInitializeIfNeeded_locked(inst, cls, behavior & LOOKUP_INITIALIZE);
// runtimeLock may have been dropped but is now locked again
runtimeLock.assertLocked();
curClass = cls;
...
return imp;
}
//
static Class realizeAndInitializeIfNeeded_locked(id inst, Class cls, bool initialize)
{
...
if (slowpath(initialize && !cls->isInitialized())) {
//进⾏初始化,如果已经被初始化,则跳过,既不会执⾏initialize⽅法
cls = initializeAndLeaveLocked(cls, inst, runtimeLock);
}
return cls;
}
static Class initializeAndLeaveLocked(Class cls, id obj, mutex_t& lock)
{
return initializeAndMaybeRelock(cls, obj, lock, true);
}
static Class initializeAndMaybeRelock(Class cls, id inst,
mutex_t& lock, bool leaveLocked)
{
lock.assertLocked();
ASSERT(cls->isRealized());
...
//初始化类
initializeNonMetaClass(nonmeta);
if (leaveLocked) runtimeLock.lock();
return cls;
}
void initializeNonMetaClass(Class cls)
{
ASSERT(!cls->isMetaClass());
Class supercls;
bool reallyInitialize = NO;
//递归调⽤, initializeNonMetaClass(⽗类)
supercls = cls->getSuperclass();
if (supercls && !supercls->isInitialized()) {
initializeNonMetaClass(supercls);
}
...
{
//调⽤initialize⽅法
callInitialize(cls);
...
}
...
}
//调⽤initialize⽅法
void callInitialize(Class cls)
{
((void(*)(Class, SEL))objc_msgSend)(cls, @selector(initialize));
asm("");
}

从上述initialize⽅法调⽤流程中我们可以发现在类初始化initializeNonMetaClass函数中会递归调⽤,直到没有⽗类为⽌,所以⽗类会优先被函数callInitialize处理,在函数callInitialize中我们可以看到是通过objc_msgSend调⽤的initialize⽅法,⾄此⾛正常的OC⽅法机制,遵守⽅法查询原则。

通过以上对initialize⽅法调⽤流程我们可以得出以下结论:

结束语

本⽂对分类的底层实现和加载过程从源码的⻆度进⾏了⼀些分析,能更好的帮助我们理解分类(Category)的⼀些特性,让我们在使⽤分类的⼀些开发场景中更加的游刃有余,同时⽂中还对load⽅法和initialize初始化⽅法做了⼀些浅析,已便我们能更好的配合分类的使⽤,⽂中⼀些注释和讲解基于⽹上的⼀些资料和⾃⼰的⼀些理解,可能会有偏差,欢迎指正。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8