Weex + Ui - Weex Conf 2018

本文是2018年 Weex Conf 中议题《Weex + Ui》的内容文档整理，主要给你们介绍飞猪 Weex 技术体系从无到有的过程，包括 Weex Ui 组件库的开发和发展，重点分享在 Weex Ui 层建设的一些经验。

文章较长，首先放上 Weex Ui 的开源地址，欢迎你们提PR，同时也能够经过 Star 来表示你的喜欢。

github.com/alibaba/wee…

Why Weex ?

Weex vs H5

咱们为何选择Weex做为咱们首要的跨端开发技术呢？写过H5的同窗确定会被它的简单高效、发布即更新、一条URL可适配多端等这些快所吸引，但写过 Native 的同窗确定也会被 Native 的富交互、性能体验、可调用原生能力、可管理内存等特性给咱们的业务带来更好的体验。

快和体验想同时兼得

可是不少时候，咱们会想将H5的快和Native的体验兼得，飞猪前几年也一直在这个方向上面探索。

包括最开始的 Hybrid 开发，经过 Bridge 提供部分 Native 能⼒来提高 H5 体验，譬如咱们在H5里面能够直接获取App的定位信息、使用相机、播放视频、导航跳转等能力，业界也有Cordova、Ionic、Meteor这些成熟的方案。

还有利用离线包体系经过提早将资源⽂件下载，访问时路由拦截加载本地资源，让咱们的H5页面能够达到秒出、动态更新、弱网可用效果，内部有手淘Zcache、飞猪信鸽、支付宝九州这些成熟的系统。

等到了16年左右，跨平台开发技术逐渐火起来后，一种全新的开发思路吸引这咱们，也即用JS来写Native，⽤ Web 的开发体验构建⾼性能、可扩展的 Native 应⽤，同时真正获取上述所说的快和体验。

业务对比分析

那么为何会选择 Weex 呢？其实和飞猪业务特色颇有关系，同时又能够很好解决这些痛点。

飞猪业务迭代速度快，也须要快速上线；同时不少时候景点和海外弱网使用，同时要体验良好；其中最重要的一点是多容器接入，适配飞猪、手淘、天猫、支付宝，也即咱们一次重要业务的开发须要一个iOS、一个Android同窗来开发两端，同时由一个H5同窗来开发兼容手淘、支付宝、UC的 Web 版本，也即一次业务发布涉及到多端同时开发、上线。

Weex 其实很好的解决了上述的一些问题，包括在飞猪、手淘、天猫 Weex环境下彻底 Native体验，同时Bundle 资源大小较 H5 小不少，加上富交互体验、长列表性能好很是适合商品列表页面和双十一场景，最重要的是真正让咱们从3我的的开发减小到了1我的，其余2我的能够去作更多有意义的事情。

接下来咱们能够从下面这个展现来看Weex和H5业务的一个展现、数据对比，详细可看此录制视频>>>

这是一个业务逻辑复杂的页面，包括筛选、排序、日历选择、收藏、长列表、业务逻辑也很复杂的页面，重构成Weex之后，咱们首屏可用时间降级68%、Bundle大小直接减小了73%，因为体验变好变快、让咱们页面转化率竟然提高了14.5%。

也上也就是咱们为何选择Weex做为咱们跨端开发的一些重要缘由，接下来介绍的是飞猪的weex 技术体系。

飞猪 Weex 技术体系

架构图

能够从底层一直往上看，底层由咱们APP的Framework / Libraries / OS Kernel等组成，咱们在Weex的上下层和手淘、天猫一块儿设计出一套统一的Api设计，包括接口请求、数据埋点、路由跳转、网络状态、支付功能、导航栏定制等这一系列的通用服务，在 Weex 上面咱们封装了Weex Ui组件库、业务组件库、UPX搭建营销模块、还有抹平多端差别的 Util 函数库，这样在咱们上层能够长出咱们众多的业务。

因为 Weex 在咱们这边和 H5 同样，都是当作页面来发布、而不是一个 View 里面写不少子View来组织，同时也很不建议你们使用vue-router来管理，更多的使用多页面来跳转体验会更好。

说到构建发布流程，咱们统一经过Clam来对咱们项目进行初始化、构建、debug、预发、发布等工做，同时在上线方面直接经过Awpp命令来直接发布页面到CND，同时能够经过信鸽将离线资源推送到APP，运营同窗也能够直接经过搭建的方式将页面发布出去。

Weex 页面如何在飞猪、手淘、支付宝进行多端投放 ?

那你可能会问 Weex 页面如何在飞猪、手淘、支付宝进行多端投放呢 ? 这里有两种方式，第一种为经过前端 URL 参数决定渲染为 Weex 仍是 H5

