iOS HotPatch的选择（Weex, React Native, JSPatch）--2016.6.24GMTC后感
这个问题来自于JSPatch场的提问。作者本人表示，没有runtime是搞不定swift的。有一天Apple强推Swift不支持OC,JSPatch就用不了了。weex可以很容易移除OC runtime的依赖的，而JSPatch是不可能做到不依赖runtime的。
但是讲道理的话这个风险比较小。也有可能Swift之后的版本提供了强大的反射。
学习曲线
RN>weex>JSPatch
RN的react.js就比较难以理解，再加上flux,reflux,redux这些，可能就更难了。
weex很多核心代码就是直接借鉴的vue.js。vue相对于react来说还是比较容易的。
JSPatch直接就是用JS映射原生对象，除了语法不一样，其实就相当于写OC。稍微有一点JS基础的就能写。另外作者提供了强大的辅助工具JSPatchX（JS写oc代码自动补全），使得写JS变的更容易。
与Native交互
从方便性和灵活度的角度考虑，应该是：JSPatch>weex>RN
RN的方式是通过新建一个manager包装调用真正对象，通过宏把这个manager暴露给JS调用。只有实例，所以没有静态方法，没有单例的概念。如果要调用单例必须通过manager包装，使得实例最终做的还是单例的事。
const myRNUtilManager = React.NativeModules.MyRNUtilManager myRNUtilManager.doSomething() const myUserSingleManager = React.NativeModules.MyUserSingleManager weex的方式具体不清楚，据讲师说会使用weex up这个东西。想通过一种方式自动注册，不需要像RN那样使用manager+宏的方式。（好像目前还没有）
JSPatch的方式就不用多说了，直接调用。
语言
RN=weex>JSPatch
三者都可以使用ES6。
RN和weex都是HTML/CSS/JS，开发效率很高，对于前端来说写起来很爽很快。另外HTML可以用jade,CSS可以用Stylus, Less, Sass主流的库。但对于移动端的程序员来说就有点困难了。但是说实话学习成本很低。
JSPatch和写OC并没有很大的区别。该裸写autolayout的地方还是得裸写。
开发的效率
weex>RN>JSPatch
weex核是vue.js相对于react.js来说更简单些。HTML/CSS/JS开发效率肯定优于native开发的。
RN的jsx本质也是HTML/CSS/JS。开发效率肯定优于native开发的。
RN和weex都用了css3的flexbox来布局，相对比较简单。
JSPatch相当于还是写native。native开发相对比较慢。并且大量的代码写autolayout也是繁重的工作。虽然有JSPatchX帮忙，但是我依然觉得没有weex和RN高效。
以上也有一个前提就是团队中的人需要懂得前端开发的基础知识。不过我觉得HTML/CSS/JS还是很容学的。
开发时的调试
RN=weex=JSPatch
都是用Chrome进行调试。
开发时的Hot Reload
RN=weex=JSPatch
RN可以Hot Reload，而且除了模拟器之外，真机也可以Hot Reload。只需要改一下URL就行了。
weex未知，没用过。但是讲师说是可以的。
JSPatch通过PlayGround也可以做到Hot Reload，也可以做真机Hot Reload。也是只需要修改一些URL就可以了。
代码下发
RN=weex>JSPatch
除了自己实现服务外。
weex 据讲师说将来会用阿里百川的服务。我想该服务应该是定制的吧，而且会是增量推。但是说不定要收费噢。也应该可以用code push。只不过不是定制的可能会有些麻烦。
RN 已经有RN版Code Push了，还是比较成熟的。Code Push唯一缺点就是目前不支持增量。也可以使用AppHub。
JSPatch 已经有自己的成熟的相当于官方代码下发服务。缺点就是收费，但是不贵。它是按量收费，对于刚刚起步的创业团队来说根本就是免费的。因为收费所以我给了RN和weex大于JSPatch。
代码下发的安全性
RN=weex=JSPatch
JSPatch的服务是RSA签名验证。还能自定义RSA密钥。应该是非常安全的。
weex和RN都可以使用Code Push背后是微软，安全性应该很有保障。weex也可以用阿里百川的服务，背后是阿里，安全性肯定有保障。
线上异常的溯源
JSPatch>RN>weex
JSPatch其实就是映射了native，所以线上异常很容易被苹果自带功能或者第三方如umeng捕获并且上传服务器供开发者查看。因为是映射也很容找到具体错误是js哪个文件中的哪行代码。
RN需要打包bundle时导出source map。代码中需要捕获异常，利用第三方库打log，这个log会自动上传服务器。RN的异常会报出line和column通过这个再结合之前导出的source map就可以溯源。但是整个一个流程比较麻烦。
weex的线上异常的溯源据讲师讲目前是没有的。
性能
JSPatch>weex>RN
JSPatch通过作者的优化，性能已经达到很高的水准。
据阿里的人说weex的内测表现优于RN。这主要也是因为他们之间目标的不同。一个是想替换H5，一个则是想替代App。
坑
JSPatch>weex=RN
JSPatch坑比较少，有坑也可能是一些c代码不能调，宏需要展开写。但是一般都不会涉及到这部分问题。
weex还没开正式开源不好说。
RN现在公认的坑比较多，iOS算比较少的。
维护
weex>RN>JSPatch
JSPatch基本就是作者一个人项目，而且是私人业余项目。
weex有一个庞大的team做维护再加上这么多活跃在社区的中国人。并且weex非常重视提交上来的issue。
RN团队精力不够，但是肯定优于JSPatch。
设计目标谁更适合Hot Patch
JSPatch>weex>RN
JSPatch这个名字就很明显了，就是要做patch的。而且作者已经在这上面花了很多精力开发。
RN设计目标是要替代native app的模式的。而且标榜着learn once, run everywhere.
weex的目标是替换H5，更灵活些。想要做到三端一体。
文档
JSPatch>RN>weex
JSPatch的文档很齐全。也受益它本身很简单。
RN的文档其实比较少的，很多人坑要踩。很多解决方案需要自己去搜索拼装解决。
weex之所以给了最后一名是因为目前还没有正式开源。差评。
平台
这个分不出高下，见仁见智，看需求
JSPatch只能在iOS平台上。android上有自己的热补丁技术，很自由，可以直接写native，不需要写JS。
RN是有明显的platform判断API的，所以它的肯定会有if iOS else这样的代码出现。有时候需求就是要不一样，有时候需求又希望一样。但是这种代码的出现，会使得App逻辑变得复杂，容易出错，更难懂。
weex的目标是三端一体。有参会者专门问了如何做platform判断和适配。讲师给出的答案是，weex的目标就是三端一体替换H5，所以我觉得应该是不会出现太多的if else。但是这很难说，比较android和iOS差太多，很难真正做到一体。拭目以待吧，我还是对weex在这方面挺有信心也相信阿里的技术能力。
以上是列举了部分点进行比较。我个人倾向Hot Patch的选型应该是这个顺序：weex>RN>JSPatch
目前我们Team用的方案是RN。
2016.7.13后记
weex终于真的正式开源。到这个时间节点为止，发现weex还不够成熟，不能够应用到实际开发。我觉得问题主要有这些：
- 文档不齐
- 没有Debug方面的文档
- 没有代码下发方面的指导
- iOS需要在didFinishLaunchingWithOptions时手动注册Module等
- 没有看到Animation的文档
- 组件不够多
- 周边服务和工具也没有
所以把Hot Patch的顺序修改为：RN>JSPatch>weex
