简单的说。UpdatePlugin是一款可以让你任意作的、用于进行app更新的简单框架。为什么你会需要用此框架呢？
我们都知道，虽然app更新功能其实很简单：
访问更新接口api -> 与本地应用判断是否需要更新 -> 下载apk -> 安装。 so easy!
但是耐不住这世间有种叫做PM的生物，脑洞能突破天际的，就算一个app更新，都能给你玩出花来。老司机都懂的。。。当然也有各种技术原因。所以，这也是为啥这个框架能存在的主要原因。
话不多说。先上链接：github.com/yjfnypeu/Up…
原理
幸好虽然需求是多变的，但是基本流程还是一致的。所以，这也是UpdatePlugin的主要原理所在：
基于对更新流程的梳理，UpdatePlugin针对整个更新流程中，所有可能需要被定制的节点，都分别拆分出来了对应的接口。下方的流程图展示了各个节点以及其触发的顺序
可以看出，框架提供了非常强大的可定制性，目前提供的可定制接口已达到13个之多.
下面将向你展示出所有的可定制节点及其作用说明, 你可以结合上方的流程图。对照着进行查看。
- 网络任务
- CheckWorker:更新接口api网络访问任务
- 用于定制请求更新api接口的网络任务，支持使用同步&异步网络操作。
- DownloadWorker:文件下载任务
- 用于定制apk文件的下载网络任务。支持使用同步&异步网络操作。
- CheckWorker:更新接口api网络访问任务
- 回调通知
- CheckCallback:执行更新检查时的回调通知
- DownloadCallback:执行文件下载时的回调通知
- 此处的两个回调通知节点，主要用于将更新任务状态通知给用户。
- 界面通知
- CheckNotifier:有新版本需要下载时的通知提醒
- DownloadNotifier:文件下载时进度通知提醒
- InstallNotifier:文件下载完成启动安装任务前的通知提醒
- 此处的三个节点均为在更新流程中，需要被展示出来提醒用户以进行更新的UI通知节点。配合下方的更新策略节点。基本可以配置出任意的UI展示效果。
- 执行策略
- UpdateStrategy:更新策略
- 此接口用于定制更新时各节点通知的显示逻辑，即上方的三个界面通知的显示逻辑
- InstallStrategy:安装策略
- 此处用于提供给用户进行安装操作的定制，如当你使用热修复、插件化时，可在此针对热修复、插件化环境。有针对性的定制对应的安装策略即可。
- UpdateStrategy:更新策略
- 数据支持
- CheckEntity:更新接口api
- 更新数据api接口
- UpdateParser:更新接口数据解析器
- 解析更新api接口所返回的数据，并提供给框架内部使用
- UpdateChecker:更新数据检查器
- 用于对通过解析器所解析返回的实体类进行检查。判断是否需要进行更新操作。
- FileCreator:文件创建器
- 指定apk文件的下载路径
- FileChecker:文件检查器
- 对下载的文件进行安全性检查。避免出现下载文件与实际需要的文件不匹配的问题：如更新api接口被DNS劫持替换。
- CheckEntity:更新接口api
当然从这里看起来。好像太麻烦了。大部分的其实就只需要一个拿来就能用的就行了。所以框架对上面提供的接口节点。大部分都提供了默认实现。大部分用户都可以直接拿来后进行简单配置后直接使用。且经过长时间的维护。保证了稳定性：
// 创建使用的更新配置，此配置建议在Application中进行初始化
UpdateConfig.getConfig()
// url 与 checkEntity方法可任选一种填写，且至少必填一种。
// 数据更新接口数据，此时默认为使用GET请求
.setUrl(url)
// 类似url方法。CheckEntity方法可填写url,params,method。可在此设置为使用post请求
.setCheckEntity(checkEntity)
.setUpdateParser(new UpdateParser() {
@Override
public Update parse(String response) throws Exception {
/* 此处根据上面url接口返回的数据response进行update类组装。框架内部会使用此组装的update实例判断是否需要更新以做进一步工作*/
return update;
}
})
// 然后在启动页。启动后台更新任务(可选项)
// 后台更新逻辑为：当此更新任务检查更新失败、或者检查到当前无更新时：
// 延迟指定时间time(毫秒)后。重启更新任务。
UpdateBuilder.create().checkForDaemon(time);
// 在关于设置页面。点击检查更新时。进行前台更新
UpdateBuilder.create().check();
以上即是最简单的用法。
特性
最大的特性：非常强大的可定制性！且得益于此类设计，框架本身提供的默认实现中。也提供了非常多的友好的特性：
- 支持断点下载
- 支持Android 7.+ 应用安装方式
- 支持接入任意更新api
- 支持定制强制更新、忽略此版本更新逻辑
- 支持对apk进行安全检查，防止类似DNS劫持后被替换更新apk包的情况
- 支持指定apk下载文件地址
- 支持定制各种网络任务。适配更多网络使用场景
- 支持定制各种更新策略。比如默认使用的WIFI下默认直接下载后再通知更新，非WIFI下先通知更新再启动下载等。
- 支持定制安装策略。比如在插件化、热修复环境下进行定制使用
- 支持任意定制更新流程中的各种通知：检查到有更新时的通知、下载时的进度条通知、下载完成后安装之前的通知。
- 支持两种不同的文件校验方式：MD5文件验证或者PackageManager解析Apk验证。
若你有更多需要的特性。欢迎结合上方的可定制节点作用说明来进行灵活定制。
进阶
下面列出了一些你可能会感兴趣的问题：
-
如何快速定位问题？
你可以通过对控制台使用标签UpdatePluginLog进行日志过滤，以方便的进行快速问题定位：
-
如果我不需要进行api版本检查，而是直接从下载文件开始走流程可以吗？
这种情况虽然很少，但是有朋友的确遇到过...佩服一波脑洞...
这种情况。可以考虑直接创建出UpdateBuilder与Update对象。然后直接通过 Launcher.launchDownload(update, builder) 方法进行启动。
-
如何在热修复、插件化等其他环境下进行使用？
对于这种非正式的app更新操作。建议的做法是：对不同的运行环境，创建对应的不同的UpdateConfig实例提供使用，比如：
// 此为插件化环境。配置更新外置插件逻辑 UpdateConfig pluginUpdateConfig = // 使用createConfig创建一个单独的更新配置 UpdateConfig.createConfig() // 针对你当前的插件化环境进行各种接口定制配置 ... // 配置插件化环境下所需要使用的安装策略。 .setInstallStrategy(pluginInstallStrategy); // 保存好插件更新配置。并在插件化环境下需要下载对应插件的时候。启动插件更新任务 UpdateBuilder.create(pluginUpdateConfig)// 指定使用插件更新配置 .setUrl(pluginCheckUrl) .check();热修复、应用商城等的使用方式均类似。都创建一个自身的更新配置提供使用即可！
