- 原因
- 由于一些h5人員方面的原因，新的非主流程需求將全部由app人員開發(fā)。然后app的人員已經(jīng)由15人縮減成ios和android各兩個了。為了應(yīng)對3個產(chǎn)品各自負責的需求，我們調(diào)研了weex和rn。
- 我們原app已經(jīng)非常完整，并且新業(yè)務(wù)都是相對獨立的頁面，顧更專注于頁面的weex更加符合（不建議整個app都使用weex做，RN和Flutter更合適）
- 我個人在16年中旬（應(yīng)該是剛開源不久）就關(guān)注了，有一定了解。
- 結(jié)合mpvue，可以讓微信小程序和weex共用組件。
- weex上手簡單，團隊整體更喜歡vue。
- 雖然網(wǎng)上有很多關(guān)于weex有深坑的文章，但我們嘗試后發(fā)現(xiàn)對于app開發(fā)來說絕大部分不是問題。但weex不適合做整個app。
- 社區(qū)支持相對弱，但我們可以自己造輪子，自己改sdk。
- 最終我們決定采用weex進行開發(fā)。
- 目前的使用程度
- 已經(jīng)有5個新業(yè)務(wù)全部使用weex開發(fā)，還有12個單獨的weex界面，共34個weex頁面，23個weex組件，3個原生提供的組件，6個moudle提供42個原生app的功能。
- 遇到的問題
- 我們自己使用okhttp封裝的網(wǎng)絡(luò)庫限制了只能返回確定的數(shù)據(jù)類型，而weex的IWXHttpAdapter需要返回bytes。
- 修改網(wǎng)絡(luò)庫解決
- android端string值傳遞到weex變成數(shù)字類型并且js精度丟失問題
- 現(xiàn)象：android端傳遞String類型的“1111111111111111...”到weex頁面時，通過weex頁面接收到的是數(shù)字類型，并且精度丟失變成：1.111e+84。ios無此問題。排查weex sdk，一直到WXBridgeManager的invokeExecJS方法時參數(shù)還是String類型的。下面的execJS方法是調(diào)用jni的，android的sdk里并沒有這部分native代碼。顧對于串數(shù)字端超長id我們暫時采用值前面拼接參數(shù)名的辦法（理論上后臺設(shè)計不應(yīng)該出現(xiàn)這么長的純數(shù)字id）。
- 編譯時間過長，預(yù)覽導(dǎo)致
- 開發(fā)時通過webpack.dev.conf的filterPage(entrys)進行過濾，通過npm run serve -- --env.page=XX，指定需要預(yù)覽的頁面。
- css展現(xiàn)的ui各端稍有不一致。
- weex官方ui庫不豐富
- 一部分使用weex-ui
- 一部分自己使用vue寫
- 使用原生ui（地圖等）
- 頁面跳轉(zhuǎn)
- 我們沒有采用vue-router和weex自帶的navigator模塊。而是使用自定義的navigator模塊通過原生已經(jīng)定義好的Scheme跳轉(zhuǎn)實現(xiàn)（與推送，h5，外部應(yīng)用跳轉(zhuǎn)共用一套），無論是調(diào)原生還是weex都采用這一套。weex間的跳轉(zhuǎn)直接帶參數(shù)到下一個weex頁面，原生只通過Scheme傳遞Map<String,object>類型的json數(shù)據(jù)。
- 使用
開發(fā)：提交代碼后GitLib通過Webhooks通知jenkins服務(wù)器編譯，app使用jenkins服務(wù)器產(chǎn)生的js鏈接地址。
線上：使用tag版本產(chǎn)生的js文件，存放到線上靜態(tài)服務(wù)器，app使用線上鏈接。下版本將支持app本地緩存和根據(jù)文件版本更新。
也可以訪問我的個人博客：http://blog.yzapp.cn
github：https://github.com/nesror
