關於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的同學探討相關的技術，一起進步。