一种应用于android系统的系统文件下载方法及下载工具与流程

文档序号:12271052阅读:231来源:国知局
一种应用于android系统的系统文件下载方法及下载工具与流程

本申请涉及通信领域,尤其涉及一种应用于android系统的系统文件下载方法及下载工具。



背景技术:

在Android的开发过程中,下载部分是一个非常常用的功能。

目前的下载文件的方式,一般采用多线程并行处理多个任务的方式。而针对单个的下载任务,则是将单个下载任务(一个文件或一个压缩包)划分为几个部分,每一个部分采用一个线程进行上传或下载,如果碰到网络故障,可以从已经下载的部分开始继续下载未完成的部分,而没有必要从头开始下载。

但是目前这种下载任务的方式,如果需要续传下载任务,那么需要先采集涉及到该下载任务的每个线程上已下载的任务量,然后综合统计获得已下载的任务总量,获得已经下载的部分,然后继续开始下载。这种处理方式需要调用涉及到的每个线程进行统计,处理过程复杂,并且需要事先计算出任务总量才能够继续下载,若有线程在处理其他任务则可能需要转线程处理等等,进而导致断点续传时文件下载的效率低下。



技术实现要素:

本发明了提供了一种应用于android系统的系统文件下载方法及下载工具,解决或者部分解决了现有技术中断点续传时文件下载效率低下的技术问题。

为解决上述技术问题,本发明提供了一种应用于android系统的系统文件下载方法,包括:

从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务;

基于所述第一下载任务获取对应的下载参数;

基于所述第一下载任务的下载参数,判断所述系统文件的数据量是否超过预设数据量阈值;

若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中;所述系统文件的每批次数据量小于或等于所述预设数据量阈值;

当重新启动所述第一下载任务时,查找所述系统文件的下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分。

优选的,所述从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中,包括:

将所述系统文件按批次依次下载到所述移动终端的内存中,同时按照相应批次实时转移到所述存储器的文件目录中。

优选的,所述若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中,包括:

若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中,并实时更新所述系统文件的下载进度信息,所述下载进度信息用于记录所述系统文件的下载进度;

所述当重新启动所述第一下载任务时,查找所述系统文件的下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分,包括:

当重新启动所述第一下载任务时,调用所述下载进度信息查找所述下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分。

优选的,所述若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中,并实时更新所述系统文件的下载进度信息,所述下载进度信息用于记录所述系统文件的下载进度,包括:

利用接口实时通知所述下载进度信息给所述系统开发程序。

优选的,所述基于所述第一下载任务的下载参数,判断所述系统文件的数据量是否超过预设数据量阈值之后,包括:

若所述系统文件的数据量没有超过所述预设数据量阈值,从所述线程池中选取所述第一线程将所述应用于android系统的系统文件下载到所述存储器的文件中,并利用所述接口模块将下载结果通知给所述系统开发程序。

优选的,所述从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务之前,包括:

接收所述系统开发程序发送的携带有下载任务的下载请求;

从所述下载请求中获取对应的下载任务;

将所述下载请求对应的下载任务放入所述任务队列中;

使所述下载请求对应的下载任务和其他下载任务在所述任务队列中一并按照优先级顺序进行排序。

优选的,所述使所述下载请求对应的下载任务和其他下载任务在所述任务队列中一并按照优先级顺序进行排序,包括:

在所述任务队列中,按照三个等级的优先级对所有的下载任务进行排序;

在同一等级中,按照接收时间对同一等级的下载任务进行排序。

优选的,所述使所述下载请求对应的下载任务和其他下载任务在所述任务队列中一并按照优先级顺序进行排序之后,包括:

从所述任务队列中按照优先级获取包含有第一下载任务的N个下载任务,其中1≤N≤5;

从线程池中选取包含有第一线程的N个线程,同时处理各自对应的下载任务,且实时更新各自的下载进度信息;

将所述N个下载任务各自的下载进度通知给所述系统开发程序。

优选的,所述将所述N个下载任务各自的下载进度通知给对应的系统开发程序之后,包括:

判断所述N个线程中是否具有执行任务完毕的线程;

若有,则从所述任务队列中选取第二下载任务,并利用执行任务完毕的线程处理所述第二下载任务。

本发明公开了一种应用于android系统的系统文件下载工具,包括:

第一获取模块,用于从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务;

第二获取模块,用于基于所述第一下载任务获取对应的下载参数;

