摘要：在最上面的，阿里一般稱之為文件，通過轉(zhuǎn)換成，再部署到服務(wù)器，這樣服務(wù)端就完成了。例如，通過安裝了業(yè)界的工具庫用上和如今前端的開發(fā)，一般離不開預(yù)處理器，比如和。在默認(rèn)的文件中，即使有的助力，這類預(yù)處理器也是對(duì)其無能為力的。

init內(nèi)一般用于初始化一些內(nèi)部變量，綁定一些自定義事件，這時(shí)還沒有數(shù)據(jù)綁定，沒有創(chuàng)建vdom，所以不能通過this獲取到data和methods，也不能獲取vdom的節(jié)點(diǎn)

created 完成了數(shù)據(jù)綁定 ，但還未開始編譯模板，可以通過this獲取data和methods，但不能獲取vdom的節(jié)點(diǎn)

ready表示渲染完成 ，從子組件往上觸發(fā)

destroyed 組件銷毀，比如頁面跳轉(zhuǎn)，從子組件開始往上觸發(fā)

Weex設(shè)計(jì)之初就考慮到在三端（iOS、安卓和H5）上能夠得到展現(xiàn)。在最上面的DSL，阿里一般稱之為Weex文件（.we），通過Transformer轉(zhuǎn)換成js-bundle，再部署到服務(wù)器，這樣服務(wù)端就完成了。在客戶端，第一層是JS-Framework，最后到RenderRengine。

輸入是Virtual DOM輸出是native或者H5 view，還原成內(nèi)存中的樹型數(shù)據(jù)結(jié)構(gòu)，再創(chuàng)建view，把事件綁定在view上，把view基本屬性設(shè)上去。Weex Render會(huì)分三個(gè)線程，不同的線程負(fù)責(zé)不同的事情，讓JS線程優(yōu)先保障流暢性。

Weex的三種工作模式。

全頁模式

目前支持單頁使用或整個(gè)App使用Weex開發(fā)（還不完善，需要開發(fā)Router和生命周期管理），這是主推的模式，可以類比RN。

Native Component模式

把Weex當(dāng)作一個(gè)iOS/Android組件來使用，類比ImageView。這類需求遍布手淘主鏈路，如首頁、主搜結(jié)果、交易組件化等，這類Native頁面主體已經(jīng)很穩(wěn)定，但是局部動(dòng)態(tài)化需求旺盛導(dǎo)致頻繁發(fā)版，解決這類問題也是Weex的重點(diǎn)。

H5 Component模式

在H5種使用Weex，類比WVC。一些較復(fù)雜或特殊的H5頁面短期內(nèi)無法完全轉(zhuǎn)為Weex全頁模式（或RN），比如互動(dòng)類頁面、一些復(fù)雜頻道頁等。這個(gè)痛點(diǎn)的解決辦法是：在現(xiàn)有的H5頁面上做微調(diào)，引入Native解決長列表內(nèi)存暴增、滾動(dòng)不流暢、動(dòng)畫/手勢(shì)體驗(yàn)差等問題。

另外，WVC將會(huì)融入到Weex中，成為Weex的H5 Components模式。

官網(wǎng) http://alibaba.github.io/weex/
官方英文 http://alibaba.github.io/weex...
官方示例 http://alibaba.github.io/weex...
Weex Playground http://alibaba.github.io/weex...
github https://github.com/alibaba/weex
工程開發(fā)套件 https://github.com/weexteam/w...
命令行工具 https://github.com/weexteam/w...
調(diào)試工具 https://github.com/weexteam/w...

awesome-weex https://github.com/joggerplus...
vczero https://github.com/vczero/wee...
h5weex開發(fā)相關(guān)文章 https://github.com/h5weex/h5w...
weex中文文檔 http://doc.weexstore.com/177086

gitter https://gitter.im/weexteam/cn
weex-help http://weex.help/
weex.store http://weexstore.com/

weex-demo-dusan 實(shí)現(xiàn)splash，guide，home頁面，交互主要是點(diǎn)擊，左右，上下滑動(dòng)。https://github.com/duqian2919...

hello-weex包括一個(gè)Weex App，和自己擴(kuò)展的WeexiOSKit。
hello-weex https://github.com/coderyi/he...

toolbox-weex 一個(gè)小型的項(xiàng)目，幫助新手體會(huì)一下如何做出可以看、可以用的原生界面。
https://github.com/hugojing/t...

