- 原因
- 由于一些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。
- 修改网络库解决
- android端string值传递到weex变成数字类型并且js精度丢失问题
- 现象：android端传递String类型的“1111111111111111...”到weex页面时，通过weex页面接收到的是数字类型，并且精度丢失变成：1.111e+84。ios无此问题。排查weex sdk，一直到WXBridgeManager的invokeExecJS方法时参数还是String类型的。下面的execJS方法是调用jni的，android的sdk里并没有这部分native代码。顾对于串数字端超长id我们暂时采用值前面拼接参数名的办法（理论上后台设计不应该出现这么长的纯数字id）。
- 编译时间过长，预览导致
- 开发时通过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本地缓存和根据文件版本更新。
也可以访问我的个人博客：http://blog.yzapp.cn
github：https://github.com/nesror
