Situation
2018-03-15公众号《移动开发前线》发布了一篇文章。讲述了《移动开发前线》将与《前端之巅》合并。为何选择与前端合并？《移动开发前线》创立者徐川这样说：
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看这里。坑确实有一些，不过你要是学会看源码了解原理也不成问题。生态环境确是需要慢慢培养，可用的轮子相对有点少，所以现在还是Apache孵化项目。
但最重要的是weex可以使用Vue作为DSL开发。Vue中文文档齐全，学习曲线相对平缓，简单容易上手。也能使用Vue开发诸如移动Web、PC Web、公众号、小程序等。能做到learn once, 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，看官方文档https://weex.apache.org/跟着能跑起项目就可以了。
其实以上这些都不着急，可以通览一遍，跟着实际项目边学边做，边做边学。这个问题下的核心答案其实是，确定一个合适的简单的实际项目来开始您的星辰大海。
如果不是一个实际项目，很难检验学习成果。
什么实际项目是适合的简单的呢？
我们用weex来做一个App吧？是新App，还是旧App重做呢？这显然太大了。不如把旧App的某些页面，比如有动态化需求或者本来就是h5做的改成weex吧，从一两个页面开始。这个我认为是合适的。
选择的页面本身业务不能太复杂，需要尽量简单作为一个开始。这个我认为是简单的。
因为是现有App项目的实际页面，那必然是一个实际项目，且还有一个非常明确的目标：体验和功能要和原来Native的一致。
实际项目
大概介绍下，希望能够帮助您评估工作量：有时3人，有时5人，一个月上线简单的首页，无加班。大概平均每人每天3小时，大部分时间还是在做native其他业务。其中只有我1人有过前端开发经验，iOS和android开发者都有。
简单的首页
碍于篇幅和能力的限制，我并不想把本文写成一个非常详细的教程。想讲的的是思路，思考，感想，过程。毕竟别人说的再详细，还是得要实践出真知。
确定目标
- 首页体验和功能和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
参考官方naitve代码，在自己的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。参考这篇。
遇到问题多看源码。
使用调试工具
您可能不幸会遇上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开发过气了，没用了。希望大家都能拥抱变化，拥抱大前端。
网友评论