JSPatch实现原理详解<二>

本文转载至 http://blog.cnbang.net/tech/2855/

距离上次写的<JSPatch实现原理详解>有一个月的时间，在这段时间里 JSPatch 在不断地完善和改进，代码已经有很多变化，有一些修改值得写一下，作为上一篇的补充。

Special Struct

先说下 _objc_msgForward，在上一篇提到为了让替换的方法走 forwardInvocation，把它指向一个不存在的 IMP: class_getMethodImplementation(cls, @selector(__JPNONImplementSelector))，实际上这样实现是多余的，若 class_getMethodImplementation 找不到 class / selector 对应的 IMP，会返回 _objc_msgForward 这个 IMP，所以更直接的方式是把要替换的方法都指向 _objc_msgForward，省去查找方法的时间。

接着出现另一个问题，如果替换方法的返回值是某些 struct，使用 _objc_msgForward（或者之前的 @selector(__JPNONImplementSelector))会 crash。几经辗转，找到了解决方法：对于某些架构某些 struct，必须使用 _objc_msgForward_stret 代替 _objc_msgForward。为什么要用 _objc_msgForward_stret 呢，找到一篇说明 objc_msgSend_stret 和 objc_msgSend 区别的文章），说得比较清楚，原理是一样的，是C的一些底层机制的原因，简单复述一下：

大多数CPU在执行C函数时会把前几个参数放进寄存器里，对 obj_msgSend 来说前两个参数固定是 self / _cmd，它们会放在寄存器上，在最后执行完后返回值也会保存在寄存器上，取这个寄存器的值就是返回值：


1

2

3

4

5

-(int) method:(id)arg;

    r3 = self

    r4 = _cmd, @selector(method:)

    r5 = arg

    (on exit) r3 = returned int

普通的返回值(int/pointer)很小，放在寄存器上没问题，但有些 struct 是很大的，寄存器放不下，所以要用另一种方式，在一开始申请一段内存，把指针保存在寄存器上，返回值往这个指针指向的内存写数据，所以寄存器要腾出一个位置放这个指针，self / _cmd 在寄存器的位置就变了：


1

2

3

4

5

6

