Weex線上踩坑實錄

關於weex的基礎集成網上有不少博客，我就不重點介紹，今天主要分享一下weex文檔中並無的，在實際項目集成中的碰到的注意點和坑。滿滿的經驗和乾貨，但願能對你們有所幫助。

1.如何集成到fragment中

集成到fragment的狀況仍是很廣泛的，由於如今不少app都是採用activity內嵌fragment的開發方式，把實際功能都放到fragment中。再好比在tab上通常是tablayout(bottomNavigationView)+fragment的佈局，tab上內容也須要使用weex來開發。

在weex文檔中只說明瞭怎麼集成到activity中，網上也有不少人在問如何將weex集成到fragment。其實答案很簡單，weex渲染出來的內容其實只是在一個控件中，因此只須要和普通的fragment開發同樣，將weex sdk嵌入便可。根據weex官方描述，在回調IWXRenderListener的onViewCreated返回建立的view。因此咱們只須要讓fragment實現IWXRenderListener，而後在onViewCreated中將渲染出來的view添加到整個視圖容器中便可。

最後提一點優化，除了考慮到weex使用到fragment中，固然也要考慮到有些頁面不是內嵌fragment的狀況。這裏能夠不用從新寫一套weex sdk的集成，直接讓activity使用已經集成了weex的fragment便可。

2.加載方式選擇

在weex文檔中提供了2種經常使用的加載js方式，本地加載和遠程加載。筆者在weex開發者大會上問過手淘官方的人員，他們表示手淘首頁入口9成都是weex的頁面，而且這2中加載方式都有用到，根據實際業務團隊本身來靈活選擇。

咱們是使用的打開app或者先後臺切換時下載js，而後直接加載本地js的方式。該方式因爲不用每次從網上下載，因此加載效率會高一些，可是也有缺點，就是每次線上發佈之後須要一段時間用戶才能下載到代碼並生效，並不能及時的達到更新效果。

注意：不要採用在上一個頁面點擊時去判斷本地js版本，而後下載運行的方式。該方式看起來很美好，又能實時更新效率又高，可是其實並否則。問題在於該方式須要去請求服務器獲取js更新狀態，萬一網絡差的時候就一直不會初始化容器，此時用戶點擊屢次就會打開多個頁面，很是的不友好，並且會給服務器帶來無所謂的壓力。

3.不一樣的業務模塊中如何進行業務交互

weex和rn不同，在rn中全部的業務默認都是放到一個模塊中的，因此rn幫咱們處理了通訊這一塊內容。可是weex不同，weex中不一樣業務是不一樣的js文件，致使通訊困難。

網上有說使用storage的方式，可是這個方式其實不太好，通過和前端協商，咱們決定本身寫一套業務模塊中通訊方式。咱們自定義了一個倉庫類，提供set方法保存業務模塊通訊中要傳的值的key和value，前端調用set方法能夠將值保存到客戶端，而後加載B模塊時由咱們客戶端將值給B模塊，也就是經過fireGlobalEventCallback推送給前端使用。

4.如何構造一個前端調用體系

這裏的前端調用體系是指在vue代碼中調用到客戶端的方法，包括自定義控件、客戶端功能等。官方告訴咱們是經過JScallback的方式，可是咱們總不能在客戶端寫不少個方法一一對應吧，這裏咱們寫的比較簡單，讓前端傳入一個約定好的僞協議過來，其中包括須要調用的方法、傳的參數等內容，接下來在客戶端中解析該協議對應到實際的方法。固然這裏其實能夠考慮用設計模式優化一下，面向修改關閉，會更加符合solid原則。

5.關於網絡框架、圖片框架

weex的sample中是使用最簡單的httpurlconnection來請求數據，可是這個是沒有任何優化的基礎訪問。可是也提供給了咱們自行修改的方式，那就是setHttpAdapter()，經過該方法可使用適合本身公司的網絡框架，好比OkHttp、Retrofit等等，weex官方也是建議修改一下網絡框架，可以提升訪問效率。