xxxx.html?_wx_tpl=xxxx.js：前面为降级时的 H5 地址， 后面 _wx_tpl 带的参数表明 Weex JS 地址， 当容器发现 URL 带有 _wx_tpl 参数时, 会下载后面的 JS 地址而后用 Weex 容器渲染。

还有一种为经过服务端返回内容决定渲染为 Weex 仍是 H5：

xxxx?wh_weex=true：前面能够是 JS 地址也能够是 H5 地址，后面是固定的参数 wh_weex=true，当容器发现 URL 带有 wh_weex=true 时, 会请求前面的 xxxx 地址， 若是发现响应的 mime type（HTTP header content-type）为 application/javascript，则使用 Weex 渲染返回的内容， 不然使用 WebView 渲染成 H5。

飞猪 Weex 业务大盘

Weex 并非像外界某些人传言说没有什么公司在使用Weex的，反而是超过你的想象，以上是咱们这边17年12月份前的一个相关weex页面的一览，你们能够在飞猪、手淘、支付宝里面找到这些页面，均是一份页面同时投放到多端的。

什么业务适合用 Weex ？

包括众多的营销业务、首页、频道、搜索列表、正向流程、简单详情、富交互页面都是很适合使用Weex来开发的，同时在咱们这边也有一个对应的原则包括 展现类项目优先使用 Weex、重构/新项目优先使用 Weex、深度垂直类目尝试使用 Weex。

Weex 不适合复杂场景 ？

你们能够看下以下这几个场景的视频展现>>>

你们可能会以为Weex不适合复杂的场景，其实也不必定，经过不少方式是能够作到复杂场景的支持，包括双11超长列表滚动，30多屏数据，快速滚动很顺滑。

同时包括逻辑异常复杂、多组件的国际机票列表页，Weex 一样也能够胜任；包括图3富交互的使用场景，粘手效果的丝滑拖动，快速滑动，动态隐藏头部等等功能都是能够作到的。

经过在咱们这边不少业务场景的使用 Weex 踩坑 最佳实践的积累，其实有不少东西能够沉淀下来 经过封装的方式给后续其余业务使用，这样让后面的业务能够达到快速生产，这也是咱们创建Weex Ui 组件体系一个很大的缘由。

Weex Ui 的发展和开源

为何要创建 Weex Ui 组件库体系 ？

• 在引入 Weex 初期，经过 Weex Ui 让未接触 Weex 的同窗对其编写有借鉴做用
• 提炼业务中的公共组件，便于直接引用，提升你们开发效率
• 业务规范、视觉规范、最佳实践的及时同步
• 将 Weex 业务中的疑难杂症经过组件封装，对外只暴露简单逻辑

Weex Ui 一览

通过一年多的建设，咱们一步一步将 Weex Ui 优化，整理，最终于20170930进行了开源，经过下图能够看到 Weex Ui 是怎么来的

目前 Weex Ui 组件库包括7大类31个成熟的组件，同时并非直接开源给你们使用，而是在内部已经使用了1年多后稳定后开源给你们使用，你们能够经过手淘、飞猪、任何浏览器扫码进行预览

同时一个开源库的文档实际上是后续发展中用户是否能快速上手的一个很大因素，Weex UI 包括组件说明、使用规则、Demo展现、详细使用API、升级文档等等，可让你快速使用。

Weex Ui 是否是只适合电商体系呢？

近期咱们队 Weex Ui的使用者作过一次问卷调查，结果让咱们很惊喜，并非只有电商在使用，还很不少其余的体系在使用，包括工具类、企业应用、文娱、自媒体、新闻这些其实都是有使用的。

组件化搭建你的 Weex 页面

不少时候基础建设，其实为了给业务开发来加速，譬如接下来这个飞猪专线的页面就是经过咱们的Weex Ui组件库来搭建起来的

然而基础基础只可以解决通用组件的问题，其实还包括业务组件这一块，也即上图中的your-item组件,也即咱们下面要说的 Weex 业务组件化

除了基础库，在 Weex Ui 层还能够作什么 ？

Weex 业务组件化

业务组件库更可能是前端、后端、设计师之间的一个“约定”，经过必定规范共同让业务组件变得可复用。也即Weex代码中直接引入此组件，直接插入后端返回的原始数据，就能够生成设计师所设计出的商品卡片，最终能够作到支撑任意 Weex 业务模块 投放到 任意 Weex 页面 中 任意位置 的能力。

那么应该怎么作呢？

能够自动化测试 Weex 吗 ？

