Weex從入門到超神（一）

隨着移動端發展進入白熱化階段，不少中小型公司愈來愈注重於APP的更新迭代速度。加上去年微信小程序的問世，前端同窗彷佛迎來了「第二春」，愈來愈多的 Native 開發者感覺到了史無前例的壓力，人家已經打到家門口了，難道就這樣兩眼旁觀嗎？

兩年前 Facebook 團隊發佈了一個全新的移動端和前端無縫銜接的框架 React Native，很明顯是用 React 開發的，支持在 Native 上運行的這麼一個玩意，這相對於蘋果漫長的審覈機制的確是一個福音。但是 React 的學習曲線比較陡，網上大部分教程的性質都是 「React Native 從入門到放棄」，RN雖好，可是對於大多數移動開發者來講學習成本太高。

去年阿里巴巴開源了一個相似 RN 的框架 Weex ，雖然面世才一年多，已經收穫了普遍的關注，今年 Weex 已經被歸入 Apache 基金會的孵化項目。

爲何選擇 Weex

轉載請註明出處：來自LeonLei的博客http://www.gaoshilei.com

做爲 Native 開發者，咱們很清楚 Native 走到今天所面臨的困境，相較於前端比較呆板不夠靈活，任何改動都須要從新打包提交審覈而後發佈版本，這個週期最短也要1~2天的時間，一直有人在說要用 H5 替代 Native ,這不是危言聳聽，移動端市場正在遭受着衝擊。

大部分中小型的互聯網公司都是小步快走的模式進行版本迭代，版本發佈的靈活性就顯得尤其重要，可能產品早上想的功能點晚上就要上線，Native 確定是辦不到的，H5 這個時候就顯示出它的優點了；可是 H5 有一個致命的缺點就是性能太差，用戶體驗遠達不到 Native 帶來的那種絲滑流暢般的享受。因此這兩年，RN 和 Weex 悄然崛起就是爲了解決這種矛盾。

不論是 RN 仍是 Weex 都能作到實時修改頁面不須要 Native 發版，他們的原理都是同樣的，經過 js 來渲染 Native 界面。
Weex 在很大程度上借鑑了 RN 的思想和方式，對比一下 RN 和 Weex 的差別和優缺點：

優勢

• 因爲 Weex 採用了 Vue 做爲上層框架，相較於 React 更加輕量，Vue 的官網宣傳就是很是輕量，體積小巧，語法簡單。
• Vue 的學習成本相較於 React 更加小，大部分 Native 開發者更容易上手。
• Weex 吸取了 RN 的精華，能夠說 Weex 是站在巨人的肩膀上問世。

缺點

• Weex 相較於 RN 起步比較晚，社區沒有 RN 活躍。
• 從問世的時間上來看，RN 具備更大的優點，Weex 的學習資料比較少。
• Weex 如今存在的 BUG 相較於 RN 還比較多，對於使用來講會有一些影響。

無論選擇 RN 仍是 Weex ，咱們的目的都是同樣：經過 js 語法渲染成 Native 的頁面，至於該選擇哪一個，這就要結合本身公司的實際狀況來選，沒有絕對的好與壞。
因爲咱們公司的 H5 項目是用 Vue 開發的，因此咱們也就堅決果斷的選擇了 Weex。

可能大部分 Native 開發者看到這裏就要說一句：球都麻袋！Weex 都還搞明白怎麼又提到 Vue ，這是什麼鬼；Vue 是國人開發的一個 JS 框架，你們能夠去官網看看，文檔都是中文比較方便，這裏就再也不贅述，有一點 H5 基礎均可以很快上手。Vue官網

Weex 項目結構

想必大多數 Native 開發者對於前端的知識仍是匱乏的，雖然 Weex 官網有教程會教你怎麼安裝怎麼運行，大部分同窗任然會卡在某一個步驟走不下去，因此基礎工做仍是要作好，後面的路纔會順暢。

首先給你們介紹 Node.js 和 npm ，剛開始接觸這個我也是懵逼的，這二者之間有什麼關係？爲何要安裝 Node.js ？ 搞懂這個關係後面對 weex 中結構理解會有很好的幫助，npm 是 Node.js 默認的包管理器，從 Node.js 0.6.3 開始，npm 集成到了 Node.js 的安裝包裏面，因此咱們安裝 Node.js 的目的是使用 npm 來管理 weex 所用到的一些依賴庫。

至於怎麼安裝，能夠參考 Weex 的官方教程

前端同窗用到的 npm 有點相似咱們用的 Cocopods 來管理第三方依賴庫，安裝 Cocopods 以前你必須安裝 ruby ，由於 Cocopods 依賴 ruby 才能運行， npm 也是同樣的道理，npm 依賴 Node.js 才能運行。

Weex 的文件格式有兩種，分別是 .we 、.vue，能夠很明顯的發現用 Vue 能夠直接寫 Weex 頁面。筆者開始接觸 Weex 的時候也是直接學 Vue ,不只能夠用來寫 Weex 還能夠寫寫其餘 H5 頁面。 因此我建議學 Weex 直接看 Vue 就能夠了。

Weex 的目錄結構

├── src  
├── node_modules 
├── dist
├── build
├── bin
├── package.json
├── webpack.config.js    
└── config.js   
       
複製代碼

src

源碼存放的位置，如.we .vue

node_modules

依賴庫的存放位置，相似於Xcode項目中的 Pods 文件夾。在 package.json 所在目錄執行 npm install 就會自動安裝好全部的依賴，有點像 pod install。

dist

存放編譯好的js文件

build

存放npm build 時的 js 文件，可在 package.json 文件中配置

bin

存放一些 shell 腳本，通常用不到

package.json

項目的配置和依賴庫文件，有點相似 podfile 文件

webpack.config.js

webpack 的配置文件

config.js

項目的相關配置文件，你能夠在這個文件中配置切換不一樣的環境

提到 webpack ，這個比較複雜，咱們只須要知道 Weex 用 webpack 進行打包編譯就好了，固然也能夠用其餘工具來打包；感興趣的同窗能夠看一下 webpack 的官網。
當你運行 npm bulid 時，對應的是運行 package.json 中配置的 scripts: build 命令，src 文件夾中的文件都會被編譯好並存放到 dist 文件夾中，這個路徑在 webpack.config.js 文件中能夠進行配置。npm run 後面跟的命令都是在 package.json 的 scripts 配置的。

轉載請註明出處：來自LeonLei的博客http://www.gaoshilei.com

Weex 前端的項目目錄大概就是這樣，Weex 前端的源碼不在此次的討論範圍之類，若是你們感興趣想看 Weex 前端的源碼，在 node_modules 文件夾中就能夠找到。關於 Weex SDK源碼在後續文章中會進行深度解析。

Weex 運行原理

官方也給出了 Weex 的運行原理圖，順手牽羊拿了過來：

不難發現，Weex 其實就是將 .vue 、.we 文件編譯成 js 文件，打包成所謂的 JS Bundle 放到 dist 文件夾中，而後將編譯好的 JS Bundle 部署到服務器上，咱們的 iOS、安卓、瀏覽器就能夠訪問對應的 JS 而後由 SDK 渲染成 Native 的頁面，或者瀏覽器的內核渲染成 DOM 節點顯示。這裏有個坑要提一下：雖說是三端統一的，實際開發中仍是要作兼容處理的。

本篇文章淺顯的介紹了 Weex 的應用背景和工做原理，下篇文章將深刻分析 Weex 的實現原理。

Weex從入門到超神（二）