昨天移動開發前線公眾號發布了一篇文章（遷移中看不了，稍后會恢復），說明了移動開發前線將與前端之巔合并。為何選擇與前端合并？《移動開發前線》創立者徐川這樣說：
2015 年，我在 QCon 上聽了鬼道的演講《Native 與 Web 的融合》，后來還專門弄到他的書《跨終端 Web》學習，我認識到終端 Web 化是不可避免的趨勢，雖然在智能移動設備上，這個進程更加曲折。但從 Hybrid、React Native、PWA 的演進來看，這個過程沒有停止。2017 年，我寫了《當我們在談大前端，我們談的是什么》，組織的第二屆 GMTC 大會的主題也正式定為大前端，吹響了進軍大前端的號角。
現在到了 2018 年，小程序達到 10 億用戶、蘋果全面擁抱 PWA、谷歌收緊非公開 API 使用，一切跡象都表明，移動 Web 的時代全面到來了。很多移動開發者在過去兩年可能會有點迷茫，感覺沒有出路，大前端是我向大家建議的一個方向。我們需要去擁抱大前端，就像我們最開始擁抱移動開發一樣。
在 5 年前，我還是前端開發。我們嘗試了 Sencha Touch+PhoneGap 和 Titanium 來開發跨平臺的移動端 App。因為性能達不到要求，開發成本，生態環境，硬件性能等等原因。最終，我們全面轉向了移動 (Native) 開發。而我轉型成為了 iOS 開發。
現在的整體的技術趨勢是大前端。似乎需要移動 (Native) 開發者也能具備前端開發的能力，成為大前端開發者。但是令人憂心的是，有不少移動 (Native) 開發者之前根本沒有開發前端經驗。那我們應該如何擁抱變化，擁抱大前端呢？
選擇 Weex 開發一個實際簡單的項目是一個很好的開始。
接下來的內容，我將盡量站在純移動 (Native) 開發者的角度，通過幾個問題和一個實際項目，來描述如何通過開發 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: 如果你對以上專有名詞不是很了解也沒關系，那不影響你開發，暫時忘記這些。
雖然說 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 表現：
//v.youku.com/v_show/id_XMzQ2NTk4Njk2MA==.html?spm=a2h3j.8428770.3416059.1
Android 表現：
//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 開發者也可以搞定
使用 Weex-toolkit，按照教程創建運行。Weex-toolkit 是有人積極維護的，可以去提 Issue。
跑起項目以后會有一個網頁，上面有二維碼。使用官方 App Demo 掃碼能夠執行。
值得一提的是，支持 Hot Load。
真實的 bundle JS 地址為
http://ip:port/dist/index.js你可以寫死 JS 的 URL，但最好的方式是把官方掃碼 Demo 搬過來
擺弄你的代碼，先把 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
比如我們的請求需要對請求參數都要做 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 應用。
