Weex避坑指南-理论篇

Posted 2021-04-29 51NB技术

李阳

51信用卡前端基础业务负责人，完整经历51信用卡混合开发技术演进历程。

长期以来，移动端分为Native和Web两大技术阵营，在体验和效率方面各有所长。于是诞生了混合开发技术，希望能够结合两者的优点，兼顾体验和效率。提到近几年的混合开发技术，一定少不了Weex和ReactNative的参与。

51信用卡前端团队在17年开始调研，最终选定了更适合我们场景的Weex技术，并逐步开始大面积在业务中落地，至今已有20+个项目在线上稳定运行，取得了较好的效果。

（ 51信用卡已上线Weex业务，可使用51信用卡管家、51人品贷体验）

但是没有技术是银弹，Weex在51的应用并非一帆风顺，遇到了很多问题，遭受到不少来自于业务、交互和开发同学的吐槽，一度让我们陷入迷茫和怀疑之中。在这个过程中，一方面我们克服了众多困难，逐渐形成比较完善的技术体系，另一方面，也让我们对Weex技术有了更清晰的理解和认知。

本文主要是给大家分享51这边对于Weex在业务实践中的遇到过的问题，希望大家在使用Weex技术之前，对Weex的技术有更全面的认识。

第一章  Weex技术原理

chapter  one

Weex是一个使用 Web 开发体验来开发高性能原生应用的框架，Weex 致力于使开发者能基于当代先进的 Web 开发技术，使用同一套代码来构建 android、ios 和 Web 应用。

51信用卡的 Weex 项目虽然可以使用前端同学非常熟悉的 ES6 + Vue (51的前端主技术栈是基于 Vue 的，也可以使用 React )来进行编写，但是实际上 Weex 应用在App中运行和在浏览器中运行是完全不一样的过程。

得益于虚拟dom等技术的发展，Vue可以很容易实现在不同的宿主环境运行，比如在Node环境中，51信用卡前端团队可以使用Vue进行ssr，同样的道理，Weex 只是利用了 vue 作为DSL，实际渲染过程完全依赖于宿主环境本身，在App中，这个宿主环境是 iOS/Andriod，而在 Web 环境下，这个宿主环境就是浏览器。

简单原理图

从图中我们可以看出，最终Vue file会编译成js bundle(即一段js字符串)，可以在不同的平台上运行，在Web平台中，还是依靠浏览器渲染，而在iOS和Android平台，会直接使用Native控件来进行渲染，这也是Weex技术区别于 hybrid 等技术最大的特点。

第二章  Weex的优点

chapter  two

从上面的原理其实很容易想到Weex的优势：

1、跨三端：write once，run anywhere。从而可以大大减少三端开发成本，提升研发效率。

2、动态能力：通过js bundle的下发可以实现动态加载和更新，从而为客户端提供了动态化能力。

3、原生体验：在iOS和Android上实际运行的都是native的代码，因此可以实现接近原生的性能和体验。

相比Native，可以提升研发效率，减少两端开发成本，同时具备热更新能力。
相比Web，可以提升页面性能，增强用户体验。

这些优点，也是51信用卡前端团队决定引入Weex技术的主要原因，对于Weex的优点，也有大量的文章可以参考，我在这里不再赘述，今天主要还是想说一下Weex存在的问题。

第三章  Weex的问题

chapter  three

在上面的原理图我们看Weex工作机制看似非常简单，但实际上渲染过程并不简单，尤其是在Native环境下，Weex需要自己实现一系列和浏览器类似的渲染工作，包括构建DOM数 -> 构建样式表 -> 样式合成 -> 布局等复杂操作。不可避免的会造成下列问题：

1) 三端表现不一致

无论是样式还是布局，weex一般情况下不直接提供绘图能力，而是将这些UI操作通过指令传递给不同的平台，依赖三端自身的UI能力实现，因此或多或少都会存在某些特性无法直接保持一致，如事件机制、阴影、毛玻璃等。

这些差异会带来额外的抹平工作量，浏览器环境下，三端一致性非常好(>95%)，weex环境下，只能保证70%-80%一致性，甚至可能会无法抹平影响业务实现。

write once，run anywhere 是Weex的目标，但是平台的天然差异会让这件事并没有那么容易完成。

2) 受限制的Web能力

