昨天移動開發(fā)前線公眾號發(fā)布了一篇文章（遷移中看不了，稍后會恢復），說明了移動開發(fā)前線將與前端之巔合并。為何選擇與前端合并？《移動開發(fā)前線》創(chuàng)立者徐川這樣說：

2015 年，我在 QCon 上聽了鬼道的演講《Native 與 Web 的融合》，后來還專門弄到他的書《跨終端 Web》學習，我認識到終端 Web 化是不可避免的趨勢，雖然在智能移動設備上，這個進程更加曲折。但從 Hybrid、React Native、PWA 的演進來看，這個過程沒有停止。2017 年，我寫了《當我們在談大前端，我們談的是什么》，組織的第二屆 GMTC 大會的主題也正式定為大前端，吹響了進軍大前端的號角。

現(xiàn)在到了 2018 年，小程序達到 10 億用戶、蘋果全面擁抱 PWA、谷歌收緊非公開 API 使用，一切跡象都表明，移動 Web 的時代全面到來了。很多移動開發(fā)者在過去兩年可能會有點迷茫，感覺沒有出路，大前端是我向大家建議的一個方向。我們需要去擁抱大前端，就像我們最開始擁抱移動開發(fā)一樣。

在 5 年前，我還是前端開發(fā)。我們嘗試了 Sencha Touch+PhoneGap 和 Titanium 來開發(fā)跨平臺的移動端 App。因為性能達不到要求，開發(fā)成本，生態(tài)環(huán)境，硬件性能等等原因。最終，我們?nèi)孓D向了移動 (Native) 開發(fā)。而我轉型成為了 iOS 開發(fā)。

現(xiàn)在的整體的技術趨勢是大前端。似乎需要移動 (Native) 開發(fā)者也能具備前端開發(fā)的能力，成為大前端開發(fā)者。但是令人憂心的是，有不少移動 (Native) 開發(fā)者之前根本沒有開發(fā)前端經(jīng)驗。那我們應該如何擁抱變化，擁抱大前端呢？

選擇 Weex 開發(fā)一個實際簡單的項目是一個很好的開始。

接下來的內(nèi)容，我將盡量站在純移動 (Native) 開發(fā)者的角度，通過幾個問題和一個實際項目，來描述如何通過開發(fā) Weex 來幫助大家擁抱大前端。

Weex 是阿里自研的、高性能、跨平臺、移動開發(fā)框架，最大的特點是解決了頻繁發(fā)版和多端研發(fā)兩大痛點，一套代碼適配 Android、iOS、 移動 Web、PC Web 等多端，極大地解放開發(fā)者的同時又保證了用戶體驗。從 2016.6 月開源，之后又捐給了 Apache 基金會。如果你沒聽過 Weex，那你已經(jīng)落伍了。

但是 Weex 令人詬病的問題也很多：擔心有人生沒人養(yǎng)、文檔不全、文檔不夠友善、坑多、Issue 沒人解決、生態(tài)環(huán)境等。

文檔不全那是你要找對地方：

https://weex./

并且語言選擇看英語。

Issue 看這里：

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

坑確實有一些，不過你要是學會看源碼了解原理也不成問題。Weex 生態(tài)環(huán)境確是需要慢慢培養(yǎng)，可用的輪子相對有點少，所以現(xiàn)在還是 Apache 孵化項目。

但最重要的是 Weex 可以使用 Vue 作為 DSL 開發(fā)。Vue 中文文檔齊全，學習曲線相對平緩，簡單容易上手。也能使用 Vue 開發(fā)諸如移動Web、PC Web、公眾號、小程序等。能做到“l(fā)earn onec, write anywhere”甚至能“write once, run anywhere ”。值得一提的是，Weex 也可以選擇 Rax 來作為 DSL 開發(fā)。Rax 和 React 的關系相當于，preact 和 react 的關系。所以你想入門 React，Weex 也可以是一個很好的起點。

另外 Weex 也需要大量的 Native 實現(xiàn)，作為 Native 開發(fā)者在 Native 你有很強的參與感。

PS: 如果你對以上專有名詞不是很了解也沒關系，那不影響你開發(fā)，暫時忘記這些。

雖然說 Vue 學習曲線相對平緩，簡單容易上手。

但是，但是，但是還是得要學習的。