weex很多功能都進(jìn)行了模塊化的封裝,內(nèi)置模塊引用需要添加@weex-module前綴,使用require("@weex-module/name")可以進(jìn)行引用。

現(xiàn)有模塊包括:

dom

steam

modal

animation

webview

navigator

阿里巴巴開源前端框架--Weex實(shí)踐
http://blog.csdn.net/zhangcan...

Weex詳解：靈活的移動(dòng)端高性能動(dòng)態(tài)化方案 http://www.imooc.com/article/...

給正在學(xué)習(xí)Vuejs同學(xué)的幾個(gè)小Tipshttp://www.imooc.com/article/...

阿里無線11.11 ： Weex——關(guān)于移動(dòng)端動(dòng)態(tài)性的思考、實(shí)現(xiàn)和未來 http://www.infoq.com/cn/artic...

Weex默認(rèn)的文件結(jié)構(gòu)是要求所有相關(guān)的we文件都在同一級(jí)目錄下，以便能準(zhǔn)確的找到依賴的組件，例如：

bar.we


foo.we

當(dāng)需要提取一些公共組件，這些公共組件一般存放在一個(gè)公共目錄下（自建的目錄或通過npm安裝到node_modules目錄），而這樣的文件結(jié)構(gòu)，也往往出現(xiàn)在一些完整的項(xiàng)目工程中，當(dāng)通過上述的腳手架搭建好示例工程手，可以通過前端習(xí)慣的require方式來引用非相同目錄下的we文件，例如：

components/bar.we


foo.we

其背后的原理，實(shí)際上是整個(gè)轉(zhuǎn)換和打包過程借助了webpack以及weex-loader，使得其中的模塊化定義遵循標(biāo)準(zhǔn)的The way of CommonJS。

有了webpack的助力，在we文件中，也能輕松使用一個(gè)符合CommonJS規(guī)范的JS文件。例如，通過npm安裝了業(yè)界No.1的工具庫lodash：

foo.we

##用上Tomorrow"s css和ES2015
如今前端的開發(fā)，一般離不開預(yù)處理器，比如postcss和babel。在默認(rèn)的we文件中，即使有webpack的助力，這類預(yù)處理器也是對(duì)其無能為力的。為此，我們需要拆分這個(gè)we文件，讓它變成標(biāo)準(zhǔn)的html、css或js文件。

bar.we.html


bar.we.css

.hello {
  font-size: 40px;
  color: #333;
}
bar.we.js

module.exports = {
  template: require("./foo.we.html"),
  style: require("./foo.we.css"),
  data: {
    name: "Weex"
  }
}

并且，需要在webpack.config.js中加入幾個(gè)能解析這些特殊文件的loader：

loaders: [
  {
    test: /.we.js(?[^?]+)?$/,
    loaders: ["weex?type=script"]
  },
  {
    test: /.we.css(?[^?]+)?$/, 
    loaders: ["weex?type=style"]
  },
  {
    test: /.we.html(?[^?]+)?$/, 
    loaders: ["weex?type=tpl"]
  }
]

之后，仍然使用require的方式來引用這個(gè)"we"文件：

foo.we

當(dāng)分割了we文件后，你就可以分別對(duì)其中的css或js文件使用你想要的預(yù)處理器。

?。?！不過需要特別提醒的是，目前weex-loader只支持module.exports={...}的模塊輸出方式，所以即使你在js文件中用了ES6的import，但請(qǐng)勿使用export來導(dǎo)出模塊

Weex的代碼本身是運(yùn)行在js的runtime下的，所以為了和native進(jìn)行通訊，就需要借由hybrid的方式。其中，對(duì)于native提供的一系列模塊方法，就需要用一種特殊，但直觀的方式來調(diào)用。

原本，Weex中集成了一些預(yù)定義的API，例如this.$sendMtop。但這些預(yù)定義API的維護(hù)成本過高，因此在最新甚至以后的Weex版本中，會(huì)漸漸廢棄這類預(yù)定義的API，而改用更加通用的方式：

var stream = require("@weex-module/stream")
module.exports = {
  ready: function() {
    if (stream && stream.sendMtop) {
      stream.sendMtop(params, callback)
    } else {
      console.error("stream.sendMtop is invalid")
    }
  }
}

這里又再次請(qǐng)出了萬能的 require ，不過和普通的 require 不同的是，需要指定特定的 @weex-module 前綴方能正確使用

為了解釋異步函數(shù)的在Weex中的危害，首先要理解在Weex中產(chǎn)生的兩類task。