答案是能够的，以前经过macacajs测试框架和Weex结合来弄，经过自定义一连串的手势、事件，最后经过用json来代表执行的顺序，能够作到，详细可见视频地址>>>

一、安装app 二、自动打开native页面 三、登陆，自动输入 四、自动测试飞猪度假首页，包括点击、跳转、滑动、下拉刷新等操做 五、自动测试飞猪专线、包括左滑、右滑操做 六、自动测试Weex Ui，包括打开组件、点击交互逻辑 七、自动各个页面运行截图，并将测试状况邮件给测试方

Weex 无障碍优化

Weex 其实也是支持无障碍的，也即让盲人在最短的时间内经过最快的方式找到本身想要的信息。 同时当盲人访问咱们Weex页面时候，让他们对 Weex 是可感知的、可操做的、可理解的、同时页面也是鲁棒的。譬如以下这个演示>>>：

无障碍在Weex实现起来是很简单的，譬如以下实现：

飞猪 Weex 双十一性能优化

每一年的双十一也就是咱们Weex的一个战场，几乎全部会场页面均由Weex实现，如何让用户丝滑的逛咱们的页面呢？期间咱们也将以前不少经验包括优化技巧放到了双十一的会场页面，包括一些经验的整理。

回到开源

其实 Weex 能够在不少不少地方使用，包括各类应用场景，这也是咱们开源Weex Ui 的一个很大缘由，给你们更多 Weex 可实现功能的输入，最佳实践实现的参考。

同时外部开发者也急须要一套成熟组件库来提升开发效率。

github.com/alibaba/wee…

从20170930开始，咱们一直在弄Weex Ui 的开源发展，包括共建 weex-toolkit 让其更好支持Weex Ui、欠缺组件的补全 + 现有组件的加强、继续扩展边界 + 轻舟解决方案 UI 库、引入更多富交互体验 + 组件的无障碍优化、简易的使用方式 + 详细的中英文档等等工做。

其实更多的是想你们一块儿参与进来，共同促进咱们 Weex 的发展。

说到共同促进，那么你能够作什么呢？ 其实能够作不少不少事情

晚上圆桌会议关于 Weex 组件方向讨论总结

1. Weex 原生组件的封装应该注意什么？

• 通用性，只有多个业务同时在使用，同时具有可抽离性特性的组件，譬如Video/TabBar/TitleBar/ImageUpload 这些在 Native中成熟的组件
• 稳定性，Native 组件不像 weex 上层的组件可调节性大，因此须要注意好 Native 组件必定须要没有Bug，防止修复和更新麻烦，同时 Native 组件一开始应该将大部分状况作成可配置化，防止频繁更新，致使须要适配不少版本
• 原子性，不建议一个组件同时作不少事情，应该是单一的功能，而后经过搭配的方式来获得更多功能

2.weex 组件开发和实践过程当中的一些经验？

• 811原则，默认80%的功能应该是不须要用户配置不少参数，10%的地方用户能够经过配置一些参数来达到目的，10%的稀有状况能够暂时不考虑，可能这里会花费不少时间开发，因此能够等到有业务须要使用时候，再更新上去
• 统一收口原则，为了不后续组件变成一个大杂烩，后续迭代视觉交互、新功能的增长须要将通用性考虑进去，这里须要一我的统一来收口、开发维护此组件，能够避免不少“业务特性”来干扰组件的可用性
• 性能体验的优化，Weex 组件比页面的编写更应该保证他的性能体验
• 信任机制：不少时候别人使用你的组件一个很大缘由是因为相信你的组件没有问题，是稳定的，同时后续会经常维护的

3.你们认为Weex Ui组件还缺乏什么？

• 缺乏一些聚集起来使用的场景，目前单个组件的使用文档已经详细说明，可是对于多个组件的一些使用，或者页面层面的开发缺乏相关案例，后期须要逐步补上weex-ui-demo
• 主题配置灵活性上须要考虑进行，目前更可能是经过参数配置的方式来更改主题颜色，实际上是能够经过一个统一外部参数的配置来使它修改

4.将来跨端开发会是怎么样的？

• Native的布局方式须要向H5的开发灵活性学习，逐步使用自动布局来实现，同时引入弹性思路开发，避免绝对计算
• 数据绑定方面会愈来愈便捷，譬如和MVVM思路同样，数据变化后，视图立马修改，而不是手动去触发

More

你们能够经过用钉钉扫一扫以下二维码，你们一块儿来讨论交流：

• 本次分享PDF文件: 《 Weex + Ui 》
• 官网地址：alibaba.github.io/weex-ui
• Github地址：github.com/alibaba/wee…

Please feel free to use and contribute to the development.