现在业内基本上都在使用WaxPatch方案，由于Wax框架已经停止维护四五年了，所以waxPatch在使用过程中还是存在不少坑(比如参数转化过程中的问题，如果继承类没有实例化修改继承类的方法无效, wax_gc中对oc中instance的持有延迟释放...)。另外苹果对于Wax使用的态度也处于模糊状态，这也是一个潜在的使用风险。

随着FaceBook开源React Native框架，利用JavaScriptCore.framework直接建立JavaScript（JS）和Objective-C(OC)之间的bridge成为可能，JSPatch也在这个时候应运而生。开始还以为是在React Native的基础上进行的封装，不过最近仔细研究了源代码，跟React Native半毛钱关系都没有。

深入了解JSPatch之后，第一感觉是这个方案小巧，易懂，维护成本低，直接通过OC代码去调用runtime的API，作为一个IOS开发者，很快就能看明白，不用花大精力去了解学习lua。另外在建立JS和OC的Bridge时，作者很巧妙的利用JS和OC两种语言的消息转发机制做了很优雅的实现，稍显不足的是JSPatch只能支持ios7及以上。

下面我们再来看看JSPatch对比WaxPatch的优势吧！

1.JS语言: JS比Lua在应用开发领域有更广泛的应用，目前前端开发和终端开发有融合的趋势，作为扩展的脚本语言，JS是不二之选。

2.符合Apple规则: JSPatch更符合Apple的规则。iOS Developer Program License Agreement里3.3.2提到不可动态下发可执行代码，但通过苹果JavaScriptCore.framework或WebKit执行的代码除外，JS正是通过JavaScriptCore.framework执行的。

3.小巧: 使用系统内置的JavaScriptCore.framework，无需内嵌脚本引擎，体积小巧。

4.支持block: wax在几年前就停止了开发和维护，不支持Objective-C里block跟Lua程序的互传，虽然一些第三方已经实现block，但使用时参数上也有比较多的限制。

什么东西都不止是有优点没有缺点的吧！我们来说说JSPatch的劣势：相对于WaxPatch，JSPatch劣势在于不支持iOS6，因为需要引入JavaScriptCore.framework。另外目前内存的使用上会高于wax，持续改进中。

讲到这里了那么就有人会问了！JSPatch的实现原理是什么呢？

那我们就来谈谈JSPatch的实现原理吧：JSPatch以小巧的体积做到了让JS调用/替换任意OC方法，让iOS APP具备热更新的能力，接下来我们就从基础原理、方法调用和方法替代来介绍整个 JSPatch 的实现原理吧！

基础原理：能做到通过JS调用和改写OC方法最根本的原因是 Objective-C 是动态语言，OC上所有方法的调用/类的生成都通过 Objective-C Runtime 在运行时进行，我们可以通过类名/方法名反射得到相应的类和方法；也可以替换某个类的方法为新的实现；还可以注册一个类为类添加方法。理论上你可以在运行时通过类名/方法名调用到任何OC方法，替换任何类的实现以及新增任意类。所以 JSPatch 的原理就是：JS传递字符串给OC，OC通过 Runtime 接口调用和替换OC方法。这是最基础的原理了。

方法的调用：引入JSPatch后，可以通过以上JS代码创建了一个 UIView 实例，并设置背景颜色和透明度，涵盖了require引入类，JS调用接口，消息传递，对象持有和转换，参数转换这五个方面，接下来逐一看看具体实现。

1.require

调用require(‘UIView’)后，就可以直接使用UIView这个变量去调用相应的类方法了，require 做的事很简单，就是在JS全局作用域上创建一个同名变量，变量指向一个对象，对象属性__isCls表明这是一个 Class，__clsName保存类名，在调用方法时会用到这两个属性。

2.JS接口

接下来看看UIView.alloc()是怎样调用的。

旧的实现方式我们就不说了我们直接说说新的实现方式吧！CoffieScript/JSX都可以用JS实现一个解释器实现自己的语法，我也可以通过类似的方式做到，再进一步想到其实我想要的效果很简单，就是调用一个不存在方法时，能转发到一个指定函数去执行，就能解决一切问题了，这其实可以用简单的字符串替换，把JS脚本里的方法调用都替换掉。最后的解决方案是，在OC执行JS脚本前，通过正则把所有方法调用都改成调用__c()函数，再执行这个JS脚本，做到了类似OC/Lua/Ruby等的消息转发机制;给JS对象基类 Object 的 prototype 加上__c成员，这样所有对象都可以调用到__c，根据当前对象类型判断进行不同操作；__methodFunc()就是把相关信息传给OC，OC用 Runtime 接口调用相应方法，返回结果值，这个调用就结束了。

这样做不用去OC遍历对象方法，不用在JS对象保存这些方法，内存消耗直降99%，这一步是做这个项目最爽的时候，用一个非常简单的方法解决了严重的问题，替换之前又复杂效果又差的实现。

3.消息传递

