在2017年1月12日 Weex Conf 2017上，来自手机淘宝移动平台Weex团队的凝砺结合淘宝实际业务分享了Weex动态化方案和双十一实践，本文先介绍了Weex的整体架构，接着重点分享了Weex在双十一会场上的实践，最后谈及了Weex的业务支撑，包括AliWeex等。
以下为精彩内容整理：
初始Weex
Weex是一套高性能跨平台移动开发框架，最大的优势是解决了频繁发版和和多端研发两大移动开发痛点。一套代码完美适配IOS、Android、HTML5和Web等多端，极大的提升开发效率同时又保证了用户体验。
Weex分为三层。最上层是DSL，早期类似于html、css、javascript这种语句的表达，让前端熟悉表达方式构建页面；中间层是Virtual DOM，Virtual DOM工作在Framework的解析引擎上，自上而下驱动底层的三端实现；底层分别架构了IOS、Android、H5的RenderEngine，从整个效果来说，Weex是三端一致的解决方案，最终各个系统平台上的UI基本上保持一致。
上图为延伸的前后端协同图，后端主要帮助我们如何从Weex源文件构建出JS Bundle，经过transformer进行转移，JS Bundle针对的是业务代码，JS Bundle会部署到后端服务器上；前台同样是三端，可以实施向后端服务器请求JS Bundle，并运行在JS Framework上，底层的RenderEngine是架构在IOS原生的JSCore，Engine上我们用了V8，它会有一个双效通道，可以通过callJS、callNative来发出指令。
图中红色标记的是WeexKernel，主要包含UI系统，UI系统中有很多重要的组件，比如List、Scroller、Slider、Image等15种组件，后续我们会进一步扩展组件，同时可以看到，在每个Components上还涵盖生命周期、动画和手势，能够让页面变得更加灵动；基于单个页面有导航Navigator，它能够帮助我们进行页面流转；不同页面之间需要进行交互，我们提供了全局事件的方式；同时我们结合了Network功能，Data Store进行数据存储。
应用级框架下面是Module，功能的扩展。然后下面做的是整个性能的把控，右侧部分为适配层，主要是网络层图片库的适配、本地的开发环境等。
双十一会场实践
2016年双十一会场首次大规模启用Weex，总计淘宝+天猫共1754张会场页面，Weex占比99.6%，约为1747张；在流量最重要的天猫主会场入口，5个Tab都是用Weex进行实现的，同时，在天猫和淘宝的分会场，基本做到零降级。
当然，双十一也并不是一帆风顺，在用Weex设计双十一会场时也遇到了一些困难。大致分为四个维度：页面交互复杂、氛围设置动态化、秒开与性能、容灾机制。
会场框架交互篇
非Push方式框架Tab可以进行切换，滑动流畅，顶部有电梯帮助运营定位到每一个楼层，还有搜索框，每个Tab的浏览历史记录要被保存；主会场——分会场——主会场时，交互方式采用Push方式，需要持续打开窗口。这样交互方式的难点在于内存治理、前向加载实时性。
在这个基础上，我们怎样设计呢？对于主会场这样一个特殊模块，采用单实例，从左上角手淘首页进入搜索框主会场，跳转到女装，女装再跳转到男装，男装通过底部导航又可以切出主会场定位到必抢页面，此处实际上共用一份实例；当从必抢进入女装会场时，Weex渲染容器数量不超过5个，保证内存开销可控；前向跳转实时更新，后向返回保存历史记录。
会场框架氛围篇
双十一分为主会场氛围和分会场氛围。主会场分为造势期、预热期、正式期，造势期需要保证运营能够实时配置效果，需要支持动态可配置性；分会场氛围涉及各个行业，每个行业利益点不一样，氛围需要根据业务来定制。其中，动态性、实效性以及加载性能都是难点。
会场框架的本质是一个可以用来抽象化描述的框架，底部有Tab，上面有导航，中间有可配置的取款，将模板和与之关联的交互逻辑通过预置的方式预置在本地，也就是从服务端去请求JS Bundle时，会略过网络请求，仅仅需要本地渲染，框架模板与数据分离，模板预加载，数据走投放。
主会场氛围是核心配置驱动（导航栏设置，独⽴tab样式以及URL投放），分会场氛围业务调用NavigatorModule Api，更加灵活。
会场框架性能篇
我们需要在会场框架中，同时加载5个200坑位的普通页面，1个全景图会场页面，1个直播会场页面。
通过压测方案如下：
1. 主链路（首页-店铺-详情-购物车）做一遍操作，让内存缓存占满，记录内存值M0;
2. 进入Weex页面，待页面全部加载完成，跳转至下一个Weex页；
3. 重复步骤2，让所有的测试场景页进行压栈；全景图-p1p2p3p4-直播-p1p2p3p4。
得出结论：
- 控制单页面坑位的个数（150）；
- 减少页面元素的层级；
- Android低端机全景图降级。
会场框架保障篇
在特定的场景下，Weex需要提供降级的能力，来保障业务。
降级预案如下：
1. Weex渲染容器降级；
2. Weex页面服务端配置降级。
现在在业务上应用比较多的是Weex页面根据操作系统、应用、WeexSDK版本进行降级。依赖JSFramework的降级能力，在容器渲染的过程中会经过JSFramework的解析构建，在解析时会比对版本规则，如果命中规则即执行降级，反之正常渲染。
业务支撑
Weex更多的服务于手淘等超大型客户端，在未来的一年中，我们可以看到在集团内部有越来越多的业务对接Weex。
业务支撑中心集中在五个方面：降低接入成本、优化开发体验、更完善的性能监控体系、更好的页面搭建平台和优化容灾机制。
业务接入
AliWeex通用模块或逻辑聚合：包括环境初始化，Weex模块或组件的注册，Weex 渲染主流程，降级判定规则等；同时，AliWeex实现了规范和标准化治理：适配层协议标准化定义，提供默认的接口实现。包括网络库、图⽚库、性能监控等。
性能监控
性能监控也很重要，需要通过数据进行不断的调优，以及异常捕获，具体包括以下两点：
1. 性能数据的实时采样:
• JS Framework加载时间
• 网络传输加载时间
• 首屏渲染时间
2. 异常或渲染错误的捕获:
• 资源请求失败错误
• js 运行时异常
搭建平台
搭建平台步骤分为以下三步：
1. 从整体进行组件化分离；
2. 定义每个组件；
3. 把组件有机组合起来。
开发体验（devTools）
Devtools方便我们做两件事：
1. 断点调试；
2. Inspector，不管Native View Element，还是Dom Element，或者Network和console log。
有了这些工具的辅佐，才有今天双十一顺利的排查问题，前端才能顺利的定位页面布局。
