作为一个有3年工作经验的iOS开发者,经历了有10余个大小项目,从来没有一个项目使用到了强制更新,一直对app强制更新有着一种好奇!正好现在所做的项目中做了这一点,此篇文章可以为同样对此感到好奇的同行提供点参考,同时也能加深自己的理解(理解是一种境界,实践是一种境界,通过自己的讲述,能让别人理解又是另一种境界)!
强制更新的好处
强制更新即为新版本app上线后,用户在进入app时,弹窗提醒用户更新(唯一的选择,不更新你没得用)。这样做可以有效的解决后台在更改新需求的同时，对之前版本的兼容问题。同时能够保证用户能够使用修复bug、以及新需求调整后的版本，方便用户使用。
强制更新的坏处
站在一个用户角度考虑,看到强制更新的app,感觉自己的自由被限制了，的确，毋庸置疑的一点事，强制更新牺牲了用户体验。
*强制更新的具体实施
app端需要在本地配置一个和后台约定好的参数,这里记为vCount，值为1.0。在app安装后第一次启动时,先请求一个检查checkVersion的接口,除了基本参数外，把vCount传过去。后台会根据vCount值去本地查看配置映射（此映射是后台来配置的） 。映射我们记为vCount = 1.0 <->version = 0.2.0，后台返回version为0.2.0。前端拿到后，和本地bundle version做比对，如果本地版本号为0.1.1则弹窗提示用户更新，点击更新跳转appstroe下载应用。
有以下两点需要注意:
一、后台的映射表是这样变化的
假设上线了3版记为 0.1.0 、0.1.1、0.2.0
那么保证正常更新，后台映射表应该是这样的:
1、上线0.1.0后,只有一条映射表 vCount = 0.1 <-> version = 0.1.0
2、上线了0.1.1后,应该有两条映射关系 vCount = 0.1 <-> version = 0.1.1
vCount = 0.5 <-> version = 0.1.1
这样才能保证0.1.0的用户,能够接收到更新提醒,同理那么下一版就应该如下
3、上线0.2.0后,应该有三条映射关系 vCount = 0.1 <-> version = 0.2.0
vCount = 0.5 <-> version = 0.2.0
vCount = 1.0 <-> version = 0.2.0
即所有版本记录中的version全部指向最新上线版本！以此类推！
二、前端做checkVersion这个接口请求的时候，需要注意不只需要在app第一次启动检查更新，还需要app从后台进入前台时检查！！
本文虽然是篇技术文章,由于此技术偏向于理解，逻辑较简单，就不贴代码！
网友评论