Weex實戰分享|Weex在盛大遊戲中的應用實踐

摘要： 大家好！ 我來自盛大遊戲游麥團隊前端負責人-李永亮，很榮幸這次被選中，與大家分享下weex在我們實踐中遇到的問題。 今天我的議題從五個大方面來說，從技術選型選定Weex，到在產品中小試牛刀，再到後來大規模的頁面實踐，再著遇到性能上的問題怎麼去優化，最後是踩坑填坑的歷程。

作者：李永亮

原文

大家好！

我來自盛大遊戲游麥團隊前端負責人-李永亮，很榮幸這次被選中，與大家分享下weex在我們實踐中遇到的問題。

今天我的議題從五個大方面來說，從技術選型選定Weex，到在產品中小試牛刀，再到後來大規模的頁面實踐，再著遇到性能上的問題怎麼去優化，最後是踩坑填坑的歷程。

一、技術選型

我們為什麼要選Weex方案呢？其實在2017年年初的時候，我們CTO期許各技術團隊要高效開發、節省成本，產品快速迭代。所以在這種倡導下，各團隊開始研究RN、Weex。

我們游麥團隊為什麼選擇了Weex呢？

（一）首先是高效交付

1、它支持三端（iOS/Android/H5）；

2、運用了Web的技術，像CSS、JS等，我們團隊中主要的前端框架是Vue；

3、Vue用起來非常簡單，如果Android或者iOS同學想學習Weex的技術，也是十分容易的；

4、我們是在現有App中接入Weex頁面的，有新的產品頁面開發，還有原有Native頁面轉化成Weex的過程。很多原生功能做得非常好，我們是希望充分利用原生的能力，Weex的可擴展性，正好能夠在這上面發揮作用。

（二）它的性能上來說非常優異的，Weex最終打包的bundle文件體積非常小，不像RN那樣依賴過多冗餘代碼；它的渲染速度也快；Weex對資源利用還是做了很多努力，這方面確實值得信賴。

（三）除了阿里集團內部在使用這些產品，下面這些數據，阿里的同學統計了一些數據，加上我在知乎上搜集了一些信息，得到了這些數據。

二、小試牛刀

我們公司有兩個團隊在同時嘗試接入Weex。信息化團隊在做公司內部App的食客在線頻道頁，這個weex頁可以直觀看到內部食堂的就餐情況，它是通過原生控制來橫屏展現的。

右邊是游麥電商平台的系統消息頁，是一個典型的列表頁。大家會看到，最開始是從原生頁面跳到此列表，點擊列表項就跳轉到原生頁。

在這兩個接入頁面中遇到一些問題，和大家分享一下。

（一）最開始用的Weex版本是0.7.0，我們在兩部手機上，小米5和三星中，不同的SDK版本下頁面會有不同的展現。紅色的區域是有問題的。我們發現在SDK0.10.0這個版本上，list是沒有問題的。所以有可能的話，盡量升級為高版本的SDK。我們目前升級到的是0.12.0，比較穩定（不過建議大家再往更高版本升級）。

（二）那個列表頁需要帶有用戶登錄態，Weex雖然不支持Cookie，但是可以借用原生的Cookie能力，調用原生的Cookie做到用戶登錄態的介入。還有一種方案，我們還有團隊採用在介面中傳遞Ticket票據獲取用戶登錄態的方式這是原生中封裝的一個自定義module方法，每個請求都會帶上Cookie；也可以Native攔截介面請求並添加Cookie信息

（三）剛才的列表頁跳到原生頁需要傳遞參數，我們要把用戶的一些訂單信息傳過去，這時Native可定義一系列的跳轉協議，協議的前綴比如sdggmm://，Native會統一做url解析並跳轉目標頁，原生同學要把所有可能跳轉的頁面全部提前寫進去。

（四）剛開始按照官方的文檔，採用了.we的版本，後來官方推薦使用.vue版本，我們使用了一些工具進行轉換，之後稍作手工的調整就切到.vue版本。

三、大規模應用Weex

我們在代練業務中差不多21個頁面用到Weex，在公司會議系統中有7個頁面用到Weex。

從展現上來說，體驗令人激動。不過在做之前，我們先考慮了很多問題。

從五方面去考慮:

我們比較習慣做單頁面應用，但Weex應用也採用單頁面方式合適嗎？其實Weex支持單頁，也支持多頁，這兩種方式看你怎麼選

第二個問題，Weex頁面之間的跳轉會存在什麼問題

第三，Weex頁面的跳轉會帶一些參數，或者通信問題該怎麼解決

第四，樣式的復用

最後是怎麼充分利用Native的一些能力。

（一）有一個同學也問到這個問題：用單頁還是多頁？我開始是以單頁的方式做的，用路由做確實有一些好處：可以避免重複載入一些資源、自定義專場效果、數據可以共享。

實際上我發現打開Weex頁面，經常出現APPCrash情況。再加上多人合作時，協作比較差。還有APP進到Weex有多個入口，還要做一些特殊的處理。還有Vue全家桶這個東西對團隊成員來說有點學習成本的.

所以說基於考量，最後我們就選定了多頁的開發方式。每一個頁面就是一個bundle，如果拆分得足夠好其實很小。那種Crash的情況也會減少，專場效果和原生保持一致等等.

（二）頁面跳轉會存在一些問題，我們剛接入的時候本來希望是正常的，實際會有右邊這種情況。這個本身也不是Weex的問題，而是原生頁面默認設置的navigationController問題，最後我們採取的方案是我們自定義一個Push方法去覆蓋SDK中的Push方法，這樣所有Weex打開頁面都會隱藏頭部導航，大家在接入Weex時注意下這一點。

