先说说断点续传的原理：这是HTTP 1.1协议的一部分，并不需要客户端特意去做多么复杂的事情。以前我曾经看过一个单位的技术标书，其中有下载的断点续传这一要求，给出的offer居然还挺高的...

简单的说，只要利用了HTTP协议(http://www.ietf.org/rfc/rfc2616.txt)中的如下字段来和服务器端交互，就可以实现文件下载的断点续传：

Range : 用于客户端到服务器端的请求，可通过该字段指定下载文件的某一段大小，及其单位。典型的格式如：

Range: bytes=0-499 下载第0-499字节范围的内容

Range: bytes=500-999  下载第500-999字节范围的内容

Range: bytes=-500  下载最后500字节的内容

Range: bytes=500-  下载从第500字节开始到文件结束部分的内容(这是最常用的一种格式)

Range: bytes=0-0,-1  下载第一以及最后一个字节的内容(这个看上去有点变态...)

Accept-Ranges : 用于服务器端到客户端的应答，客户端通过该字段可以判断服务器是否支持断点续传(注意RFC中注明了这一部分并不是必须的)。格式如下：

Accept-Ranges: bytes  表示支持以bytes为单位进行传输。

Accept-Ranges: none  表示不支持

Content-Ranges : 用于服务器端到客户端的应答，与Accept-Ranges在同一个报文内，通过该字段指定了返回的文件资源的字节范围。格式如下：

Content-Ranges: bytes 0-499/1234  大小为1234的文件的第0-499字节范围的内容

Content-Ranges: bytes 734-1233/1234  大小为1234字节的文件的第734-结尾范围的内容

据此我们可以知道，断点续传这个功能是需要客户端和服务器端同时支持才能完成。

Android平台面向开发者提供了DownloadManager这个服务(service)，可以用来完成下载，同时异步地得到下载进度的实时更新提示。原生的浏览器，Android Market以及GMail等客户端都使用了该接口。该接口也部分的提供了断点续传功能：如果在下载过程中遇到网络错误，如信号中断等，DownloadManager会在网络恢复时尝试断点续传继续下载该文件。但不支持由用户发起的暂停然后断点续传。

要扩展该功能也不难，只要为下载任务新增一种状态(类似paused_by_user)，以及相关逻辑即可，这里暂不赘述，把话题引到一些常见问题上。

1. 关于ETag

RFC中的定义有些抽象，简单的说，ETag可以用来标识/保证文件的唯一性或完整性，你可以把它看作是服务器为某个文件生产的唯一标识值，每次文件有更新该值就会变化。通过这种机制客户端可以检查某个文件在断点续传(当然它不仅仅用于断点续传)的前后是否有所改动：如果ETag改变了就应该重新下载整个文件以保证它的完整性。

但是在现实环境中，有一些服务器并不返回ETag字段，同时它又是支持断点续传的，这种情况下原生的Android就会认为服务器端不支持断点续传。这应该不是什么bug，仅仅是这么实现而已。还有更麻烦的情况是，有些服务器给了错误的ETag，但文件是从未更改的，这时候要想从客户端修改这个“bug”，估计只能忽略ETag值了。

2. 关于HTTP 206

RFC中定义了断点续传时服务器端的应答情况：如果支持且返回的内容如请求所要求的那样，是该文件的一部分，则使用HTTP 206状态码；如果不支持，或需要返回整个文件，则使用HTTP 200状态码。但是现实网络中有些服务器不管三七二十一，都返回200。没办法，如果还是想从客户端来修改这个“bug”，那就多做一些判断处理吧：如果服务器指定了“Content-Ranges”，就忽略HTTP 200的状态码。

附图一张，简述流程。见附件

补记：有一次被问起如何在原生的Android手机上暂停一个下载任务，回头再断点续传。我想是不是可以在下载过程中将手机信号关闭，下次再打开手机信号时，那个下载任务就可以自动接着续传了(当然前提是服务器支持)...这个用例没多大实用价值，懒得实测了