整体解决方案

QP 是一套为 QRN、HY 和 YIS 等动态化框架提供静态资源离线包的整体解决方案。整套解决方案都是以 QP 资源包为维度,包括打包、发布、更新、运维等。解决了版本控制、页面加载慢和灵活发版的问题。

image

1、解决版本控制问题

版本控制问题归根结底就是对应版本的客户端能下载到适合的最新QP包(qunar 自定义的文件格式,类似zip包,本文不做过多介绍)。如果做不好版本控制,可能会引起线上故障,想象一个场景,Native在最新版本提供了一个新插件供QRN使用,在最近一次迭代时QRN项目使用了这个新插件,那么将这个QRN项目发出去之后,如果让老版本的客户端运行了这个最新的QRN项目代码,因兼容性问题将会引起不可预知的故障。

我们解决版本控制问题的思路是,配置一个客户端的vid(随着客户端发版递增)字段,然后通过这个配置打出的QP包,能被所有比指定vid大的客户端下载,当有新的QP包更适合指定vid客户端时,服务端会下发最新的QP包。

vid配置如下所示:

iOS_vid : vid_80011085
android_vid : vid_60001091,com.mqunar.attemper_1,com.mqunar.home_2 

注:Android 因为有模块的动态热发,所以比起iOS多一个组件版本项。

还有一种场景我们经常遇到,要求修复指定版本的bug时,该如何处理呢?比如android的预装,通常都是半年前的客户端。我们采取的解决方案是vid字段可以配置区间,这样就只用vid落到区间里的客户端能下载到bugfix的QP包。 Vid配置如下所示:

iOS_vid : vid_80011085-vid_80011085

2、解决页面加载慢问题

针对页面加载慢,我们可以通过缓存策略,将本来应该从线上请求的资源,在本地存在的情况下直接从本地获取,本地不存在再去线上请求。如下图所示:

image

步骤1先发起一个网络请求没有直接从服务端获取数据,而是通过步骤2经过了“网络请求拦截器”,再经过“拦截过滤器”进行一次摔选,保证本地有资源的情况下,直接从本地拿数据,在本地构造一个Response完成网络请求,本地没有数据的情况下,通过步骤7从线上获取资源,这样就在数据获取方面做到了最快。

3、解决发版灵活问题

针对灵活发版,我们先给出一个最小化解决方案。 我们的业务代码一般放在gitlab,当代码开发完成之后接着就是打包,生成一个可供客户端下载的包(即QP包),这个包需要一个服务端来做版本控制,我们暂且叫QP Server,最后客户端通过一定的更新策略,就可以更新到合适的QP包,当本地有包了,就按前面介绍的缓存策略来加载资源,如下图所示。

image

仅通过上图所示方式,当QP Server故障或者网络慢时,客户端将下载不到QP包,这时应该考虑一个应对这种情况的方案,当本地获取不了资源时,会从线上获取,这个在“解决加载慢问题”的图片中也是可以看出来的。在上图方案的基础上,我们在打包环节加一些步骤,先将qrn代码打包成jsbundle 上传到jsbundle Server, 接着再打出QP包,这样就可以保证客户端在下载不到QP包时,可以通过jsbundle Server直接加载js。如下图所示。

image