【Weex】 理性思考
什麼是動態性
今天在移動端，尤其是像手機淘寶這樣的 App 中，動態性問題逐漸成爲一個比較棘手的問題。所謂動態性，就是把移動應用本身的靈活性、迭代更新的週期和成本優化到極致。比如手機淘寶的店鋪首頁，它允許商家實時裝修自己的店鋪，更新自家的商品、活動等信息；再比如淘寶、天貓每次大促的會場頁面，要求我們非常靈活的及時調整界面信息和狀態，確保在瞬息萬變的活動當天緊跟促銷節奏，應對各種突發情況。
爲什麼要解決動態化的問題
動態性需求的出現有很多必然的因素：我們的移動應用背後是一個平臺級甚至是生態級的電商系統，它需要有海納百川的能力和高速流通的特點，市場上很多移動應用也有類似的客觀形態和訴求；同時整個行業迄今爲止在移動端的積累都還不足以對產品形態、用戶體驗、交互方式等細節有完全的前期把握，一個移動應用，客觀上需要更多的嘗試和探索，甚至是“試錯”，而這種動態化的程度和產品迭代演進的速度有着強烈的正相關；第三，我們不必要爲這些動態性在多個端投入重複的精力，更不應該因此而頻繁的觸發新版本。所以動態性問題在今天的移動端顯得尤其重要。
無線電商動態化
無線（移動端）：
1、前端快速迭代（試錯）：
無線端很多形態大家都還在一起摸索之中，這其中有很高的“試錯”成本，產品經理甚至會在項目初期就主動坦承我們需要很多試錯，需要快速迭代。
2、後臺版本兼容：
由於前端以平均每兩週一個版本的速度在瘋狂迭代，後臺代碼中從最開始的比較規整的代碼，演變成進行各種各樣的容錯、兼容的臃腫代碼。
電商：
電商是和真金白銀打交道的，這要求我們對技術方案的穩定性和準確性做非常嚴格的把控，對項目工程化有極高的要求，項目過程中的半點鬆懈都有可能對用戶產生極大的影響。
動態化：
今天前端app 都是 native 的，有必要的版本控制和發佈節奏，並且能夠快速迭代、實時調整、還能把控性能和各方面風險，就變成了重中之重，但是這部分還有其他的問題修復BUG需要送審
IOS審覈週期不定，打包-發佈-審覈（這個工作流程避免不了，總是在浪費時間），在這種惡略條件下，催生出了動態化這個概念，app不發佈照樣更新，這樣必將是未來互聯網發展的大方向。
動態化歷史：
Weex的由來
WEEX前身
Weex的前身是WeApp，一個用JSON配置原生UI組件來實現動態化的框架，關於類似這個的思想，可以在天貓這篇配置中心實踐中看到，已經很牛了，Weex是WeApp的進化版本，加上ex去掉App，就成了現在這個名字。他們還編了個段子：
You give us a few weeks, so we bring you a weex
這個段子要表達的意思，你get到了嗎？
與Vue.js的關係
Weex由多個關鍵模塊組成，分別是DSL transformer、JS Framework、HTML5/iOS/Android Renderer和工具鏈 ， 其中JS Framework就直接使用了部分來自Vue.JS的代碼。不過這種使用也是遵守開源協議的（Vue使用MIT協議，Weex使用Apache協議），Weex團隊在源碼的說明文件中記錄了來自Vue.JS和其他開源項目的貢獻。
爲什麼不用React Native
關於這個問題，莊卓然列舉了一些原因：
1、因爲手淘之前有WeApp，從WeApp進化到Weex是很自然的選擇，拋棄自己的解決方案去用別人的反而很奇怪。
2、React Native的JSX、CSS in JS寫法都很彆扭，淘寶有很多ISV（即各種店鋪），他們之前只會Web技術，寫這個有門檻。另外，HTML標準在過去二十年內經受了檢驗，HMTL/CSS/JS對應的結構、樣式和行爲，天然分離，代碼的可維護性會更好。拋棄標準自己發明DSL也不明智。
3、React Native重視平臺獨立性，不能做到100%代碼共用，實際上還是要學習各平臺的特性，Weex希望做到100%共用，即一次編寫到處運行，進一步降低開發門檻。
4、React Native在一些地方的性能上還有問題，手淘希望能自己主導優化的進程，否則會很被動。
Weex的優勢
Weex工作原理：
state 有更改的時候，weex會自動調用組件的 render 方法重新渲染整個組件的
UI。weex主要的目標是提供一套不同的, 高效的方案來更新 DOM.不是通過直接把 DOM 變成可變的數據, 而是通過構建 “Virtual DOM”, 虛擬的 DOM, 隨後 weex處理真實的 DOM 上的更新來進行模擬相應的更新。
DOM 樹上的節點被稱爲元素, 而 virtual DOM 是完全不同的抽象, 叫做 components，component 的使用在 weex裏極爲重要, 因爲 components 的存在讓計算 DOM diff 更高效。
簡單的說就是：
當然如果真的這樣大面積的操作 DOM，性能會是一個很大的問題，所以 Weex實現了一個虛擬 DOM，組件 DOM 結構就是映射到這個虛擬 DOM 上，weex在這個虛擬 DOM 上實現了一個 diff 算法，當要更新組件的時候，會通過 diff 尋找到要變更的 DOM 節點，再把這個修改更新到瀏覽器實際的 DOM 節點上，所以實際上不是真的渲染整個 DOM 樹。這個虛擬 DOM 是一個純粹的 JS 數據結構，所以性能會比原生 DOM 快很多。
3、Android RenderEngine 將輸入Virtual DOM 轉換成輸出的android原聲控件；
目前Weex有三種集成方式：
全頁模式：
：目前支持單頁使用或整個app使用weex開發（還不完善，需要開發router和生命週期管理）這是主推的模式，可以類比RN。
Native Component模式
：把weex當作一個iOS/Android組件來使用，類比ImageView。這類需求遍佈手淘主鏈路，如首頁、主搜結果、交易組件化等，和業務同學溝 通下來這類Native頁面主體已經很穩定，但是局部動態化需求旺盛導致頻繁發版，解決這類問題也是Weex的重點。
：這也涉及到如何讓Native同學快速上手“準Web”開發，有意思的話題，大家多給些建議。
H5 Component模式
：在H5種使用Weex，類比WVC。一些較複雜或特殊的H5頁面短期內無法完全轉爲Weex全頁模式（或RN），比如貓超、互動類頁面、一些複雜頻道 頁 等。針對這個痛點我發起過WVC項目，並在實際業務中驗證了這樣的想法：在現有的H5頁面上做微調，引入Native解決長列表內存暴增、 滾動不流暢、動 畫/手勢體驗差等問題。
：WVC將會融入到Weex中，成爲Weex的H5 Components模式。這3種模式幾乎涵蓋了淘系業務上的動態化需求（針對Native）或體驗提升需求（針 對H5）。更有趣的是這3種模式的技術基礎是一致的，這非常重要，意 味着：業務方可以使用Native或H5 Component模式 解決實際的業務痛 點，同時平滑過渡到Weex全頁模式。期待Weex成長壯大到AppFramework的那天。