这周遇到一个很神奇的crash，报错是找不到 responser，然后惊讶的发现了一些二进制打包的坑，也是太久没写小水文儿了于是来玩儿一下~
背景是酱紫的：
我们有个 protocol A，声明了很多属性，然后有一个 proxy 实现了这个 protocol A，然鹅它其实木有实现协议里面的属性，而是重写了forwarding方法，当你读取他的某个属性的时候，他会调用自己的一个方法，获取到自己持有的另一个对象来返还给forwardInvocation。如何找到要返回哪个对象的呢？
是通过 runtime 找到property_list和属性对应的 class，然后存到一个map里面，当外面找某个属性的时候，它会通过map里面找到这个属性对应的 class，再从自己持有的一个字典里面找到这个 class 的对象。
然后这个crash是在一个会给这个 protocol A 新增一个属性的分支上面发生的，报的crash是调用了这个实现了 protocol A 的对象forwarding的时候没能找到响应这个新属性的对象，然鹅肯定的是这个字典里一定有这个新属性class对应的对象。
- 问题出在哪里呢？
这个问题当时我木有反应过来是为什么其实，后来在大佬的帮助下了解到了为啥。
这个 protocolA 是在其他库里面也会用到的，protocol 在编译的时候会被搞成 struct，于是每个用到这个 protocol 的binary库都有一份自己的 struct，于是在我们 runtime 找这个 protocol 的属性的时候，可能用到了其他二进制包里面的 struct，但是这个 struct 是旧的，没有加新的属性的，那么在生成属性和class对应的map的时候就木有找到这个属性，所以才会crash。
- 解决方式：
- 把所有用到了这个 protocol 的库都加入到开发库新发一个版，之前的缓存就不生效啦
- 由于被其他库引用的 protocol 会被其他库的二进制缓存，那么我们可以在内部新建一个protocol B 继承自 protocol A，并且把属性重写一遍（因为不是很清楚继承的原理），这样内部用的 protocol B 一定是可以runtime找到这个属性的啦~ 但是要保证其他库不能 import 到这个protocol B 哦~
#define propertiesDeclaration \
@property (nonatomic, readonly) XXXClass *xxx;\
@property (nonatomic, readonly) YYYClass *yyy;
------
@protocol ProtocolA <NSObject>
propertiesDeclaration
@end
------
@protocol ProtocolB <ProtocolA>
propertiesDeclaration
@end
※ Protocol编译后是个什么样子的struct呢？
我们用clang来康康包含protocol的类是咋编译的：
xcrun -sdk iphonesimulator clang -rewrite-objc 文件名.m
文件里面定义了这么一个协议：
@protocol RStoreObserver <NSObject>
-(void)onStateChanged:(RState *)newState;
@end
产物是酱紫的，里面的RStoreObserver木有啥感觉，然后就是所有都是struct毕竟其实OC底层都是靠C搭起来的：
struct _protocol_t;
struct _objc_method {
struct objc_selector * _cmd;
const char *method_type;
void *_imp;
};
struct _protocol_t {
void * isa; // NULL
const char *protocol_name;
const struct _protocol_list_t * protocol_list; // super protocols
const struct method_list_t *instance_methods;
const struct method_list_t *class_methods;
const struct method_list_t *optionalInstanceMethods;
const struct method_list_t *optionalClassMethods;
const struct _prop_list_t * properties;
const unsigned int size; // sizeof(struct _protocol_t)
const unsigned int flags; // = 0
const char ** extendedMethodTypes;
};
※ 其他的一些小插曲
我们远端会在做一些check防止我们改了接口，其他二进制编译不过。于是我就遇到了一个check失败的问题，虽然是他们check脚本的bug。
这个背景比较简单，就是如果你在development pod里面定义了一个宏，然后其他非开发仓引用了并且出了二进制包。这个时候我把我们定义的宏改成 inline 函数，但其实里面调用的都是一样的。这个时候虽然本地木有报错，但是远端的出包都会挂掉。或者你把定义这个别的库用到的宏的.h文件里面删掉几个宏之类的可能也会引发报错。
于是我和胖友们讨论了一下：（以下都是个人理解不保证正确哦）
- 宏在预编译会被展开，生成的二进制不应该因为宏而有变化，除非是宏展开以后的接口变化。那如果我import的不是自己库里面的宏，生成二进制的时候还是展开的咩？
应该是的，宏应该不会像函数调用那种需要rebase link之类的。 - 复习一下，二进制之间的函数调用，是每个库都会有一个自己对外的接口表，我们build最后一步会做link，这个时候会把组件间的调用去查表之类的进行连接，如果有找不到的接口调用会报错哒。
我决定要刷一遍程序员自身修养了。。。
