weex分為組件component和模塊（module）以及事件
組件就是各種標記組件，比如div 、slider、indicator等通過下面這種方式使用
<div>
<image src="..."></image>
<text>...</text>
</div>
js模塊
let modal = require('@weex-module/modal');
modal.toast({
"message":"我是提示框",
"duration":2
});
其他的還有stream,dom，animation之類的
事件
<div onviewappear="viewappear" onviewdisappear="viewdisappear">
......
</div>
Weex源碼結構
package.json
node_modules依賴，更重要的是里面包含了npm run xxx 等快捷命令。比如之前我們運行node.js程序是這樣的：$ node xx.js。這里我們可以把它配置化，例如package.json文件中scripts的 “build:config”: “node build/config.frameworks.js”，其實就是npm run build:config 相當於執行了node build/config.frameworks.js
start文件: 啟動程序文件，里面包換編譯和啟動腳本：
examples: 示例Demo
android/ios/html： 各平台代碼
build：打包各平台的腳本，配置在package.json中。
native 渲染和 JavaScript 引擎之間，主要進行三類通信：
- 界面渲染，單向 (JS -> native)：這毫無疑問，JavaScript 引擎需要把界面的結構和樣式告訴 native 端，這樣我們才能得到 native 級別的終極界面效果
- 事件綁定與觸發，雙向：在我們的客戶端技術方案中，native 端只負責界面渲染和非常薄的事件觸發層，事件的邏輯處理都會放在 JavaScript，這樣我們就具備了復雜數據處理和邏輯控制的動態性可能。JS 告訴 native 需要監聽的交互行為，而當用戶產生對應的交互行為時，native 端會把交互信息回傳給 JS
- 對外的數據/信息請求與響應，雙向：JS 引擎在處理特殊邏輯時，難免需要向服務器請求數據、或請求本地的系統信息和用戶信息、或調用 native 的某個功能，這個時候也會通過 JS Bridge 進行請求，native 收到這些請求之后，也會在必要的情況下通過 JS Bridge 把信息回傳給 JS 引擎
圖：客戶端運行時的 JS 引擎和 native 之間的通信
我們在 JS 處理界面邏輯的過程中采取了數據監聽+依賴收集的策略，既沒有通過臟檢查，也沒有通過全量 diff Virtual DOM 樹的方式
3. 服務端部署
我們在服務端提供了基礎的程序包發布，給每個程序包一個特定的 page id，然后為客戶端提供通用的服務，通過 page id 獲取程序包，這樣本地開發、動態實時部署、客戶端動態化渲染和邏輯處理就完美的串聯在一起了
細節8：實際上，除了界面本身可以動態化之外，客戶端的 JS 引擎的代碼、還有部分 native 的實現，我們也准備了相應的動態化機制，也就是說客戶端的動態能力本身也是具有動態性的
4. 瀏覽器端渲染
同一份 JavaScript 程序包，可以同時通過客戶端的 JS Bridge 渲染成為 native 界面，也可以通過瀏覽器渲染成為 web 界面。我們的做法也非常簡單，就是把 JS Bridge 背后的 native 處理邏輯同構成了 HTML5 版本。然后發布這樣的一個頁面。
整個 Weex 的工作原理大致可以用一張圖來表述：
目前Weex給大家直觀的感覺是可以用Weex寫很多頁面，有一個路由機制，內部叫導航，幫助你將頁面進行串連，我們提供很多features，由這樣的形式構成Weex大家所看到的一個結
Weex的集成方式
目前Weex有三種集成方式：
- 全頁模式
o 目前支持單頁使用或整個app使用weex開發（還不完善，需要開發router和生命周期管理）這是主推的模式，可以類比RN。 - Native Component模式
o 把weex當作一個iOS/Android組件來使用，類比ImageView。這類需求遍布手淘主鏈路，如首頁、主搜結果、交易組件化等，和業務同學溝 通下來這類Native頁面主體已經很穩定，但是局部動態化需求旺盛導致頻繁發版，解決這類問題也是Weex的重點。
o 這也涉及到如何讓Native同學快速上手“准Web”開發，有意思的話題，大家多給些建議。 - H5 Component模式
o 在H5種使用Weex，類比WVC。一些較復雜或特殊的H5頁面短期內無法完全轉為Weex全頁模式（或RN），比如貓超、互動類頁面、一些復雜頻道頁 等。針對這個痛點我發起過WVC項目，並在實際業務中驗證了這樣的想法：在現有的H5頁面上做微調，引入Native解決長列表內存暴增、滾動不流暢、動 畫/手勢體驗差等問題。
o WVC將會融入到Weex中，成為Weex的H5 Components模式。
這3種模式幾乎涵蓋了淘系業務上的動態化需求（針對Native）或體驗提升需求（針對H5）。更有趣的是這3種模式的技術基礎是一致的，這非常重要，意 味着：業務方可以使用Native或H5 Component模式 解決實際的業務痛點，同時平滑過渡到Weex全頁模式。期待Weex成長壯大到AppFramework的那天。
頁面間通信
頁面跳轉是通過指定下一個頁面的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
}
\
WXSDKEngine
WXSDKEngine主要用於初始化WeexSDK的環境
一開始會載入配置文件main.js並且注冊一些默認的組件、模塊以及handler
WXSDKInstance
一個WXSDKInstance就對應一個UIViewController,對應一個weex頁面。
主要用來渲染頁面,一般通過renderWithURL方法，然后能夠接收一些回調和一些視圖相關的方法
WXBridgeManager
WXBridgeManager 是JS與iOS通過JSCore交互的類,相關的類還有WXBridgeContext、WXJSCoreBridge。
JS調用native的話需要通過WXJSCoreBridge的registerCallNative方法
WXComponent
組件基類，自己實現iOS端的組件需要繼承它。相關的還有負責組件初始化的工廠類WXComponentFactory，以及WXComponentManager
WXModuleProtocol
自定義module需要實現的協議
參考鏈接：
1.http://www.infoq.com/cn/articles/introducing-weex
2.http://www.tuicool.com/articles/Yr6zIr6