深度揭秘阿里移动端高性能动态化方案Weex

2016年Qcon大会首日，阿里巴巴资深总监、淘宝移动平台、阿里百川负责人庄卓然宣布移动端高性能动态化方案Weex即时内测，并将于6月开源。此消息一出，群情汹涌，在座的程序猿、攻城狮们纷纷拿起手机扫码，以期第一时间感受Weex的神奇之力。

在第二天的主题分享会上，阿里巴巴前端开发专家赵锦江和技术专家徐凯对Weex进行了深入的解析。以下为演讲速记整理后的成文。

阿里怎么看待移动开发？

目前的移动开发者面临的最大痛点就是面对极其复杂的环境，对此，庄卓然给出一个公式，移动开发的复杂度=应用数量×平台数量×要适配的各种各样的机型。

如何解决这个问题呢？在解决问题之前，首先要对移动开发的未来有着精准的研判。

阿里认为，移动开发的未来必定更加平衡，也就是说必须是性能与动态兼得，如此，才能够满足未来用户的需求。另外，移动开发在未来也必定是开放互联的状态，移动互联网将来肯定是基于更加大众化的技术体系，没有平台之间的隔阂，而且简单易用。

所以，阿里结合移动开发的现状并围绕其愿景推出了Weex解决方案。

事实上，在去年的双11活动中，Weex就得到了实战的验证，且表现不俗。时至今日，Weex已经被阿里技术团队多次运用，并“创造”出各种丰富的场景，整体的表现非常优异。

把移动端所有界面拆分成各个page，然后中间设置有路由的控制逻辑，同时，将移动端各种各样的能力通过各种API提供给开发者。这是阿里对移动开发模型的理解。

Weex通过标准化的东西，包括HTML、CSS和JS这些前端非常快速易用好学的语法作为开发体验，提供给开发者。另外，Weex的语法设计尊重还Web的标准。

Weex的工作原理

Weex设计之初就考虑到在三端（iOS、安卓和H5）上能够得到展现。在最上面的DSL，阿里一般称之为Weex文件（.we），通过Transformer转换成js-bundle，再部署到服务器，这样服务端就完成了。在客户端，第一层是JS-Framework，最后到RenderRengine。

输入是Virtual DOM输出是native或者H5 view，还原成内存中的树型数据结构，再创建view，把事件绑定在view上，把view基本属性设上去。Weex Render会分三个线程，不同的线程负责不同的事情，让JS线程优先保障流畅性。

Weex的性能、扩展性以及可用性究竟怎样呢？

性能方面，阿里对Weex做了多次压测。在加载时间、帧率、内存消耗、CPU占用（包括静默和峰值）等多个方面，Weex都表现得非常出色。

在谈及性能之时，帧率和加载时间几乎都会被提及，但是往往忽略了一个事实，那就是Native UI开发中通常没有JS资源在服务器端加载。Weex会把JS内置到客户端里，以免除下载的问题，从而更为有效地提升性能。

兼容性是Weex非常重视的问题，对此，阿里是这样来解决的。

首先是单测保证，包括JS和H5的单测，保证最基础的UT（Unit Test）本身所带来的含义。

其次是UI的自动化，分为两个部分，一是截图对比，将最终产生的结果和意料中的结果进行图形对比；二是Layout Results，包括Model以及其他的布局类的，通过基本的信息完成测试的过程。

在扩展性方面，Weex可以写很多页面，而且通过路由机制帮助开发者将页面进行串联。

Weex已开放内测，可用性方面正在逐步完善。包括Playground、调试工具、脚手架、AppHub、编辑器等多个方面，一些工作已经完成就绪，绝大部分工作将在5、6月份完成。

最后，是Weex的三种工作模式。

1. 全页模式

目前支持单页使用或整个App使用Weex开发（还不完善，需要开发Router和生命周期管理），这是主推的模式，可以类比RN。

2. Native Component模式

把Weex当作一个iOS/Android组件来使用，类比ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，这类Native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是Weex的重点。

3. H5 Component模式

