JSPatch defineProtocol部分实现详解
本文为投稿文章，作者： 唯敬
这个是给 JSPatch 新增的小功能点，想要详细了解JSPatch整体部分的工作及原理戳这个wiki JSPatch实现原理详解 。
感谢：JSPatch原作者bang哥的指导，还有DevSnow帮了我好多大忙。
出发点
一个不小心引发的bad case
工作中遇到了一个case，有一部分代码被重构了，一个函数被彻底的废弃并且.m文件中的具体函数实现已经被整体注释掉了，但是.h文件这个函数还存在.
由于被重构的那部分在客户端很多处代码都有调用，没有及时的替换成最新的函数，导致造成了线上crash，unrecognized selector.
我最开始想用JSPatch发出一个hotfix，既然是unrecognized selector，具体的函数实现不存在，那么我用JsPatch动态补上这个函数实现，就可以封住crash了.
结果操作后发现，无法实现，原因是.h文件中这个selector里面有一个非id类型的参数.
JsPatch只能新增参数类型为id的方法
在JsPatch的Wiki中 defineClass 有一句说明
可以给一个类随意添加 OC 未定义的方法，但所有的参数类型都是 id:
为什么会这样，探究其源码可以发现
if (!overrided) { NSMutableString *typeDescStr = [@"@@:" mutableCopy]; for (int i = 0; i < numberOfArg; i ++) { [typeDescStr appendString:@"@"]; } overrideMethod(currCls, selectorName, jsMethod, !isInstance, [typeDescStr cStringUsingEncoding:NSUTF8StringEncoding]); } 当使用defineClass对新方法命名的时候，defineClass能通过_自动识别参数的位置和个数，但是并没有能识别参数的类型。
而在通过这段代码创建新方法的时候，需要输入方法的type encode，由于defineClass只有参数的个数和位置信息，并未获得参数的类型，因此JsPatch默认要求新方法所有输入的参数都是id类型，返回的参数也必须是id类型，通过@@:+参数数量个@来生成，只允许id类型的参数及返回的新方法
关于type encode后面会详细解释
当我在尝试通过JsPatch修复我的case的时候，由于我希望新增的方法是一个含有非id类型参数的方法，而JsPatch最终添加的新方法的参数都是id，所以程序运行的时候依然会crash，因为他还是找不到那个他想要的方法，依然是unrecognized selector
修改思路
知道原因，寻找思路
-
defineClass为覆盖修改方法而设计，对于新增方法，传入的信息不足，不能生成正确的type encode，所以无法正确的添加任意参数类型的方法，于是统一设定为id类型。
-
如果由使用者传入足够的信息，借而生成正确的type encode，则我们的目的就可以达成。
我们可以考虑修改defineClass的input，专门在新增方法处开新的接口传入参数，从而使得一切信息都能到手，正常生成正确的新方法。
但是眼下还有3个问题
-
defineClass在设计上，新增方法和覆盖修改方法走的是同一个输入口，单独为新增方法而重新调整输入接口，会使代码逻辑和设计模式变化比较大。
-
在用户已经养成的JsPatch编写习惯上，新增和覆盖二者本是统一的，为新增方法而大改defineClass的输入模式，势必会让已经习惯使用的用户有很大不便。
-
寻找一个合适的方案，能不大范围影响现在的设计模式，又能完成我的想法。
defineClass的Protocol
JsPatch的 defineClass 中提到的Protocol的作用
可以在定义时让一个类实现某些 Protocol 接口，写法跟 OC 一样。
defineClass("JPViewController: UIViewController
这样做的作用是，当添加 Protocol 里定义的方法，而类里没有实现的方法时，参数类型不再全是 id，而是自动转为 Protocol 里定义的类型。
看到原作者bang的说明我们就可以明白，defineClass中的Protocol的作用本是借助已经存在的Protocol的定义，从已经存在的Protocol中就可以抽取出描述selector的type encode，进而生成含有非id参数的方法描述，从而能新增出正确的方法。
我们还可以看下源码，就一清二楚
if (class_respondsToSelector(currCls, NSSelectorFromString(selectorName))) { overrideMethod(currCls, selectorName, jsMethod, !isInstance, NULL); } else { BOOL overrided = NO; for (NSString *protocolName in protocols) { char *types = methodTypesInProtocol(protocolName, selectorName, isInstance, YES); if (!types) types = methodTypesInProtocol(protocolName, selectorName, isInstance, NO); if (types) { overrideMethod(currCls, selectorName, jsMethod, !isInstance, types); free(types); overrided = YES; break; } } if (!overrided) { NSMutableString *typeDescStr = [@"@@:" mutableCopy]; for (int i = 0; i < numberOfArg; i ++) { [typeDescStr appendString:@"@"]; } overrideMethod(currCls, selectorName, jsMethod, !isInstance, [typeDescStr cStringUsingEncoding:NSUTF8StringEncoding]); } } 源码中先判断是否该方法已经存在，存在的情况下进行覆盖，如果不存在，先判断defineClass中是否指定了Protocol，指定了的话从Protocol中寻找匹配的Method进行覆盖和新增，如果在指定Protocol中也找不到，才进行强制id参数类型的方法新增。
所以我选一个比较好的角度，既不破坏原本defineClass的设计逻辑，又能将新的参数传入其中。
那就是设计一个全新的接口defineProtocol，在这个全新的接口里面输入足够多的参数信息，进而通过运行时创建全新的Protocol，创建完成的新Protocol就自然可以借助defineClass里面的功能，引入正确的新增方法
具体实现
JS接口设计
一开始我是想直接让使用者输入type encode这样也省了我的事，后来和原作者交流觉得，尽可能的节省使用者的学习成本，毕竟type encode不知道的人还真不太能很快搞明白这一大堆: # @ v b i的乱七八糟字符到底该怎么写，如果输入接口这样，就会比较直观
defineProtocol('lalalala',{ testProtocol: { paramsType:"int, id", returnType:"BOOL" }, ... }, { ... }); 使用者直接输入int,float,id,void等，由代码自动识别生成最终的type encode，而且因为自动识别需代码进行逐一的支持和转换，有些特殊的参数类型，代码转换并不能完全覆盖，于是还添加了一个可选的参数typeEncode，一旦自动转换无法支持的参数类型，就可以通过可选参数，需要使用者自己想办法手写type encode了，主要无法支持的参数是用户自定义的struct
代码实现
Js接口这部分实现就不详细描述了，和JsPatch其他接口完全一致，
context[@"_OC_defineProtocol"] = ^(NSString *protocolDeclaration, JSValue *instProtocol, JSValue *clsProtocol) { return defineProtocol(protocolDeclaration, instProtocol,clsProtocol); }; 是不是和defineClass一模一样？^_^
context[@"_OC_defineClass"] = ^(NSString *classDeclaration, JSValue *instanceMethods, JSValue *classMethods) { return defineClass(classDeclaration, instanceMethods, classMethods); }; 通过运行时objc_allocateProtocol创建新Protocol，通过protocol_addMethodDescription来为新Protocol增加方法，通过objc_registerProtocol来注册新Protocol，这是基本的runtime代码，不多描述了，源码里都可以看到。
唯一需要注意的是新protocol一经注册生效objc_registerProtocol，就不可在更改了，所以defineProtocol不能修改已经存在的Protocol。
protocol_addMethodDescription需要输入seletorName和type encode，接下来重点说下如何在js返回的字典里识别这两个参数。
识别selector
如接口设计里面的样例testProtocol，是被当做字典中的key，可以直接取出来的，因为我们设计defineProtocol中Js新方法的命名和defineClass一致，都是参数用_代替，原本的下划线用`_`代替，所以解析key这个字符串的步骤和defineClass也一致。
NOTES:源码中需要用paramsType的个数来判断函数名结尾是否存在参数，所以在typeEncode可选参数使用的情况下，paramsType可以随意输入任意的字符串，但是必须保证数量匹配。
识别type encode
如接口设计里面的样例，参数会输入"int, id"这样的字符串，返回值会输入"void"这样的字符串，前者再通过,号拆分成字符串数组，就接下来就可以通过代码获取了，我打算构建一个有限字符串映射表typeEncodeDic，以type字符串为key，映射int到i这样。
typeEncodeDic这个表已经构建好了，这样从js传来的type字符串当做key，直接从这个表里就能get到编码。
人肉去写这个表太low了，怎么也得用酷炫一点的方式支持一下，看到原作者bang，在JsPatch里面风骚的宏的用法，我也照猫画虎了一个
NSMutableDictionary* typeEncodeDic = [[NSMutableDictionary alloc]init]; #define JP_DEFINE_TYPE_ENCODE_CASE(_type) \ if ([@#_type length] > 0) {\ char* encode = @encode(_type);\ NSString * encodestr = [NSString stringWithUTF8String:encode];\ [typeEncodeDic setObject:encodestr forKey:@#_type];\ } JP_DEFINE_TYPE_ENCODE_CASE(id); JP_DEFINE_TYPE_ENCODE_CASE这个宏就自动的将输入参数_type通过语法糖@encode()写入字典，这里面还有一处很nb的地方
宏里面用参数生成静态字符串
这是一个很trick的地方，原本我的宏是这么设计的JP_DEFINE_TYPE_ENCODE_CASE(@"id",id)为什么这么设计？因为我搞不定怎么在宏里将id转成@“id”,试了很多种方法都不行╮(╯_╰)╭
后来原作者bang交流，他给了解决办法，@#_type他在JsPatch里已经用到了，说他当初也遇到一样的困扰，然后查到的。
所以最终这个宏被设计成了这样。
JP_DEFINE_TYPE_ENCODE_CASE(id); JP_DEFINE_TYPE_ENCODE_CASE(BOOL); JP_DEFINE_TYPE_ENCODE_CASE(int); JP_DEFINE_TYPE_ENCODE_CASE(void); JP_DEFINE_TYPE_ENCODE_CASE(char); JP_DEFINE_TYPE_ENCODE_CASE(short); JP_DEFINE_TYPE_ENCODE_CASE(unsigned short); JP_DEFINE_TYPE_ENCODE_CASE(unsigned int); JP_DEFINE_TYPE_ENCODE_CASE(long); JP_DEFINE_TYPE_ENCODE_CASE(unsigned long); JP_DEFINE_TYPE_ENCODE_CASE(long long); JP_DEFINE_TYPE_ENCODE_CASE(float); JP_DEFINE_TYPE_ENCODE_CASE(double); JP_DEFINE_TYPE_ENCODE_CASE(CGFloat); JP_DEFINE_TYPE_ENCODE_CASE(CGSize); JP_DEFINE_TYPE_ENCODE_CASE(CGRect); JP_DEFINE_TYPE_ENCODE_CASE(CGPoint); JP_DEFINE_TYPE_ENCODE_CASE(CGVector); JP_DEFINE_TYPE_ENCODE_CASE(UIEdgeInsets); JP_DEFINE_TYPE_ENCODE_CASE(NSInteger); JP_DEFINE_TYPE_ENCODE_CASE(Class); JP_DEFINE_TYPE_ENCODE_CASE(SEL);
从这可以看出来，想要扩展支持更多的参数类型？没问题，在这里添加就好了（不想修改源码，动态添加就走之前说的可选参数typeEncode）
处理id类型参数
看到上面我们知道，如果我的新函数中存在id类型，无论是系统类型NSArray还是用户自己写的CustomObject，在使用我们的defineProtocol的时候用户需要自己记得所有的NSObject都要输入id,仔细想想这也挺不方便的对吧？
所以我额外做了一个处理，当从typeEncodeDic表里面找不到对应的key的时候，就会NSClassFromString来判断是否是一个Oc对象，如果是自动转换为id的类型编码@
NSString* argencode = [typeEncodeDic objectForKey:argstr]; if (argencode.length <= 0) { Class cls = NSClassFromString(argstr); if ([(id)cls isKindOfClass:[NSObject class]]) { argencode = @"@"; } } 这样无论用户输入类名还是id,我这边的处理都是完全一样，等效的
paramsType:"id" paramsType:"CustomObject"
生成SEL的类型编码
SEL的类型编码命名方式是这样的
- (void) setSomething:(id) anObject
这个函数他的类型编码是
v@:@
-
第一个v代表返回值是void即void的类型编码
-
第二个@代表self（其实是第一个参数 Self和SEL是任何oc函数的隐藏参数），这个基本是固定的
-
第三个:代表SEL（其实是第二个参数 Self和SEL是任何oc函数的隐藏参数），这个基本是固定的
-
第四个@代表Oc函数第一个参数的类型即id的类型编码
通过这些规律，我们可以手写SEL的类型编码了,每一种参数类型可以查询苹果的定义
代码中可选参数typeEncode优先级最高，如果用户手写了可选参数，则不会执行代码自动生成，直接使用用户输入的typeEncode，生成Protocol。
if (typeEncode) { addMethodToProtocol(protocol, selectorName, typeEncode, isInstance); }else { //type encode string automatic create } 详探TypeEncode
我们可以手写typeEncode，其实也可以借助oc代码生成typeEncode
我们先在代码中实现- (void) setSomething:(id) anObject这个方法，然后使用下面的代码，就能通过系统取出SEL的typeEncode
Class cls = self.class; SEL selstr = NSSelectorFromString(@"setSomething:"); Method method = class_getInstanceMethod(cls, selstr); const char* type = method_getTypeEncoding(method);
经过系统的读取，惊讶的发现，系统算出来的type居然是v12@0:4@8，这他喵的一堆数字是什么鬼！，刚才不是说v@:@嘛？？？？？？？？！！！！！！
经过我反复地测试，发现无论是输入v12@0:4@8还是v@:@，Protocol都能正常的生成，一点区别也没有，完全不影响使用，但是他喵的为什么系统就会多出来这么多数字？
栈溢出的一个回答似乎能解释 StackOverFlow-What are the digits in an ObjC method type encoding string?
和gitHub上的@DevSonw聊，觉得这可能是一个字节补齐的过程，并不影响使用。