一類，是由Weex控制的js和native交互時(shí)產(chǎn)生的task（以下簡稱Weex的task），比如一系列異步調(diào)用native模塊方法，或者點(diǎn)擊事件等。

一類，是系統(tǒng)原生的task（以下簡稱原生的task），比如·setTimeout，Promise·。

在Weex的task中更新數(shù)據(jù)時(shí)，Weex可以自動(dòng)更新View。而在原生的task中，因?yàn)閃eex喪失了控制權(quán)，所以無法做到自動(dòng)更新。這就導(dǎo)致，在原生的task中產(chǎn)生的diff，會(huì)滯留直到下一次Weex的task才會(huì)被觸發(fā)更新View。從表面上看，就是在這些原生的task中改變數(shù)據(jù)后，并沒有及時(shí)反應(yīng)到View上。為了，避免這個(gè)問題的產(chǎn)生，目前來說并不推薦使用Promise。而對(duì)于setTimeout來說，可以使用native提供的timer.setTimeout的模塊方法。

Weex當(dāng)前版本設(shè)計(jì)了組件的生命周期，以下的一張圖可以比較直觀的告訴大家在整個(gè)生命周期里都做了些什么事情：

那么在這些生命周期的Hook里，可以做哪些事情呢：

在init中可以進(jìn)行數(shù)據(jù)請(qǐng)求，比如mtop。但這個(gè)時(shí)候上下文中還沒有data對(duì)象，同時(shí)也不建議在之后的任何階段改變data的數(shù)據(jù)結(jié)構(gòu)。
在created中，可以對(duì)data進(jìn)行操作了，且此時(shí)更新數(shù)據(jù)不會(huì)產(chǎn)生多余的diff，但切忌也不能更改data的數(shù)據(jù)結(jié)構(gòu)。另外，可以通過this.$on來監(jiān)聽子組件的dispatch。
在ready中，此時(shí)子組件已經(jīng)ready，可以獲取子組件的Vm對(duì)象了。而此時(shí)，如果更新數(shù)據(jù)，會(huì)產(chǎn)生多余的diff。
特別提醒：這三個(gè)階段，都是不允許更改data的數(shù)據(jù)結(jié)構(gòu)的。

來看一個(gè)通過改變class來改變樣式的例子：

上述例子，通過點(diǎn)擊來切換樣式名。但是你會(huì)驚奇的發(fā)現(xiàn)，在最初一次切換之后，字體的顏色就一直是紅色的了。

這其實(shí)是目前Weex一個(gè)bug，討論如何修復(fù)的issue在這里#397。原因就是，在Weex中樣式表樣式的切換，并不會(huì)清除原來的樣式。例如，當(dāng)前樣式是highlight，其中字體顏色是red，在切換到normal時(shí)，因?yàn)闆]有指定字體顏色，結(jié)果原來的red顏色就被保留了下來而并沒有清除掉。所以，在上面的例子中為了避開這個(gè)bug，需要顯示的設(shè)置字體顏色：

.normal {
  font-size: 40px;
  color: black;
}

另外，對(duì)于最佳實(shí)踐來說，可以通過組合class名稱的方式，把需要切換的樣式提取出來：

Weex擁有一套類似前端開發(fā)習(xí)慣的DSL，HTML和CSS部分也都會(huì)遵循W3C的標(biāo)準(zhǔn)。其中元素上的屬性定義，對(duì)于非前端同學(xué)來說會(huì)有很多誤區(qū)，這里務(wù)必要說明下。

屬性名必須全部小寫，可以使用連接符-。
屬性值，盡量保證是原始類型，即number/string/boolean/undefined/null。對(duì)象類型的值一般用于大數(shù)據(jù)量的數(shù)據(jù)綁定。
一些HTML文章里會(huì)推薦在屬性上用data-xxx的方式，這里并不需要特意加data前綴，因?yàn)閃eex的js中并沒有dataset的API可供調(diào)用。

趁熱打鐵，來說下子組件的數(shù)據(jù)綁定。因?yàn)閿?shù)據(jù)綁定也是通過屬性來定義的，所以首先要遵循上一段所說的規(guī)則。

