下线功能

1. 需求场景

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

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

2. 如何操作下线

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

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

3. 下线逻辑解析

服务端

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

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

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

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

客户端

统一设计

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

（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对应的包不重置，那么下线了之后，还是需要重启之后才起作用，其它逻辑保持不变。