關于語言，學習 JS(ES6)，阮一峰的這個課程就夠了：

http://es6./

先不要著急弄清 TS 和 JS 什么關系，也不要管 JS 和 ES6 啥關系，也不要急著開始用 TS 開始寫。

關于 Vue，官方文檔不能再好了：

https://cn./v2/guide/

關于 Weex，看官方文檔跟著能跑起項目就可以了。

其實以上這些都不著急，可以通覽一遍，跟著實際項目邊學邊做，邊做邊學。這個問題下的核心答案其實是，確定一個合適的簡單的實際項目來開始你的星辰大海。

如果不是一個實際項目，很難檢驗學習成果。

我們用 Weex 來做一個 App 吧？是新 App，還是舊 App 重做呢？重做的話顯然工作量太大了。不如把舊 App 的某些頁面，比如有動態(tài)化需求或者本來就是 H5 做的改成 Weex 吧，從一兩個頁面開始。這個我認為是合適的。

選擇的頁面本身業(yè)務不能太復雜，需要盡量簡單作為一個開始。這個我認為是簡單的。

因為是現(xiàn)有 App 項目的實際頁面，那必然是一個實際項目，且還有一個非常明確的目標：體驗和功能要和原來 Native 的一致。

大概介紹下我們的案例，希望能夠幫助你評估工作量：有時 3 人，有時 5 人，一個月上線簡單的首頁，無加班。大概平均每人每天 3 小時，大部分時間還是在做 Native 其他業(yè)務。其中只有我一人有過前端開發(fā)經(jīng)驗，團隊里 iOS 和 Android 開發(fā)者都有。

簡單的首頁

iOS 表現(xiàn)：

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

Android 表現(xiàn)：

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

礙于篇幅和能力的限制，我并不想把本文寫成一個非常詳細的教程。想講的的是思路，思考，感想，過程。畢竟別人說的再詳細，還是得要實踐出真知。

• 首頁體驗和功能和 Native 版保持一致

• 首頁動態(tài)化：能夠動態(tài)改變?nèi)肟冢浜匣顒雍透鞣N節(jié)日動態(tài)更新

• 能夠靈活的跳轉 App 內(nèi)的其他 Native 頁

• 對首頁功能進行分析

• 跑起 Weex 官方 Demo 和文檔

• 了解簡單的原理和基本概念

• 了解 Flex 布局

• 了解平臺的差異

• 了解 Weex 支持 Vue 哪些功能

（以上官方文檔足夠）

重要的結論：

• Weex 官方功能大部分都能涵蓋，可能需要 fork 一份改源碼。比如我們能夠看到首頁適配里的滾動圖，Weex 對應的官方組件里有 slider

• Weex 在 Native 層的三個重要概念

• Components UI 組件

• Modules 功能模塊

• protocol/adapter 部分功能需要接口實現(xiàn)或擴展

• 為了跨平臺

• Native 層面需要 iOS 和 Android 各自實現(xiàn)相同功能

• 需要 iOS 和 Android 的 Native 開發(fā)者都參與

• Vue 部分并不是很困難，Native 開發(fā)者也可以搞定

使用 Weex-toolkit，按照教程創(chuàng)建運行。Weex-toolkit 是有人積極維護的，可以去提 Issue。

跑起項目以后會有一個網(wǎng)頁，上面有二維碼。使用官方 App Demo 掃碼能夠執(zhí)行。

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

真實的 bundle JS 地址為

你可以寫死 JS 的 URL，但最好的方式是把官方掃碼 Demo 搬過來

擺弄你的代碼，先把 UI 做成首頁的樣子。當中可能會遇到很多問題，那些不是坑，而是你可能對前端不了解。克服這些問題，你才能再進一步。

值得一提的是：

需要考慮好高度的適配。比如 iPhoneX 的劉海，比如 status bar，比如 navigation bar，比如 tab bar。按照我們首頁的例子，我們的 Weex 頁面等同于整個屏幕，我們使用 JS 代碼動態(tài)的流出了頂部和底部區(qū)域，理由是這樣最為靈活。

需要理解 Weex 中 css 特殊單位：wx。參考這篇：

https:///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

• 網(wǎng)絡請求一個好的推薦 Weex-axios

• 如果有點追求的話，建議加上 ESLint

• 在 js 中斷點你可以在代碼中寫 debugger

