一、背景首先說(shuō)下我為什么要問(wèn)這個(gè)問(wèn)題(沒(méi)錯(cuò)我就是這個(gè)問(wèn)題的提問(wèn)者)，剛開(kāi)始在微博上看到有技術(shù)連載覺(jué)得很感興趣，所以就關(guān)注了。當(dāng)
@趙錦江(勾三股四) 發(fā)布說(shuō)一套代碼能動(dòng)態(tài)的運(yùn)行在三端，我頓時(shí)覺(jué)得很牛X啊，既然說(shuō)是無(wú)線電商動(dòng)態(tài)化方案，那么其他場(chǎng)景呢，所以想問(wèn)問(wèn)大家的看法。問(wèn)題從發(fā)布一個(gè)晚上就關(guān)注度到了1， 2百。估計(jì)跟邀請(qǐng)了一些大V有關(guān)。至今已經(jīng)到了快800了, 讓我這個(gè)小菜很是緊張。在此感謝各位的回答。
下面我對(duì)我提問(wèn)獲得的答案加我的理解進(jìn)行下總結(jié)。
二、Weex是什么Weex是什么？考慮這個(gè)問(wèn)題我們先來(lái)看看Weex不是什么把，根據(jù)文章(
對(duì)無(wú)線電商動(dòng)態(tài)化方案的思考（三） · Issue #15 · amfe/article · GitHub)中聲明的是：
也想強(qiáng)調(diào)一下 Weex 不是什么：
- 不是一個(gè) HTML5 庫(kù)或開(kāi)發(fā)框架
- 不是一套全新的技術(shù)
- 不是為了解決純 native 開(kāi)發(fā)的體驗(yàn)問(wèn)題
- 不是一個(gè)以自身為中心的移動(dòng)應(yīng)用開(kāi)發(fā)框架
而根據(jù)第二篇文章開(kāi)頭聲明的定位我們了解到：
Weex 是一款輕量級(jí)的移動(dòng)端跨平臺(tái)動(dòng)態(tài)性技術(shù)解決方案。相信到這里可以大概了解了Weex其實(shí)一個(gè)整套的技術(shù)解決方案，并不是一個(gè)新的框架或者庫(kù)，它是一些技術(shù)的整合。三、實(shí)現(xiàn)原理關(guān)于實(shí)現(xiàn)原理我下班路上收到的第一個(gè)答案我想應(yīng)該是
@寸志的回答把，其實(shí)一開(kāi)始我覺(jué)得他調(diào)侃的成分多一些(所以一直沒(méi)有點(diǎn)同意，待會(huì)補(bǔ)上，哈哈)，之后
@尤雨溪也跟答道：
其實(shí)就叫 Vue-Native 我也不介意的...
快點(diǎn)開(kāi)源啦！
我開(kāi)始覺(jué)得這不是在打哈哈的回答。所以我回到家認(rèn)真看了下
@寸志提到的那張圖。附圖如下：
然后結(jié)合文章，再理解了一遍后覺(jué)得叫Vue-Native也不為過(guò) (
@趙錦江(勾三股四) 提到內(nèi)部開(kāi)發(fā)時(shí)候代號(hào)就是這個(gè))，哈哈。下面先從Vue-Native角度來(lái)理解下：
簡(jiǎn)單的在調(diào)侃這個(gè)名稱(chēng)上可以對(duì)比理解react.js & react-native 感覺(jué)這像是Vue.js推出的針對(duì)native端的一個(gè)框架（剛才我們說(shuō)了它并不是框架）。認(rèn)真的理解其實(shí)就涉及到Weex的真實(shí)實(shí)現(xiàn)方式了。整個(gè)簡(jiǎn)單的流程如下：
- 組件的聲明方式：可以看到Weex并沒(méi)有采用Vue.js官方的聲明方式，而是采取了跟標(biāo)準(zhǔn)更靠近一步的Webcomponents形式，但是在文中有提到Weex采取的數(shù)據(jù)綁定和依賴收集是復(fù)用了Vue.js的實(shí)現(xiàn)。
- 在有了組件并且用組件搭建好了界面后，這里添加了一層transformer。把組件中的數(shù)據(jù)綁定，style等的解析提前到了在渲染真實(shí)dom之前，編譯成json，或者js function。
- 經(jīng)過(guò)transform后，怎么一套代碼對(duì)應(yīng)到多端呢？這里可以看到Weex吸取了reactjs的virtual dom的思想。在web view& broswer中直接生成dom。在native中生成native控件。這里使用了JavaScript 引擎接收js bundle通過(guò)JS Bridge 和原生API交互。最終生成原生的控件或頁(yè)面。
這只是一個(gè)簡(jiǎn)單的流程，詳細(xì)的技術(shù)細(xì)節(jié)還是看文章把。從上面的流程可以看見(jiàn)，是借鑒了Vue.js的mvvm + react的virtual dom。關(guān)于這個(gè)結(jié)合的創(chuàng)意 可以看到
@趙錦江(勾三股四) 在
對(duì)無(wú)線電商動(dòng)態(tài)化方案的思考（三） · Issue #15 · amfe/article · GitHub文章總結(jié)的QA部分(沒(méi)想到我一句評(píng)論勾起了
@趙錦江(勾三股四)的心路歷程，讓我們有機(jī)會(huì)了解到當(dāng)初這個(gè)項(xiàng)目的起因)。
終于知道 @Jinjiang 為啥之前一直在研究 webcomponents & vue.js 了
anywhere，既然人家取名叫Weex了，我們還是要尊重下別人的勞動(dòng)成果?？吹?
@尤雨溪修改了回答，還真說(shuō)不定之后有可能跟Vuejs官方合作呢~
四、使用的場(chǎng)景&發(fā)展關(guān)于使用場(chǎng)景和發(fā)展，從
對(duì)無(wú)線電商動(dòng)態(tài)化方案的思考（三） · Issue #15 · amfe/article · GitHub文章中透露的細(xì)節(jié)來(lái)看，還有一些技術(shù)問(wèn)題還沒(méi)有解決。
- 因?yàn)橐苿?dòng)設(shè)備的資源非常有限，所以就算同時(shí)打開(kāi)多個(gè) Weex 實(shí)例，也只能公用一個(gè) JavaScript 實(shí)例，如何有效的讓多個(gè)實(shí)例在 JavaScript 引擎中共存是個(gè)關(guān)鍵的問(wèn)題
- 如何優(yōu)雅的設(shè)計(jì)動(dòng)畫(huà)和表單的語(yǔ)法并合理的實(shí)現(xiàn)，是否照搬 HTML Form 和 CSS Transition/Transform/Animation 是最好的選擇？
- 如何合理設(shè)計(jì)上層的 IDE 或可視化工具/編輯器
- 如何同一個(gè) URL 或二維碼，客戶端請(qǐng)求到的是 JS Bundle，而瀏覽器打開(kāi)的是一個(gè) HTML5 頁(yè)面
- 還有SEO的問(wèn)題（既然要開(kāi)源，這個(gè)我覺(jué)得不應(yīng)該以阿里的業(yè)務(wù)場(chǎng)景為前提。）
以上是目前Weex的一些技術(shù)問(wèn)題。但是，我覺(jué)得自從
@winter拋出說(shuō)這個(gè)是一個(gè)后KPI項(xiàng)目后。大家普遍關(guān)注于Weex之后的發(fā)展問(wèn)題。覺(jué)得可能會(huì)是一個(gè)KPI的鋪路石( 貌似Kissy這次躺的很徹底)。而且從其他的匿名回答來(lái)看，阿里其實(shí)有在研究基于RN的動(dòng)態(tài)方案。所以之后阿里是推哪套方案目前好像阿里內(nèi)部員工也比較搞不懂。我們只能說(shuō)希望Weex能克服目前的困難，然后像
@尤雨溪說(shuō)的那樣推出一套有誠(chéng)意的開(kāi)源作品。然后造福FE同學(xué)輕松hold住多端的問(wèn)題。
五、其他1. 關(guān)于開(kāi)源的時(shí)候
我根據(jù)
@winter的回答，找了下Qcon的報(bào)道，據(jù)說(shuō)是2016年中開(kāi)源.(留給阿里同學(xué)的時(shí)間不多了)。
六、最后我們并不是一個(gè)人在戰(zhàn)斗，市面上已經(jīng)有很多非常優(yōu)秀的技術(shù)可供參考和使用，Weex 希望集優(yōu)秀技術(shù)之大成，快速落地，解決業(yè)務(wù)上“最后一公里”的問(wèn)題。
雖然后來(lái)了解到這個(gè)是一個(gè)KPI的項(xiàng)目，哈哈，我還是非常認(rèn)可
@趙錦江(勾三股四)使用"最后一公里" 對(duì)Weex這樣的描述。我佩服認(rèn)真做事并且保持謙卑的人。
第一次碼這么長(zhǎng)的回答，算是對(duì)這問(wèn)題的一個(gè)總結(jié)(雖然可能沒(méi)有人看)，不對(duì)之處還請(qǐng)指正~ 最后謝謝大家的回答。