解决了JS接口问题，接下来看看JS和OC是怎样互传消息的。这里用到了 JavaScriptCore 的接口，OC端在启动JSPatch引擎时会创建一个 JSContext 实例，JSContext 是JS代码的执行环境，可以给 JSContext 添加方法，JS就可以直接调用这个方法；JS通过调用 JSContext 定义的方法把数据传给OC，OC通过返回值传会给JS。调用这种方法，它的参数/返回值 JavaScriptCore 都会自动转换，OC里的 NSArray, NSDictionary, NSString, NSNumber, NSBlock 会分别转为JS端的数组/对象/字符串/数字/函数类型。上述__methodFunc() 方法就是这样把要调用的类名和方法名传递给OC的。

4.对象持有/转换

UIView.alloc通过上述消息传递后会到OC执行[UIView alloc]，并返回一个UIView实例对象给JS，这个OC实例对象在JS是怎样表示的呢？怎样可以在JS拿到这个实例对象后可以直接调用它的实例方法(UIView.alloc().init())？

对于一个自定义id对象，JavaScriptCore 会把这个自定义对象的指针传给JS，这个对象在JS无法使用，但在回传给OC时OC可以找到这个对象。对于这个对象生命周期的管理，按我的理解如果JS有变量引用时，这个OC对象引用计数就加1 ，JS变量的引用释放了就减1，如果OC上没别的持有者，这个OC对象的生命周期就跟着JS走了，会在JS进行垃圾回收时释放。

传回给JS的变量是这个OC对象的指针，如果不经过任何处理，是无法通过这个变量去调用实例方法的。所以在返回对象时，JSPatch 会对这个对象进行封装。

5.类型转换

JS把要调用的类名/方法名/对象传给OC后，OC调用类/对象相应的方法是通过 NSInvocation 实现，要能顺利调用到方法并取得返回值，要做两件事：

1.取得要调用的OC方法各参数类型，把JS传来的对象转为要求的类型进行调用。

2.根据返回值类型取出返回值，包装为对象传回给JS。

例如开头例子的view.setAlpha(0.5)， JS传递给OC的是一个 NSNumber，OC需要通过要调用OC方法的NSMethodSignature得知这里参数要的是一个 float 类型值，于是把NSNumber转为float值再作为参数进行OC方法调用。这里主要处理了 int/float/bool 等数值类型，并对 CGRect/CGRange 等类型进行了特殊转换处理，剩下的就是实现细节了。

方法替换

JSPatch 可以用defineClass接口任意替换一个类的方法，方法替换的实现过程也是颇为曲折，一开始是用 va_list 的方式获取参数，结果发现 arm64 下不可用，只能转而用另一种hack方式绕道实现。

整个 JSPatch 实现原理就大致描述完了，剩下的一些小点，例如GCD接口，block实现，方法名下划线处理等就不细说了，可以直接看相关的代码。

说完了JSPatch原理后我们再来说说怎么学习和理解吧！

（1）OC的动态语言特性

不管是WaxPatch框架还是JSPatch的方案，其根本原理都是利用OC的动态语言特性去动态修改类的方法实现。

OC的动态语言特性是在runtime system(全部用C实现，Apple维护了一份开源代码)上实现的，面向对象的Class和instance机制都是基于消息机制。我们平时认为的[object method]，正确的理解应该是[receiver sendMsg], 所有的消息发送会在编译阶段编译为runtime c函数的调用：_obj_sendMsg(id, SEL).

2）JS如何调用OC

在JS运行环境中，需要解决两个问题，一个是OC类对象（objc_class）的获取，另一个就是使用对象提供的接口方法。

3）JS如何替换OC方法

JSPatch的主要作用还是通过脚本修复一些线上bug，希望能够达到替换OC方法的目标。JSPatch的实现巧妙之处在于：利用了OC的消息转发机制。

Patch现场复原的补充：

Patch现场恢复的功能主要用于连续更新脚本的应用场景。由于IOS的App应用按Home键或者被电话中断的时候，应用实际上是首先进入到后台运行阶段（applicationWillResignActive），当我们下次再次使用App的时候，如果后台应用没有被终止（applicationWillTerminate），那么App不会走appliation:didFinishLaunchingWithOptions方法，而是会走（applicationWillEnterForeground）。 对于这种场景如果我们连续更新线上脚本，那么第二次脚本更新则无法保留最开始的方法实现，另外恢复现场功能也有助于我们撤销线上脚本能够恢复应用的本身代码功能。

了解了这些后知道热更新的重要性了吧！那么问题就来了，如何实现热更新呢？目前为止能够实现热更新的方法，总结起来有以下三种：

第一种：便是使用FaceBook 的开源框架 reactive native，用JS来写原生的iOS应用，iOS APP可以在运行时从服务器拉取最新的JS文件到本地，然后再执行，因为JS是一门动态的脚本语言，所以可以在运行时直接读取js文件执行，也因此能够实现iOS的热更新。

第二种：就是使用lua 脚本了。lua脚本如同JS 一样，也能在动态时被加载。比如之前愤怒的小鸟使用lua脚本做的一个插件 wax，可以实现使用lua写iOS应用。热更新时，从服务器拉去lua脚本，然后动态的执行就可以了。遗憾的是 wax目前已经不更新了。

第三种：是在xcode 6 之后，苹果自己开放了 iOS 的动态库编译权限。什么是动态库？所谓的动态库，其实就是可以在运行时进行加载。正好利用这一个特性，用来做ios的热更新。

一款超简单的社会化分享的demo：https://github.com/XHXSS/XHXSS-