-(struct st) method:(id)arg;

    r3 = &amp;struct_var (in caller's stack frame)

    r4 = self

    r5 = _cmd, @selector(method:)

    r6 = arg

    (on exit) return value written into struct_var

objc_msgSend 不知道 self / _cmd 的位置变了，所以要用另一个方法 objc_msgSend_stret 代替。原理大概就是这样。

上面说某些架构某些 struct 有问题，那具体是哪些呢？iOS 架构中非 arm64 的都有这问题，而怎样的 struct 需要走上述流程用 xxx_stret 代替原方法则没有明确的规则，OC 也没有提供接口，只有在一个奇葩的接口上透露了这个天机，于是有这样一个神奇的判断：


1

if ([methodSignature.debugDescription rangeOfString:@&quot;is special struct return? YES&quot;].location != NSNotFound)

在 NSMethodSignature 的 debugDescription 上打出了是否 special struct，只能通过这字符串判断。所以最终的处理是，在非 arm64 下，是 special struct 就走 _objc_msgForward_stret，否则走 _objc_msgForward。

内存泄露

先说下上一篇文章留下的一个问题，在从 NSInvocation 取返回值时，为什么这样取参数会 crash：


1

2

id arg;

[invocation getReturnValue:&amp;arg];

这是因为 &arg 传入 -getArgument:atIndex: 方法后 arg 就指向了返回对象，但并不持有它，不会对返回对象引用+1，但因为 id arg 在ARC下相当于 __strong id arg，arg 是 strong 类型局部变量，所以退出作用域时会调用一次 release，不持有对象又对对象调 release，会导致对象多 release 了一次，所以 crash。只要把 arg 类型改成 __unsafe_unretained，表明只是指向对象但不持有它，退出作用域时不 release 就没问题了：


1

2

__unsafe_unretained id arg;

[invocation getReturnValue:&amp;arg];

还可以通过 __bridge 转换让局部变量持有返回对象，这样做也是没问题的：


1

2

3

4

id returnValue;

void *result;

[invocation getReturnValue:&amp;result];

returnValue = (__bridge id)result;

double release 的问题解决了，但这里还有个大坑：内存泄露。某天 github issue 上有人提对象生成后没有释放，几经排查，定位到还是这里 NSInvocation getReturnValue 的问题，当 NSInvocation 调用的是 alloc 时，返回的对象并不会释放，造成内存泄露，只有把返回对象的内存管理权移交出来，让外部对象帮它释放才行：


1

2

3

4

5

6

7

8

id returnValue;

void *result;

[invocation getReturnValue:&amp;result];

if ([selectorName isEqualToString:@&quot;alloc&quot;] || [selectorName isEqualToString:@&quot;new&quot;]) {

    returnValue = (__bridge_transfer id)result;

} else {

    returnValue = (__bridge id)result;

}

这里想不明白为什么，从开源 Cocotron 里对 NSInvocation 的实现来看，NSInvocation 并不持有返回的对象，调用方法也是直接用 msgSend，没什么特别的地方，让人怀疑这是 ARC 的 bug。

‘_’的处理

JSPatch 用下划线’_’连接OC方法多个参数间的间隔：


1

2

3

- (void)setObject:(id)anObject forKey:(id)aKey;

<==>

setObject_forKey()

那如果OC方法名里含有’_’，那就出现歧义了：


1

2

3

- (void)set_object:(id)anObject forKey:(id)aKey;

<==>

set_object_forKey()

没法知道 set_object_forKey 对应的 selector 是 set_object:forKey: 还是 set:object:forKey:。

对此需要定个规则，在 JS 用其他字符代替 OC 方法名里的 _。JS 命名规则除了字母和数字，就只有 $ 和 _，看起来只能用 $ 代替了，但效果很丑：


1

2

3

4

5

- (void)set_object:(id)anObject forKey:(id)aKey;

- (void)_privateMethod();

<==>

set$object_forKey()

$privateMethod()

于是尝试另一种方法，用两个下划线 __ 代替：


1

2

set__object_forKey()

__privateMethod()

但用两个下划线代替有个问题，OC 方法名参数后面加下划线会匹配不到


1

2

3

- (void)setObject_:(id)anObject forKey:(id)aKey;

<==>

setObject___forKey()

实际上 setObject___forKey() 匹配到对应的 selector 是 setObject:_forKey:。虽然有这个坑，但因为很少见到这种奇葩的命名方式，感觉问题不大，使用 $ 也会导致替换不了 OC 方法名包含 $字符的，最终为了代码颜值，使用了双下划线 __ 表示。

JPBoxing

在使用 JSPatch 过程中发现JS无法调用 NSMutableArray / NSMutableDictionary / NSMutableString 的方法去修改这些对象的数据，因为这三者都在从 OC 返回到 JS 时 JavaScriptCore 把它们转成了 JS 的 Array / Object / String，在返回的时候就脱离了跟原对象的联系，这个转换在 JavaScriptCore 里是强制进行的，无法选择。

若想要在对象返回 JS 后，回到 OC 还能调用这个对象的方法，就要阻止 JavaScriptCore 的转换，唯一的方法就是不直接返回这个对象，而是对这个对象进行封装，JPBoxing 就是做这个事情的：


01

02

03

04

05

06

07

08

09

10

11

@interface JPBoxing : NSObject

@property (nonatomic) id obj;

@end

@implementation JPBoxing

+ (instancetype)boxObj:(id)obj

{

   JPBoxing *boxing = [[JPBoxing alloc] init];

    boxing.obj = obj; 

    return boxing;

}

把 NSMutableArray / NSMutableDictionary / NSMutableString 对象作为 JPBoxing 的成员保存在 JPBoxing 实例对象上返回给 JS，JS 拿到的是 JPBoxing 对象的指针，再传回给 OC 时就可以通过对象成员取到原来的 NSMutableArray / NSMutableDictionary / NSMutableString 对象，类似于装箱/拆箱操作，这样就避免了这些对象被 JavaScriptCore 转换。

实际上只有可变的 NSMutableArray / NSMutableDictionary / NSMutableString 这三个类有必要调用它的方法去修改对象里的数据，不可变的 NSArray / NSDictionary / NSString 是没必要这样做的，直接转为 JS 对应的类型使用起来会更方便，但为了规则简单，JSPatch 让 NSArray / NSDictionary / NSString 也同样以封装的方式返回，避免在调用 OC 方法返回对象时还需要关心它返回的是可变还是不可变对象。最后整个规则还是挺清晰：NSArray / NSDictionary / NSString 及其子类与其他 NSObject 对象的行为一样，在 JS 上拿到的都只是其对象指针，可以调用它们的 OC 方法，若要把这三种对象转为对应的 JS 类型，使用额外的 .toJS() 的接口去转换。

对于参数和返回值是C指针和 Class 类型的支持同样是用 JPBoxing 封装的方式，把指针和 Class 作为成员保存在 JPBoxing 对象上返回给 JS，传回 OC 时再解出来拿到原来的指针和 Class，这样 JSPatch 就支持所有数据类型 OC<->JS 的互传了。

nil的处理

区分NSNull/nil

对于”空”的表示，JS 有 null / undefined，OC 有 nil / NSNull，JavaScriptCore 对这些参数传递处理是这样的：

  • 从 JS 到 OC，直接传递 null / undefined 到 OC 都会转为 nil，若传递包含 null / undefined 的 Array给 OC，会转为 NSNull。
  • 从 OC 到 JS，nil 会转为 null，NSNull 与普通 NSObject 一样返回指针。

JSPatch 的流程上都是通过数组的方式把参数从 JS 传入 OC，这样所有的 null / undefined 到 OC 就都变成了 NSNull，而真正的 NSNull 对象传进来也是 NSNull，无法分辨从 JS 过来实际传的是什么，需要有种方式区分这两者。

考虑过在 JS 用一个特殊的对象代表 nil，null / undefined 只用来表示 NSNull，后来觉得 NSNull 是很少手动传递的变量，而 null / undefined 以及 OC 的 nil 却很常见，这样做会给日常开发带来很大不便。于是反过来，在 JS 用一个特殊变量 nsnull 表示 NSNull，其他 null / undefined 表示 nil，这样传入 OC 就可以分辨出 nil 和 NSNull，具体使用方式：


1

2

3

4

5

6

7

8

9

@implementation JPObject

+ (void)testNil:(id)obj

{

     NSLog(@"%@", obj);

}

@end

require("JPObject").testNil(null)      //output: nil

require("JPObject").testNil(nsnull)      //output: NSNull

这样做有个小坑，就是显示使用 NSNull.null() 作为参数调用时，到 OC 后会变成 nil：


1

require("JPObject").testNil(require("NSNull").null())     //output: nil

这个只需注意下用 nsnull 代替就行，从 OC 返回的 NSNull 再回传回去还是可以识别到 NSNull。

链式调用

第二个问题，nil 在 JS 里用 null / undefined 表示，造成的后果是无法用 nil 调用方法，也就无法保证链式调用的安全：


01

02

03

04

05

06

07

08

09

10

@implementation JPObject

+ (void)returnNil

{

     return nil;

}

@end

[[JPObject returnNil] hash]     //it’s OK

require("JPObject").returnNil().hash()     //crash

原因是在 JS 里 null / undefined 不是对象，无法调用任何方法，包括我们给所有对象加的 __c() 方法。解决方式一度觉得只有回到上面说的，用一个特殊的对象表示 nil，才能解决这个问题了。但使用特殊的对象表示 nil，后果就是在 js 判断是否为 nil 时就要很啰嗦：


1

2

3

4

5

6

//假设用一个_nil对象变量表示OC返回的nil

var obj = require("JPObject").returnNil()

obj.hash()     //经过特殊处理没问题

if (!obj || obj == _nil) {

     //判断对象是否为nil就得附加判断是否等于_nil

}

这样的使用方式难以接受，继续寻找解决方案，发现 true / false 在 JS 是个对象，是可以调用方法的，如果用 false 表示nil，即可以做到调用方法，又可以直接通过 if (!obj) 判断是否为 nil，于是沿着这个方向，解决了用 false 表示 nil带来的各种坑，几乎完美地解决了这个问题。实现上的细节就不多说了，说”几乎完美”，是因为还有一个小坑，传递 false给 OC 上参数类型是 NSNumber* 的方法，OC 会得到 nil 而不是 NSNumber 对象：


1

2

3

4

5

6

7

@implementation JPObject

+ (void)passNSNumber:(NSNumber *)num {

     NSLog(@"%@", num);

}

@end

require("JPObject").passNSNumber(false) //output: nil

如果 OC 方法的参数类型是 BOOL，或者传入的是 true / 0，都是没问题的，这小坑无伤大雅。

题外话，神奇的 JS 里 false 的 this 竟然不再是原来的 false，而是另一个 Boolean 对象，太特殊了：


1

2

Object.prototype.c = function(){console.log(this === false)};

false.c() //output false

新增方法

在 JS 给类添加 OC 上没有定义的方法，实现上有两个变化：

1.流程

原先的做法是把新增的方法指向一个静态的 IMP，脱离了方法替换的流程，这样做的优点是调用新增方法时不需要走 forwardInvocation的流程，提升性能，但缺点一是不能跟方法替换走一样的流程，需要额外的代码，二是参数个数有限制，由于不能用 va_list 可变参数的方式定义（详见上篇文章），所以需要对每种参数个数都单独定义一个方法，原来的实现中定义了5个方法，所以新增方法最多只能支持5个参数。权衡下，为了去除参数个数限制，最后还是改成了跟替换方法一样走 forwardInvocation 的流程。

2.Protocol

现在 JSPatch 已支持 Protocol，这样在新增 Protocol 里已定义的方法时，参数类型会按照 Protocol 里的定义去实现，Protocol 的定义方式跟 OC 上的写法一致：


1

2

3

4

5

defineClass("JPViewController: UIViewController <UIAlertViewDelegate>", {

  alertView_clickedButtonAtIndex: function(alertView, buttonIndex) {

    console.log('clicked index ' + buttonIndex)

  }

})

实现方式比较简单，先把 Protocol 名解析出来，当 JS 定义的方法在原有类上找不到时，再通过 objc_getProtocol 和 protocol_copyMethodDescriptionList runtime 接口把 Protocol 对应的方法取出来，若匹配上，则按其方法的定义走方法替换的流程。

扩展

当前 JSPatch 还有两个问题：

  1. JS 无法动态调用C函数，只能通过手动在代码上给每个要调用的C函数封装成 JS 函数，像 dispatch 几个函数的实现一样。
  2. struct 类型只支持原生的 NSRange / CGRect / CGSize / CGPoint 这四个，其他 struct 类型无法在 OC / JS 间传递。

这两个问题都无法一次到位全部解决，C函数需要逐个添加，struct 需要逐个手动转为 NSDictionary，这些直接写在 JSPatch 里是不合适的，所以需要以扩展的形式给这些额外的需求提供支持。

扩展接口的设计上，我设想的效果是：

  1. 接口清晰
  2. 每个扩展独立存在，互不影响
  3. 不影响JPEngine的正常使用，尽量少暴露JPEngine的接口
  4. 扩展的接口可扩展，以后有其他扩展需求可以在其基础上添加
  5. 动态加载，扩展可能会给JS全局变量添加很多接口，最好能在真正使用到时才加载

最终的扩展接口：


01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

@protocol JPExtensionProtocol <NSObject>

@optional

- (void)main:(JSContext *)context;

- (size_t)sizeOfStructWithTypeEncoding:(NSString *)typeEncoding;

- (NSDictionary *)dictOfStruct:(void *)structData typeEncoding:(NSString *)typeEncoding;

- (void)structData:(void *)structData ofDict:(NSDictionary *)dict typeEncoding:(NSString *)typeEncoding;

@end

@interface JPExtension : NSObject <JPExtensionProtocol>

+ (instancetype)instance;

- (void *)formatPointerJSToOC:(JSValue *)val;

- (id)formatPointerOCToJS:(void *)pointer;

- (id)formatJSToOC:(JSValue *)val;

- (id)formatOCToJS:(id)obj;

@end

@interface JPEngine : NSObject

+ (void)addExtensions:(NSArray *)extensions;

...

@end

所有扩展都需要继承 JPExtension，-main: 方法会在加载扩展的时候执行，可以在 -main: 方法里为当前 JSContext 添加 JS 方法，若要支持自定义的 struct 类型，需要实现 JPExtensionProtocol 的三个 struct 相关方法（参考了Robert的实现），JSPatch 会在参数转换时根据 typeEncoding 向扩展取得 struct<->NSDictionary 的互转。所有扩展都要继承 JPExtension，基类提供了 OC<->JS 参数处理的几个方法，在添加 JS 方法传递参数时使用。JPEngine 添加了加载扩展的接口 +addExtensions:，其他接口没变。

效果上基本实现了我的设想：

  1. 接口还算清晰，struct 接口麻烦一点，但看过示例应该也容易理解。
  2. 每个扩展都是独立的，都可以添加自己想支持的 struct 类型，添加 JS 方法，互不影响
  3. JPEngine 接口没有变化，参数处理和 JPBoxing 也没有暴露出来，都封装在 JPExtension 的方法里。
  4. 若以后有其他扩展需求，可以直接在 JPExtension 添加。
  5. 以接口 +addExtensions: 的方式添加扩展，不但可以在 OC 上使用，还可以在 JS 上动态加载：

1

require("JPEngine").addExtensions(require("JPCGTransform").instance())

——————
版权声明：本文章在微信公众平台的发表权，已「独家代理」给指定公众帐号：iOS开发(iOSDevTips)。

时间： 2024-12-26 20:26:54

JSPatch实现原理详解<二>的相关文章

JSPatch实现原理详解

本文转载至 http://blog.cnbang.net/tech/2808/ JSPatch以小巧的体积做到了让JS调用/替换任意OC方法,让iOS APP具备热更新的能力,在实现 JSPatch 过程中遇到过很多困难也踩过很多坑,有些还是挺值得分享的.本篇文章从基础原理.方法调用和方法替换三块内容介绍整个 JSPatch 的实现原理,并把实现过程中的想法和碰到的坑也尽可能记录下来. 基础原理 能做到通过JS调用和改写OC方法最根本的原因是 Objective-C 是动态语言,OC上所有方法的

JSPatch 实现原理详解

原文地址https://github.com/bang590/JSPatch/wiki/JSPatch-%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3 JSPatch 是一个 iOS 动态更新框架,只需在项目中引入极小的引擎,就可以使用 JavaScript 调用任何 Objective-C 原生接口,获得脚本语言的优势:为项目动态添加模块,或替换项目原生代码动态修复 bug. 之前在博客上写过两篇 JSPatch 原理解析文章(1 

图像处理中的数学原理详解17——卷积定理及其证明

欢迎关注我的博客专栏"图像处理中的数学原理详解" 全文目录请见 图像处理中的数学原理详解(总纲) http://blog.csdn.net/baimafujinji/article/details/48467225 图像处理中的数学原理详解(已发布的部分链接整理) http://blog.csdn.net/baimafujinji/article/details/48751037 1.4.5   卷积定理及其证明 卷积定理是傅立叶变换满足的一个重要性质.卷积定理指出,函数卷积的傅立叶变

Java虚拟机工作原理详解

原文地址:http://blog.csdn.net/bingduanlbd/article/details/8363734 一.类加载器 首先来看一下java程序的执行过程. 从这个框图很容易大体上了解java程序工作原理.首先,你写好java代码,保存到硬盘当中.然后你在命令行中输入 [java] view plaincopy javac YourClassName.java 此时,你的java代码就被编译成字节码(.class).如果你是在Eclipse IDE或者其他开发工具中,你保存代码

kickstart安装系统原理详解

前言 作为中小公司的运维,经常会遇到一些机械式的重复工作,例如:有时公司同时上线几十甚至上百台服务器,而且需要我们在短时间内完成系统安装. 常规的办法有什么? 光盘安装系统===>一个服务器DVD内置光驱百千块,百台服务器都配光驱就浪费了,因为一台服务器也就开始装系统能用的上,以后用的机会屈指可数.用USB外置光驱,插来插去也醉了. U盘安装系统===>还是同样的问题,要一台一台服务器插U盘. 网络安装系统(ftp,http,nfs) ===>这个方法不错,只要服务器能联网就可以装系统了

Storm概念、原理详解及其应用（一）BaseStorm

本文借鉴官文,添加了一些解释和看法,其中有些理解,写的比较粗糙,有问题的地方希望大家指出.写这篇文章,是想把一些官文和资料中基础.重点拿出来,能总结出便于大家理解的话语.与大多数"wordcount"代码不同的是,并不会有如何运行第一storm代码等内容,只有在运行完代码后,发现需要明白:"知其然,并知其所以然". Storm是什么?为什么要用Storm?为什么不用Spark? 第一个问题,以下概念足以解释: Storm是基于数据流的实时处理系统,提供了大吞吐量的实

SVM -支持向量机原理详解与实践之四

SVM -支持向量机原理详解与实践之四 SVM原理分析 SMO算法分析 SMO即Sequential minmal optimization, 是最快的二次规划的优化算法,特使对线性SVM和稀疏数据性能更优.在正式介绍SMO算法之前,首先要了解坐标上升法. 坐标上升法(Coordinate ascent) 坐标上升法(Coordinate Ascent)简单点说就是它每次通过更新函数中的一维,通过多次的迭代以达到优化函数的目的. 坐标上升法原理讲解 为了更加通用的表示算法的求解过程,我们将算法表

SVM-支持向量机原理详解与实践之一

目录(?)[+] 前言 SVM机器学习与深度学习 人工智能领域 机器学习与深度学习 SVM简介 SVM原理分析 快速理解SVM原理 线性可分和线性不可分 函数间隔和几何间隔 超平面分析与几何间隔详解 二次最优化 SVM-支持向量机原理详解与实践 前言 去年由于工作项目的需要实际运用到了SVM和ANN算法,也就是支持向量机和人工神经网络算法,主要是实现项目中的实时采集图片(工业高速摄像头采集)的图像识别的这一部分功能,虽然几经波折,但是还好最终还算顺利完成了项目的任务,忙碌一年,趁着放假有时间好好

Linux下FFMPEG--H264--编码&&解码的C实现与相关原理详解

FFMPEG是很强大的一套视频音频处理库,不过,强大的功能一般免不了复杂的实现,或者更加现实地说,"麻烦"的部署和使用流程 关于"FFMPEG怎么部署"这事就放在另一篇文章啦,下面入正题.. 编码encoder模块和解码decoder模块都有init初始化方法和资源free方法 init初始化方法主要是进行ffmpeg所必需的编解码器的初始化和部分功能方法的参数配置,而free资源释放方法则是相应地进行必要的回收 Encoder模块的实现和细节分析 #include