判断模块,用于基于所述第一下载任务的下载参数,判断所述系统文件的数据量是否超过预设数据量阈值;

第一选取模块,用于若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中;所述系统文件的每批次数据量小于或等于所述预设数据量阈值;

下载模块,用于当重新启动所述第一下载任务时,查找所述系统文件的下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分。

通过本发明的一个或者多个技术方案,本发明具有以下有益效果或者优点:

本发明公开了一种应用于android系统的系统文件下载方法,先从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务,然后基于所述第一下载任务获取对应的下载参数,并由此判断所述系统文件的数据量是否超过预设数据量阈值。若超过则表示系统文件的数据量过大,需要按批次传输。即便线程池中具有其他线程,也只使用第一线程处理该系统文件,而不会利用几个线程下载。另外,在下载时是将系统文件分成小于预设数据量阈值的多个批次,然后按批次依次下载到移动终端的存储器的文件目录中,进而在当重新启动所述第一下载任务时,由于本发明是按照批次依次下载,故而不用调用线程计算已完成的任务总量,能够按照批次便能够快速的寻找到系统文件的中断处,然后继续下载系统文件中未下载的部分,处理简单方便,能够提高断点续传的效率。

进一步的,本发明还记录并且实时更新了系统文件的下载进度信息,进而程序开发系统直接调用下载进度信息便可以获知系统文件已下载的任务量,进而快速的获知系统文件的中断处,然后继续下载系统文件中未下载的部分,处理简单方便,能够提高断点续传的效率。

另外,本发明还以接口的方式将所述下载进度信息实时通知给系统开发程序,由于接口调用方式简单且为一对一的通知,不会像广播会进行分发处理占用内存,故而即便系统占用率很高也能够保证进度通知的时效性。

进一步的,本发明将所述系统文件按批次依次下载到所述移动终端的内存之后,会实时将内存中的系统文件转移到存储器的文件目录中,因此能够使内存一直保持在空置状态,即便传输数据量大的系统文件也不会出现内存溢出的情况。

附图说明

图1为本发明实施例中应用于android系统的系统文件下载方法的流程图;

图2为本发明实施例中下载系统文件的具体实施过程图;

图3为本发明实施例中应用于android系统的系统文件下载工具的结构示意图。

具体实施方式

为了使本申请所属技术领域中的技术人员更清楚地理解本申请,下面结合附图,通过具体实施例对本申请技术方案作详细描述。

OOM:内存溢出(out of memory)通俗理解就是内存不够,通常在运行大型软件或游戏时,软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小,就叫内存溢出。

断点续传:将下载或上传任务(一个文件或一个压缩包)人为的划分为几个部分,每一个部分采用一个线程进行上传或下载,如果碰到网络故障,可以从已经上传或下载的部分开始继续上传下载未完成的部分,而没有必要从头开始上传下载。

线程池:线程池是一种多线程处理形式,处理过程中将任务添加到队列,然后在创建线程后自动启动这些任务。线程池线程都是后台线程。每个线程都使用默认的堆栈大小,以默认的优先级运行,并处于多线程单元中。

Url:统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示,是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的URL,它包含的信息指出文件的位置以及浏览器应该怎么处理它。

正则表达式:正则表达式,又称规则表达式。(英语:Regular Expression,在代码中常简写为regex、regexp或RE),计算机科学的一个概念。正则表通常被用来检索、替换那些符合某个模式(规则)的文本。

本发明设计了一种应用于android系统的系统文件下载方法以及下载工具,主要供系统(或者软件)开发者下载原始的系统文件,系统文件中主要包含开发系统程序时所用的系统数据。本发明的下载方法和下载工具主要应用在装载有Android系统的移动终端,而不用于装载有windows系统的设备。该下载工具可嵌入系统开发程序中,在系统开发程序需要下载系统文件时,可以直接调用该下载工具进行下载。这和普通的应用程序提供的下载方法是有区别的。具体来说,普通的应用程序比如‘XX雷’,面对的是普通用户。‘XX雷’的下载方式是通过访问URL地址下载图片、文档、视频等等数据。而本发明提供的应用于android系统(安卓系统)的系统文件下载方法以及下载工具面对的是系统(或者软件)开发者在开发程序时下载原始的系统文件。

下面请参看图1,是本发明应用于android系统的系统文件下载方法的实施过程图。

S1,从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务。

在具体的实施过程中,本发明设计了任务队列存储所有下载任务,并且对所有下载任务进行优先级排序管理。

