最近開始試水weex開發，使用這麼長一段時間，感覺寫weex還是非常友善的。作為一個android開發，免不了要追查一下weex的sdk源碼。今天，就以weex sdk for android為例，分析sdk的
<a href="https://github.com/alibaba/weex/tree/dev/android">源碼:https://github.com/alibaba/weex/tree/dev/android</a>
整體分析下拉，按照js檔案的渲染過程，繪制出了下面架構圖：
為了更加詳細的說明整個渲染過程，我對源碼進行了分析。并結合示例，進行了日志分析；比如，我們要開發如下一個簡單的元件(紅色方框内)：
那麼，我們的wxc-title.we源碼為：
上述.we檔案經過weex編譯之後，生成的js檔案，經過格式化如下：
上述分别使用了三個function，對template、style和script進行了封裝；那麼，這個檔案是怎麼被weex sdk執行并解析，最終生成結構化的view的呢？
從掃碼開始，首先經曆如下過程；依次經過readerpage，createinstance，一直到wxbridge的exejs方法；也就是說，最終，java通過調用native的exejs方法，來執行js檔案的。
緊接着時序圖1：執行到jni層的java_com_taobao_weex_bridge_wxbridge_execjs方法;
然後js通過native調用wxbridge的callnative方法，達到js調用java代碼的目的；
jni層的部分代碼如下：
接着上面的時序圖，開始做頁面的建立；關鍵的代碼在wxrenderstatement中的createbodyondomthread，該方法通過建立跟布局的mgodcomponent,通過遞歸generatecomponenttree生成component的邏輯樹結構;然後，在wxrenderstatement的createbody方法中，生成view，綁定屬性和資料；具體如下圖所示：
以上面的weex頁面為例：使用playground掃碼之後的調用過程中的日志為：
首先，我們看一下android原聲的view繪制過程：
主要是measure測量大小，layout确定位置。
其次，我們對比一下weex的wxcomponent的測量和布局過程；
主要是通過csslayout進行測量，使用view的setlayoutparams來确定view在父viewgroup中的位置。
核心代碼如下：
渲染過程對比：
weex的渲染過程，上面已經寫的比較清晰了；對于android，其渲染過程大緻可以總結為：
1.編譯期使用aapt對xml進行編譯，生成二進制的xml
2.運作時，使用xmlblock建構xmlpullparser，通過layoutinflater的rinflater進行解析，最終生成view；
那麼，兩種方式的解析效率差異有多大呢？官方的資料如下：
目前以飛豬app的購物車為例：weex，native，以及投放到手淘的h5，進行了幀率對比，資料如下：
weex無論在createbody、addelement，還是在callnative中對module的調用，都還有很多優化空間。比如，可以把部門運作時的工作，搬到編譯期做，這樣可以加快頁面的渲染時間；在渲染之後，滑動過程中的幀率對比發現，weex和native基本相近，比h5的表現要好。