iOS 底层探索篇 ——Runtime-objc_msgSend流程分析 - 快速查找流程

补充：在lldb中调用方法为什么mask为7

我们看到在代码中调用方法的情况，那么在lldb中调用方法呢？试一下：

这里的mask变成了7，这是为什么呢？
mask变成了7，那么代表着，cache一定进行了一次类似的扩容，那么其必然就会到insert里面，那么我们去insert实现里面。

之前证明了，当缓存方法到了3/4 的时候，就会进行扩容，那么是不是我们在lldb中调用方法的时候，会同时调用其他方法呢，我们来看一下，在insert中打印一下sel，imp 和 receiver，这样就会打印所有的方法。运行一下。

然后在lldb中调用对象方法，看看输出。

我们想要找的情况是receiver是p的情况，所以我们打印一下p的地址。

然后在上面的打印结果中寻找，发现这三个方法的receiver都是p。

所以我们发现，在我们调用saySomething方法之前，会先调用 respondsToSelector以及class 方法，所以在插入saySomething的时候会进行扩容，所以mask变为7.

作业：代码运行方法会不会插入结束符号

代码中调用方法，这里调用两次
在insert里面把bucket的sel，imp和地址打印出来。

这里saySomething之前调用setName是因为上面的打印方法放在开辟空间之前，如果不先调用空间还没开辟打印不出来东西，因为oldCapacity会是0，运行一下。

打印结果可以看到，还是有结束符号的。

这里的0x7fff7c838d69是setName 方法，因为saySomething在下面才插进去。

接着看insert 里面的插入。

这里有一个do while 循环，上次说到这里，当插入的时候如果找到一个值，发现里面有人，就会进行cache_next。看一下cache_next内部是什么样的。

发现这里如果发现有值在里面的话，如果i不等0，就往前移一位重新插入，否则就会到mask开始重新插入，那么什么是mask呢。前面看到传进来的是m，往前找，发现m是：

大致流程图：

那么会不会有一种情况，就是一直找不到空位呢？如果一直找不到，那么就会退出循环，然后调用bad_cache。

    bad_cache(receiver, (SEL)sel);

再看一下set方法。

发现是先存imp，在存sel。

objc_msgSend流程

上文讲解了objc_msgSend 汇编源码，得到了以下流程：

1. 判断receiver是否存在
2. 通过receiver获取isa，进而获取class

现在已经获取到了class了，那么class要拿来干什么呢？
这里看到拿到了class之后，调用了 CacheLookup NORMAL, _objc_msgSend, __objc_msgSend_uncached 这个函数

接着我们去搜索一下CacheLookup 的实现。这里把之前的函数复制过来，一一对应发现少了一个参数，那么说明最后一个参数是默认参数。

往下看代码：

// 之前的p16是class，这里是把class放到x15里
mov	x15, x16			
LLookupStart\Function:
	// p1 = SEL, p16 = isa
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16_BIG_ADDRS
	ldr	p10, [x16, #CACHE]				// p10 = mask|buckets
	lsr	p11, p10