【需求解决系列之四】Android App 在线 自动更新，android 观察者模式
使用方式和注意事项都在这里，点赞咱们就是好兄弟，[github.com/MZCretin/Au…](
)
Demo 体验
[Demo 下载](
)
扫描二维码下载 Demo：
效果预览
没有效果图的 demo 是没有灵魂的，没图你说个锤子哦！！！
过程分析与实现阐述
下面会对本次重构中的一些细节做些说明，但是不会提及到代码，既然已经提供了 demo，觉得好用的兄弟还是去看 demo 吧！
过程分析
整个更新的逻辑大致可分成三步：
获取更新信息，校验数据，确定是否需要更新
展示更新信息，处理更新逻辑
下载 Apk 文件，安装文件
用几句话描述就是：获取服务端最新的版本信息，最新 Apk 文件的下载路径，最新 Apk 文件大小信息，是否需要强更以及需要强更的版本号；对比当前 App 的版本信息，确定是否需要更新，确定是否需要强制更新；选择一个好看的样式展示这些信息；当用户点击更新按钮之后，检查本地是否已经下载好 Apk 文件，如果已经有下载好的文件，检查这个文件的大小和版本号是否与线上的 apk 的文件一致，不一致直接删除重新发起下载；另外本身如果没有下载完，会继续断点续传下载；获取到最终的安装文件之后，诱导用户去安装 Apk 文件并做好各个 Android 版本的兼容问题从而实现整个 App 的更新操作。
拆解分步阐述
获取更新信息，校验数据，确定是否需要更新
这里需要服务器端提供数据，我们需要知道当前生产环境中最新的版本是多少，通过这个最新的版本号，跟当前 app 的版本做比较，如果当前的版本要低于线上环境，则需要提示更新。
对于数据的获取也是一个比较头疼的问题，正常情况下应该都是直接请求一个接口，获取服务器端最新的版本信息，app 解析对应的字段数据；但是有些时候获取这些信息并不是通过接口来实现的，也可能只是一个云端 txt 文件，所以获取数据的方式不能太单一。
这里提供了两大类方式，一种是提供 api 接口地址，sdk 自主请求加解析；另外一种是直接提供解析好的数据给 sdk，sdk 直接处理更新逻辑，这种方式里面有两种小的方式，一种是提供数据源 model，另外一种是提供一个 json 字符串，交给 sdk 帮忙解析和处理。这样就可以满足大多数场景下的使用了。
展示更新信息，处理更新逻辑
当上一步确定需要更新之后，才会走到这一步。当确定需要更新之后，为了增强功能，我们提供了强制更新的逻辑，这种场景其实很常见，比如新版新增了一个功能，老版本无法做同步兼容处理，这个时候就需要老版本强制更新到最新的版本。
对于强制更新，我们还做了一个优化，可以对指定的版本强更，比如当前最新版本号为 10，我们希望老版本中版本号为 9 的强制更新，其他更老的版本普通更新，我们就可以指定需要强更新的版本号，实现指定版本强更。
对于展示更新信息来说，可能最大的痛点在于交互和样式，对于没有 UI 的朋友来说，可能怎么弄都觉得不好看，所以我们这里提供了 12 种 UI 样式，总有一个是你喜欢的吧！如果这 12 种你还是没有喜欢的，我们也提供了自定义 UI 的方式给你自己折腾。
下载 Apk 文件，安装文件
这一步可能就是核心了，有一些注意点以及优化的思路。
下载文件之前我们需要检查存储权限，并做好 Android6.0 以上申请存储权限的准备，
下载 Apk 文件使用的是 filedownloader，用这个的好处在于他本身支持下载失败的重试机制，断点续传的机制，以及网络切换自动重启下载等优点，对文件的下载比较友好。
下载文件还需要注意另外一点，我们在确定需要更新之后，在下载文件之前，我们需要检测下这个版本的 app 是否已经下载过了，如果下载过了就不要再重复下载了！对于是否下载好了有两个判断，一个对应这个版本的 apk 文件是否已经存在，第二个是这个 apk 文件的大小是否是正确的大小，因为有可能会出现文件下载异常的可能，这个时候需要删除掉这个 apk 去重新下载。
还有一点就是在下载文件之前我们还是需要友好的检测下网络环境，如果是数据流量，还是需要提醒下用户当前是非 wifi 环境，优化用户体验。
另外我们提供了通知栏进度的展示功能，默认是开启的，如果你不需要，可以在配置中关掉它。有这个通知栏的好处在于，当文件下载失败并重试三次依然失败之后，通知栏会显示下载失败，点击通知栏可以唤起重新下载的逻辑，仅此而已。当文件下载完成之后，我们需要处理的是 Apk 的安装问题，要注意 Android 不同系统版本之前的差异，并做好相关的兼容处理，我们已经兼容到 Android9.0 了，具体兼容细节大家移步源代码。结语
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论