其实很好理解，浏览器和web标准发展多年，已经基本到达可以满足99%的需求状态，但是weex已经实现的文档、样式表和布局，只能是浏览器的一个非常小的子集，正是因为weex只完成很小的子集才能保证简单和高性能，否则全部都实现了和浏览器相比又有多少优势呢 ？

前端同学受Web开发惯性影响，开发Weex会非常不适应，有很多在web中很自然的写法，在weex环境下会有问题，短时间内会感觉 效率明显降低。同时，web拥有非常很高的灵活性，有一些在web环境下非常好实现的效果，在weex环境实现会比较笨重，增加开发时间。

3) 依赖客户端发版

但是在Native环境中，Weex 除了提供了基础布局能力之外，也提供了很多内置基础组件，如modal、input等。另外，许多复杂场景也会将Native封装好的UI组件直接进行调用。这部分组件，无论是bug修复还是增强功能，都需要Native参与，于是会涉及到发版以及版本碎片问题，尤其是前期能力不够丰富的时候，这些问题是不可避免的。

而在web环境中，浏览器经过这么多年的发展，已经基本遇不到需要依赖浏览器升级才能完成的需求，因此这块也是和web开发不能相提并论的地方。

4) 性能问题

并不是Weex使用原生渲染就没有性能问题，51信用卡前端团队的同学在做Weex项目时，也经常会遇到页面闪烁、白屏等问题.

因为在Native环境中 UI 的执行方是客户端，但是逻辑控制是通过js完成，因此js会和 Native 有一个通信过程，所有的交互过程都需要以数据的形式传递给 Native ，如果是单次的数据传递和响应不存在问题，频繁通信就带来性能问题，每一次渲染其实都有可能经历的dom解析、css解析、布局等过程，即使 Weex 团队针对此做了大量优化，51信用卡前端团队依然要保持谨慎。其实在浏览器上也一样，就是常说的 reflow/ repaint。

5) 缺乏现成的解决方案

无论是Web，还是iOS、Android，经过多年发展，GitHub、社区存在大量的开源方案可以直接拿过来用，而在 Weex 上，很多效果并非不能做，只是没有现成的代码可以直接使用。

带来的问题是，很多代码需要进行移植或者是重新实现，开发周期必然会被拉长。

6) 更长的排查问题链路

浏览器环境下，前端同学自己能解决绝大多数问题，Weex 环境下，很多问题都需要客户端同学协助排查。而客户端的同学也需要理解 Vue 和前端的知识才能快速协助解决问题，这个过程，无形的也会带来效率损耗。

第四章  应对措施

chapter  four

看到Weex有上面这么多问题，是不是想打退堂鼓了呢？其实所有的技术都是有两面性的，我们只需要保持一颗客观和理性的心态看待，尽可能扬长避短，即可充分发挥出技术的价值。

1) 相对充裕的排期

由于要适应受限制的Web能力，缺乏现成的解决方案等，51信用卡前端团队在排期的时候，如果是Weex项目，需要给予更多的时间，51信用卡前端团队的实践经验是前期为 1.3-1.5 倍于正常Web项目的排期，这个时间会随着熟练度和基础成熟度逐渐减少，逼近 Web 排期。

2) 混合开发基础技术团队

强有力的混合开发团队是Weex技术能够较好落地的前提，如果你的团队里面无法配备专业的客户端和前端同学，Weex可能不是你的最佳选择。

51有专门的Weex技术保障团队，是由前端和客户端的基础组同学共同组成，因此在问题排查、兼容性处理、基础能力建设等各方面都能够得到足够的支持。

3) 可接受发版或可妥协设计的预期

由于Weex动态能力的宣传，很多业务方会以为Weex能够和Web一样，做到随心所欲的发布，但是实际上前面也解释过，一旦超出现有能力范围，我们就需要Native的发版支持或者调整设计方案，因此，这个预期需要提前和业务方沟通好，避免带来不必要的麻烦。

4) 合理的技术选型

开篇就提到过，没有技术是银弹，因此，Weex并不是拿来解决所有问题的，对于很多排期紧，体验要求不高的项目，51信用卡前端团队依然可以使用Web技术。另外，51信用卡前端团队在实践过程中，还摸索出先上线 Weex降级H5，逐步替换成 Weex 的研发流程，以减少不确定性给业务带来的影响。

附上51信用卡前端团队的技术选型指南作为参考：

 • end • 

但盼风雨来

能留君在此

欢迎关注更多

51信用卡NB技术