鑑於Weex在效能方面做過一些針對性的優化並且已在阿里的業務線上得到了規模性的應用，我們決定在內涵段子這個具備800萬日活的產品中嘗試應用Weex。這樣做的主要目的是為了深化對Weex的認識，與React Native進行對比分析，確立IES客戶端跨平臺方案的下一步研究方向。

一、工程實踐

1.1 準備工作

• 開發環境搭建：https://weex.incubator.apache.org/cn/guide/set-up-env.html
• 整合Weex SDK到已有應用：https://weex.incubator.apache.org/cn/guide/integrate-to-your-app.html
• 下載Weex Playground APP：https://weex.apache.org/cn/playground.html Weex Playground APP整合了Weex SDK，它內建了用於展示Weex元件功能的Demo。通過它的掃碼功能，還可以載入自己本地Server的Weex程式碼進行除錯（前提是手機和電腦在同一個區域網內）。

1.2 除錯

1.2.1 除錯環境

在Weex專案中，除錯程式碼的環境有三種：瀏覽器、Weex Playground APP、自己的應用內。

因為Weex的程式碼可以同時相容瀏覽器、iOS和安卓三種執行環境，因此可以在瀏覽器環境中除錯Weex專案程式碼。在Weex工程中執行npm run dev和npm run serve命令並在瀏覽器中訪問http://localhost:8080即可預覽Weex專案效果，如下圖所示。但是就目前的狀況來講，Weex對三端的相容性支援還不是很完善，在瀏覽器中除錯好的程式碼再放到客戶端環境中執行還是有極大的可能會出問題，因此如果最終目標只是想在客戶端中執行Weex程式碼，並不建議通過瀏覽器來除錯。

Weex Playground APP整合了Weex SDK，可以通過它的掃碼功能來除錯自己的Weex專案程式碼。專案開始時，如果客戶端Weex整合工作還沒完成且除錯環境還沒有準備好，可以使用Weex Playground APP來輔助除錯，因為此時專案的主要工作還是編寫介面，並不需要客戶端擴充套件功能模組的支援。

專案介面開發完成後，後面階段的除錯工作就需要在自己的應用內進行了，因為此時一般需要客戶端擴充套件的功能模組或元件的支援。例如，獲取網路請求通用引數、打點、接收客戶端事件訊息等。應用內整合了Weex SDK後，在需要除錯Weex程式碼的頁面，建議客戶端在DEBUG模式下提供重新整理頁面按鈕以方便除錯。

1.2.2 DEBUG

在React Native的開發中，可以通過點選開發者選單中的“Debug JS Remotely”選項來開啟JS程式碼的遠端除錯。然而在Weex的開發中，開啟JS程式碼遠端除錯功能的步驟要麻煩一些，需要在應用內整合Weex DevTools工具。由於Weex Playground APP已經整合了Weex DevTools工具，可以使用Weex Playground APP來試驗一下如何使用weex-toolkit裡面提供的除錯工具。

首先，在命令列中執行weex debug命令，該命令會啟動一個除錯伺服器，並同時喚起Chrome瀏覽器開啟除錯主頁，如下圖所示。

然後，開啟Weex Playground APP掃描除錯主頁下方的二維碼，即可在應用與除錯伺服器之間建立socket連線並向除錯伺服器註冊應用資訊，如下圖所示。

此時，點選上圖中的Debugger按鈕可以開啟JavaScript程式碼的遠端除錯功能，在ChromeDevTools裡面對Weex工程的JavaScript程式碼進行除錯；點選Inspector按鈕可以檢視Weex頁面的element屬性結構。

如果想使用weex-toolkit提供的除錯工具對自己應用內的Weex頁面進行除錯，必須先在應用內整合Weex DevTools。具體整合方法請參考：整合 DevTools 到 iOS和整合 DevTools 到 Android。

1.3 開發

此次Weex應用於內涵的發現頁，發現頁的UI如下面三張圖所示。發現頁有以下特徵：

• 由熱吧和訂閱兩個列表頁組成，通過頂TAB進行切換；
• 熱吧和訂閱資料一次性載入完畢，無loadmore邏輯，熱吧資料大概在200~300條；
• 使用者可切換主題：白天模式和夜間模式。

1.3.1 元件劃分及佈局

發現頁的頁面組成元素比較簡單，元件分為輪播圖元件、熱吧Cell元件以及訂閱吧Cell元件。

發現頁的文件結構大致如下：

其中值得一提的是實現TAB切換的方式。一般來講，很容易想到使用vue的條件渲染來實現TAB的切換，如下：

但是這樣做會造成TAB切換時列表渲染卡頓，因為熱吧列表有200~300條資料，每次切換都重新渲染一次會造成較大的效能消耗。因此，在實現的時候對list採用了絕對定位的佈局方式，在TAB切換的時候，將已經渲染好的列表結構在DOM樹中保留，只改變列表節點的visibility屬性。如下：

