android项目中，不可避免会下载一些第三方应用，或者自身更新的包，或者下载视频文件，那么都会考虑用到断线续传的方式。
那么，断电续传的方式大概有3种：
1.比如下载视频的时候，调用js的方法，把文件下载下来，然后用randomAccessFile合并成一个文件。
2.如xUtils的断点续传代码，具体自己看。
3.利用sqlite，配合上randomAccessFile来实现。
第一种主要是用于下载视频，为啥呢，因为考虑到网络问题之类的，频繁的断点和续传，有概率性出现花屏等，用后面2中会出现这种问题，而前者没，而缺点是如果不会写js或者没后台工程师帮忙就不行了。
第二种和第三种的优劣性表面上可以形容为xutils的断线续传为根据文件大小就可以判断下一次的起始位置，而且下载的文件大小都可以通过eclipse中查看文件的地方看得到实时的增长。
第三种的方式可以形容为文件的大小从开始就定死了，而且会多一个数据库的调用，不考虑同步问题的话很容易出现数据库读取异常的问题，优点就是逻辑简单。
那么，坑有哪些呢？
1.网络异常，也就是自己手动断网，模拟路由或者wifi中断的情况。
xutils和randomAccessFile并没考虑到这种问题，会出现流等待网络正常才继续读取的情况，看似没事，但是实际上会大概率出现文件大小异常，拉文件出来不是解析不了就是视频花屏的情况。
2.频繁断点（几十次，10次以下概率性极小）。
xutils的情况还好。但是对于项目而言，能不使用第三方包就不用，因为实用第三方包的话不能排除第三方包有后门的问题。
而使用randomAccessFile的话，频繁断点，会有小概率的异常事件，不外乎2种：
1）文件大小异常。
2）文件解析异常。比如apk文件，正常的话可以在文件管理器看到一个有自己logo的apk，而失败会出现解析包失败，logo为android本身的logo
解决的方法很简单。
就是在进度大于等于100%时，读取当前apk文件的MD5值，也就是根据MessageDigest来获取并转换为md5值，再与网络获取的md5比较。
如果正常则打开文件，失败则直接重新下载。
当然还要看自己的具体情况来实现这个功能，下载文件大，或者文件为视频，应考虑使用项目内嵌js的方式，由js来实现暂停或者继续下载的功能，项目小可以直接考虑xutils，当出现网络异常的情况直接通过广播来手动控制暂停，网络正常才继续下载这个文件，从而减少异常情况的出现。
谢谢！