一、设计流程
上述策略的优缺点如下:
策略优势:灵活控制各个历史版本的升级方式,可以指定修复相应的历史版本,不会操成大规模的“误伤”;
策略劣势:每次发版都需要对历史版本进行状态修改,如果接口变动对历史版本产生影响,需明确出对那些历史版本有影响,也就要求了上传新版本的PM需要对历史版本有重新的了解。
二、具体实现
1. 配置升级的json文件
设计思路:拆分最新版本和历史版本,再分别拆分Android平台和iOS平台,采用读取文件的方式获取版本信息。
- 拆分成两个节点,一个latest表示最新版本,各个平台需要更新的内容。一个history表示历史版本,用于获取历史版本的信息。
- 历史版本以版本号为key,结构清晰。
- 拆分两个平台,防止出现各个平台出现不同地方的优化。
- 其中must节点:0 表示不强制更新,1 表示强制更新。
- config:表示通用配置信息。
{
"latest": {
"android": {
"version": "最新应用版本号",
"name": "应用名称",
"url": "应用下载地址",
"must": "1",
"desc": "新增强制更新|优化用户体验"
},
"ios": {
"version": "最新应用版本号",
"name": "应用名称",
"url": "下载地址t",
"must": "1",
"desc": "新增强制更新|优化用户体验"
},
"config": {
"logFlag": "1"
}
},
"history": [
{
"历史应用版本号": {
"android": {
"version": "历史应用版本号",
"name": "应用名称",
"url": "应用下载地址",
"must": "0",
"desc": "优化了部分操作流程,更加快捷|修复业务bug"
},
"ios": {
"version": "历史应用版本号",
"name": "应用名称",
"url": "应用下载地址t",
"must": "0",
"desc": "优化了部分操作流程,更加快捷|修复业务bug"
},
"config": {
"logFlag": "1"
}
}
}
]
}
2. 代码实现逻辑
用到的插件
- Device
平台判断 - AppVersion
本地版本获取 - FileTransfer
文件下载 - FileOpener
安卓apk打开 - Diagnostic
权限申请
检查更新代码逻辑
- 从服务器拉取更新文件,获取所有版本信息
- 通过AppVersion 获取本地版本号,在服务器版本文件中的history节点中获取对应的本地版本信息。
- 从配置文件中latest节点获取最新版的信息,分别是Android和iOS平台的版本信息。
- 根据Device插件获取平台,分别取latest节点中的版本信息,分别跟本地的版本信息做比对,如果不一致,则需判断获取到的本地版本信息的must节点,如果为0表示不需要强制更新,如果为1则需要强制更新。
更新代码逻辑
- 根据Device插件获取平台
- Android平台需要Diagnostic动态申请相应权限,如果有相应的权限,则可以正常下载,否则提示异常
- iOS平台也需要相应的权限,请在项目的plist文件申请即可。
至此基于ionic的对应版本实现是否强制更新方案设计完成,希望道友们玩的愉快。