拥抱大前端——从Weex开始

Posted 2021-04-29 前端之巅

Situation

2015 年，我在 QCon 上听了鬼道的演讲《Native 与 Web 的融合》，后来还专门弄到他的书《跨终端 Web》学习，我认识到终端 Web 化是不可避免的趋势，虽然在智能移动设备上，这个进程更加曲折。但从 Hybrid、React Native、PWA 的演进来看，这个过程没有停止。2017 年，我写了《当我们在谈大前端，我们谈的是什么》，组织的第二届 GMTC 大会的主题也正式定为大前端，吹响了进军大前端的号角。

现在到了 2018 年，小程序达到 10 亿用户、苹果全面拥抱 PWA、谷歌收紧非公开 API 使用，一切迹象都表明，移动 Web 的时代全面到来了。很多移动开发者在过去两年可能会有点迷茫，感觉没有出路，大前端是我向大家建议的一个方向。我们需要去拥抱大前端，就像我们最开始拥抱移动开发一样。

Confliction

在 5 年前，我还是前端开发。我们尝试了 Sencha Touch+PhoneGap 和 Titanium 来开发跨平台的移动端 App。因为性能达不到要求，开发成本，生态环境，硬件性能等等原因。最终，我们全面转向了移动 (Native) 开发。而我转型成为了 ios 开发。

现在的整体的技术趋势是大前端。似乎需要移动 (Native) 开发者也能具备前端开发的能力，成为大前端开发者。但是令人忧心的是，有不少移动 (Native) 开发者之前根本没有开发前端经验。那我们应该如何拥抱变化，拥抱大前端呢？

Answer

选择 Weex 开发一个实际简单的项目是一个很好的开始。

接下来的内容，我将尽量站在纯移动 (Native) 开发者的角度，通过几个问题和一个实际项目，来描述如何通过开发 Weex 来帮助大家拥抱大前端。

为什么是 Weex？

Weex 是阿里自研的、高性能、跨平台、移动开发框架，最大的特点是解决了频繁发版和多端研发两大痛点，一套代码适配 android、iOS、 移动 Web、PC Web 等多端，极大地解放开发者的同时又保证了用户体验。从 2016.6 月开源，之后又捐给了 Apache 基金会。如果你没听过 Weex，那你已经落伍了。

但是 Weex 令人诟病的问题也很多：担心有人生没人养、文档不全、文档不够友善、坑多、Issue 没人解决、生态环境等。

文档不全那是你要找对地方：

https://weex.apache.org/

并且语言选择看英语。

Issue 看这里：

https://issues.apache.org/jira/projects/WEEX/issues/WEEX-248?filter=allopenissues

坑确实有一些，不过你要是学会看源码了解原理也不成问题。Weex 生态环境确是需要慢慢培养，可用的轮子相对有点少，所以现在还是 Apache 孵化项目。

另外 Weex 也需要大量的 Native 实现，作为 Native 开发者在 Native 你有很强的参与感。

PS: 如果你对以上专有名词不是很了解也没关系，那不影响你开发，暂时忘记这些。

如何开始 Weex？

虽然说 Vue 学习曲线相对平缓，简单容易上手。

但是，但是，但是还是得要学习的。

关于语言，学习 JS(ES6)，阮一峰的这个课程就够了：

http://es6.ruanyifeng.com/

先不要着急弄清 TS 和 JS 什么关系，也不要管 JS 和 ES6 啥关系，也不要急着开始用 TS 开始写。

关于 Vue，官方文档不能再好了：

https://cn.vuejs.org/v2/guide/

关于 Weex，看官方文档跟着能跑起项目就可以了。

其实以上这些都不着急，可以通览一遍，跟着实际项目边学边做，边做边学。这个问题下的核心答案其实是，确定一个合适的简单的实际项目来开始你的星辰大海。

如果不是一个实际项目，很难检验学习成果。

什么实际项目是适合的简单的呢？