在具体的实施过程中,本发明首先对下载任务预先定义了优先级等级,并将此优先级等级告知给系统开发程序(也即:android(安卓)系统开发程序),进而使系统开发程序在生成下载任务之后,可以给下载任务进行优先级的标定。本发明对优先级的标定可以是自定义标志。例如,定义了3个等级的优先级:低优先级low、普通优先级normal、高优先级high。

系统开发程序在发送下载请求时,会对下载请求中携带的下载任务进行优先级标定,例如低优先级low、普通优先级normal、高优先级high。在系统开发程序指定了下载任务之后,可以根据本发明定义的3个标志位,对下载任务进行优先级的标定,进而本发明在处理下载任务时,可根据标定的优先级按照顺序进行处理。如果不传递任何优先级默认为普通优先级。

在具体的实施过程中,从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务之前,本实施例包括:

接收所述系统开发程序发送的携带有下载任务的下载请求;

从所述下载请求中获取对应的下载任务;

将所述下载请求对应的下载任务放入所述任务队列中;

使所述下载请求对应的下载任务和其他下载任务在所述任务队列中一并按照优先级顺序进行排序。

而在具体的排序过程中,在所述任务队列中,按照三个等级的优先级对所有的下载任务进行排序;在同一等级中,按照接收时间对同一等级的下载任务进行排序。

在具体的实施过程中,在接收到下载任务之后,首先会将任务放入到下载队列中,对下载任务的优先级进行重新排序,将高优先级的下载任务排放在队列前段优先处理。将低优先级的下载任务排放在队列尾端最后处理。排列规则如下:

1、将高优先级的下载任务排列在队列的最前段,对所有高优先级的下载任务内部的排列规则是:按照接收高优先级的下载任务的接收时间的顺序来排列。

2、将普通优先级的下载任务排列在高优先级后,对所有普通优先级的下载任务内部的排列规则是:按照接收普通优先级的下载任务的接收时间的顺序来排列。

3、将低优先级的下载任务排列在普通优先级后,对所有低优先级的下载任务内部的排列规则是:按照接收低优先级的下载任务的接收时间的顺序来排列。

作为一种可选的实施例,在处理下载任务时,本发明应用于android系统的系统文件下载工具可以同时进行多任务处理,下面进行具体的介绍。

从所述任务队列中按照优先级获取包含有第一下载任务的N个下载任务,其中1≤N≤5。

从线程池中选取包含有第一线程的N个线程,同时处理各自对应的下载任务,且实时更新各自的下载进度信息。

将所述N个下载任务各自的下载进度通知给对应的系统开发程序。

而在所述将所述N个下载任务各自的下载进度通知给对应的系统开发程序之后,判断所述N个线程中是否具有执行任务完毕的线程;若有,则从所述任务队列中选取第二下载任务,并利用执行任务完毕的线程处理所述第二下载任务。

在具体的实施过程中,本发明利用了线程池来同时处理多个下载任务。

因为是请求下载多个下载任务,为了提高执行效率且不影响系统运行,本发明利用了线程池来管理线程,而不是简单利用一个单线程去处理所有的下载任务。当然,即便是利用了线程池并行处理多个下载任务,但是每个下载任务是对应一个线程独立处理,而不会将单个下载任务分成几份分别发送到不同的线程池处理。当某个线程处理完毕下载任务之后,才会启动处理其他下载任务。当然,若下载任务在处理的过程中中断,那么该线程则会等待,直到超过该下载任务的时限之后,才会启动处理其他下载任务。

考虑到Android系统的承载量,本发明的线程池同时开启的线程最多为5个,即最多可同时处理5个下载任务。

当多个下载任务请求处理的时候,则可利用线程池开启多个线程去同时处理,并且在处理完成后及时进行释放。

线程池在使用的过程中有多种模式可以选择,常见的几种模式如下:

newCachedThreadPool:创建一个可缓存线程池,如果线程池长度超过处理需要,可灵活回收空闲线程,若无可回收,则新建线程。

newFixedThreadPool:创建一个定长线程池,可控制线程最大并发数,超出的线程会在队列中等待。

newScheduledThreadPool:创建一个定长线程池,支持定时及周期性任务执行。

newSingleThreadExecutor:创建一个单线程化的线程池,它只会用唯一的工作线程来执行任务,保证所有任务按照指定顺序(FIFO,LIFO,优先级)执行。

