下线功能

1. 需求场景

下线功能是个刚需,不管是发包发出了问题,还是线上的包过期了,都需要下线功能,让客户端已有的故障离线包失效。

下线功能从 2016.12.13 后发布的客户端开始支持。

2. 如何操作下线

针对所有在热更新平台发布的qp包,都可以进行下线操作。进入发版记录里,可以看到下线按钮。

image

点了这个下线功能之后,服务端将会对应版本的qp包标记为下线状态。

3. 下线逻辑解析

服务端

在客户端检查更新请求的时候,如果客户端传的参数中版本和下线了的qp包匹配,则会返回一个下线相关的数据。

比如: 客户端本地hybridid 是"mob_uc"", version="99",服务端对这个包进行了下线操作。

这时客户端检查更新的时候,收到的数据将会比之前多了一个offline_hlist字段。如下所示: image

客户端接收到数据后级可以进行相应的操作了。

客户端

统一设计

这部分逻辑比较复杂,先来一张流程图

image

(1)这部分是我们上个版本做的一个功能,做了一个特殊的qp包,里面是各个qp包的版本信息,我们用这个信息监测其它qp包,如果版本小于指定的,则标记为下线, 可以参考这里

(2)上次检查更新得到的下线信息进行本地持久化,方便下次启动的时候可以快速进行qp包校验

(3)单页更新,这个是在页面打开的时候就会发,不同于第5的全量更新,只发一次。 单页更新获取到的下线信息不做处理,只做记录,下次app启动再使用。

(4)加载hy或者rn业务,随时在客户端中会发生,这是用户行为。

(5) 全量更新不管是在wifi还是在其它网络环境下都会发,参数包含所有的本地的qp包信息,这样服务端才会知道要不要给客户端返回更新信息或者下线信息。得到下线信息之后,要对没有使用的qp包进行下线操作。已经使用了的qp包,不敢随时替换和下线。

(6)没有qp包时,其实就和用户刚从app store上下载了app一样。所以不再深究,只要保证做新功能不影响这里即可。

(7)如果在下线之前,qp包已经被使用了,则进行一个标记,不能再下线了,继续使用当前的qp包,直到下次启动。

注意:开发时要保证线程的安全。

iOS 和Android 的差异

考虑到iOS设备用户很少主动退出app,所以两平台还有一些差异。

Android是每次启动的时候才替换qp包的。

iOS是从任何页面pop到首页(认为业务线页面都关了,但是类似“我的”、“订单”这些,还是有差异的,需要特殊处理),会进行一次替换

即便是是以上特殊处理之后,从目前的统计结构来看,Android的更新率比iOS的高8个点左右。所以为了提高下线的可靠性,iOS还是做了个特殊处理。 从上面的流程图可以看出,如果一个qp包使用过了,就会进行标记。那么这个标记啥时候去掉呢?并没有在图中提现出来。但是这两平台在处理上确实有差异:

Android是在重启之后就会重置

iOS 用户很少重启,那么就需要在回到大首页就重置,但是"mob_uc", "hotel_rn_ios", "commonbusiness_rn_ios",因为它们是预加载的,重置了可能会出现多版本问题。 那么既然上面三个hybridid对应的包不重置,那么下线了之后,还是需要重启之后才起作用,其它逻辑保持不变。