app应用内升级方案选型与优化

一.在app内做版本升级的几种方式:

1.是用应用内部使用的网络框架进行下载安装包

2.是调用系统的下载器进行下载

 

二.两种方式的优缺点比较:

1.框架下载:

优点:结合自己的需求,实现高度自由定制比如:监听下载进度,后台静默下载

缺点:下载速度慢,无法享用部分手机下载加速(如小米手机的迅雷加速)

 

实现代码:

 

2.下载器下载:

优点:可以享用手机系统下载器带来的便利,如小米手机的迅雷加速(速度很快)

缺点:无法监听下载进度(只能监听到下载任务是否完成,后面会优化),只要下载,通知栏会出现提示

实现代码:

 

 

 

三.下载器优化

前面优缺点比较的时候,说过了下载器是无法监听到下载进度的,只能监听到下载任务是否完成,基于上面的优缺点比较,我最初也是倾向于框架下载的,但是小米手机上的下载器下载有迅雷加速,那下载速度个人感觉体验很好,就因为不能监听下载进度而不考虑优点不甘,所以在不影响项目的进度的前提下,先实现了框架下载,作为备用,而后开始尝试下载器下载优化

通过代码可以看到,先创建了一个DownloadManager,给它传入我们要下载的安装包地址,然后紧接着构建状态栏展示的信息体以及文件下载路径,和进度监听的DownloadChangeObserver,

为了尽可能的节省手机资源,不提前浪费手机资源,所以我们已开始没有监听启动监听,我们已开始给它设置一个默认链接,当链接发生变化的时候,代表我们真正的下载业务开始了,所以在链接变化的时候,开始注册下载进度的监听,如下图:

 

由于我们上面的下载器监听已经创建并且注册了,那么,就来看看下载器的实现:

由于咱们的下载业务开始了,链接变化,所以会回调onChange方法,在这个方法里面,我们利用ScheduledExecutorService的定时功能,指定线程是progressRunnable,在这个子线程里面,我们可以做一些计算之类的耗时操作,

前面我downloadApk方法中,我们已经通过创建的系统下载器获取到了下载任务的id,所以,我们通过id可以定时查询下载任务的状态.看下图:

在子线程中计算好了这些数据,通过handler发送消息到主线程,然后通过接口回调,把我们需要的内容回调到下载页面,那么这样我们就实现下载器实时显示下载进度.

 

 

四 方案定型

经过上面的一番尝试下来,果断选择了下载器下载(毕竟天下武功,唯快不破,体验好!)