为了提高线程的使用率且不太影响系统开销,我们选择了带有缓存功能的线程管理器newCachedThreadPool,我们设置线程最大任务数为5个,这样当下载任务过来的时候,最多可以同时执行5个下载任务一起工作,并且后续进来的任务不会开启新的线程会直接使用之前使用过的缓存线程。这样处理能够大大节省系统不断开启线程的资源损耗,也降低了垃圾回收器对无用资源回收的计算时间。

这种处理既提高了处理任务的效率,因为使用了缓存,可以重复利用缓存的线程,所以也不至于会对系统造成过大的压力,从而达到了一个比较好的平衡效果。

当然,即便多个线程同时处理多个下载任务,但是每个线程处理各自的下载任务的过程是相同的,下面介绍单个线程处理各自的下载任务的实施过程。

S2,基于所述第一下载任务获取对应的下载参数。

在具体的实施过程中,每一个下载任务都含有系统文件的信息,进而下载任务的参数主要如下:

1、文件下载地址。文件下载地址(例如系统文件的url)传递进来后,通过正则表达式工具过滤出最后一个字符串,将最后一个字符串作为文件的存储名称。

2、文件名称。

3、文件大小,这个是为了后期方便计算下载进度使用的。文件大小是读取系统文件的头部信息来进行获取的。通常计算机中的文件组成成分分为2部分,头部信息部分和内容部分。头部信息部分主要是记录文件的大小,编码,创建时间、修改时间等属性。内容部分就是文件所记录的内容信息。文件大小则通过获取文件的头部信息来获取。

S3,基于所述第一下载任务的下载参数,判断所述系统文件的数据量是否超过预设数据量阈值。

作为一种可选的实施例,所述基于所述第一下载任务的下载参数,判断所述系统文件的数据量是否超过预设数据量阈值之后,包括:

若所述系统文件的数据量没有超过所述预设数据量阈值,从所述线程池中选取所述第一线程将所述系统文件下载到所述移动终端的存储器的文件中,并利用所述接口模块将下载结果通知给所述系统开发程序。

S4,若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中;所述系统文件的每批次数据量小于或等于所述预设数据量阈值。

作为一种可选的实施例,系统文件会先下载到内存,然后转移到存储器的目录中。在具体的实施过程中,首先将所述系统文件按批次依次下载到内存中,同时按照相应批次实时转移到存储器的文件目录中。

将系统文件按照批次依次下载,是为了保证系统文件在断点续传时,能够快速的按照批次寻找到系统文件的中断处继续下载系统文件中未下载的部分,处理简单方便,能够提高断点续传的效率。

当然,本发明还可以在下载系统文件的同时,生成并更新系统文件的下载进度信息,所述下载进度信息用于记录所述系统文件的下载进度。

在具体的实施过程中,若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中,并实时更新所述系统文件的下载进度信息。故而当重新启动所述第一下载任务时,调用所述下载进度信息查找所述下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分。这样做的好处是,在当重新启动所述第一下载任务时,可以调用所述下载进度信息,从所述下载进度信息中快速查找到系统文件的中断点,以继续按批次依次下载所述系统文件中未下载的部分。

而在处理下载进度信息时,可以将所述下载进度信息转换为下载进度文件,并存储在所述存储器的文件目录中。将其生成文件,可以方便系统开发程序进行调用。

若所述系统文件的数据量超过所述预设数据量阈值,则读取小于预设数据量阈值的系统文件写入内存,然后判断系统文件是否超过预设数据量阈值,若超过则继续读取小于预设数据量阈值的系统文件写入内存,再次判断并重复处理,直到系统文件全部写入内存中为止。

在具体的实施过程中,具体流程设计如图2所示:

S21,开始下载系统文件,读取系统文件的下载参数。

S22,读取系统文件的头部信息(文件头部信息是文件本身具有的信息,其中记录了文件的描述信息,例如文件大小、文件创建时间、文件修改时间等)。

S23,基于预设数据量阈值判断系统文件的大小,即:判断系统文件的大小是否小于1M。

在具体的实施过程中,如果预设数据量阈值设置为1M,那么若系统文件的小于1M,那么执行S24:直接将系统文件全部读进内存中,然后将内存中的文件全部一次性写入存储器(该存储器可以是具有android系统的终端的存储器)中的文件目录中。