綁定數(shù)據(jù)通過屬性來定義，不僅需要在使用的元素上指定屬性并綁定父組件中的數(shù)據(jù)，也要在子組件的data中指定對(duì)應(yīng)的鍵，并且元素上的屬性和子組件中的鍵名的對(duì)應(yīng)規(guī)則是：如果屬性中有連接符，則鍵名為去掉連接符后的駝峰寫法，否則全部以小寫命名。
如果僅僅需要給子組件傳遞數(shù)據(jù)，而其中的數(shù)據(jù)結(jié)構(gòu)對(duì)父組件是透明的，那么建議直接使用一個(gè)屬性來映射；如果，屬性是子組件的一些功能（且數(shù)量小于等于5個(gè)），則可以獨(dú)立開來（基本上和API行為的設(shè)計(jì)原則差不多），例如：

在我們各類大型運(yùn)營活動(dòng)的頁面中，大家對(duì)樓層/坑位這些詞應(yīng)該不陌生。而這些名詞的界面，基本都要靠循環(huán)列表來完成。而循環(huán)列表的性能又是整個(gè)運(yùn)營頁面的關(guān)鍵。所以在遍歷這樣的列表或者數(shù)組的時(shí)候，就需要一些技巧。

通常來說，因?yàn)榇嬖跇菍拥母拍?，而樓層里又是多個(gè)坑位，坑位又經(jīng)常是雙列寶貝，眼瞅著這得用個(gè)三重循環(huán)才能搞定。不過實(shí)際上，雙列寶貝可以優(yōu)化成不使用循環(huán)的結(jié)構(gòu)。當(dāng)然了，前端的童靴們一定要對(duì)著你們的服務(wù)端童靴保持堅(jiān)定立場(chǎng)，要求獲得清晰且正確的數(shù)據(jù)結(jié)構(gòu)，確保前端不需要對(duì)數(shù)據(jù)結(jié)構(gòu)做二次處理。

通常的數(shù)據(jù)結(jié)構(gòu)和對(duì)應(yīng)的模板一般是這樣的：

其中比較常見的數(shù)據(jù)結(jié)構(gòu)問題，比如items只是一個(gè)一維數(shù)組。如果能在服務(wù)端就處理好items的多維數(shù)組問題，那么前端的效率會(huì)高很多。

再仔細(xì)剖析其中的模板：

...

  computed: {
    headers: function() {
      return this.floors.map(function(v) {
        return {name: v.name}
      })
    }
  }

這里綁定了一個(gè)computed特性的數(shù)據(jù)。當(dāng)某類數(shù)據(jù)不太適合展示的時(shí)候，推薦可以用computed的方式來達(dá)到數(shù)據(jù)預(yù)處理的目的，而不是在created中吭哧吭哧的算一份新的數(shù)據(jù)結(jié)構(gòu)出來。

...
    

...


      

在這三個(gè)repeat中都用了track-by。它的特點(diǎn)是，可以記錄數(shù)組中某個(gè)項(xiàng)的一個(gè)主鍵，并在之后的更新中復(fù)用這個(gè)特定的項(xiàng)，而不是重構(gòu)整個(gè)數(shù)組。例如

樓層1增加兩行坑位

this.floors[0].items.push(
  {lineId: 3, list: [{itemId:5, name: "i5"}, {itemId:6, name: "i6"}]},
  {lineId: 4, list: [{itemId:7, name: "i7"}, {itemId:8, name: "i8"}]} 
)
增加一個(gè)樓層

this.floors.push({
  floorId: 2,
  name: "f2",
  items: [
    {lineId: 5, list: [{itemId:9, name: "i9"}, {itemId:10, name: "i10"}]},
    {lineId: 6, list: [{itemId:11, name: "i11"}, {itemId:12, name: "i12"}]}
  ]
})

如果沒有設(shè)置track-by，那么Weex會(huì)重構(gòu)整個(gè)數(shù)組，導(dǎo)致元素被刪除后又重新添加。而添加了id作為track-by的主鍵后，id相同的元素會(huì)通過移動(dòng)的方式來優(yōu)化操作。

長列表相信大家都做過。Weex中，對(duì)列表的優(yōu)化已經(jīng)非常接近原生系統(tǒng)的列表了，這個(gè)要?dú)w功于我們的Native團(tuán)隊(duì)。但即使有了性能不錯(cuò)的列表，對(duì)于首屏的渲染還是有追求的。

在Weex中，要做無盡列表其實(shí)非常簡單，因?yàn)樵趌ist和scroll的元素上，已經(jīng)實(shí)現(xiàn)了onloadmore事件，這個(gè)事件會(huì)在滾動(dòng)觸底（或者離底部一定的距離）時(shí)觸發(fā)，所以這樣看起來，做無盡列表變得非常容易。不過，這樣的無盡列表體驗(yàn)絕對(duì)算不上極致。這個(gè)時(shí)候，可以借助loading這個(gè)組件，并配合onloading事件，來展現(xiàn)更加出色的無盡列表。

