在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设计双十一会场时也遇到了一些困难。大致分为四个维度：页面交互复杂、氛围设置动态化、秒开与性能、容灾机制。
<b>会场框架交互篇</b><b></b>
非push方式框架tab可以进行切换，滑动流畅，顶部有电梯帮助运营定位到每一个楼层，还有搜索框，每个tab的浏览历史记录要被保存；主会场——分会场——主会场时，交互方式采用push方式，需要持续打开窗口。这样交互方式的难点在于内存治理、前向加载实时性。
在这个基础上，我们怎样设计呢？对于主会场这样一个特殊模块，采用单实例，从左上角手淘首页进入搜索框主会场，跳转到女装，女装再跳转到男装，男装通过底部导航又可以切出主会场定位到必抢页面，此处实际上共用一份实例；当从必抢进入女装会场时，weex渲染容器数量不超过5个，保证内存开销可控；前向跳转实时更新，后向返回保存历史记录。
<b>会场框架氛围篇</b><b></b>
双十一分为主会场氛围和分会场氛围。主会场分为造势期、预热期、正式期，造势期需要保证运营能够实时配置效果，需要支持动态可配置性；分会场氛围涉及各个行业，每个行业利益点不一样，氛围需要根据业务来定制。其中，动态性、实效性以及加载性能都是难点。
会场框架的本质是一个可以用来抽象化描述的框架，底部有tab，上面有导航，中间有可配置的取款，将模板和与之关联的交互逻辑通过预置的方式预置在本地，也就是从服务端去请求js bundle时，会略过网络请求，仅仅需要本地渲染，框架模板与数据分离，模板预加载，数据走投放。
主会场氛围是核心配置驱动（导航栏设置，独⽴tab样式以及url投放），分会场氛围业务调用navigatormodule api，更加灵活。
<b>会场框架性能篇</b><b></b>
我们需要在会场框架中，同时加载5个200坑位的普通页面，1个全景图会场页面，1个直播会场页面。
通过压测方案如下：
1. 主链路（首页-店铺-详情-购物车）做一遍操作，让内存缓存占满，记录内存值m0;
2. 进入weex页面，待页面全部加载完成，跳转至下一个weex页；
3. 重复步骤2，让所有的测试场景页进行压栈；全景图-p1p2p3p4-直播-p1p2p3p4。
得出结论：
控制单页面坑位的个数（150）；
减少页面元素的层级；
android低端机全景图降级。
<b>会场框架保障篇</b><b></b>
在特定的场景下，weex需要提供降级的能力，来保障业务。
降级预案如下：
1. weex渲染容器降级；
2. weex页面服务端配置降级。
现在在业务上应用比较多的是weex页面根据操作系统、应用、weexsdk版本进行降级。依赖jsframework的降级能力，在容器渲染的过程中会经过jsframework的解析构建，在解析时会比对版本规则，如果命中规则即执行降级，反之正常渲染。
业务支撑
weex更多的服务于手淘等超大型客户端，在未来的一年中，我们可以看到在集团内部有越来越多的业务对接weex。
业务支撑中心集中在五个方面：降低接入成本、优化开发体验、更完善的性能监控体系、更好的页面搭建平台和优化容灾机制。
<b>业务接入</b><b></b>
aliweex通用模块或逻辑聚合：包括环境初始化，weex模块或组件的注册，weex
渲染主流程，降级判定规则等；同时，aliweex实现了规范和标准化治理：适配层协议标准化定义，提供默认的接口实现。包括网络库、图⽚库、性能监控等。
<b>性能监控</b><b></b>
性能监控也很重要，需要通过数据进行不断的调优，以及异常捕获，具体包括以下两点：
1. 性能数据的实时采样:
• js framework加载时间
•
网络传输加载时间
首屏渲染时间
2. 异常或渲染错误的捕获:
资源请求失败错误
• js 运行时异常
<b>搭建平台</b>
搭建平台步骤分为以下三步：
1. 从整体进行组件化分离；
2. 定义每个组件；
3. 把组件有机组合起来。
<b>开发体验（</b><b>devtools</b><b>）</b><b></b>
devtools方便我们做两件事：
1. 断点调试；
2. inspector，不管native view
element，还是dom element，或者network和console log。
有了这些工具的辅佐，才有今天双十一顺利的排查问题，前端才能顺利的定位页面布局。