Weex如何支撑200w+同时在线的优酷猫晚直播？Weex如何支撑200w+同时在线的优酷猫晚直播？阿里技术百家号阿里妹导读：天猫双十一已经成为被大众普遍接受的文化符号，而猫晚则是连接线下线上的重要节点。2017年天猫晚会的前台直播任务被交给了优酷来承担。 优酷直播，优酷主客团队，优酷架构组等多方组成了联合项目组，合力承担优酷双十一猫晚直播的开发任务。缘起虽然优酷直播在线上已经有业务稳定运行，但是我们还是遇到了大量问题需要解决。除开直播晚会现场这个最重要的功能之外，晚会项目组还规划了点赞/分享有礼，竞猜，开宝箱，红包雨等五花八门的互动玩法，需要在原有的Native直播间上增加大量的功能。更加雪上加霜的是，晚会的招商并未结束，对直播会场的需求一直在变化。特别是直播会场换肤的需求可能导致会场的框架结构发生大幅度变化，用老的Native直播间应对这种需求变化比较困难。所以我们决定用Weex重写一个新的优酷直播间，全面还原当前的Native直播间的业务，同时添加对各种双十一互动玩法的支撑。老的Naitve直播间仅仅作为降级的备用直播间。组件封装在开始正式工作之前，我们的第一件事情是划分功能模块，确定哪些模块用Weex sdk或者aliweex自带的原生组件实现, 哪些模块需要把现有的Native代码封装为一个Weex Component供Weex业务代码引用。上图即为双十一优酷直播间的最终形态，其大致的技术架构图和功能如下图所示。经过评估，我们做出如下模块划分：会场框架: 由Weex业务代码搭建回看列表tab: 是一个包含图文的视频列表，由Weex原生实现聊天tab: 包含了大量聊天气泡动效和复杂的业务逻辑，将原有的聊天室Native代码封装为Weex Component图文直播tab：包含了投放图片，文字，视频，商品链接等复杂的逻辑，将原有的Native代码封装为Weex Component播放器组件：将原有的优酷直播播放器Native代码封装为Weex Component点赞标签： 这个组件被点击或者收到服务端推送的互动消息时会飘出大量的动画，我们的选择是将原有的Native代码封装为Weex component自定义Tab: 这个组件我们自行封装了一个webview的Component，包含多种功能1) 利用百川能力加载淘宝商品，实现边看边买2) 加载互动h5页面，实现红包雨，竞猜等功能3) 加载阿里星球投放的H5页面等其余的跳转，分享，监控埋点等功能模块封装为Weex Module供Weex业务代码使用在功能模块拆分完毕之后，整个直播间已经完全成为组件化，模块化的，可以随意地组合，分解，定制。无论未来的会场设计如何变化，只要编写新的会场皮肤，根据需要嵌入各种自定义标签，就能组合出需要的直播会场。互动玩法支撑运营同学在优酷直播中台的投放系统编辑主持人话题，换肤，红包雨等互动消息后，具体的投放信息会被服务端填入互动玩法动态模板，通过PowerMsg通道下发到端上; 当端上收到此类互动消息之后，直接通过globalEvent发给Weex直播会场，会场解析收到的字段后，根据指令显示主持人话题，拉起宝箱，红包雨页面等。降级与一般情况下的Weex页面降级到H5页面不同，我们的降级逻辑是发生加载/跳转/运行异常时，从Weex直播间跳转到Native直播间; 所以我们没有沿用Weex常见的降级逻辑，而是另外实现了一套downgrade逻辑。遇到的困难及其解决办法手势冲突在开发直播会场的过程中，我们遇到了tabbar框架和自定义Weex Component手势冲突的问题。我们希望上下滑动的手势被当前tab接收，可以在当前列表中上下滑动我们希望左右滑动的手势被tabbar接收，可以在不同的tab之间切换但是结合使用tabbar和自定义Weex Component，要么上下左右手势全部被当前tab吃掉，导致无法在tab之间切换。要么上下左右手势都被tabbar吃掉，导致当前tab无法上下滑动上图是Android View点击事件分发的简化逻辑父View与子View同时可以滑动时就会产生滑动冲突, 常见套路的一种是在父View的onInterceptTouchEvent()做拦截：public boolean onInterceptTouchEvent(MotionEvent event){
boolean intercepted =
switch(event.getActionMasked){
case MotionEvent.ACTION_DOWN:
intercepted =
case MotionEvent.ACTION_MOVE:
if(父控件拦截){
intercepted =
intercepted =
}最后我们的解法是重写了一个自定义Div标签, 将自定义Weex Component嵌入自定义Div标签中，自定义Div标签吃掉上下滑动手势并传给自定义Weex Component，将左右滑动手势抛出让身为父View的tabbar处理，这样就解决了这个手势冲突问题。然而，直播会场的Weex代码使用了ExpressionBinding来优化滑动性能，新的解法导致ExpressionBinding失效了。为了解决这个问题，我们又重写了Weex的WXGesture手势识别代码，覆盖掉WXComponent自带的默认手势识别代码，使得ExpressionBinding重新生效。ExpressionBinding的执行顺序如下:touchstart -& panstart -& ExpressionBinding panstart -&ExpressionBinding panmove -& ExpressionBinding panend -& touchend -& panend其核心概念是检测出panstart事件，然后执行js层预先传下来的“手势处理逻辑”，而不是将识别出的手势传给js层处理。我们对自定义Div标签和自定义Weex Component的修改使得ExpressionBinding识别不到panstart事件了。所以我们重写的WXGesture会在合适地方给自己所在的WXComponent发出：WXGestureType.HighLevelGesture.HORIZONTALPAN或者：WXGestureType.HighLevelGesture.VERTICALPAN事件，人为地触发ExpressionBinding的识别代码执行，最终使得ExpressionBinding可以与自定义Div标签和自定义的Weex Component协同工作。转屏体验优化之前优酷直播页面的转屏是直接将Activity转过来，然后让视频撑满屏幕; 若要恢复竖屏则把Activity再转回来，恢复vieoView为原始大小，让其余的布局显示出来。由于新的Weex直播会场复杂度大大提高，切换横竖屏的体验变得很糟糕，每次切换之后画面要黑屏一会儿才能把布局重新显示出来。经过多番尝试，我们采用如下的解法来提高体验：竖屏转横屏时，先记录下videoView的各种布局参数，然后将videoView从它的父View中取出，直接attach到当前Window的decorView上。横屏转回竖屏时，将videoView从decorView中取出，add到旧的父View中，然后重设各种布局参数。经过这个优化之后，转屏体验被大大提升了; 即使在几年前的低端机器上，也能很快速地完成横竖屏切换动作。视频圆角如图所示，双十一直播会场的直播视频是嵌入到一个天猫电视机荧幕内的。实现方式是在自定义video标签之上覆盖一个天猫电视机图片，使得视频只从带圆角的框中露出。这个实现方式在iOS端是没问题的，在Android上却失效了; 视频和图片的层级存在问题，在Android上视频的四个边角仍然会透出来，视觉上非常难看。我们的解决办法是给自定义播放器组件添加&borderRadius&属性，将UED设计稿中的电视机图片圆角值量出来，设置给自定义video标签，把这个值透传到Native层，经过750px转换之后，将视频VideoView在Native端直接切出合适的圆角。最终，呈现出来的带圆角视频画面与电视机图片的圆角完美契合，看上去就像是一体的。页面渲染速度和体验优化懒加载Weex直播间是默认是竖屏的，但是也可以转屏幕进入横屏状态。最开始进入Weex直播间时，旧逻辑是同时初始化竖屏下的布局和横屏下的布局，耗时比较长。我们的修改是进入直播间时只初始化竖屏下需要的组件，将横屏下需要的组件延迟加载，真正需要时才创建和初始化。优化冗余布局优化减少Layout层级，将设置Visibility为gone的冗余View全部删除。此外，Weex直播会场页也做了大量的层级/View精简的动作，两者结合起来最终使得加载体验有了很大的提高。飘赞动画优化直播间的点赞图标是一个Native封装的Weex Component，当用户手动点击或者收到其他用户的点赞推送时，点在图标会飘出若干个红心或者服务端下发的其他图片。粗略一看点赞功能实现的没有什么问题，但是在晚会预演的高并发条件下问题就暴露出来了，由于用户量太大，点赞推送消息太多，Android端的点赞动画会变得非常卡顿。我们的解决办法是做了一个Orange开关，在较低性能的机器上减少或者屏蔽飘赞动画；收到点赞消息推送后，不再立即飘出点赞动画，而是点赞数大于某个阈值，或者大于某个时间间隔才飘出动画，减少端上的渲染压力。此外，我们注意到飘赞动画是飘出显示区域之后直接销毁，需要飘出新动画时再创建新的图片，我们有考虑引入对象池的技术预先分配一些动画帧并复用，但是由于时间关系未能发布到线上。减轻服务端压力1 zcache将Weex bundle JS，图片等静态资源通过zcache推送到客户端上。（1） 减轻了猫晚当天，客户端请求服务端拉取资源的压力（2）由于待请求的资源就在本地，大大提高了页面渲染的速度（3） 提高了页面加载成功率2 请求合并由于某些mtop接口功能庞杂，Weex和Native代码都要请求，且调用时序无法确定。我们封装了一个Mtop Weex module，兼顾mtop请求和DataPool的功能，Weex和Native代码都通过这个module来发出mtop请求；当某个请求发出之后，短期内对同一个接口的重复请求会被缓存; 第一个请求数据返回之后，结果会通知给所有被缓存的mtop请求方。通过这个小小的优化，我们将服务端QPS压力降低了十多万。3 猫晚当天，只请求最低限度的服务端接口，不再请求诸如“直播间预告订阅”之类的非必要接口。双十一猫晚直播成果最终，优酷的双11直播取得较好的成绩：1.助力天猫双11，引导点击用户655万。2.猫晚直播同时在线达209万。我们在直播会场的关键路径和优酷直播播放器均加上了埋点信息, 根据统计信息：余温以双十一直播会场为基础，依据老的标准直播间样式重写了一份皮肤之后，Weex直播间已经在优酷直播业务中全量上线，老的Native直播间已经下线。我们为双十一Weex直播间开发的各种互动玩法已经落地为优酷直播的常态化运营手段。此次双十一猫晚直播是优酷历史上采用Weex承接的规模最大的项目，也是阿里历史上直播在线人数最高的项目。在各部门的通力合作之下，整个晚会的直播任务运行平稳，没有出现任何意外情况。在当前的双十一直播会场成果基础上，Weex直播间不仅承担了目前线上全部的优酷直播业务，还会承担即将到来的跨年晚会，春节联欢晚会的直播任务，直播团队还将推出更多酷炫的互动玩法，更加流畅的直播加载体验，敬请期待。你可能还喜欢如何把范冰冰“送”到你家？双11晚会逆天技术首次公开百万级物理和虚拟网络设备的智能化之路王坚博士跨年演讲：人类最伟大的发明，你是否忽视了？关注「阿里技术」把握前沿技术脉搏本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。阿里技术百家号最近更新：简介:阿里技术号，所有阿里技术创新均将呈现于此作者最新文章相关文章在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
现在在Weex实现的Android/iOS页面内，想实现业务埋点，将用户在该页面内的操作（如按钮点击，链接跳转）上报到行为分析服务器。不知道Weex是否有这方面的现有方案？如果要自己实现的话，建议在哪一层实现（Native层／JS层）？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
客户端写一个module扩展来实现打点，打点这个每家公司可能都不一样，所以weex对外的版本没有提供这样的功能。
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。Weex 在双11会场的大规模应用 - A5创业网
扫一扫，联系编辑获得审核机会
符合以下要求，获得报道机会
1. 新公司求报道
2. 好项目求报道
3. 服务商求报道
4. 投资融资爆料
客服热线：400-995-7855
当前位置：&&&
Weex 在双11会场的大规模应用
14:51&&来源：csdn&
作者： 徐凯（鬼道），阿里高级前端开发专家。
声明： 本文为阿里巴巴集团技术发展部投稿，版权归阿里巴巴所有，未经允许，请勿转载。
责编： 唐小引，技术之路，共同进步。欢迎技术投稿、给文章纠错，请发送邮件至。
Native 开发的诸多亮点中，流畅体验和系统调用是最多被提及的。流畅体验体现在页面滚动/动画的流畅性，背后是更好的内存管理和更接近原生的性能；同时又是 Web 的痛点：资源首次下载、长页面内存溢出和滚动性能、动画性能、传统 Web 性能（如 JS 执行效率）。Native 有丰富的系统调用能力，而 Web 痛点在于：W3C 标准太慢，有限的设备访问能力，API 兼容性问题较严重，如 Geolocation 在 Android WebView 中可用性很差。
Web 开发同样有诸多亮点，其中最耀眼的当属发布能力和规模协作。Native App 商店审核周期长（尤指 iOS）；应用更新周期长，iOS 稍快大概能达到一周更新率 60%-80%，Android 同样的更新率要 2 周甚至更长。而 Web 在合适的缓存机制下一分钟可达到 99%+。浏览器内核 WebKit 提供了相对一致的底层运行环境，HTML/JS/CSS 控制页面的结构/行为/样式，URI 连接不同的页面，有了这些基础设施，大规模的业务复用和人与人的分工协作变得相对轻松。
同时今天阿里诸多客户端已经面临包大小接近临界值，大促活动页面（H5）体验较差等一系列问题。结合 Native 和 Web 技术亮点，同时又能解决阿里遇到的业务问题，这就是 Weex 诞生的客观环境。
，在 1754 张双 11 会场页面中（统计了天猫和淘宝），Weex 页面数为 1747 占比 99.6%。手淘 iOS/Android 分别有 83.5%/78.3% 版本（UV）启用了 Weex 会场，手猫 iOS/Android 分别为 91.7%/87.9% 版本（UV）。Weex 覆盖了包括主会场、分会场、分分会场、人群会场 等在内几乎所有的双 11 会场业务。
在这样的应用规模下，工作和目标是：
业务支撑，支撑住双 11 需求，这是最基本的要求，详见下文&业务支撑&一节； 稳定性保障，Weex 引发的问题第一时间响应并处理，不留到双 11 当天，详见下文&稳定性数据&一节； 秒开实战，稳定当先力争高性能，双 11 正式主会场秒开率冲到 97%，所有会场秒开率冲到 93%，详见下文&秒开数据&。
2016 双 11 会场的感受可查看原始录屏文件：Wi-Fi | 4G | 3G | 2G | 无网络。录屏时主会场已经是预加载版本，其中 Wi-Fi 和 4G 效果接近，2G 效果取决于数据的网络请求速度（录屏时数据请求约 3.9s），无网络情况下打底数据来自前一次成功请求。流畅性可查看该视频，左起为 H5、iOS Weex、Android Weex。
展开 Weex 双 11 细分目标：
三、业务支撑
支撑住双 11 的业务需求，是 Weex 必须要迈过的坎。双 11 的会场结构大致为：会场框架（框架 + 主会场、全部会场、必抢、清单、我的双 11）、分会场、其他会场（分分会场、人群会场等）。
Weex 支撑双 11 业务首要解决的是会场框架及其交互形式：
交互主流程：
非 Push 方式（框架 Tab 切换）：主会场 - 全部会场 - 必抢 - 清单 - 我的双 11； Push 方式：主会场 - 分会场 - 主会场。 iOS 考虑到内存开销，需严控打开的主分会场 Weex 页面，定为 N 级可配，默认为 5；同时 iOS 会场框架为单实例，也是出于内存的考虑；Android 连续打开 30 级以上 Weex 页面，未见内存异常增长，无需特殊方案。
会场框架交互
Weex 会场框架很好支撑住了双 11 的复杂交互需求并提供了更好的内存管理。除了会场框架，更多的 Component 和 Module 支撑住了各色各样的双 11 需求，这里仅列出几个代表：
List 组件是几乎所有会场页面的标配，流畅的滚动帧率、高性能的内存复用机制和渲染机制是页面流畅体验的重要基础； Animation 尽管是实验版需求，却支撑住了会场的垂直弹幕、坑位显隐等动画效果，动画效果细腻； Weex 点播/直播组件 和 全景图组件支撑住了更为垂直个性化的业务需求。 组织结构
上节内容也可以看出，参与 Weex 双 11 会场涉及多个团队和平台系统：
Weex 双 11 中组织结构 天猫业务：通过斑马（活动页面搭建和发布平台）发布会场页面； 淘宝业务：通过斑马和 AWP （产品页面发布平台）发布会场页面，上层 DSL 使用 Rx（即将开源）； 预加载：提前将会场 js-bundle 下载到客户端，客户端访问 Weex 会场时网络 IO 被拦截到本地文件 IO，从而极大加快了网络加载速度，预加载是这次秒开实战的抓手（注：最核心的工作）； 手淘、手猫客户端，Weex 是客户端的一部分，客户端中其实是 Weex、Native、H5 并存的； Weex SDK、业务模块：Weex 容器和基础的 Components、Modules，业务模块包括直播/点播组件、全景图组件。
以上也仅涉及到客户端和发布端，背后还有无数的业务后台系统，就不一一列出了。
将 Weex 架构自上而下地展开：
Business，Weex 业务层，Weex 双 11 主战场是手淘和手猫，此外还有大量客户端已经启用或接入了 Weex； Middleware，Weex 中间件层，包括为 Weex 页面提供发布（斑马、AWP）、预加载（AWP）、客户端接入支持（AliWeex）、组件库（SUI）、游戏引擎、图表库等模块；其中斑马、AWP、预加载都直接参与了双 11；
Tool，工具层：
DevTools，界面和交互复用了 WebKit Devtools，支持 elements、network、断点、console 等 Playground，方便开发者调试 Weex 页面，同时也是 Weex example 的聚集地； Cli，Weex 命令行工具集； 目前仍在建设更多的工具，如 [weex-pack](https://www.npmjs.com/package/weex-pack) 支持一键打包成 App。
JS Framework，Weex 最初的 DSL 是基于 Vuejs 1.0 语法子集；目前在社区中在推进基于 Vuejs 2.0 的版本 Rx，基于 reactjs 语法的 Weex DSL（将于 12 月正式开源） Engine，渲染引擎，从架构设计上，Android/iOS/H5 RenderEngine 是相互独立和平等地位的渲染端，这是保持三端一致的基础，当然在协议实现层面需要更多的设计、质量保证。
以上就是 Weex 在双 11 中的架构和业务支撑的范围了。
四、稳定性保障
Weex 的首要挑战就是稳定性，或者说保障 Weex 会场最大限度不降级。
iOS JSCore 内存治理
8 月初（同期双 11 启动）奥运大促时，手淘 iPhone 中反复进出会场 20+（手猫 15+），会出现 Crash。奥运大促当天，手淘 iOS 1.59% Crash 次数来自该问题（top 6），手猫 1.94%（top 8）。发现问题的当天成立了攻坚小组，从 JS 业务代码、JSFM（框架）、iOS 渲染、iOS JSCore 几个方向同时排查，一周内各方向排查到逐步收敛到：根本原因是 Weex 页面实例被全局持有（Weex Runtime 只有一份），进而导致页面退出时内存不被释放，反复进出直至内存爆掉。因而任何可能导致页面实例被全局持有的因素都会触发这个问题：
业务代码中的问题，意外导致的，给出 Lint 工具扫描业务代码，引入了&全局污染治理&（见下一节）； JSFM 框架中的问题，如在 destroyInstance 时清理 commonModules 和所有 dependency target；iOS7 下的 Set Polyfill 内存飙升问题； iOS 中的问题，通过下发配置控制 VC Push 层级控制；内存警告时的非当前实例销毁策略，加入开关控制；iOS 9.x JSCore 原生 Promise 和 Polyfill 并存时的内存问题。
除了建立攻坚团队推进解决该问题，也在造势期前就展开双 11 会场压测，反复验证该问题，自双 11 造势期会场开测之后，该问题未再出现。
全局污染治理
在治理 JSCore 内存的过程中，逐步意识到对全局变量管控的必要性。Weex 中多个页面共用 1 个 Runtime，单个页面如果写法不规范不仅可能导致内存泄露，更有可能污染全局环境，进而导致所有 Weex 页面无法正常工作。全局污染治理的核心抓手：
严格模式，即 use strict，使用严格模式可以将较多常见的 JS 陷阱转化为错误，如：无法再意外创建全局变量、将拼写错转成异常、限制了 eval 的能力等； 冰冻对象，利用 ES5 的 Object.freeze()，将 Weex 核心对象和 JS 原生对象&冰冻&住。尝试修改被&冰冻&的对象会抛出错误，一旦&冰冻&无法&解冻&。 跨端依赖梳理
Weex 通过 Adapter 来适配不同客户端的具体实现，诸多通用库，如：网络库、图片库、API 库、 H5 容器（Web 组件）、埋点库、配置库 等在不同客户端上版本不一致，因此导致的线上问题将会成为双 11 会场的隐患。为此展开的依赖梳理和同步机制是双 11 稳定性的保障之一。这件事情可能将会长期出现在 Weex 问题清单之中，如何做到上层 Weex SDK。
5 个 200 坑位的普通会场页面，1 全景图会场页面，1 UT Expose 压测页面，1 直播会场页面； 页面中提供链接，能够按顺序进行 Push 跳转。 压测方案
主链路（首页-&店铺-&详情-&购物车）做一遍操作，让内存缓存占满，记下内存值 M0； 进入 Weex 页面，滑动到底部，滑动到顶部，记下 M1；点击跳转按钮，跳转到下一个页面； 重复步骤 2，让所有的页面进行压栈；全景图-&p1p2p3p4-&直播-&p1p2p3p4-&UT。 压测结果：iOS 通过，Android 通过
测试过程手淘手猫均未出现因为压栈导致的 Crash，稳定性可以保证； Android 低端机压栈过多会导致体验较差，之后也会引入类似 iOS VC 层级控制。
压测在造势期会场测试阶段展开，在超出真实会场压力的情况下（真实会场 150 坑位上限），尽可能提前嗅探出潜在的 iOS JSCore 内存问题、iOS/Android 异常闪退等细节问题。
稳定性数据
，Weex 在手淘中的 Crash 占比情况：
iOS 1.46%（TOP7） Android Java Crash 0.85%（TOP13）、Native Crash 1.72%（TOP8）
考虑到会场的业务量级，Weex 的稳定性仍然是不错的。
注：单独计算的 Weex Crash 率太小，参考价值不大。
五、秒开实战
Weex 秒开率 = （加载时间 + 首屏渲染时间）& 1s 的比率
其中：加载时间指 Weex js-bundle 的加载时间（从网络下载或本地加载）；首屏渲染时间指 Weex 页面开始渲染到第 1 个元素 bottom 超出首屏范围的时间。下文提到的&首屏网络时间&为加载时间与首屏渲染时间的和。
从双 11 结果看预加载大幅度提升加载时间，对秒开率的贡献尤其突出；但性能优化是个长期迭代的过程，回头来看优化的抓手是：预加载和首屏渲染优化。
预加载解决了 1 个问题：
用户访问页面（H5/Weex）之前，将页面静态资源（HTML/JS/CSS/IMG&）打包提前下载到客户端；用户访问页面时，将网络 IO 拦截并替换为本地文件 IO；从而实现加载性能的大幅度提升。
启用预加载后加载时间的变化，粗算一下：手淘 iOS，走网络平均 296ms，走预加载 18ms，网络性能提升约 15 倍；手淘 Android，走网络平均是 696ms，走预加载是 54ms，网络性能提升约 12 倍，但绝对值更大，对 Android 会场秒开贡献更为突出。
2015 年预加载已经在双 11 H5 会场中有较多应用，2016 年预加载升级为一项基础服务，不仅为 WindVane 提供预加载能力，也成为 Weex 秒开的最强外援。
此次双 11 会场共启用 30 个预加载包，总容量超过 20MB，业务需求相对稳定且流量较大的几个页面（会场框架+主会场 等）是独立的包，保证了对整体秒开的贡献，其他分会场均分在剩余的包中。同时主要采用强制更新的策略，即新的资源包（服务端有新发布）未下载到本地就直接读取线上，可以保证业务的实时性。，双 11 会场中 Android 走预加载占比为 59.4%，iOS 为 62.5%，高于平均水平（但还可以更高）。
首屏渲染优化
首屏渲染优化的目标就是尽力缩短首屏的渲染时间，为此在一系列的优化过程中，可以粗分为：DOM 解析优化、UI 渲染优化、分段懒加载。
DOM 解析优化
Component append 属性定义了 node 和 tree 2 种渲染模式，node 就是逐个节点渲染， tree 就是整棵树一起渲染。直观地对比：node | tree。
node 模式，节点逐个从 js 提交到 native 的， native 侧有个 16ms 间隔的 layout 保证渲染的正确性，这是更接近于 WebKit 的一种解析渲染模式。优势是每一个被解析完的节点都可以立刻显示，同时保证不会长时间阻塞主线程，劣势是可能会造成多次冗余 layout，拉低流畅性。 tree 模式，整棵树（以当前节点为 root 的整棵树）从 js 提交到 native。优势是只需布局一次，渲染更高效；劣势是如果 tree 过大，就可能会阻塞主线程甚至阻塞渲染。 node 和 tree 可以精细化地控制页面展示的逻辑和颗粒度，典型的实践为首屏以内按 tree 解析，首屏以外按 node 解析。
UI 渲染优化
List 组件在 Native 分别对应 iOS UITableView 和 Android RecyclerView，这两种 View 构建了 App 的半壁江山，使用它们来封装 list 的好处：
只会渲染可见区域，减少首屏的渲染消耗； 内存复用，所有滑动到不可见区域的 cell 都会被系统回收，用于渲染下一个 cell； cell 之间天然互相隔离， 可以默认以 cell 维度划分并用 tree 的模式解析，提高渲染效率； 拥有原生的交互体验，在 cell 上点击、左滑、右滑、移动排序等交互方式后续可以更方便地支持。 想要达到 60FPS 的体验，一次主线程渲染必须少于 16ms。Weex 中一次渲染需要经过 6 个主要步骤（Build Tree、Compute Style、CSS Layout、Create View、Update Frame、Set View Props），所以必须在 16ms 内完成这 6 个步骤，现实是任何一步在主线程中都可能超过 16ms，这块。
分段懒加载
除了底层的优化，业务上也通过分段懒加载进一步降低整体渲染时间，对首屏渲染有间接帮助（减少调度）。 方案为：会场页面使用 List 进行布局，一个 cell 对应一个模块；页面启动默认加载 6 个模块（少数页面因为首屏模块过多因此特殊处理）；默认往下滑到底触发 loadmore 后再加载 5 个模块；若加载过程中遇到电梯则电梯以下模块全部加载。
除了底层的保障，我们也坚持每天产出&性能优化建议&，推进业务性能优化，接下来会有更加方便的工具提供给业务方直接性能调优；如双 11 期间 devtool 中增加了层级检测和告警，可以帮助排查深层级导致的 Android 低端机 Stackoverflow。
由于主会场流量占据了总流量的大部分，对其秒开率单列统计。 数据为：
秒开率峰值（00:00）：整体 96.9%（278.8ms） ios 99.4%（146.4ms） Android 93.4%（411.1ms）； 秒开率均值：整体 94.4%（367.6ms） ios 99.0%（177.0ms） Android 91.8%（473.3ms）； 帧率（FPS）：红米 Note1s 53、小米 5s 58.5；iPhone5c 53.1、iPhone6p 56.9、iPhone7 58，帧率数据来自线下采集，见视频（左起为 H5、iOS Weex、Android Weex）。
秒开率峰值（00:49）：整体 92.4%（490.7ms） iOS 97.4%（291.6ms） Android 87.5%（689.8ms）； 秒开率均值：整体 83.9%（651.9ms） iOS 94.5%（368.0ms） Android 78.6%（797.4ms）。 六、新的起点 Weex 不只是 Weex 容器，Weex 业务背后是发布、预加载、A/B、线上监控、质量效能度量、数据埋点、业务开发技能转变/升级 等一系列行为的交织，如何减少业务从 H5/Native 转向 Weex 时的&阵痛&，是接下来的攻坚重点； 双 11 中遇到的典型案例或问题，会成为下一阶段的工作重点之一； 仍有大量业务需求需要开发，为此我们已经启动了 Weex BigBang 项目，按照 WindVane API 的调用频度和业务反馈情况，分批实现 30+ Weex Module/Component，包括常用的 schema 唤起支持、网络类型判断、geolocation、audio、cookie、大图预览、通讯录等； 减少新客户端接入 Weex 的成本，目前在尝试的 AliWeex 项目会扩大应用范围并成为客户端接入的标配； 跨客户端的底层依赖不同步问题会一直存在下去，需要更好的解法。
不一一列举了，之后会有 Weex Roadmap 的讨论并且会及时公布出来，欢迎关注。
了解最新移动开发、VR/AR 干货技术分享，请关注 mobilehub （ID: mobilehub)。
责任编辑：扬扬
延伸阅读：关键词：
变设龙 企业高质量图片智造平台
扫描二维码关注A5创业网了解最新创业资讯服务
&徐州八方网络科技有限公司&版权所有&
举报投诉邮箱：
扫一扫关注最新创业资讯