Weex 剛剛開源，非常幸運能在 Weex 團隊實習，也見證了 Weex 正式開源的夜晚，作為一名 Androider，當然是萬分激動。近三個月的實習過程，Weex Android 的源碼也搗騰了不少，寫篇文章紀念一下~ 寫的不對的地方，還望各大神指點迷津！

PS：這里只對 Weex Android 源碼進行分析。

---

一、Weex第一眼

• A framework for building Mobile cross-platform UI (一款輕量級的移動端跨平臺動態性技術解決方案)
• 通過 Html 搭建組件結構，flexbox 負責界面布局， Js 控制數據和邏輯
• 相比 RN，Weex 真正做到了 write once run anywhere
• RN 可以認為是一個全新的跨平臺移動開發框架，比較重，適合一個完整應用的開發；而 Weex 是為了增強移動端動態性而生的輕量級框架，具有極強的可擴展性，能夠比較容易的融入成熟的Native項目中。
• 跟 QZone 的前輩聊到過 RN，QZone 接入 RN 后，總體性能還不如原來騰訊的 Webview 方案，而 Weex 在加載性能上是要占優勢的。

二、Weex的重要器官

1、WXDomObject

• DomObject 包括了 <template> 在 Dom 樹中的所有信息，如 style、attr、event、ref（結點的唯一標識符）、parent、children

2、WXComponent

• Component 負責承載 Native View，可以通過泛型指定承載 View的類型：

abstract class WXComponent{};

class WXListComponent extends WXVContainer{};

• Component 會保留 DomObject 的強引用，兩者實例是一一對應的。

• 通過調用 initComponentHostView 創建 Component 需要承載的 View，所有 的Component 必須重寫 initComponentHostView 方法，返回需要承載的 View 的最外層容器。如下：

class WXBaseRefresh extends WXVContainer {

@Override
protected WXFrameLayout initComponentHostView(Context context) {
return new WXFrameLayout(context);
}
}

3、WXModule：

• 通過 Module 可以將 Native Api 暴露給Js。

4、WXSDKInstance

• Weex 的渲染單位。

• 明確兩個容器的概念：

  • Instance RootView: Weex 最外層容器， Native 接入方可以設置 Instance RootView 大小, 最終通過 onViewCreated 返回給用戶的View也就是 Instance RootView。
  • JS Root: JS 可以描述的最外層容器， 為 RootView 的唯一子節點， 受 JS 樣式的控制。

• Instance 寬高設置遵循以下幾個原則

  • Instance RootView 的寬高優先遵循 instance 設置的寬高，如果開發者沒有設置，則與 JS Root 節點的寬高保持一致。
  • JS Root 節點的寬高優先遵循 CSS 樣式設置的寬高，如果沒有設置，則使用 instance 上設置的寬高，如果 instance 也沒有設置，則使用 layout 出來的寬高
  • 特殊情況，當 scroller 和 list 作為 JS Root 時，如果不設置高度, 會給 scroller 和 list 設置 flex:1
  • 綜上所述，Instance RootView 和 JS Root 的寬高可以不一致，應該根據需求正確的設置 Instance 的寬高，也可以在運行時動態的改變 Instance 的寬高。

---

三、Weex工作原理

1、渲染原理

• .we文件由 <template> 、 <style> 、 <script> 三部分組成；首先，transformer 會將 .we 文件轉換成 Js Bundle，JSFramework 根據 Js Bundle 生成 Virtual Dom，根據Virtual Dom 控制 Native 的視圖層；首次渲染時，會將所有結點都交給 Native Render 渲染，在 UI 更新時，計算出最小 dif，讓 Native 僅渲染發生改變的結點。

2、派發渲染指令的樞紐：WXDomModule