擺弄你的代碼，實現(xiàn)原來的功能。當中可能會遇到很多問題，那些不是坑，而是你可能對前端不了解?？朔@些問題，你才能再進一步。

• 比如你可能會發(fā)現(xiàn)圖片加載不出，原來是需要在 Native 實現(xiàn)一個協(xié)議

• 比如有些 UI 樣式或組件 Weex 不支持，我們可以擴展 Components

• 比如我有分享功能該怎么實現(xiàn)？你可以使用你原來 Native 的分享代碼，使用 module 封裝給 JS 使用

• 比如埋點怎么埋？Native 包裝，或者 JS 自己實現(xiàn)，或者 JS 加載一個可用的庫

• 比如 Native 暴露的異步方法和同步方法的區(qū)別

• 比如線程問題，看看源碼你就明白了

• 比如一些組件想復用，你可以學習 Vue 的組件開發(fā)方式，自己封裝

• 一些輪子或者代碼上的參考可以參考 Weex-ui。也可以去 Weex market 試試運氣。到后期你甚至可以像 weex-ui 一樣發(fā)布自己的 Weex UI 組件或者 Weex plugin。

• 比如解決嵌套滾動手勢問題等。解決不了，改源碼吧。本來在 Native 層面也是老大難問題，所以不要想 Weex 就幫你簡單搞定了。

• 比如要改源碼。源碼是一定要改的。不是因為 Weex 爛，而是很多東西是你們自己業(yè)務特有的，人家也想不到。改源碼的話，盡量擴展吧。然后要保留官方 git remote，將來還有機會升級。

這個時候你發(fā)現(xiàn)需要在雙端寫大量的代碼，或者封裝原來的代碼，實現(xiàn)接口已達到雙端一致的效果。

注意，如果你想要做到三端復用，Web 端也得實現(xiàn)。但這不是我們的目標。雖然能做到，但是需要花費大量的工作量。

關心的是:

• Native to Weex

• Weex to Weex

• Weex to Native

比如我們的請求需要對請求參數(shù)都要做 md5 校驗，校驗的簽名需要放到請求頭中。怎么做才能最快實現(xiàn)了呢？原本 Native 就有相關代碼，我們注冊了自己的網(wǎng)絡請求實現(xiàn)，在當中調(diào)用原來的 Native 代碼邏輯。iOS 和 Android 都一樣。

值得一提的是：

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

可以參考的東西不少，全在網(wǎng)上。bundle 包放在哪里，目錄結構是怎么樣的，都可以自定。

代碼下發(fā)服務是我們自己做的。對的，使用 Node 寫的。這才叫真正的全面擁抱大前端吧。

• 降級方案

• 三端復用

• 增量更新

• JS framework 復用（減少 bundle 包大?。?/p>

最后發(fā)現(xiàn)，我們寫了不少 iOS，寫了不少 Android，寫了 Vue，工作量是 1+1+1=3。但是隨著時間，項目更迭，components 和 module 還有 Vue 組件的積累。最終工作量會變成 1。

在一個實際的簡單而又不簡單的項目中，作為 Native 開發(fā)者你有自己的用武之地，也能有機會逼迫自己離開自己的舒適區(qū)去一個陌生領域學習，并且學以致用。以 Weex 開發(fā)經(jīng)歷為基礎去了解更多更廣泛的前端知識，比如：Webpack，TS，Scss，Stylus，Less，Babel，CSS3，PUG，ESLint，NPM，Karma，Vue，React，Angular 等等。

很重要的一點是：擁抱大前端，不代表 Native 開發(fā)過氣了，沒用了。希望大家都能擁抱變化，擁抱大前端。

「前端之巔」是 InfoQ 旗下關注前端技術的垂直社群。投稿請發(fā)郵件到 editors@cn.infoq.com，注明 “ 前端之巔投稿 ”。

活動推薦：

前端面對的業(yè)務正在快速發(fā)展變化，工程的規(guī)模不斷擴大，對迭代速度的要求也更高了。我們應該如何選擇最合適的方案在工程中實踐？這里有一些互聯(lián)網(wǎng)名企的應用可參考——淘寶：前端交互的基礎設施的建設；百度：PWA 的探索與最佳實踐；微博：QUIC 的應用實踐；微軟：使用云和人工智能技術構建 Web 應用。