鬼道（徐凯），就职于手机淘宝基础架构团队，曾为天猫Pad客户端TL并负责天猫Web前端架构。就职百度移动推广团队期间，负责开发Android/iOS推广SDK、统计SDK，及对应的Web管理站点。 前言
Native开发的诸多亮点中，流畅体验和系统调用是最多被提及的。流畅体验体现在页面滚动/动画的流畅性，背后是更好的内存管理和更接近原生的性能；同时又是Web的痛点：资源首次下载、长页面内存溢出和滚动性能、动画性能、传统web性能（如JS执行效率）。Native有丰富的系统调用能力，而Web痛点在于：W3C标准太慢，有限的设备访问能力，API兼容性问题较严重，如Geolocation在AndroidWebview中可用性很差。
Web开发同样有诸多亮点，其中最耀眼的当属发布能力和规模协作。NativeApp商店审核周期长（尤指iOS）；应用更新周期长，iOS稍快大概能达到一周更新率60%-80%，Android同样的更新率要2周甚至更长。而Web在合适的缓存机制下一分钟可达到99% 。浏览器内核webkit提供了相对一致的底层运行环境，html/js/css控制页面的结构/行为/样式，uri连接不同的页面，有了这些基础设施，大规模的业务复用和人与人的分工协作变得相对轻松。同时今天阿里诸多客户端已经面临包大小接近临界值，大促活动页面（H5）体验较差等一系列问题。结合Native和Web技术亮点，同时又能解决阿里遇到的业务问题，这就是Weex诞生的客观环境。2016.11.11，在1754张双11会场页面中（统计了天猫和淘宝），Weex页面数为1747占比99.6%。手淘iOS/Android分别有83.5%/78.3%版本（UV）启用了Weex会场，手猫iOS/Android分别为91.7%/87.9%版本（UV）。Weex覆盖了包括主会场、分会场、分分会场、人群会场等在内几乎所有的双11会场业务。在这样的应用规模下，工作和目标是：1.业务支撑，支撑住双11需求，这是最基本的要求，详见下文“业务支撑”一节2.稳定性保障，Weex引发的问题第一时间响应并处理，不留到双11当天，详见下文“稳定性数据”一节3.秒开实战，稳定当先力争高性能，双11正式主会场秒开率冲到97%，所有会场秒开率冲到93%，详见下文“秒开数据”2016双11会场的感受可查看原始录屏文件：WIFI|4G|3G|2G|无网络。录屏时主会场已经是预加载版本，其中WIFI和4G效果接近，2G效果取决于数据的网络请求速度（录屏时数据请求约3.9s），无网络情况下打底数据来自前一次成功请求。流畅性可查看该视频，左起为H5、iOSWeex、AndroidWeex。1 目标
展开Weex双11细分目标：图-Weex双11细分目标2 业务支撑
支撑住双11的业务需求，是Weex必须要迈过的坎。双11的会场结构大致为：会场框架（框架 主会场、全部会场、必抢、清单、我的双11）、分会场、其他会场（分分会场、人群会场等）。3 会场框架
Weex支撑双11业务首要解决的是会场框架及其交互形式：
1.交互主流程：1.非push方式（框架Tab切换）：主会场-全部会场-必抢-清单-我的双112.push方式：主会场-分会场-主会场2.iOS考虑到内存开销，需严控打开的主分会场weex页面，定为n级可配，默认为5；同时iOS会场框架为单实例，也是出于内存的考虑；Android连续打开30级以上Weex页面，未见内存异常增长，无需特殊方案图-会场框架交互Weex会场框架很好支撑住了双11的复杂交互需求并提供了更好的内存管理。除了会场框架，更多的Component和Module支撑住了各色各样的双11需求，这里仅列出几个代表：1.List组件是几乎所有会场页面的标配，流畅的滚动帧率、高性能的内存复用机制和渲染机制是页面流畅体验的重要基础2.Animation尽管是实验版需求，却支撑住了会场的垂直弹幕、坑位显隐等动画效果，动画效果细腻3.Weex点播/直播组件和全景图组件支撑住了更为垂直个性化的业务需求4 组织结构
上节内容也可以看出，参与Weex双11会场涉及多个团队和平台系统：图-Weex双11中组织结构1.天猫业务：通过斑马（活动页面搭建和发布平台）发布会场页面2.淘宝业务：通过斑马和AWP（产品页面发布平台）发布会场页面，上层DSL使用Rx（即将开源）3.预加载：提前将会场js-bundle下载到客户端，客户端访问Weex会场时网络IO被拦截到本地文件IO，从而极大加快了网络加载速度，预加载是这次秒开实战的抓手（注：最核心的工作）4.手淘、手猫客户端，Weex是客户端的一部分，客户端中其实是Weex、Native、H5并存的5.WeexSDK、业务模块：Weex容器和基础的Components、Modules，业务模块包括直播/点播组件、全景图组件以上也仅涉及到客户端和发布端，背后还有无数的业务后台系统，就不一一列出了。将Weex架构自上而下地展开：1.Business，Weex业务层，Weex双11主战场是手淘和手猫，此外还有大量客户端已经启用或接入了Weex2.Middleware，Weex中间件层，包括为Weex页面提供发布（斑马、AWP）、预加载（AWP）、客户端接入支持（AliWeex）、组件库（SUI）、游戏引擎、图表库等模块；其中斑马、AWP、预加载都直接参与了双113.Tool，工具层1.DevTools，界面和交互复用了WebkitDevtools，支持elements、network、断点、console等2.Playground，方便开发者调试Weex页面，同时也是Weexexample的聚集地3.Cli，Weex命令行工具集4.目前仍在建设更多的工具，如weex-pack支持一键打包成App4.DSL1.JSFramework，Weex最初的DSL是基于Vuejs1.0语法子集；目前在社区中在推进基于Vuejs2.0的版本2.Rx，基于reactjs语法的WeexDSL（将于12月正式开源）5.Engine，渲染引擎，从架构设计上，Android/iOS/H5RenderEngine是相互独立和平等地位的渲染端，这是保持三端一致的基础，当然在协议实现层面需要更多的设计、质量保证图-Weex架构以上就是Weex在双11中的架构和业务支撑的范围了。5 稳定性保障
Weex的首要挑战就是稳定性，或者说保障Weex会场最大限度不降级。6iOSJSCore内存治理
8月初（同期双11启动）奥运大促时，手淘iPhone中反复进出会场20 （手猫15 ），会出现crash。奥运大促当天，手淘iOS1.59%crash次数来自该问题（top6），手猫1.94%（top8）。发现问题的当天成立了攻坚小组，从JS业务代码、JSFM（框架）、iOS渲染、iOSJSCore几个方向同时排查，一周内各方向排查到逐步收敛到：根本原因是Weex页面实例被全局持有（weexruntime只有一份），进而导致页面退出时内存不被释放，反复进出直至内存爆掉。因而任何可能导致页面实例被全局持有的因素都会触发这个问题：1.业务代码中的问题，意外导致的，给出Lint工具扫描业务代码，引入了“全局污染治理”（见下一节）2.JSFM框架中的问题，如在destroyInstance时清理commonModules和所有dependencytarget；iOS7下的SetPolyfill内存飙升问题3.iOS中的问题，通过下发配置控制VCPush层级控制；内存警告时的非当前实例销毁策略，加入开关控制；iOS9.xJSCore原生Promise和Polyfill并存时的内存问题除了建立攻坚团队推进解决该问题，也在造势期前就展开双11会场压测，反复验证该问题，自双11造势期会场开测之后，该问题未再出现。7 全局污染治理在治理JSCore内存的过程中，逐步意识到对全局变量管控的必要性。Weex中多个页面共用1个runtime，单个页面如果写法不规范不仅可能导致内存泄露，更有可能污染全局环境，进而导致所有Weex页面无法正常工作。全局污染治理的核心抓手：
1.严格模式，即`usestrict`，使用严格模式可以将较多常见的JS陷阱转化为错误，如：无法再意外创建全局变量、将拼写错转成异常、限制了eval的能力等2.冰冻对象，利用ES5的`Object.freeze()`，将Weex核心对象和JS原生对象“冰冻”住。尝试修改被“冰冻”的对象会抛出错误，一旦“冰冻”无法“解冻”。8 跨端依赖梳理Weex通过Adapter来适配不同客户端的具体实现，诸多通用库，如：网络库、图片库、API库、H5容器（Web组件）、埋点库、配置库等在不同客户端上版本不一致，因此导致的线上问题将会成为双11会场的隐患。为此展开的依赖梳理和同步机制是双11稳定性的保障之一。这件事情可能将会长期出现在Weex问题清单之中，如何做到上层WeexSDK？9 会场压测
*压测场景1.5个200坑位的普通会场页面，1全景图会场页面，1UTExpose压测页面，1直播会场页面2.页面中提供链接，能够按顺序进行push跳转*压测方案1.主链路（首页- | 
注册
登录