• 上面提到，JSFramework 根據 Virtual Dom 計算出來的 dif，將渲染指令（Json）通過 Js Engine 發送給 Native Render 進行渲染。而 WXDomModule 會接收到所有渲染指令，然后將指令post 給 DomHandler，最后由 DomHandler 來派發渲染任務。
• DomStatement 在 Dom 線程中創建 DomObject 和 Component，RenderStatement 負責在 UI 線程中渲染 View；每個 WXSDKInstance 會持有一個 DomStatement 和 RenderStatement 實例。
• RenderStatement 會從 DomStatementclone 一份 DomObject，是為了避免兩個線程同時操作 Dom 造成的同步問題。
• 主要有如下指令：
• createBody：DomStatement 首先在 Dom 線程中創建 JS Root 對應的 Component，然后會將 JS Root 添加到 WXSDKInstance 作為 GodCom 的子節點，從而生成 Component 樹的最頂端。生成 Component 樹后，將 createBody 任務 post 到 UI 線程，由 RenderStatement 創建 WXSDKInstance 的 Rootview，并通過 onViewCreated 回調給 WXSDKInstance 的上下文。
• addElement：首先，DomStatement 在 Dom 線程中創建 DomObject 和對應的 Component 實例，加入 Dom 樹和 Component 樹；然后將 addElement 任務 post 到 UI 線程，RenderStatement 會觸發 Component 完成以下任務： createView（初始化 Component 承載的 View）、applyLayoutAndEvent（觸發 setLayout 和 setPadding、綁定 Event）、bindData（給 View 設置 style、attr）、addChild（將 View 加入 View 樹）
• removeElement：是 addElement 的逆向操作，將 View、Component、DomObject 分別從各自的樹中刪除，并銷毀數據回收資源。
• moveElement：將 View、Component、DomObject 在樹中移動位置，move 操作最終被拆分成一次 remove 操作和一次 add 操作。
• addEvent：綁定事件。
• removeEvent：撤銷事件綁定。
• updateAttrs：當結點 attr 被改變時，會觸發 updateAttrs，最終會觸發 WXComponent 中的 updateProperties 刷新 UI。
• updateStyle：與 updateAttrs 類似。
• createFinish：JsFramework 將所有渲染指令都發出后，會觸發 createFinish，最后會觸發 onRenderSuccess 回調。
• updateFinish：JsFramework 將所有 update 指令發出后，會觸發 updateFinish，最后會觸發 onUpdateFinish 回調。

3、Js與Native的通信方式

（1）Js調用Native

• Js 調用 Native 必須以 Module 的方式實現，@WXModuleAnno 注解會將 Module 方法暴露給Js。

• Js 調用 Module 方法：

  this.$call('modal', 'toast', {'message': 'naviBar.rightItem.click','duration': duration});
• modal 是 Module 名字，toast 是 Module 的方法名。

• Js 調用 Native 方法，均通過如下方式完成：

  WXModuleManager.callModuleMethod(instanceId, (String) task.get(WXDomModule.MODULE),(String) task.get(WXDomModule.METHOD), (JSONArray) task.get(WXDomModule.ARGS));