在Weex原生功能越來越豐富的前提下，開發(fā)者可以設(shè)計(jì)出各類符合業(yè)務(wù)需求的UI組件，這些UI組件基本可以遵循標(biāo)準(zhǔn)的模塊化開發(fā)，已達(dá)到復(fù)用和高度定制的目的。

用腳手架來初始化Weex組件的倉庫再合適不過了。
Weex是一種數(shù)據(jù)驅(qū)動(dòng)的設(shè)計(jì)框架，組件并不是通過API來暴露行為，而是通過數(shù)據(jù)綁定來給組件設(shè)置行為。
組件的通信，可以通過$dispath/$broadcast來完成，不過這得付出一點(diǎn)點(diǎn)性能的代價(jià)。而在父組件拿到直接子組件的對(duì)象后，其實(shí)可以通過$on/$emit來減少性能的開銷。
如果組件需要高度定制UI，可以考慮使用content/slot標(biāo)簽，具體可以參考下wxc-marquee。
借由腳手架初始化Weex組件工程，可以輕松發(fā)布到npm/tnpm，并且開發(fā)者在通過npm install安裝后，可以輕松的以require方式來引入這些組件。

Weex未來會(huì)接入Chrome Dev-tools，甚至Debugger for IDE，這些都可以小小期待下的。而當(dāng)下可以通過輸出日志的原始方式來調(diào)試。

在最開始的利器一章中，我已經(jīng)讓大家安裝了weex-toolkit，并擁有了weex命令。那么現(xiàn)在要用它來開啟調(diào)試的大門：

weex --debugger
或者在腳手架工程中運(yùn)行：

npm run debugger
這個(gè)時(shí)候會(huì)輸出一段本地的ip地址，在瀏覽器里輸入這個(gè)地址，會(huì)展示一個(gè)二維碼。用手淘debug包或Playground掃碼之后，就開啟了輸出日志模式。

在這個(gè)界面中，你可以通過選擇設(shè)備的日志級(jí)別，以及展示的輸出級(jí)別來找到你想要的日志。同時(shí)在代碼中，可以通過console.log/debug/info/warn/debug來輸出相應(yīng)級(jí)別的日志。

在日志debug級(jí)別中，以[js framework]開頭的，便是js-framework的解析操作。在日志verbose級(jí)別中，以Calling JS和Calling Native開頭的，就是js和native互相通信的操作。

頁面跳轉(zhuǎn)是通過指定下一個(gè)頁面的url，然后通過openurl或者push的方式來跳轉(zhuǎn)

獲取url的方式可以通過下面這段JS代碼

function getAppBaseUrl(self) {
    var dir ="examples"
    var url = self.$getConfig().bundleUrl;
    var bundleUrl = url;
    bundleUrl = new String(bundleUrl);

    var nativeBase;
    var isAndroidAssets = bundleUrl.indexOf("file://assets/") >= 0;

    var isiOSAssets = bundleUrl.indexOf("file:///") >= 0;
    if (isAndroidAssets) {
      nativeBase = "file://assets/";
    }
    else if (isiOSAssets) {
      nativeBase = bundleUrl.substring(0, bundleUrl.lastIndexOf("/") + 1);
    }
    else {
      var host = "localhost:12580";
      var matches = ///([^/]+?)//.exec(self.$getConfig().bundleUrl);
      if (matches && matches.length >= 2) {
        host = matches[1];
      }
      nativeBase = "http://" + host + "/" + dir + "/build/";
    }
    var h5Base = "./index.html?page=./" + dir + "/build/";
    //Native端
    var base = nativeBase;
    //H5端
    if (typeof window === "object") {
      base = h5Base;
    }
    return base
}

第六篇 導(dǎo)航、頁面跳轉(zhuǎn)、stream、webview

頁面通信有兩種方式

1.通過 url 參數(shù)傳遞。

/**
 * 獲取URL參數(shù)
 */
getUrlParam: function (key) {
    var t = this.$getConfig().bundleUrl;
    var reg = new RegExp("[?|&]" + key + "=([^&]+)");
    var match = t.match(reg);
    return match && match[1];
}

2.通過 localStorage 數(shù)據(jù)存儲(chǔ)。

如果是組件間通信不是頁面通信，則參考：組件之間通信 - (Communicate Between Components)

https://github.com/alibaba/we...