不得不說，使用Weex開發應用程序對于我們純前端人員來說，是件「很爽」的事情，只要你熟悉了他的語法，基本可以做到一周上手寫的應用程序。極其適合交互要求不高，時間緊迫，人手不足的同構開發需求。
但是，當然有但是，如果你想寫出一個完美的應用程序，你需要在性能優化上下很大的功夫，包括動畫的優化，過場的優化，圖片的優化，細節的打磨等等，再者，就是你需要掌握或者“能寫”一些原生的代碼，不然有有些功能你是實現不了的，比如狀態欄的屬性更改，開場動畫的制作，內存的回收，webview的監聽等等。
下面我們具體講講入門知識
寫一次，隨處運行
Weex提供了多端一致的技術方案。
*首先，Weex的開發和web開發體驗可以說是幾乎一樣。包括語法設計和工程鏈路等。
*其次，Weex的組件，模塊設計都是iOS，Android，Web的開發者共同討論出來的，有一定的通用性和普遍性。
*Weex開發同一份代碼，可以在不同的端上分別執行，避免了多端的重復研發成本。
在同構這條路上，Weex比React Native做得更徹底，他「幾乎」做到了，「你來用vue寫一個webapp，我順便給你編譯成了ios和android的原生app」
至于為什么要造這個輪子，官方給了以下說法
1.Web開發本身具有非常強的高效率和靈活性，這和Web開發者Weex想解決的移動端動態性問題不謀而合。
2.網頁標準和開發體驗是很多頂尖而優秀的科技公司共同討論和建設的結果，本身的設計和理念都有極高的品質保障
3.同時Weex也希望可以借此機會努力為標準貢獻一點自己的微薄之力。
4.Web是一種標準化的技術，標準本身就是一種力量，基于標準，尊重標準，貼近標準都意味著擁有更多的可能性。
5.Web今天的生態和社區是非常繁榮的，有很多成熟的工具，庫，工程體系，最佳實踐可以使用，引入和借鑒。
在我看來，Weex其實是阿里巴巴團隊提高生產效率的產物，在淘寶這類要求多端統一迭代快速的部門，三端約定一種便于統一的規范，在加上時間的發酵，漸漸的就有了React Native開源帶來的極大轟動后，自己也坐不住了吧^ _ ^
開發過程中必須考慮的幾點：
性能
性能是一個大課題，在此就不做展開了，只稍微提及一些我們開發需要注意的幾點
1.性能影響點：UI更新>UI事件響應>后臺運算
2.合理優化過場&動畫，過場和 console 容易引起 app crash 需要注意
3.降低 js <-> native 的通信頻率
4.優化list結構，降低重排重繪壓力
5.把優先級低且耗時較長的工作推后處理
Weex 的現狀
Weex 解決了的
我的發布我做主（熱更新）
腳本語言天生自帶“熱更新”，Weex 針對 React Native 的熱更新策略做了優化，將 WeexSDK 事先綁到了客戶端上，并且對 JSBundle 進行分包增量更新，大大提高了熱更新的效率。
但優點也是缺點，如果新包依賴于心的 SDK，此情況下，我們需要發布還有新 SDK 的 app 到應用市場，用戶也須從市場更新此 app。不夠隨著 WeexSDK 版本的穩定后，相信此策略的優勢就會凸顯出來。
性能問題
Weex 是一種輕量級、可擴展、高性能框架。集成也很方便，可以直接在 HTML5 頁面嵌入，也可嵌在原生UI中。由于和 React Native 一樣，都會調用 Native 端的原生控件，所以在性能上比 Hybrid 高出一個層次。
統一三端
雖說這是一個大膽的實踐，但對于大前端社區的統一有著推動作用，顯然阿里在這一方面已經邁出了第一步。基本解決了三端同等需求導致資源浪費的痛點。
但后期可能會出現這種現象，開發一個三端的 App 會從原來的個人變成四個人，多出來的那一個人負責開發 Weex 單頁。
意思就是，三端統一的不夠徹底，但就目前的環境下，這一句是最優方案了，卻是提高了開發效率。大前端將來將如何一統三國我們且行且觀望吧。
做游戲
對于一些交互視覺統一且沒有很大的性能需求的游戲，Weex 還是可以勝任的。
近期筆者將嘗試發布一款純Weex構建的益智小游戲，敬請期待。
朋友們可以用這個demo體驗下 Weex 版掃雷游戲開發
Weex “暫時”放棄的
雖然說大一統事件百利的事，但并非無一害。
差異化
對于一些有差異化完美體驗追求的項目就只能收斂或者放棄了。
獨立的 bug 修復
對于三端同時上線，一端存在 bug 的情況，Weex 并不能保證做到牽一發而不動全身。
個性化功能
比如安卓的波紋按鈕、3DTouch、 Widget、iWatch版本等，目前這些功能還是沒有的，不知道以后 Weex
是否將其加入到官方文檔中。
不過部分功能我們也可以通過原生代碼去實現，就是這么靈活！！！