（三）數據通信問題，是很多團隊比較關心的。從Native跳到Weex要傳數據，Weex跳到native也要傳給原生數據，WeexA頁面跳到B頁面。還有WeexA頁面跳到B頁面，再pop回到A頁面。還有最下面的WeexA頁面跳到原生頁面，再回到WeexA頁，這些應用場景下數據的傳遞，我們經過了一些嘗試，有一些參考方案。

1、Native跳到Weex，剛才列表頁就是一個典型的例子。可以用原生去封裝數據變數，實例變數，把order_id等數據包進去。

2、Native向Weex主動傳遞數據，相當於推送。右上角的消息數量，這是主動推送數據給Weex頁的場景。我們會怎麼做呢？其實就是訂閱原生的事件，如果原生推送到了以後，監聽這個事件的Weex頁面就可拿到數據，是通過這種方式解決推送。

3、Weex向原生傳數據，就是像前面說的通過url拼接，原生抓到url並對url進行處理。

4、WeexA頁面傳到WeexB頁面，這個大家都經常處理。我們的JS全部是通過預載入本地，是在APP本地中無法運用到url解析方式，所以用到了storage方式，在A頁面set數據，在B頁面get數據，拿到時回調中做一下remove，否則可能會導致後面操作受影響。

還有一種解決方式：viewappear與viewdisappear。

5、在A頁面跳到B頁面，然後B頁面pop並回傳一些數據給A頁面的情況。在原生中，到B頁面之後是一個view棧壓在上一層，再回傳回來的話A頁面像休眠一樣。這時候怎麼把數據傳回來？看一個場景吧！

我在左邊這個區域選了區服，彈出右邊的Weex界面。選中一個區服數據，回傳數據到左邊的Weex頁面。

我們是怎麼做的？.we這個版本有BroadcastChannel對象，是可以解決的。但是vue版本不支持（注意：現在新的SDK版本已支持）當時我們不知道怎麼辦，後來討論了一下，發現還是可以用fireGlobalEventCallback做一個封裝，封裝一個sendEvent方法.

它的過程是在WeexA頁面跳到B頁面時，B頁面做了操作以後，A頁面其實在監聽B頁面的事件。你在B頁面回傳時會發送一個事件，A事件監聽到這個事件，A頁面就在回調中拿到了想要的數據。

6、還有一種場景，從WeexA頁面跳到Native的頁面，為什麼跳到native的頁面呢？因為有些Native頁面是可復用的，它的功能很獨立。比如一個簡訊驗證原生頁面、評價頁，它非常通用，這類頁面沒有必要做二次開發，可直接調用；調用完以後，它會跳到另外一個Weex頁面。我們是一個遊戲虛擬電商的平台，會有支付的流程，我們會封裝一個自定義的module。

比如支付，下單頁面支付完之後，成功跳到支付成功頁面。在這樣的場景中調用了Native錢包支付頁，我們會調用fireEvent，彈起原生支付錢包流程，支付完以後就進行回調。

我不認為我們的做法是最佳實踐，希望Weex團隊給出一些最佳實踐和通用方案出來。其實這個問題不僅僅是我，很多團隊都會遇到通信這方面的問題，希望官方有些反饋。

（四）樣式怎麼做復用，多虧了CSS-loader，我們可以形成組件化的樣式文件。因為樣式在Weex中不能嵌套，SASS的很多優點不能得到很好的發揮，所以我們放棄了SASS工具。

（五）接下來非常重要的一個內容，就是充分利用原生的能力。很多Weex頁面，比如圖片上傳或者分享組件，然後圖片放大縮小的全屏預覽，等等一些原生的功能，它已經封裝得非常好。而且像調用支付SDK這種，Weex還沒有這方面的能力，我們可直接自定義一個module使用。其實Weex的優勢就是可擴展性，有一些想像力在。

四、性能優化實踐

說到性能優化，我們主要是對兩塊進行了優化。其實網路載入這個問題也不是關鍵，因為我們bundle資源都是APP打開後預載入的（Weex頁面一般在三級頁面）。預載入的bundle資源是經過壓縮，圖片也經過壓縮，然後本地訪問非常快。

其次是注意scoller和list的使用。長列表一定要做懶載入，還要劃分好cell顆粒度，嵌套不要太深。像我之前做單頁，我都懷疑當時做單頁是嵌套太深了，所以導致App偶爾出現Crush。嵌套一定要扁平一些，這時候就考驗前端工程師的功底了。

性能優化這方面上午阿里同學已經講過，我們首選list，還有未來的list性能會更好，我們好好期待吧！平時還要注意劃分好Vue組件的顆粒度。

五、踩坑填坑

（一）Dialog點透問題。點透的問題，這個彈出框和Mask是平級標籤，但點擊中間彈出區域莫名會觸發Mask層的關閉事件，當時感覺有點懵了。後來怎麼解決呢，就是在彈出層加一個阻止冒泡事件。

（二）這是一個圖片放大的東西，會有輪播、放大，全屏的展現。後端反饋的數據沒有帶寬高信息的，這種情況下對於Weex做上下居中，放大縮小，做輪播，剛開始做這個圖片，在不知道寬高情況下做上下居中有一點困難。因為image標籤一定要規定寬高才好，當時直接利用自定義原生控制項封裝好，兩行代碼搞定，我覺得很方便省事。

其實我是希望它返回url帶一些寬高信息，這樣就可以根據寬高信息來定點陣圖片。

本文來自雲棲社區合作夥伴「淘寶技術」

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