UpdatePlugin:轻松定制出属于你自己的app更新神器

简单的说。UpdatePlugin是一款可以让你任意作的、用于进行app更新的简单框架。为什么你会需要用此框架呢？

我们都知道，虽然app更新功能其实很简单：

访问更新接口api -> 与本地应用判断是否需要更新 -> 下载apk -> 安装。 so easy!

但是耐不住这世间有种叫做PM的生物，脑洞能突破天际的，就算一个app更新，都能给你玩出花来。老司机都懂的。。。当然也有各种技术原因。所以，这也是为啥这个框架能存在的主要原因。

话不多说。先上链接：github.com/yjfnypeu/Up…

原理

幸好虽然需求是多变的，但是基本流程还是一致的。所以，这也是UpdatePlugin的主要原理所在：

基于对更新流程的梳理，UpdatePlugin针对整个更新流程中，所有可能需要被定制的节点，都分别拆分出来了对应的接口。下方的流程图展示了各个节点以及其触发的顺序

可以看出，框架提供了非常强大的可定制性，目前提供的可定制接口已达到13个之多.

下面将向你展示出所有的可定制节点及其作用说明, 你可以结合上方的流程图。对照着进行查看。

• 网络任务
  • CheckWorker:更新接口api网络访问任务
    • 用于定制请求更新api接口的网络任务，支持使用同步&异步网络操作。
  • DownloadWorker:文件下载任务
    • 用于定制apk文件的下载网络任务。支持使用同步&异步网络操作。
• 回调通知
  • CheckCallback:执行更新检查时的回调通知
  • DownloadCallback:执行文件下载时的回调通知
    • 此处的两个回调通知节点，主要用于将更新任务状态通知给用户。
• 界面通知
  • CheckNotifier:有新版本需要下载时的通知提醒
  • DownloadNotifier:文件下载时进度通知提醒
  • InstallNotifier:文件下载完成启动安装任务前的通知提醒
    • 此处的三个节点均为在更新流程中，需要被展示出来提醒用户以进行更新的UI通知节点。配合下方的更新策略节点。基本可以配置出任意的UI展示效果。
• 执行策略
  • UpdateStrategy:更新策略
    • 此接口用于定制更新时各节点通知的显示逻辑，即上方的三个界面通知的显示逻辑
  • InstallStrategy:安装策略
    • 此处用于提供给用户进行安装操作的定制，如当你使用热修复、插件化时，可在此针对热修复、插件化环境。有针对性的定制对应的安装策略即可。
• 数据支持
  • CheckEntity:更新接口api
    • 更新数据api接口
  • UpdateParser:更新接口数据解析器
    • 解析更新api接口所返回的数据，并提供给框架内部使用
  • UpdateChecker:更新数据检查器
    • 用于对通过解析器所解析返回的实体类进行检查。判断是否需要进行更新操作。
  • FileCreator:文件创建器
    • 指定apk文件的下载路径
  • FileChecker:文件检查器
    • 对下载的文件进行安全性检查。避免出现下载文件与实际需要的文件不匹配的问题：如更新api接口被DNS劫持替换。

当然从这里看起来。好像太麻烦了。大部分的其实就只需要一个拿来就能用的就行了。所以框架对上面提供的接口节点。大部分都提供了默认实现。大部分用户都可以直接拿来后进行简单配置后直接使用。且经过长时间的维护。保证了稳定性：

// 创建使用的更新配置，此配置建议在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();
复制代码

以上即是最简单的用法。

特性

最大的特性：非常强大的可定制性！且得益于此类设计，框架本身提供的默认实现中。也提供了非常多的友好的特性：

1. 支持断点下载
2. 支持Android 7.+ 应用安装方式
3. 支持接入任意更新api
4. 支持定制强制更新、忽略此版本更新逻辑
5. 支持对apk进行安全检查，防止类似DNS劫持后被替换更新apk包的情况
6. 支持指定apk下载文件地址
7. 支持定制各种网络任务。适配更多网络使用场景
8. 支持定制各种更新策略。比如默认使用的WIFI下默认直接下载后再通知更新，非WIFI下先通知更新再启动下载等。
9. 支持定制安装策略。比如在插件化、热修复环境下进行定制使用
10. 支持任意定制更新流程中的各种通知：检查到有更新时的通知、下载时的进度条通知、下载完成后安装之前的通知。
11. 支持两种不同的文件校验方式：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();
  复制代码

  热修复、应用商城等的使用方式均类似。都创建一个自身的更新配置提供使用即可！