在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短期内无法完全转为Weex全页模式（或RN），比如互动类页面、一些复杂频道页等。这个痛点的解决办法是：在现有的H5页面上做微调，引入Native解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。

另外，WVC将会融入到Weex中，成为Weex的H5 Components模式。

前端中多端/跨端/融合的桌面应用 随着互联网的发展，桌面应用程序也成为了人们日常生活中不可或缺的一部分。在这个场景下，前端开发也面临着各种挑战，如不同操作系统的兼容性、不同设备的屏幕尺寸等。为了解决这些问题，多端/跨端/融合的桌面应用程序的概念应运而生。
基于优酷业务特色的跨平台技术 | GaiaX 开源解读 GaiaX 跨端模板引擎，是在阿里优酷、淘票票、大麦内广泛使用的 Native 动态化方案，其核心优势是性能、稳定和易用。本系列文章《GaiaX 开源解读》，将带大家看看过去三年GaiaX的发展过程。 GaiaX 开源地址：https://github.com/alibaba/GaiaX
打造算法在线服务领域极致开发体验与性能 — 阿里TPP图化框架技术实践 TPP图化致力于打造一个算法在线服务领域易用、性能极致、迭代效率远超普通方式的产品。本文将介绍TPP图化以及2021年在性能、开发体验上的改进，并介绍未来TPP图化的规划。
移动端信息无障碍技术方案全解：以手淘为例 目前中国有1700多万视障人士，他们渴望购物，也希望在任何情况下都能平等的获取他们想要的信息，手淘作为全国最大的购物 App，我们也希望通过技术让视障消费者能更好的享受移动互联带来的便利，这既是公益，也是义务。 本文将和大家分享手淘在使用 DinamicX 支持无障碍的技术方案，并给出了相关示例，希望对移动端开发者有所启发。
Cube 技术解读 | 支付宝新一代动态化技术架构与选型综述 支付宝客户端的动态化技术经历三个阶段：现阶段也就是第三阶段是实体组件+部分光栅化的hybrid模式，Cube 就是该模式下的产物。
OTT端性能优化建设之本地缓存设计 | 《优酷OTT互联网大屏前端技术实践》第七章 目前，做2C业务的应用，更多强调SSR、客户端缓存以及PWA等，以实现首屏加载体验优化、秒开等性能指标，相比较而言，这些策略更加“综合”“强壮”，如果合理运用以及借助端能力，实现冷启动提速、首屏加载优化、秒开等不在话下。 但是笔者业务服务于“OTT端酷喵APP”前端业务，主要是酷喵APP的HTML5投放(目前更换使用Rax)，而端内浏览器并不支持service worker（PWA），且受制于端及浏览器内核，并无zcache类似能力。至此，大写的无奈涌上心头，这种情况还能不能抢救一把？答案是：可以，localStorage迂回包抄方案。也介于此，本文方案诞生，虽不完美，但是终究有闪光所在。
OTT端性能优化建设之Weex实践之路 | 《优酷OTT互联网大屏前端技术实践》第三章 追求极致的用户体验是个永恒的话题。无论在PC端、移动端，还是IOT端，大家都在尝试着各种技术方案，如提高秒开率，降低白屏时间等等。 在OTT端进行营销活动开发的我们，也面临这一挑战，尽管PC端和Mobile端都有成熟的技术方案，但是到了大屏端，由于终端的差异性，很多技术方案不能完全照搬照抄。 回顾优酷在OTT端的用户体验探索之路，经历了三个阶段：webview时期、自定义内核Blitz时期、weex阶段。
重磅首发 | 承载亿级流量的开发框架，闲鱼Flutter技术解析与实战大公开 去年闲鱼发布的《Flutter in action》为开发者带去一手的实践经验总结，现在《Flutter in action》全新升级啦！这本书并非基础知识的简单罗列，而是从一线问题出发，循序渐进，娓娓道来。不仅把Flutter的重要理念讲得极为清晰， 而且给开发者提供了应对眼前各种问题的实用方法。同时，书中还给出了详尽的可以融会贯通、举一反三的思路，理论陈述和问题分析面面俱到，力求让读者可以获得全面系统的技术知识。