weex並無提供圖片加載的方式，用官方的解釋來講就是你們的方式都不同，加進去會讓sdk很臃腫，並且不必定能符合各個公司的實際業務場景。因此weex官方只提供了一個setImageAdapter()來讓咱們自定義適合本身的圖片框架，咱們必須實現IWXImgLoaderAdapter，否則圖片是沒辦法加載出來的。

注意：圖片加載框架須要考慮到gif等其餘格式，作好兼容性測試，咱們當時ios就出現過問題。

6.關於降級措施

因爲咱們是使用先下載到本地，而後加載本地js的方式，因此不能避免的一個問題是在打開weex頁面的時候實際的業務代碼還沒下載。針對這種狀況，咱們使用了降級策略，在打開weex頁面以前首先判斷一下本地是否有該業務代碼，若是沒有就打開入口上已配置的h5連接

7.有關打點方面

這裏只分享客戶端這邊的打點，咱們在下載js的流程中都有好幾個打點，分別是下載成功（失敗及緣由）、解壓成功（失敗及緣由）、增量更新成功（失敗及緣由），除此以外，還有進入weex頁面信息、weex渲染成功與否、是否進入降級以及降級緣由等基本打點。

8.其餘weex文檔沒有說起的要點

weex文檔很不全面，致使實際運用到項目中的時候坑點多多，weex上線之後最初基本每一個版本都要上一些代碼去填坑。固然weex官方是提早知道這些的，只是沒有及時分享出來而已。舉幾個例子，好比ua、cookie等的支持都須要客戶端進行支持。

ua：weex sdk中有帶一個默認ua，但那確定不是咱們想要的，通常服務端須要的是帶app信息的ua。

cookie：cookie的話是在請求時須要帶上的，因此咱們須要讓weex的網絡請求框架帶上。這些在第一次上線時不必定能考慮到，可是客戶端發版問題一直都是老大難，這裏分享出來但願能對你們有所幫助。除此以外，咱們須要賦予前端保存和修改cookie的能力，因此咱們在客戶端提供好了相關的set和get方法。

9.線上已知weex的未解決bug

咱們上線以來碰到了不少的問題，其中大部分weex團隊獲得瞭解決，筆者在此對weex團隊表示感謝，好比只支持aremabi，致使和項目中其餘功能衝突的問題、還有線上崩潰也愈來愈少，說明weex已經逐步愈來愈成熟。可是不能否認的是，目前weex仍然有一些問題，好比weex sdk中有framework層初始化失敗的問題，發生的機率大概在千分之三左右，weex官方的建議是這個問題沒法在sdk中修復，須要本身去判斷是否初始化，萬一沒有初始化便進入降級策略，他們在最新的weex sdk中是已提供了是否初始化的接口的。還有一個線上已知問題是部分三星手機上會crash問題，該問題只出如今三星手機上，目前weex官方沒有獲得解決。另外，weex對recyclerview的支持不是很好，致使有些列表的效果實現不了，相信這個在之後應該會解決。另外還有些莫名其妙的問題，不知道該怎麼說，也不是很重要，這裏就不一一描述了，不過相信weex的逐步成熟，這些問題都會迎刃而解的。

10.其餘建議

因爲weex目前自己就不大穩定，加上第一次使用，避免不了會碰到不少的坑，因此可使用灰度發佈的方式，根據設備號或者id分流只發布一部分的用戶使用weex頁面，這樣萬一出現問題影響範圍較小，若是一段時間之後沒問題再大批量上線。集成weex的客戶端開發人員也要學習一下vue，這樣本身就能夠測試weex的集成代碼，提高和前端人員的溝通效率。多關注weex的社區以及github、jira、釘釘羣等weex官方平臺，有問題能夠在裏面提issue，筆者親自體驗仍是會回覆的，包括如今weex官方已經提供了一個專用weex討論羣，有阿里人員在裏面解答問題。有空能夠研究一下weex底層的代碼和核心原理，提高技術的深度和看源碼的能力。

最後：以上經驗都是筆者做爲在線上項目中實際使用過weex，而後分享的在使用過程當中的感覺。絕對不是網上隨便搬抄的，但願能對你們實際應用weex到項目中有所幫助。也歡迎使用過weex的同窗探討相關的技術，一塊兒進步。