NSURLProtocol之property猜想

在NSURLProtocol中有3个方法:

1. +propertyForKey:inRequest:;

2. + setProperty:forKey:inRequest:;

3. + removePropertyForKey:inRequest:;

This method provides an interface for protocol implementors to access/customize/ protocol-specific information associated with NSURLRequest objects.

    开始接触的时候,直觉上以为每个property是对应request的属性,于是做了一个测试,测试的步骤在URL loading system 调用NSURLProtocol的startLoading之后,根据创建的NSURLConnection发起请求,此时URL loading system又会调用NSURLProtocol的canInitWithRequest:方法,在这两个方法中比较NSURLRequest的地址,就知道是否为同一个对象了:

NSURLProtocol之property猜想_第1张图片
不同的NSURLRequest对象

    从结果看出是不同的NSURLRequest对象,说明了保存的property应该不是保存在NSURLRequest对象上的。那到底保存在哪里呢?

    从图中还可以看出不同的NSURLRequest对象的URL是一样的,这说明了请求的是同一个资源,而定义中说是protocol-specific information,因此可以推测每一个NSURLProtocol对象提供了一个全局的cache字典保存所有的property。那保存的形式又是怎样的呢?

    作者猜想应该是是一个嵌套的2层字典形式,最外层的key应该跟对应的NSURLRequest有关,根据上面不同的NSURLRequest有相同的NSURL猜想,最外层的key很可能就是NSURL。为了证明猜想,我们可以在canInitWithRequest:方法中改变request对应的URL值,看改变之后还能不能拿到对应request的值,值得一提的是这里是NSURLRequest,对应的NSURL是readonly的,不过通过调试我们发现实际指向的是NSMutableURLRequest,所以这里可以使用objc_msgSend神器来做:

NSURL *url = [NSURL URLWithString:@"https://www.objc.io/"];
SEL selector = @selector(setURL:);
if ([request respondsToSelector:selector]) {
    void (*obj_msgSendURL)(id, SEL, id) = (void (*)(id, SEL, id)) objc_msgSend;
    obj_msgSendURL(request, selector, url);
}

NSURLProtocol之property猜想_第2张图片
改变URL之后依然命中

    从结果可以看出,猜想不正确,那还剩下什么呢?hash,每个对象都有的hash属性!Apple文档中是这样描述的:

An integer that can be used as a table address in a hash table structure.

   正好是我们所需要的!那就打印出来看看:

NSURLProtocol之property猜想_第3张图片
具有相同URL的不同NSURLRequest对象hash值一样
NSURLProtocol之property猜想_第4张图片
具有不同URL的不同NSURLRequest对象hash值不一样

可以猜想出Apple内部应该还维护了其他变量来做到外层的key值的一致性。最终保存的方式很可能是:

NSURLProtocol之property猜想_第5张图片
NSURLProtocol保存property的格式

实验Demo

参考资料:

What exactly +[NSURLProtocol setProperty:forKey:inRequest:] does

你可能感兴趣的:(NSURLProtocol之property猜想)