拥抱大前端——从Weex开始

2018 年 3 月 16 日 前端之巅 曹俊

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 可以使用 Vue 作为 DSL 开发。Vue 中文文档齐全，学习曲线相对平缓，简单容易上手。也能使用 Vue 开发诸如移动Web、PC Web、公众号、小程序等。能做到“learn onec, write anywhere”甚至能“write once, run anywhere ”。值得一提的是，Weex 也可以选择 Rax 来作为 DSL 开发。Rax 和 React 的关系相当于，preact 和 react 的关系。所以你想入门 React，Weex 也可以是一个很好的起点。

另外 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。

真实的 bundle JS 地址为

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 旗下关注前端技术的垂直社群。投稿请发邮件到 editors@cn.infoq.com，注明 “ 前端之巅投稿 ”。

活动推荐：

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

点击「阅读原文」查看 QCon 北京 2018 更多关于前端的思考。大会 8 折报名最后一周，立减 1360 元，有任何问题欢迎咨询购票经理 Hanna，电话：15110019061，微信：qcon-0410。