我们用 Weex 来做一个 App 吧？是新 App，还是旧 App 重做呢？重做的话显然工作量太大了。不如把旧 App 的某些页面，比如有动态化需求或者本来就是 H5 做的改成 Weex 吧，从一两个页面开始。这个我认为是合适的。

选择的页面本身业务不能太复杂，需要尽量简单作为一个开始。这个我认为是简单的。

因为是现有 App 项目的实际页面，那必然是一个实际项目，且还有一个非常明确的目标：体验和功能要和原来 Native 的一致。

实际项目

大概介绍下我们的案例，希望能够帮助你评估工作量：有时 3 人，有时 5 人，一个月上线简单的首页，无加班。大概平均每人每天 3 小时，大部分时间还是在做 Native 其他业务。其中只有我一人有过前端开发经验，团队里 iOS 和 Android 开发者都有。

简单的首页

iOS 表现：

http://v.youku.com/v_show/id_XMzQ2NTk4Njk2MA==.html?spm=a2h3j.8428770.3416059.1

Android 表现：

http://v.youku.com/v_show/id_XMzQ2NTk4NjA0NA==.html?spm=a2h3j.8428770.3416059.1

碍于篇幅和能力的限制，我并不想把本文写成一个非常详细的教程。想讲的的是思路，思考，感想，过程。毕竟别人说的再详细，还是得要实践出真知。

---

确定目标

• 首页体验和功能和 Native 版保持一致

• 首页动态化：能够动态改变入口，配合活动和各种节日动态更新

• 能够灵活的跳转 App 内的其他 Native 页

调研

• 对首页功能进行分析

• 跑起 Weex 官方 Demo 和文档

• 了解简单的原理和基本概念

• 了解 Flex 布局

• 了解平台的差异

• 了解 Weex 支持 Vue 哪些功能

（以上官方文档足够）

重要的结论：

• Weex 官方功能大部分都能涵盖，可能需要 fork 一份改源码。比如我们能够看到首页适配里的滚动图，Weex 对应的官方组件里有 slider

• Weex 在 Native 层的三个重要概念

• Components UI 组件

• Modules 功能模块

• protocol/adapter 部分功能需要接口实现或扩展

• 为了跨平台

• Native 层面需要 iOS 和 Android 各自实现相同功能

• 需要 iOS 和 Android 的 Native 开发者都参与

• Vue 部分并不是很困难，Native 开发者也可以搞定

跑起 Vue 的项目

使用 Weex-toolkit，按照教程创建运行。Weex-toolkit 是有人积极维护的，可以去提 Issue。

跑起项目以后会有一个网页，上面有二维码。使用官方 App Demo 扫码能够执行。

值得一提的是，支持 Hot Load。

http://ip:port/dist/index.js

参考官方 Native 代码，在自己的 Native 项目里创建 viewcontroller 和 activity

你可以写死 JS 的 URL，但最好的方式是把官方扫码 Demo 搬过来

不考虑使用 Scss、Less、PUG 等，直接写 css、html、es6

摆弄你的代码，先把 UI 做成首页的样子。当中可能会遇到很多问题，那些不是坑，而是你可能对前端不了解。克服这些问题，你才能再进一步。

值得一提的是：

需要考虑好高度的适配。比如 iPhoneX 的刘海，比如 status bar，比如 navigation bar，比如 tab bar。按照我们首页的例子，我们的 Weex 页面等同于整个屏幕，我们使用 JS 代码动态的流出了顶部和底部区域，理由是这样最为灵活。

需要理解 Weex 中 css 特殊单位：wx。参考这篇：

https://lybeen.me/2017/07/30/Weex-ui-adaptive/

遇到问题多看源码。

使用调试工具

• Weex-debugger

• integrate-devtool-to-ios

• integrate-devtool-to-android

你可能不幸会遇上 Weex debug 装不上，参考 Weex-debugger 的 issue 应该能帮你解决。

开始写业务代码

• 一定要了解 promise

• 可以不使用 async/await

• 学以致用 Vue、CSS、CSS animation、ES6

• 网络请求一个好的推荐 Weex-axios

• 如果有点追求的话，建议加上 ESLint

• 在 js 中断点你可以在代码中写 debugger