如果系统文件大于等于1M,因为在系统文件比较大的情况下不能一次性全部把文件读进内存中,如果全部读进内存中很有可能造成内存溢出异常(OOM),进而为了解决OOM异常的出现,针对大文件采取了分批读取的策略,即执行S25:每次获取1M的数据进内存中。执行S26:当内存中有1M的数据后,将1M的数据写入存储器中的文件目录中。重复执行S25,一直循环到系统文件读取完成。

在上一步的循环中,如果最后一次去读取有可能数据小于1M,在这种情况的时候,虽然数据会小于1M,但是会读取到文件结束的标识符。通过文件结束标示符就知道这个文件已经结束了。如果读取到结束文件标示符就会直接将内存中读取的数据写入到文件中去,这个时候整个文件读取过程就完成了。

每次当数据下载写入文件后,会立即更新下载进度信息。下载进度信息是保存在SD卡上的文件中,每次将一定数据写入文件后,则会立即更新下载进度信息中的已经下载字段的数据,这么处理是为了断点续传做准备的,假如下载到一半因为异常原因导致下载失败了,当再次重新开启下载的时候,则会首先去读取下载进度信息,从下载进度信息中发现该系统文件已经下载了部分数据了,则只需要向服务器请求文件后半部分的数据内容继续读取写入到原来文件中即可,这样就能够很好的保证断点续传功能的实现。需要注意的是,本发明的一个下载任务是通过一个线程去完成的,不会切换到其他线程去完成。即下载同一个系统文件,是通过一个线程去下载完成的,即便有多个线程,也不会转移给其他的线程去处理。也不会将系统文件分为几个部分,分别传给不同的线程去下载,这也是本发明和现有技术不同的区别所在。

若该下载任务由于外部原因导致中断没有完成,那么这个线程会暂停工作,直到超过规定时间仍然没有接收到继续下载的指令,那么该线程会启动其他下载任务。当然,若后续接收到重新下载该系统文件,则会继续从中断的部分继续开始下载。

另外,由于本发明将所述系统文件按批次依次下载到所述移动终端的内存之后,会实时将内存中的系统文件转移到存储器的文件目录中,因此能够使内存一直保持在空置状态,即便传输数据量大的系统文件也不会出现内存溢出的情况。

在实际的下载过程中,在将系统文件下载到内存中的同时,也会实时更新系统文件的下载进度,并实时的通知给给系统开发程序。因此,将系统文件转移到存储器的文件目录中的步骤,和更新下载进度信息的步骤是没有先后关系的。本发明可以先转移,后更新进度信息,且将进度信息通知给系统开发程序。也可以先更新进度信息并将进度信息通知给系统开发程序之后,再转移系统文件到存储器的文件目录中。

将系统文件按批次下载的同时,会实时更新系统文件的进度信息,系统文件的下载进度信息,包括但不限于是:文件名,文件下载地址,文件总大小,和已经下载文件的大小。另外,下载进度信息的计算方式也可以用百分比表示,例如:已经下载的部分除以总的文件大小得到下载的百分比,将这个百分比数据通过接口的形式通知给系统开发程序,这样系统开发程序就能够根据该百分比发送继续下载的下载指令,且本发明也可以根据该百分比继续下载系统文件未下载完成的部分。

本方案在将系统文件存储在存储器的文件目录时,可同时存储下载进度信息,例如,先将下载进度信息转为下载进度文件,然后存放在手机的SD卡目录上,进而为断点续传提供了参考,在重新启动第一下载任务之后,可以直接调用并根据下载进度文件中的下载进度信息继续下载,简单方便。

S5,当重新启动所述第一下载任务时,查找所述系统文件的下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分。

在继续下载时,处理过程和系统文件的已下载部分的处理方式相同,此处不再赘述。

作为一种可选的实施方式,本发明利用接口实时通知所述下载进度信息给所述系统开发程序,而放弃了广播的形式,是因为接口的时效性高,能够实时的通知系统开发程序。而若以广播的形式传送,系统语言会对广播进行分发处理,而分发处理过程会占用时间,如果系统占用率很高的时候分发处理过程就会很慢,无法对时效性进行保证。

本方案接口设计提供了3个功能。

onError(下载出现异常的时候通知外界错误)。

onSuccess(完成的时候通过外界完成)。

onProgress(下载进度更新的时候通知外界下载信息有更新)。

本发明通过定义了这3个接口,当程序执行过程中出现异常的时候,可调onError接口将信息告知系统开发程序出现异常,系统开发程序通过接口返回的数据就能够知道产生异常了。

