4个月原生weex混合开发终结（）

1. 原因

• 由于一些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进行开发。

2. 目前的使用程度

• 已经有5个新业务全部使用weex开发，还有12个单独的weex界面，共34个weex页面，23个weex组件，3个原生提供的组件，6个moudle提供42个原生app的功能。

2. 遇到的问题

• 我们自己使用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（地图等）

3. 页面跳转

• 我们没有采用vue-router和weex自带的navigator模块。而是使用自定义的navigator模块通过原生已经定义好的Scheme跳转实现（与推送，h5，外部应用跳转共用一套），无论是调原生还是weex都采用这一套。weex间的跳转直接带参数到下一个weex页面，原生只通过Scheme传递Map类型的json数据。

4. 使用

• 开发：提交代码后GitLib通过Webhooks通知jenkins服务器编译，app使用jenkins服务器产生的js链接地址。

• 线上：使用tag版本产生的js文件，存放到线上静态服务器，app使用线上链接。下版本将支持app本地缓存和根据文件版本更新。

• 也可以访问我的个人博客：http://blog.yzapp.cn

• github：https://github.com/nesror

• 掘金：[https://juejin.im/user/561b1b9c60b2617174659ba0]