Weex 问题处理

需要多端一起解决的问题

客户端配置统一

问题描述:

Android 和 iOS 版本控制不统一,但是其实大多数界面都是统一的,在 weex 里面做了基本的兼容,可以使用一套配置

解决方案:

老版本 weex 保留,方案定下之后,在客户端(3.9.0),不管需不需要客户端支持,weex 页面最小支持版本全部升级到 3.9.0 ,兼容性测试后上线,此后都只配一套,一段时间后 3.9.0 用户比例上去了,老页面可以直接删除了。


历史版本记录和随时上下页面

问题描述:

不需要客户端版本更新支持的的 weex 页面上线时是改变原来的链接,觉得有风险时需要自己手动保存原来的版本。

解决方案:

只要有变动,总是新增版本,js 版本增加,每一行增加开关,点击关闭则该页面下掉


MD5 问题

问题描述:

对文件作md5耗时耗力,因为大多数weex不会频繁更新,所以 95% 的计算并没有意义

解决方案:

使用 page + jsVersion 来比对版本更新,二者可以唯一标记一个 weex js

存在问题:

线下没有版本控制,现在是使用 md5 比对文件更新下载, 暂时想到的方案是,线下可以使用时间戳作为 jsVersion, 保证每次构建都会给一个新的版本号,待商榷


构建自动推送

问题描述:

Weex 项目在预发、线上构建后需要人工手动配置,容易出错,期待做成自动化的。

解决方案:

触发构建后自动推送到后台数据,但是默认上线按钮不打开,人工确认开启


Weex 配置文件越来愈大(@嘉文)

问题描述:

由于页面增多,客户端拿到的 weex 配置的 json 相当庞大,目前有80多个页面,且大部分并不使用, 而且客户端会对所有的js作文件缓存,即使以后不可能用到

解决方案:

客户端请求配置文件时,传递自己的版本号,从服务端拉取自己版本能用的配置版本,比如 版本是 3.7.0,A 页面在 3.6.0 和 3.7.0 都有配置,则只返回 3.7.0 的配置项。


新用户第一次触发下载量过大

问题描述:

新用户本地没有任何 js 缓存,需要爆发性的下载大量文件,并且每个文件都是启动新的连接传输,速度较慢

解决方案:

针对新用户第一次安装后的请求,能够将所有js文件打包gzip下载一次即可,后续更新还是按照原来的方案,基本一两个文件的下载。

存在问题:

本地文件缓存控制不好协调,还有就是打成包下载的话,可能比下载单文件更耗时,导致首页等资源无法准备好,暂时想到的解决方案是,新用户准备个启动准备页,类似qq数据库迁移那种。


Js 更新问题(暂时还没想明白)

问题描述:
由于JsBundle在构建完成后就已经完全独立了,当涉及到修改组件、适配等涉及页面较多的需求时非常难以解决,比如如下几个场景:

  • 适配 IPhoneX, 解决全面屏显示问题
  • 修改 spon-field 字体大小,原本不支持设置字体大小,需要发布组件,然后重新构建相关页面
  • request.js 修改了文案,不构建的页面无法生效,只能等其他人发布慢慢跟上去
  • img-upload 组件开发初期功能不完善, 改动频繁,已经用了该组件的的页面没法一起跟着生效

解决方案:
参考 H5 的升级方法,可以批量发布,每次指定一个 js 版本和一个 app 版本就可以发布,app 版本采用这次发布的 js 中最小需要支持的版本,举个例子:

  • 适配 IPhoneX,更改了 20 个页面,页面中最小支持的 app 版本在 3.8.0。。。。。。
  • 现在要发布一个优化项目,改动 7 个页面,其中 4 个页面需要 app 在 3.6.0 ,3 个页面需要客户端在 3.9.0 ,构建完成 js 版本为 0.16.4,则使用 0.16.4 + 3.9.0 发布

增量更新

效果没那么大,且容易出错,暂时不研究


客户端容器需要优化的问题

检索升级

问题描述:

现在客户端跳转时,回去遍历所有的 weex 配置列表,并挨个比对,然后跳转,这个过程很耗时,表现在点击跳转时会停止一回再跳转

解决方案:

拿到配置列表时,先做一个 map, 用 h5(host/path/jsversion), 后续查找直接使用 h5 拿对应的配置,避免遍历


事件机制升级

问题描述:

现在基于 weex 页面内通信机制,做了两个方案:

  • 向上个页面发送事件,基于存储+weex 单页面通讯实现 -> 局限性大,容易出错
  • 所有页面事件,通过遍历所有 weex 实例实现 -> 比较耗,没注册的页面也会收到

解决方案:

在内存中做一个 EventBus,页面使用注册机制,维护一个映射 Map<EventKey, Array<InstanceId>>

  • 注册事件时,将页面 InstanceId 注册到 EventKey 对应的 Array<InstanceId>
  • 发送事件时,取出 InstanceId 列表发送事件。
  • 页面销毁时,自动取消注册
    `

数据传输升级

问题描述 :

目前的数据传输基于 url, 所有数据以 get 请求的方式拼接在 url 后面,传输内容十分有限,无法传输大量数据或者特殊格式数据(如整个 json),解析会有问题

解决方案:

在内存中维护一个 Map<Url,Object> 的映射,将数据先放到内存中存起来,页面创建时,用自己的 url 从内存中取出,然后删除掉内存里面的数据,页面销毁时也要做删除。

缓存策略升级

问题描述:

目前 js 只有一级文件缓存,加载新页面需要频繁文件 IO,而且会造成页面加载慢的问题,越大的 weex 页面问题越显著,如页面中有 base64 编码的图片

解决方案:

js 采用两级缓存方案, 能加快页面打开和渲染的速度,减少频繁 IO 占据的内存

  • 提前加载页面到内存中
  • 内存 LRU 缓存,加快访问速度
  • 文件 LRU 缓存,避免垃圾文件堆积
------ 本文结束 🎉🎉 谢谢观看  ------