当执行下载完成后会通过onSuccess接口将下载进度信息告知系统开发程序下载成功了,系统开发程序通过接口返回的数据就能够知道整个下载过程完成了。

当执行下载进度更新后会通过onProgress接口将下载进度信息告知系统开发程序当前进度,系统开发程序通过接口返回的数据就能够知道下载过程目前的进度信息了。

当系统文件下载成功之后就会通过接口的形式通知系统开发程序该系统文件下载成功,并可将下载成功的系统文件一并返回给系统开发程序。若系统文件因为异常情况下载失败的时候,这个时候会通过接口的形式通知系统开发程序下载失败了,并将失败原因通知给系统开发程序。

以上便是本发明公开的一种应用于android系统的系统文件下载方法,在具体的实施过程中,本发明能够支持多任务下载,线程池可以同时最多开启5个任务,支持最多5个任务同时下载。另外,本发明下载进度和下载状态能够实时反馈给系统开发程序,本方案中的文件下载状态的进度信息(下载量、下载百分比、下载批次数、下载失败、下载成功等等信息)都能够通过接口的形式将状态实时的反馈到系统开发程序,系统开发程序能够很方便的获取到下载的具体信息。进一步的,本发明下载任务具有优先级管理,例如使用了3种优先级,低、普通、高优先级,能够有效的对下载任务进行级别排序,能够优先响应高优先级的任务。进一步的,通过调用存储在存储器中的文件目录下的下载进度信息,便能够快速的寻找到系统文件的中断处继续下载系统文件中未下载的部分,处理简单方便,能够提高断点续传的效率。进一步的,本发明大文件下载,例如将文件进行分片每次下载1M的数据并写入文件,不是全部一次性读取到内存再一次性写入文件,所以能够在下载大文件的时候有效的避免内存溢出问题的产生。

基于同一发明构思,下面本发明介绍一种应用于android系统的系统文件下载工具。

参看图3,在本发明中的一种数据下载工具,包括:

第一获取模块31,用于从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务;

第二获取模块32,用于基于所述第一下载任务获取对应的下载参数;

判断模块33,用于基于所述第一下载任务的下载参数,判断所述系统文件的数据量是否超过预设数据量阈值;

第一选取模块34,用于若所述系统文件的数据量超过所述预设数据量阈值,从线程池中选取第一线程将所述系统文件按批次依次下载到存储器的文件目录中;所述系统文件的每批次数据量小于或等于所述预设数据量阈值;

下载模块35,用于当重新启动所述第一下载任务时,查找所述系统文件的下载中断点,从所述下载中断点继续按批次依次下载所述系统文件中未下载的部分。

通过本发明的一个或者多个实施例,本发明具有以下有益效果或者优点:

本发明公开了一种应用于android系统的系统文件下载方法,先从具有优先级排序的任务队列中获取系统开发程序发送的用于下载系统文件的第一下载任务,然后基于所述第一下载任务获取对应的下载参数,并由此判断所述系统文件的数据量是否超过预设数据量阈值。若超过则表示系统文件的数据量过大,需要按批次传输。即便线程池中具有其他线程,也只使用第一线程处理该系统文件,而不会利用几个线程下载。另外,在下载时是将系统文件分成小于预设数据量阈值的多个批次,然后按批次依次下载到移动终端的存储器的文件目录中,进而在当重新启动所述第一下载任务时,由于本发明是按照批次依次下载,故而不用调用线程计算已完成的任务总量,能够按照批次便能够快速的寻找到系统文件的中断处,然后继续下载系统文件中未下载的部分,处理简单方便,能够提高断点续传的效率。

进一步的,本发明还记录并且实时更新了系统文件的下载进度信息,进而程序开发系统直接调用下载进度信息便可以获知系统文件已下载的任务量,进而快速的获知系统文件的中断处,然后继续下载系统文件中未下载的部分,处理简单方便,能够提高断点续传的效率。

另外,本发明还以接口的方式将所述下载进度信息实时通知给系统开发程序,由于接口调用方式简单且为一对一的通知,不会像广播会进行分发处理占用内存,故而即便系统占用率很高也能够保证进度通知的时效性。

进一步的,本发明将所述系统文件按批次依次下载到所述移动终端的内存之后,会实时将内存中的系统文件转移到存储器的文件目录中,因此能够使内存一直保持在空置状态,即便传输数据量大的系统文件也不会出现内存溢出的情况。

尽管已描述了本申请的优选实施例,但本领域内的普通技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1