static boolean callModuleMethod(String instanceId, String moduleStr, String methodStr, JSONArray args) {//通過 ModuleFactory 拿到 module 的實例ModuleFactory factory = sModuleFactoryMap.get(moduleStr);final WXModule wxModule = findModule(instanceId, moduleStr, factory);wxModule.mWXSDKInstance = WXSDKManager.getInstance().getSDKInstance(instanceId);/**** 通過反射拿到方法和參數，構造 Invoker 對象*/Map<String, Invoker> methodsMap = factory.getMethodMap();final Invoker invoker = methodsMap.get(methodStr);invoker.invoke(wxModule, params);}

（2）Native 調用 Js 之 fireEvent

• fireEvent 一般在 Component 中使用，多用于事件監聽

  WXSDKManager.getInstance().fireEvent(mInstanceId, getRef(), WXEventType.ONCLICK);
• 第一個參數表示其所在 WXSDKInstance 的 id，第二個參數是 Component 的 ref（唯一標識），第三個參數是事件名稱。

<text onclick="onclick">weex</text> <script>module.exports = {methods: {onclick: function(param) {param.x;param.y;},}}</script>

（3）Native調用Js之JSCallback

• JSCallback 一般在 Module 中使用，可以參考 WXStreamModule 的實現

  @WXModuleAnno public void fetch(String optionsStr, final JSCallback callback) {Options.Builder builder = new Options.Builder().setMethod("GET").setUrl(url);extractHeaders(headers, builder);final Options options = builder.createOptions();sendRequest(options, new ResponseCallback() {@Overridepublic void onResponse(WXResponse response, Map<String, String> headers) {if (callback != null) {Map<String, Object> resp = new HashMap<>();resp.put(STATUS, response.statusCode);resp.put("ok", (code >= 200 && code <= 299));......resp.put(STATUS_TEXT, Status.getStatusText(response.statusCode));resp.put("headers", headers);callback.invoke(resp);}}}); }
• 在 callModuleMethod 中已經將 JSCallback 與 instanceIs、callbackId 封裝成 SimpleJSCallback，只需調用 invoke，傳入參數即可。

• 那么 JS 這邊又該如何接收回調呢？

  stream.fetch({ method: 'GET', url: GET_URL, }, function(ret) { if(!ret.ok){me.getResult = "request failed"; }else{console.log('get:'+ret);me.getResult = ret.data; } });

---

四、存在的問題

• List 是業務中較為常用的容器，而 Weex Android 的 List 是通過 原生的 RcyclerView 實現的，由于 RecyclerView 的復用機制，給 List 組件帶來了不少坑，這里主要說下我在開發中碰到的幾個例子。

1、RecyclerView原理

• 首先簡單介紹一下 RecyclerView 的復用原理~

• Recycler 是 RecyclerView 中管理組件復用的核心內部類，而 Recycler 中有幾個重要的成員變量：

  • mCachedViews：剛剛從屏幕中滑出的 ViewHolder，且 bind 的數據未修改，會緩存在 mCachedViews 中 , mCachedViews 中的 ViewHolder 隨時可以重新顯示在屏幕上而不需要重新 bindData；針對每一種 ViewType 的 ViewHolder，緩存的數量默認為2
  • mAttachedScrap、mChangedScrap：mCachedViews 中被修改過的臟塊，會轉移到 scrap 中（Attached 和 Changed 的區別僅僅在于對 itemAnimation 的支持，這里不展開說了，統稱為 scrap）；scrap 中的 ViewHolder，如要重新顯示在屏幕上，需要重新 bindData。
  • RecycledViewPool：RecycledViewPool 是可以支持多個 RecyclerView 共享的 ViewHolder 緩存池，當 mCachedViews 或 scrap 滿了之后，會將末尾的元素移動到 RecycledViewPool 中，這里可以理解為分級緩存。RecyclerViewPool 里有兩個成員變量，SparseArray> mScrap 和 SparseIntArray mMaxScrap，mScrap 根據 ViewType 對 ViewHolder 進行二級索引存儲；mMaxScrap 表示每一類 ViewType 的允許緩存 ViewHolder 的最大數量；但是 RecycledViewPool 并沒有對不同 ViewType 的數量進行限制，所以這里會涉及到一些坑，下面展開說明。

2、Cell復用存在的問題

• 在 Android 中，RecyclerView 提供了復用機制來減少內存開銷、提升滑動效率，Weex 中 List 也暴露出相應的 API 支持 Cell 復用：設置相同 scopeValue 的 Cell 支持 ViewHolder 復用。但是，List 在對 scopeValue 的支持上，還存在一些問題：

（1）Cell 使用 if 控制子元素發生 crash

• Cell 復用的前提條件是 view 層級和布局完全一致，如果使用 if 控制 Cell 子元素的可見性，可能導致復用時舊 Cell 和新 Cell 結構不一致，在重新 bindData 時產生 crash。

（2）Cell 復用后產生文字截斷

• 為了提升滑動效率，Cell 被復用時不會觸發 setLayout，如果在 Cell 子元素中含有不定寬度的 text 組件，復用后不會重新計算 text 寬度，所以導致文字截斷。
• 建議： 目前 List 對 scopeValue 的支持還不夠完善，使用時要多加注意，前端應該遵循“Cell 可復用的前提是 view 層級和布局完全一致”的規則，對于內部結構不確定、樣式可能發生變化的 Cell 不要進行復用；如果使用得當，scopeValue 還是很強大的~

3、Cell 內存泄露

• 由于 Weex 重寫了 Recycler.ViewHolder，使得 ViewHolder 持有 Cell 的強引用，由于 RecyclerView 會將 ViewHolder 緩存在 RecycledViewPool 中，導致 Cell 被 remove 后，無法被 JVM 回收，導致 Cell 樹內存泄漏；這個問題在 0.7.0 中已經修復，ViewHolder 持有 Cell 的軟引用，List 持有 Cell 的強引用，可以保證 Cell 在正確的時機被回收。

4、無用的 ViewHolder 緩存

• 如果不指定 Cell 的 scopeValue，會使得每一個 Cell 都有不同的 ViewType，之前提到 RecycledViewPool 不限制不同類型的 ViewHolder，所以這里會導致 ViewHolder 不限數量的緩存堆積在 RecycledViewPool 中，而且根本不會參與復用，所以理解為“無用的緩存”。在 v0.7.0 中解決了這個問題，限制了不同 ViewType 在 RecycledViewPool 中緩存的數量；由于 Cell 和 Cell 中承載的 View 都會保存在內存中，可以省去 Component 創建，所以 ViewHolder 的創建耗時不多。
• v0.6.1：Cell 被 RecyclerView 緩存池引用
  
• v0.6.1：內存情況
  
• v0.7.0：內存情況（可以明顯看到內存被釋放的過程）
  

5、Weex 中 ViewHolder 創建過程存在的問題

• 當 RecyclerView 在緩存中找不到合適的 ViewHolder 復用時，會調用 onCreateViewHolder 創建新的 ViewHolder；Weex 繼承 RecyclerView.ViewHolder 實現了自己的ListBaseViewHolder，將 Cell 作為 ViewHolder 的成員變量，所以在 onCreateViewHolder 創建 ViewHolder 的時候，需要找到一個“ViewType一致，且沒有被 ViewHolder 綁定過”的 Cell 與其關聯。
• 在 v0.6.1 中，查找方式是遍歷所有的 Cell，直到找到合適的那個，這樣存在一個問題，當 List 元素特別多的時候，查找過程的性能消耗會有一些劣勢：

for (int i = 0; i < childCount(); i++) {WXComponent component = getChild(i);if (component == null || component.isUsing() || getItemViewType(i) != viewType)continue;....... }

• 在 v0.7.0 中，做了相應優化，與 RecyclerView 的緩存池使用同一種查找方式，也就是根據 ViewType 對 Cell 做分類的二級索引，這樣就避免了多余的循環。

ArrayList<WXComponent> mTypes = mViewTypes.get(viewType); ....... for (int i = 0; i < mTypes.size(); i++) {WXComponent component = mTypes.get(i);if (component == null || component.isUsing()) {continue;}....... }private int generateViewType(WXComponent component) {long id;try {id = Integer.parseInt(component.getDomObject().ref);String type = component.getDomObject().attr.getScope();if (!TextUtils.isEmpty(type)) {if (mRefToViewType == null) {mRefToViewType = new ArrayMap<>();}if (!mRefToViewType.containsKey(type)) {mRefToViewType.put(type, id);}id = mRefToViewType.get(type);}} catch (RuntimeException e) {id = RecyclerView.NO_ID;}return (int) id; }

---

五、快速接入Weex

• sdk的接入就不贅述了，主要說下Native這邊需要的代碼配置。

1、首先創建 WXSDKInstance 實例

mInstance = new WXSDKInstance(this);mInstance.setImgLoaderAdapter(new ImageAdapter(this));mInstance.registerRenderListener(this);

2、實現渲染的監聽接口

public class WXBaseActivity implements IWXRenderListener {}mInstance.registerRenderListener(this);

3、指定要渲染的Page

mInstance.render( TAG, // path表示需要渲染的js文件的路徑 WXFileUtils.loadFileContent(path, WXPageActivity.this), null, null, ScreenUtil.getDisplayWidth(WXPageActivity.this), ScreenUtil.getDisplayHeight(WXPageActivity.this), // 傳入WXRenderStrategy.APPEND_ASYNC表示異步渲染 WXRenderStrategy.APPEND_ASYNC);

• 這里需要說明一下，第5、6個參數是用來指定 Instance 的寬高

4、實現回調

@Override public void onViewCreated(WXSDKInstance instance, View view) {// 這里返回的view就是weex將我們指定path的js文件渲染出來的view }

總結

以上是生活随笔為你收集整理的Weex-初次见到你的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。