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

init內一般用于初始化一些內部變量，綁定一些自定義事件，這時還沒有數據綁定，沒有創建vdom，所以不能通過this獲取到data和methods，也不能獲取vdom的節點

created 完成了數據綁定 ，但還未開始編譯模板，可以通過this獲取data和methods，但不能獲取vdom的節點

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

destroyed 組件銷毀，比如頁面跳轉，從子組件開始往上觸發

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

輸入是Virtual DOM輸出是native或者H5 view，還原成內存中的樹型數據結構，再創建view，把事件綁定在view上，把view基本屬性設上去。Weex Render會分三個線程，不同的線程負責不同的事情，讓JS線程優先保障流暢性。

Weex的三種工作模式。

全頁模式

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

Native Component模式

把Weex當作一個iOS/Android組件來使用，類比ImageView。這類需求遍布手淘主鏈路，如首頁、主搜結果、交易組件化等，這類Native頁面主體已經很穩定，但是局部動態化需求旺盛導致頻繁發版，解決這類問題也是Weex的重點。

H5 Component模式

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

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

官網 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
工程開發套件 https://github.com/weexteam/w...
命令行工具 https://github.com/weexteam/w...
調試工具 https://github.com/weexteam/w...

awesome-weex https://github.com/joggerplus...
vczero https://github.com/vczero/wee...
h5weex開發相關文章 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 實現splash，guide，home頁面，交互主要是點擊，左右，上下滑動。https://github.com/duqian2919...

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

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

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

現有模塊包括:

dom

steam

modal

animation

webview

navigator

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

Weex詳解：靈活的移動端高性能動態化方案 http://www.imooc.com/article/...

給正在學習Vuejs同學的幾個小Tipshttp://www.imooc.com/article/...

阿里無線11.11 ： Weex——關于移動端動態性的思考、實現和未來 http://www.infoq.com/cn/artic...

Weex默認的文件結構是要求所有相關的we文件都在同一級目錄下，以便能準確的找到依賴的組件，例如：

bar.we


foo.we

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

components/bar.we


foo.we

其背后的原理，實際上是整個轉換和打包過程借助了webpack以及weex-loader，使得其中的模塊化定義遵循標準的The way of CommonJS。

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

foo.we

##用上Tomorrow"s css和ES2015
如今前端的開發，一般離不開預處理器，比如postcss和babel。在默認的we文件中，即使有webpack的助力，這類預處理器也是對其無能為力的。為此，我們需要拆分這個we文件，讓它變成標準的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中加入幾個能解析這些特殊文件的loader：

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

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

foo.we

當分割了we文件后，你就可以分別對其中的css或js文件使用你想要的預處理器。

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

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

原本，Weex中集成了一些預定義的API，例如this.$sendMtop。但這些預定義API的維護成本過高，因此在最新甚至以后的Weex版本中，會漸漸廢棄這類預定義的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")
    }
  }
}

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

為了解釋異步函數的在Weex中的危害，首先要理解在Weex中產生的兩類task。

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

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

在Weex的task中更新數據時，Weex可以自動更新View。而在原生的task中，因為Weex喪失了控制權，所以無法做到自動更新。這就導致，在原生的task中產生的diff，會滯留直到下一次Weex的task才會被觸發更新View。從表面上看，就是在這些原生的task中改變數據后，并沒有及時反應到View上。為了，避免這個問題的產生，目前來說并不推薦使用Promise。而對于setTimeout來說，可以使用native提供的timer.setTimeout的模塊方法。

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

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

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

來看一個通過改變class來改變樣式的例子：

上述例子，通過點擊來切換樣式名。但是你會驚奇的發現，在最初一次切換之后，字體的顏色就一直是紅色的了。

這其實是目前Weex一個bug，討論如何修復的issue在這里#397。原因就是，在Weex中樣式表樣式的切換，并不會清除原來的樣式。例如，當前樣式是highlight，其中字體顏色是red，在切換到normal時，因為沒有指定字體顏色，結果原來的red顏色就被保留了下來而并沒有清除掉。所以，在上面的例子中為了避開這個bug，需要顯示的設置字體顏色：

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

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

Weex擁有一套類似前端開發習慣的DSL，HTML和CSS部分也都會遵循W3C的標準。其中元素上的屬性定義，對于非前端同學來說會有很多誤區，這里務必要說明下。

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

趁熱打鐵，來說下子組件的數據綁定。因為數據綁定也是通過屬性來定義的，所以首先要遵循上一段所說的規則。

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

在我們各類大型運營活動的頁面中，大家對樓層/坑位這些詞應該不陌生。而這些名詞的界面，基本都要靠循環列表來完成。而循環列表的性能又是整個運營頁面的關鍵。所以在遍歷這樣的列表或者數組的時候，就需要一些技巧。

通常來說，因為存在樓層的概念，而樓層里又是多個坑位，坑位又經常是雙列寶貝，眼瞅著這得用個三重循環才能搞定。不過實際上，雙列寶貝可以優化成不使用循環的結構。當然了，前端的童靴們一定要對著你們的服務端童靴保持堅定立場，要求獲得清晰且正確的數據結構，確保前端不需要對數據結構做二次處理。

通常的數據結構和對應的模板一般是這樣的：

其中比較常見的數據結構問題，比如items只是一個一維數組。如果能在服務端就處理好items的多維數組問題，那么前端的效率會高很多。

再仔細剖析其中的模板：

...

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

這里綁定了一個computed特性的數據。當某類數據不太適合展示的時候，推薦可以用computed的方式來達到數據預處理的目的，而不是在created中吭哧吭哧的算一份新的數據結構出來。

...
    

...


      

在這三個repeat中都用了track-by。它的特點是，可以記錄數組中某個項的一個主鍵，并在之后的更新中復用這個特定的項，而不是重構整個數組。例如

樓層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"}]} 
)
增加一個樓層

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"}]}
  ]
})

如果沒有設置track-by，那么Weex會重構整個數組，導致元素被刪除后又重新添加。而添加了id作為track-by的主鍵后，id相同的元素會通過移動的方式來優化操作。

長列表相信大家都做過。Weex中，對列表的優化已經非常接近原生系統的列表了，這個要歸功于我們的Native團隊。但即使有了性能不錯的列表，對于首屏的渲染還是有追求的。

在Weex中，要做無盡列表其實非常簡單，因為在list和scroll的元素上，已經實現了onloadmore事件，這個事件會在滾動觸底（或者離底部一定的距離）時觸發，所以這樣看起來，做無盡列表變得非常容易。不過，這樣的無盡列表體驗絕對算不上極致。這個時候，可以借助loading這個組件，并配合onloading事件，來展現更加出色的無盡列表。

在Weex原生功能越來越豐富的前提下，開發者可以設計出各類符合業務需求的UI組件，這些UI組件基本可以遵循標準的模塊化開發，已達到復用和高度定制的目的。

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

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

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

weex --debugger
或者在腳手架工程中運行：

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

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

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

頁面跳轉是通過指定下一個頁面的url，然后通過openurl或者push的方式來跳轉

獲取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
}

第六篇 導航、頁面跳轉、stream、webview

頁面通信有兩種方式

1.通過 url 參數傳遞。

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

2.通過 localStorage 數據存儲。

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

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