摆弄你的代码，实现原来的功能。当中可能会遇到很多问题，那些不是坑，而是你可能对前端不了解。克服这些问题，你才能再进一步。

发现问题，解决问题

• 比如你可能会发现图片加载不出，原来是需要在 Native 实现一个协议

• 比如有些 UI 样式或组件 Weex 不支持，我们可以扩展 Components

• 比如我有分享功能该怎么实现？你可以使用你原来 Native 的分享代码，使用 module 封装给 JS 使用

• 比如埋点怎么埋？Native 包装，或者 JS 自己实现，或者 JS 加载一个可用的库

• 比如 Native 暴露的异步方法和同步方法的区别

• 比如线程问题，看看源码你就明白了

• 比如一些组件想复用，你可以学习 Vue 的组件开发方式，自己封装

• 一些轮子或者代码上的参考可以参考 Weex-ui。也可以去 Weex market 试试运气。到后期你甚至可以像 weex-ui 一样发布自己的 Weex UI 组件或者 Weex plugin。

• 比如解决嵌套滚动手势问题等。解决不了，改源码吧。本来在 Native 层面也是老大难问题，所以不要想 Weex 就帮你简单搞定了。

• 比如要改源码。源码是一定要改的。不是因为 Weex 烂，而是很多东西是你们自己业务特有的，人家也想不到。改源码的话，尽量扩展吧。然后要保留官方 git remote，将来还有机会升级。

这个时候你发现需要在双端写大量的代码，或者封装原来的代码，实现接口已达到双端一致的效果。

注意，如果你想要做到三端复用，Web 端也得实现。但这不是我们的目标。虽然能做到，但是需要花费大量的工作量。

想好路由跳转怎么做，实现相关协议

关心的是:

• Native to Weex

• Weex to Weex

• Weex to Native

针对业务的特殊性，去扩展 module，注册自己的协议等

比如我们的请求需要对请求参数都要做 md5 校验，校验的签名需要放到请求头中。怎么做才能最快实现了呢？原本 Native 就有相关代码，我们注册了自己的网络请求实现，在当中调用原来的 Native 代码逻辑。iOS 和 Android 都一样。

值得一提的是：

为了高性能，要尽量避免 Weex 和 Native 通信。module 尽量不要使用同步方法暴露。

准备上线了，代码下发怎么做？

可以参考的东西不少，全在网上。bundle 包放在哪里，目录结构是怎么样的，都可以自定。

代码下发服务是我们自己做的。对的，使用 Node 写的。这才叫真正的全面拥抱大前端吧。

更高追求？

• 降级方案

• 三端复用

• 增量更新

• JS framework 复用（减少 bundle 包大小）

总结

最后发现，我们写了不少 iOS，写了不少 Android，写了 Vue，工作量是 1+1+1=3。但是随着时间，项目更迭，components 和 module 还有 Vue 组件的积累。最终工作量会变成 1。

在一个实际的简单而又不简单的项目中，作为 Native 开发者你有自己的用武之地，也能有机会逼迫自己离开自己的舒适区去一个陌生领域学习，并且学以致用。以 Weex 开发经历为基础去了解更多更广泛的前端知识，比如：Webpack，TS，Scss，Stylus，Less，Babel，CSS3，PUG，ESLint，NPM，Karma，Vue，React，Angular 等等。

很重要的一点是：拥抱大前端，不代表 Native 开发过气了，没用了。希望大家都能拥抱变化，拥抱大前端。

前端之巅

「前端之巅」是 InfoQ 旗下关注前端技术的垂直社群。投稿请发邮件到 [e-mail]，注明 “ 前端之巅投稿 ”。

活动推荐：

前端面对的业务正在快速发展变化，工程的规模不断扩大，对迭代速度的要求也更高了。我们应该如何选择最合适的方案在工程中实践？这里有一些互联网名企的应用可参考——淘宝：前端交互的基础设施的建设；百度：PWA 的探索与最佳实践；微博：QUIC 的应用实践；微软：使用云和人工智能技术构建 Web 应用。