1.3.2 客戶端支援

(1) 客戶端模組

(2) 客戶端事件

1.3.3 Weex使用問題總結

• 如何處理本地圖片資源？ Weex image元件不支援本地圖片，然而在專案開發過程中經常需要引入一些本地圖示檔案，例如:

此時，可以在webpack配置檔案裡面配置url-loader，將圖片資源輸出到構建目錄。然後，通過output.publicPath配置項來配置資源的訪問路徑，在DEBUG模式下，將output.publicPath配置為本機server地址，在Production模式下，將output.publicPath配置為線上域名。由於圖示檔案一般比較小，為了避免在無網路狀態下渲染Weex頁面拉取不到線上圖示資源的情況，專案中將圖示檔案直接用Base64編碼。url-loader的配置如下所示：

• 關於適配 Weex程式碼中的高度和寬度的單位均為px，但是所設定的寬高並不是實際呈現出來的寬高，Weex框架在底層做了針對不同螢幕的適配工作，具體計算公式為 實際高寬 = 程式碼高寬 * (螢幕寬度 / 750)。所以，在編寫介面的時候，最好以寬度為750的設計稿最為標準，否則需要根據計算公式對設計稿上標明的寬高做轉換。當需要設定元素的絕對寬高時，需要自行計算。計算時，需要獲取以下引數：

• cell元件的appear事件和disappear事件在安卓端引發的效能問題 在熱吧列表，有一個打點需求，就是統計每一個吧Cell的展示時間。為了實現這個打點需求，對每一個吧Cell都監聽了appear事件和disappear事件。通過測試發現，當監聽了吧Cell的appear事件和disappear事件時，安卓端列表滾動不流暢，會出現明顯的卡頓現象。
• slider元件的點選事件在安卓端不觸發 由於Weex提供的slider元件無法滿足使用要求，所以基於slider重新封裝了一個輪播圖元件，結構如下：

輪播圖元件需要監聽點選事件，當在slider元件或slider元件的父元件div上監聽點選事件時，在安卓端點選輪播圖並不觸發點選事件。因此，需要在slider元件的子元件上監聽點選事件。 在沒有設定loadmoreoffset時，list元件的loadmore事件在安卓端不觸發 雖然發現頁沒有loadmore邏輯，但是在使用weex的過程中對list元件進行了效能測試，使用到了list元件的loadmore功能，因此發現了list元件的loadmore事件在預設情況下不觸發的問題。只有顯示設定了loadmoreoffset且loadmoreoffset的值大於0時，list元件的loadmore事件才會觸發。

• cell元件的scope屬性 使list元件的時候，建議為同種類的cell設定相同的scope屬性。Weex內部會緩衝cell，每種型別的cell最多緩衝9個。如果不設定cell的scope屬性，weex會認為所有的cell的型別都不一樣，會緩衝所有的cell，導致記憶體佔用大。

1.3.4 Weex實現效果

Weex實現的頁面操作體驗基本上接近原聲應用，列表滾動、TAB切換、頁面跳轉等都十分流暢。效果如下圖所示：

二、實踐總結

Weex可以選擇使用Vue作為開發框架，開發與除錯體驗都比較好，接近Web開發體驗，但是使用上仍然存在一些問題，例如：

• CSS支援不夠完善，有些地方CSS樣式的在客戶端中的表現與WEB中的不太一致，甚至iOS和安卓端都會存在樣式表現的不一致。而且CSS不支援繼承，定義CSS樣式的時候無法引入變數，這樣在實現一些效果的時候十分不方便，例如白天模式和夜間模式；
• 文件資料不夠完善；
• 某些內建元件存在使用上的BUG，例如slider元件在安卓手機上無法監聽click事件、list元件在沒有設定loadmoreoffset的情況下在安卓手機上不觸發loadmore事件；

當然，這些使用上的問題都可以解決或通過一定辦法去規避。Weex更值得我們關注的問題可能還是list元件的效能問題。在React Native的實踐中，我們深受長列表效能問題的困擾，而Weex號稱是一套可以構建高效能原聲應用的跨平臺方案，它在長列表的效能表現上如何呢？我們對此進行了測試和評估，發現Weex在長列表的效能表現上也並不樂觀。在列表長度不斷增長的時候，Weex的記憶體佔用也是不斷增長的，在安卓和iOS上皆是如此。在iOS上，列表在不斷向下滾動的過程中，CPU使用率的表現也十分堪憂。以下兩張圖分別是在列表cell定高和變高下的測試結果【詳細測試結果請前往：RN & Weex ListView效能對比評估】：

因此，Weex目前可能更適用於非長列表的場景。由於其體驗接近原生應用，比H5要好，可以用於替換端內的一些H5頁面或一些需要頻繁變動的客戶端頁面。在這些方面Weex是否可規模投入使用尚待驗證，此次在內涵發現頁的使用正好可以觀察其穩定性。