1.立项

大约在2017年的时候，QQ浏览器IPAD项目组还在北京，那时候AppStore上架还比较慢，我们项目组决定做自己的动态化框架，动态化框架的目标是：真正实现一次发版本，多次发布。

整个iPAD项目组对整个市场的动态化框架做了一次比较深入的研究（为期一周）当时团队的分工如下：如今小伙伴都以天各一方，怀念和大家一起战斗的日子。

项目组分工

最开始我们并没有信心完全从0开始做一个全新的动态化框架，我们的想法是从WEEX上进行更改和扩展，形成QB团队自己的动态化框架。这一决定其实浪费我大约1.5个月的时间。WEEX的核心问题非常严重。整个动态化框架的设计和实现工作最后交给我来实现。

2.第一版本架构

接到任务后，大约利用了2周左右的时间对WEEX的源码进行了了解，我们第一步对weex的整个一些UI层面的限制进行了修正。主要有如下几个方面：（当时版本的weex比较早，现在这些问题可能已经不存在了。）

上面的内容我就不展开说明了，这并不是本系列文章的重点，但是里面有非常多有意思的小trick。有兴趣的同学可以单独联系我。

以上主要是针对UI层面的。但是WEEX在逻辑层面有天生的短板，它和RN是完全一样，采用预先注册的形势进行和Native交互，这只能算作是跨平台，并不能算作完全能力的动态化，我猜想这也是苹果之所以没有对RN和WEEX动手的原因。比如我在WEEX要用的某个NATIVE写好的BUTTON，那么这个BUTTON在WEEX引擎初始化的时候用以下代码注册好。

这就根本算不上动态化了，这也造成了WEEX还不能够进行打PATCH。

第一版本架构

3.第二版本架构

但是等等，当时是有能够完全能力动态运行和打PATCH的框架的偶～ YES， JSPATCH！所以我当初想的是用WEEX处理UI层面的操作，用JSPATCH来做逻辑层面的引擎从而达到无限制的动态化能力。架构大约是这个样子。

第二版本的架构

这里面的核心问题是怎么WEEX的脚本里嵌入JS脚本，这个设计也是比较有意思的，我设计的几个宏字符串

通过这几个宏字符串可以完成JSPATCH代码内嵌到WEEX里。这几个宏定义我也不展开详细介绍了，大致的思路是JSPATCH运行的时候先通过全局替换的方案，把这些字符串替换为一个内置的方法，比如 XXX_CALL（1），这样，然后把每段JSPATCH代码编号，这样当运行到XXX_CALL 这个方法时候，就能知道要去取什么JSPATCH脚本了。同时_OBJC_JSP_REGISTERTARG_方法预先注入参数，_OBJC_JSP_JSCALL_RETURN_ 输出参数即可。此时的代码看起来是这个样子的。