为什么要设计metaclass

源代码来自objc-750

__objc_msg发送

ENTRY _objc_msgSendUNWIND _objc_msgSend, NoFramecmpp0,#0 // nil check and tagged pointer check#if SUPPORT_TAGGED_POINTERSb.leLNilOrTagged// (MSB tagged pointer looks negative)#elseb.eqLReturnZero#endifldrp13, [x0]// p13 = isaGetClassFromIsa_p16 p13// p16 = classLGetIsaDone:CacheLookup NORMAL// calls imp or objc_msgSend_uncached#if SUPPORT_TAGGED_POINTERSLNilOrTagged:b.eqLReturnZero// nil check// taggedadrpx10, _objc_debug_taggedpointer_classes@PAGEaddx10, x10, _objc_debug_taggedpointer_classes@PAGEOFFubfxx11, x0,#60, #4ldrx16, [x10, x11, LSL#3]adrpx10, _OBJC_CLASS_$___NSUnrecognizedTaggedPointer@PAGEaddx10, x10, _OBJC_CLASS_$___NSUnrecognizedTaggedPointer@PAGEOFFcmpx10, x16b.neLGetIsaDone// ext taggedadrpx10, _objc_debug_taggedpointer_ext_classes@PAGEaddx10, x10, _objc_debug_taggedpointer_ext_classes@PAGEOFFubfxx11, x0,#52, #8ldrx16, [x10, x11, LSL#3]bLGetIsaDone// SUPPORT_TAGGED_POINTERS#endifLReturnZero:// x0 is already zeromovx1,#0movid0,#0movid1,#0movid2,#0movid3,#0retEND_ENTRY _objc_msgSend复制代码

原始码给的部分注释，不愿看代码的直接看下面的流程吧1，进入_objc_msgSend后首先判断消息的接受者是否为nil或是否使用了tagPointer技术，由于这里是为了探究存在META-CLASS的意义，所以关于tagPointer的东西就直接直接忽略了。2，根据消息接受者的isa指针找到metaclass（因为类方法存在元类中。如果调用的是实例方法，isa指针指向的是类对象。）3，进入CacheLookup流程，这一步会去寻找方法缓存，如果缓存命中中则直接调用方法的实现，如果缓存不存在则进入objc_msgSend_uncached流程。

缓存查找

/********************************************************************** CacheLookup NORMAL|GETIMP|LOOKUP** Locate the implementationfora selectorina class method cache.** Takes:* x1 = selector* x16 = class to be searched** Kills:* x9,x10,x11,x12, x17** Onexit: (found) calls or returns IMP* with x16 = class, x17 = IMP* (not found) jumps to LCacheMiss*********************************************************************/#define NORMAL 0#define GETIMP 1#define LOOKUP 2// CacheHit: x17 = cached IMP, x12 = address of cached IMP.macro CacheHit.if$0== NORMALTailCallCachedImp x17, x12// authenticate and call imp.elseif$0== GETIMPmovp0, p17AuthAndResignAsIMP x0, x12// authenticate imp and re-sign as IMPret//returnIMP.elseif$0== LOOKUPAuthAndResignAsIMP x17, x12// authenticate imp and re-sign as IMPret//returnimp via x17.else.abort oops.endif.endmacro.macro CheckMiss// missifbucket->sel == 0.if$0== GETIMPcbzp9, LGetImpMiss.elseif$0== NORMALcbzp9, __objc_msgSend_uncached.elseif$0== LOOKUPcbzp9, __objc_msgLookup_uncached.else.abort oops.endif.endmacro.macro JumpMiss.if$0== GETIMPbLGetImpMiss.elseif$0== NORMALb__objc_msgSend_uncached.elseif$0== LOOKUPb__objc_msgLookup_uncached.else.abort oops.endif.endmacro.macro CacheLookup// p1 = SEL, p16 = isaldpp10, p11, [x16,#CACHE] // p10 = buckets, p11 = occupied|mask#if !__LP64__andw11, w11, 0xffff// p11 = mask#endifandw12, w1, w11// x12 = _cmd & maskaddp12, p10, p12, LSL#(1+PTRSHIFT)// p12 = buckets + ((_cmd & mask) << (1+PTRSHIFT))ldpp17, p9, [x12]// {imp, sel} = *bucket1:cmpp9, p1//if(bucket->sel != _cmd)b.ne2f// scan moreCacheHit$0// call orreturnimp2:// not hit: p12 = not-hit bucketCheckMiss$0// missifbucket->sel == 0cmpp12, p10// wrapifbucket == bucketsb.eq3fldpp17, p9, [x12,#-BUCKET_SIZE]! // {imp, sel} = *--bucketb1b// loop3:// wrap: p12 = first bucket, w11 = maskaddp12, p12, w11, UXTW#(1+PTRSHIFT)// p12 = buckets + (mask << 1+PTRSHIFT)// Clone scanning loop to miss instead of hang when cache is corrupt.// The slow path may detect any corruption and halt later.ldpp17, p9, [x12]// {imp, sel} = *bucket1:cmpp9, p1//if(bucket->sel != _cmd)b.ne2f// scan moreCacheHit$0// call orreturnimp2:// not hit: p12 = not-hit bucketCheckMiss$0// missifbucket->sel == 0cmpp12, p10// wrapifbucket == bucketsb.eq3fldpp17, p9, [x12,#-BUCKET_SIZE]! // {imp, sel} = *--bucketb1b// loop3:// double wrapJumpMiss$0.endmacro复制代码

