WeexConf 2018干货系列|Weex技术演进第二篇

既昨日给大家介绍了过去一年里Weex业务规模不断扩大，业务复杂度不断上升，给Weex带来了哪些技术挑战，以及Weex在技术架构和设计上做了哪些升级来应对这些挑战。

今天，我们会从内核角度切入，为大家继续带来Weex技术演进之路的分享。

内核挑战

随着Weex业务规模的扩大和业务覆盖场景的丰富，Weex 不仅在性能稳定性上面临越来越大的挑战，在安全隔离方面，也遇到前所未有的风险。

性能方面：例如，去年的“双11”和今年“双11”主会场规模对比，去年整个会场的JS Bundle大小控制在250K以内，今年主会场页面平均达到500K+，业务复杂度增加了接近2倍，Weex 的加载性能跟JS bundle 的大小基本成正相关；

稳定性方面：业务场景覆盖面的提升，从原来的偏展示的场景到偏交互场景的业务，以及一些常规业务的接入；新的业务场景，必然导致新的稳定性方面的挑战，事实也如此；

富交互：引入Gcanvas、AR/VR等富交互场景，对Weex js-native的通信效率要求极高；

我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。

安全性：旧引擎的安全漏洞的问题，以及业务之间存在相互污染，无法做到安全隔离的问题；

证书问题：Yoga引擎的证书授权问题；

内核技术演进

从三个方面来阐述Weex 在内核重要方向的演进：JS引擎、Layout 引擎、WeexCore架构的演进；

JS引擎: 我们的目标是更快、更稳定、更安全、更小；其一：我们投入大量资源在JS引擎的优化上，从JS引擎的替换，由原来旧版本的V8 换成最新版本JavaScriptCore；其二：我们开创性地将JS Runtime 运行于独立的进程里，不仅保证主进程的稳定性，而且加入了智能恢复的能力；其三：重新考虑Weex 业务隔离的安全问题，开发设计了多Context 隔离的方案，保证避免业务间互相污染；其四：瘦身，包的精简；

原文链接