移动端应用升级

移动端应用升级是一个非常常见的需求，那么假如让你来设计此方案应该如何设计？

有哪些问题是需要解决的？

目前现在使用的技术方案有哪些不足，哪些是目前可以改进的，哪些是以后需要改进的？

移动端升级

确定移动端应用是不是有需要升级的更新包
去服务器下载更新文件a.json，对比本地的版本文件b.json和下载夏利的a.json对比版本号，是否需要更新，如果需要更新，则更加b.json里边的内容去下载对应的升级包，下载完成之后，替换移动端应用里边对应的包或者添加，同时更新a.json为最新。

首先查看是否本地存在离线包，如果存在则升级，然后保存当前版本号和离线版本号

{
  currentVersion:1.0.1,
  currentOfflineVersion: 1.0.3
}

去服务器下载更新文件，更新文件包含各个版本号对应的升级包地址（因为每个客户的版本可能会不一致，所以会保存不同的版本号），比如如下：

{
  currentVersion:1.0.1,
  updateVersion:1.0.2,
  updateOfflineVersion: 1.0.2,
  updateOfflineUrl: "www.xxx.con/ss"
}

下载以后，进行对比两个文件，如果需要更新，则去服务器下载对应的离线包，更新本地文件，更新成功之后，更新本地对应的版本号和离线包号。

更新时机是移动端再次启动的时候，通过文件替换更新，让移动端可以使用最新的文件。

这里还会涉及到一个验证可靠性的问题？换句话说就是如果确定你下载的文件已经全部下载完了，下载的是不是对应的文件，如果在下载的过程中，别人更新了服务器上的文件呢？

可以先考虑下，如果是你，如何来做可靠性的验证？

想想有哪些方案，如果是你如何来解决这个问题，先思考再搜索，才是解决问题的好方法，而不是先搜素再思考反着来。

这里是采用MD5验证，第一次从服务器下载下来的文件中会包含当前需要更新文件的MD5值，然后等到所有更新文件下载完成之后，会再次计算MD5值，如果两者相等，就会认为下载成功了，如果不相等，就会放弃此次更新，重新下载。

每种方案都会有自己的适应场景，有自己的优点也会有自己的缺点，关键是在优点和缺点之间找到想要的平衡点。

可以先考虑下这种有什么不足呢？

这种方案全程没有用户参与操作，都是自动升级的，有些用户喜欢，但是另外一些可能就会反感，比如有些用户可能就觉得目前的版本很好，我不想升级，你为什么要强制我升级呢？所以有些升级方案其实是会提醒用户，让用户自己选择是跳过该版本还是升级，但是这样也会带来实现的复杂度。
这种方案是全量更新，应该还可以做到更细粒度化的处理，比如只更新某个文件。
一些错误回滚的处理，比如升级失败或者升级之后有问题，如何回滚到以前的版本？