之前的_objc_msgSend代码中我们知道CacheLookup走的是NORMAL流程，别的支线代码就忽略了从上述代码中可见发现当缓存命中时会调用TailCallCachedImp验证方法IMP的有效并调用改方法的实现，如果缓存没有命中中则进入__objc_msgSend_uncached流程。

关于缓存是如何缓存和寻找缓存的，后续会写博客进行详解。

__objc_msgSend_uncached

STATIC_ENTRY __objc_msgSend_uncachedUNWIND __objc_msgSend_uncached, FrameWithNoSaves// THIS IS NOT A CALLABLE C FUNCTION// Out-of-band p16 is the class to searchMethodTableLookupTailCallFunctionPointer x17END_ENTRY __objc_msgSend_uncached// MethodTableLookup.macro MethodTableLookup*这里忽略寄存器的操作*// receiver and selector alreadyinx0 and x1movx2, x16bl__class_lookupMethodAndLoadCache3*这里忽略寄存器的操作*.endmacro复制代码

一通操作后从后面调用到了_class_lookupMethodAndLoadCache3这个方法，该方法在objc_runtim_new.mm文件中，终于从汇编代码中走了出来！

__class_lookupMethodAndLoadCache3

IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls){returnlookUpImpOrForward(cls, sel, obj,YES/*initialize*/, NO/*cache*/, YES/*resolver*/);}复制代码

该方法会去调用lookUpImpOrForward，由于lookUpImpOrForward方法篇幅有点长，这里简述一下该方法的流程。

1，首先会再一次的从类中寻找需要调用方法的缓存，如果能命中缓存直接返回该方法的实现，如果不能命中则继续往下走。

2，从类的方法列表中寻找该方法，如果能从列表中找到方法则对方法进行缓存并返回该方法的实现，如果找到该方法则继续往下走。

3，从父类的缓存寻找该方法，如果父类缓存能命中则将方法缓存至当前调用方法的类中（注意此处不是存进父类），如果缓存未命中则遍历父类的方法列表，之后操作著名第2步，替代命中则继续走第3步直到寻找到基类。

4，如果到基类依然没有找到该方法则触发动态方法解析流程。

5，还是找到就触发消息转发流程

走到这里一套方法发送的流程就都走完了，那这跟元类的存在有啥关系？我们都知道类方法是存储在元类中的，那么可不可以把元类干掉，在类中把实例方法和类方法存在两个不同的副本中？

答：行是肯定可行的，但是在lookUpImpOrForward执行的时候就得标注上预期的cls到底是实例对象还是类对象，这也就意味着在查找方法的缓存时同样也需要判断cls到底是个啥。

倘若该该类存在同名的类方法和实例方法是该调用该方法呢？这也就意味着还得给给的该方法带上是类方法还是实例方法的标识，SEL并没有带上当前方法的类型（实例方法还是类方法），参数又多加一个，而我们现在的objc_msgSend()只接收了（id self，SEL _cmd，...）这类型参数，第一个自我就是消息的接收者，第二个就是方法，后续的...就是各式各样的参数。

通过元类就可以准确的解决上述问题，让各类各司其职，实例对象就干存储属性值的事，类对象存储实例方法列表，元类对象存储类方法列表，完美的符合6大设计原则中的单一职责，而且忽略了对对象类型的判断和方法类型的判断可以大大的提升消息发送的效率，并且在不同种类的方法走的都是相同套流程，在之后的维护上也很大节约了成本。

总结

本文从OC的消息机制分析了元类存在的意义，元类的存在简化的简化了实例方法和类方法的调用流程，大大提高了消息发送的效率