- 原因
- 由於一些h5人員方面的原因，新的非主流程需求將全部由app人員開發。然後app的人員已經由15人縮減成ios和android各兩個了。為了應對3個產品各自負責的需求，我們調研了weex和rn。
- 我們原app已經非常完整，並且新業務都是相對獨立的頁面，顧更專注於頁面的weex更加符合（不建議整個app都使用weex做，RN和Flutter更合適）
- 我個人在16年中旬（應該是剛開源不久）就關注了，有一定了解。
- 結合mpvue，可以讓微信小程式和weex共用元件。
- weex上手簡單，團隊整體更喜歡vue。
- 雖然網上有很多關於weex有深坑的文章，但我們嘗試後發現對於app開發來說絕大部分不是問題。但weex不適合做整個app。
- 社群支援相對弱，但我們可以自己造輪子，自己改sdk。
- 最終我們決定採用weex進行開發。
- 目前的使用程度
- 已經有5個新業務全部使用weex開發，還有12個單獨的weex介面，共34個weex頁面，23個weex元件，3個原生提供的元件，6個moudle提供42個原生app的功能。
- 遇到的問題
- 我們自己使用okhttp封裝的網路庫限制了只能返回確定的資料型別，而weex的IWXHttpAdapter需要返回bytes。
- 修改網路庫解決
- 編譯時間過長，預覽導致
- 開發時通過webpack.dev.conf的filterPage(entrys)進行過濾，通過npm run serve -- --env.page=XX，指定需要預覽的頁面。
- css展現的ui各端稍有不一致。
- weex官方ui庫不豐富
- 一部分使用weex-ui
- 一部分自己使用vue寫
- 使用原生ui（地圖等）
- 頁面跳轉
- 我們沒有采用vue-router和weex自帶的navigator模組。而是使用自定義的navigator模組通過原生已經定義好的Scheme跳轉實現（與推送，h5，外部應用跳轉共用一套），無論是調原生還是weex都採用這一套。weex間的跳轉直接帶引數到下一個weex頁面，原生只通過Scheme傳遞Map<String,object>型別的json資料。
- 使用
-
開發：提交程式碼後GitLib通過Webhooks通知jenkins伺服器編譯，app使用jenkins伺服器產生的js連結地址。
-
線上：使用tag版本產生的js檔案，存放到線上靜態伺服器，app使用線上連結。下版本將支援app本地快取和根據檔案版本更新。
-
也可以訪問我的個人部落格：blog.yzapp.cn
-
github：github.com/nesror