iOS app热修复方案调研

项目需要集成热修复，解决线上紧急的缺陷，及时修复，而无需另发版本到appstore。
主要考察了四种方案：

热修复方案对比

Dynamic Framework

区别于静态库的编译时链接，动态库是在程序运行时动态加载的，并且可以多个程序共享，动态库中包含修复的的代码即可实现热修复。关于动态加载可以参考《程序员的基本素养》了解详细情况，也可以参考文章关于iOS中的库。
这种技术问题在于虽然apple从xcode6开放了用户自己建立动态framework的权利（参考iOS中的SDK开发），但是为了保证系统安全性（可能多个程序公用同一个动态库，存在兼容性问题），apple只允许系统自己的动态库出现，而用户自己开发的这种动态库只能用于企业分发的app，无法用在上架appstore的app中。

CodePush

CodePush是微软推出的一种热修复技术，但主要用户对app中ReactNative（ReactNative是facebook提供的一种开源框架，能够用JavaScript脚本就可以写出App的界面，使用JS语法进行跨平台开发）部分的热修复，不多讲。
源码地址：https://github.com/Microsoft/react-native-code-push#getting-started

Lua+wax

2013年之前wax虽然有调试麻烦、线程不安全等问题，但已经是当时不错的热修复方案，但是12年推出的64位的iphone5s，让一直以来只支持32位的wax陷入尴尬，Lua字节码也有32位与64位编译区分，所以原来的Wax中的stdlib库在64位无法运行，阿里从13年接手了长期无人维护的wax，修改了原有的Lua字节码打包逻辑使其能在64位正常运行。另外，阿里完善了block调用、lua调试等方面，让wax方案更加易用。
Lua是一个在大量的游戏中使用的简洁、轻量、可扩展的脚本语言，用于实现游戏的可配置和可更新。但Lua需要预先绑定很多C函数才可在脚本中使用，所以单独使用Lua无法做到高复用性。Wax的核心逻辑是替换函数，并且连接了Lua与Objective-C runtime，使得Lua可以调用和替换任意类的方法，甚至新增类、方法。这样一来就能在app不发布新版的情况下，通过远程下载脚本的方式修复线上app里的bug、甚至新增一些功能。
使用时，工程需要集成Lua解释器和Wax框架。
源码地址：https://github.com/alibaba/wax

JSPatch

与Lua+wax方案的想法相同，微信团队（bang）利用Objective-C Runtime的特性及iOS7系统开始支持的JavaScript脚本运行，开发了自己的JavaScript热修复方案--JSPatch。
JSPatch中JavaScript脚本运行的基础是JavaScriptCore，JavaScriptCore是一种JavaScript引擎，主要为webkit提供脚本处理能力，可以将JavaScript的能力更轻便地、高性能地带给原生的iOS应用，可以实现oc和JavaScript两种语言的互转。
JSPatch能做到通过JS调用和改写OC方法：通过类名和方法名反射得到相应的类和方法，也可以替换某个类的方法为新的实现，或新注册一个类，为类添加方法。JSPatch 的原理就是：JS传递字符串给OC，OC通过 Runtime 接口调用和替换OC方法。实际使用时，我们一般通过下发js脚本，在app启动时判断是否需要执行脚本，如果有故障需要修复，就执行指定的js脚本。如果我们自己实现js脚本的下发，需要自己开发平台接口，保证脚本传输的安全性和高并发能力。JSPatch善解人意的提供了这样的JSPatch平台，并且开发了OC转JS工具，便于将待修复的OC代码转为热修复的JS代码。
源码地址：https://github.com/bang590/JSPatch

综上，
Lua+wax和JSPatch都可以作为我们项目中热修复的方案，二者都出自大厂，并且有多个知名app已经应用了他们的方案上架appstore。
对于学习成本来说js和lua相当，但是应用场合来说js明显更广泛，而且JSPatch方案普及度更高，风险更小。

热修复需要注意：

1. 要有及时的线上产品故障报警，包含crash的报警和核心业务出错的报警，开发及时定位到问题；
2. 对于已经通过热修复解决的问题，下个版本要替换为新的native代码；
3. 不要使用热修复添加业务模块或大量非修复性的逻辑代码，将给维护带来很大麻烦；
4. 热修复对应的补丁要充分考虑相关业务影响，测试充分，避免热修复带来新问题；