下载到最后回调两次99%但是接下来的任何进度 #631
Comments
|
06-26 16:49:39.308 9479-10094/com.wodi.who D/FileDownloader.MessageSnapshotGate: ~~~callback 342569507 old[3] new[3] 1 |
|
@Jacksgong 这个抓的最后暂停的log |
|
就是没有下载完成，应该是一直在下载，但是也没有触发超时暂停 |
|
@wanghaihui 这些日志无法定位到问题。我这边无法复现，可否贴下更全的完整的日志，顺便在遇到问题时在日志中输出上面提到的那几个数据。 P.S. 如果是超时，返回的是 |
|
06-26 17:11:09.187 2040-2040/com.wodi.who D/FileDownload: progress:99 |
|
@Jacksgong 这是打的几个数据，我感觉是有一个下载一直没完成，卡在那了 |
|
@wanghaihui 嗯，谢谢，不过这里要判断是否存在 不过根据你读取的status是 3，说明内部应该是还在下载，不存在已经完成了，还没有回调完成。 这样吧，你通过 需要注意的是一般的读写超时是15s左右，最后等待15s左右看看有没有超时的 |
|
FileDownloader.setupOnApplicationOnCreate(this).connectionCreator(new FileDownloadUrlConnection |
|
上面是配置 |
|
最后等待15s左右看看有没有超时的error回调---这个没有回调error |
|
这个问题不是必现，但是复现概率在oppo r9s上挺高的 |
|
@wanghaihui 可是我这边看不到所有下载服务（默认是再下载进程(:filedownloader)上)的所有日志诶。。。估计你是就贴了你主进程的日志。 我主要想看下载服务上面的日志，可否提供下 P.S. 或者是你通过在filedownloader.properties中配置 |
|
FileDownloadLog.NEED_LOG = BuildConfig.DEBUG; 我这样设置 可以吗？ |
|
|
这是filedownloader进程log |
|
@wanghaihui 谢谢，我们针对最后一次的任务来定位: 如日志，最后一次任务是:
启动了三个连接线程下载: 成功启动了对应的三个连接: 最终三个连接线程都下载完成: 整个流程都是正确的，并且最后也完成了下载。这个任务最后你没有收到
|
|
如果按这个分析的话，的确是正确的，但是我遇到的就是最后没调用completed，我再测试下 |
|
06-26 19:49:11.531 16991-17006/com.wodi.who:filedownloader D/FileDownloader.FileDownloadManager: request start the task with url(https://qiniustatic.wodidashi.com/cocos_update_melee_1.5.6.zip) path(/storage/emulated/0/Android/data/com.wodi.who/files/cocos//melee/cocos_update.zip) isDirectory(FALSE) |
|
这个是fileDownloader进程的log |
|
看起来好像是下载完成，但是的确 之后就没有调用completed |
|
// 执行下载过程 |
|
@Jacksgong 上面是下载的过程 |
|
@wanghaihui 谢谢，我看了你的代码这个是一个正常的使用场景，我在demo project中测试，始终无法复现。所以还需要你的协助:
|
|
06-27 12:38:55.774 26393-26404/com.wodi.who:filedownloader D/FileDownloader.FileDownloadManager: request start the task with url(https://qiniustatic.wodidashi.com/cocos_update_ball_1.5.7.zip) path(/storage/emulated/0/Android/data/com.wodi.who/files/cocos//ball/cocos_update.zip) isDirectory(FALSE) @Jacksgong 我按你的方式配了，不过貌似log没什么变化 |
|
@wanghaihui 你确定你是在 |
|
06-27 21:15:04.017 8252-8252/com.wodi.who:filedownloader I/FileDownloader.FileDownloadProperties: init properties 1 @Jacksgong 你看这样是开了吗？ 我的确是按照demo上来的， |
|
@wanghaihui 这样说名没有开诶。要输出的那个
|
|
@Jacksgong 停留在了progress的99，没调用到completed |
|
@wanghaihui 你升级到1.5.8，看看有没有修复你的问题。 |
|
@Jacksgong 还是会遇到，我不是一个下载链接来回测，我是多个链接下载，来回切换，会出现 |
|
@wanghaihui 你看看在demo project中看看会复现吗，我这边在demo project上始终复现不了。或者是可否编写一个可以复现的简单项目给我（可以发邮件给我 ( [email protected] )，或者push到github上给我)，然后我这边认真复现下看看什么问题。 |
|
@Jacksgong 我邮箱发你一个demo，你可以给看看，邮箱是[email protected] |
|
@wanghaihui 好的，多谢。我这两天抽空看下。 |
|
@Jacksgong 我还想问个问题，我两个apk都使用这个库时，第二个apk就安装不上了 |
|
@wanghaihui FileDownloader并没有做过跨app共享或者其他的事情，是一个符合Android规范的简单的lib，对于不同的apk同时使用该库，完全没有任何影响，这个应该是其他原因导致。 |
|
@wanghaihui 我找到你说的不同应用无法安装的原因了....是1.5.7引入的。一个broadcast权限的申明， 关注这个issue: #641 |
|
@wanghaihui 你的demo 4个按钮我下载下来在我的mi6上反复测试了一晚上都没有复现，明天我到公司借一台如你所说的vivo或者oppo试下。或者你加下我QQ(82780465)，什么时候你有空了，我远程看下日志，你给复现下可以吗？ |
|
@Jacksgong 恩 已经加你了，测试时清空下缓存数据，基本上来回三四次就会复现 我这里 |
|
而且再提供个思路 这个downloader进程的log，按理说这里代表下载完成，但是下面的log 所以就会一直卡在了完不成的界面，感觉是FileDownloadMessenger的问题，并没有notify |
|
07-05 16:23:48.619 2855-2855/com.conquer.manyouji D/FileDownloader.FileDownloadManager: request pause the task -14584498 @Jacksgong 还有遇到了这种情况 |
|
@Jacksgong 请问啥时候有时间呢？我打log定位了一下 在这个地方，出现99%的情况时，log如下： 此时，一共起了三个线程，第三个线程总会卡死在最后，所以完不成 |
|
@Jacksgong 好吧 我找到原因了 我这样打了下log，最后出现99%的log如下： downloadRunnableList.size() <= 0 这里永远也没走，所以allConnectionCompleted = false, 能不能给看看呀，还是我的写法有问题 |
|
@wanghaihui 谢谢哈，不好意思这两天有点忙，根据你新的日志信息我看看。 也十分欢迎PR。 |
|
@wanghaihui 挺奇怪的，QQ上聊先吧。 |
|
@wanghaihui 感谢你的配合🙏～ 已经找到原因，这个是一个多线程安全问题导致。 具体原因是多个分块线程同时完成下载回调到 深层原因翻看 public boolean remove(Object o) {
if (o == null) {
for (int index = 0; index < size; index++)
if (elementData[index] == null) {
fastRemove(index);
return true;
}
} else {
for (int index = 0; index < size; index++)
// 问题就出在当两个线程同时访问这段代码段时
// 假设第一个线程要移除的是0，第二个线程要移除的是1
// 假设队列数据是[0, 1, 2, 3]
// 异常情况一：当第二个线程刚遍历过0时，还没有开始对比1，
// 第一个线程刚好执行了fastRemove将0移除，
// 此时队列变为了[1,2,3]，就这样错过了需要移除的内容。
if (o.equals(elementData[index])) {
fastRemove(index);
return true;
}
}
return false;
}
private void fastRemove(int index) {
modCount++;
int numMoved = size - index - 1;
// 异常情况二：当两个线程都同时到达这里，此时第二个计算出来要移动的位置必然是错误的
if (numMoved > 0)
System.arraycopy(elementData, index+1, elementData, index,
numMoved);
elementData[--size] = null; // clear to let GC do its work
}解决方案保持 |
|
This is the thread-safe problem. ReasonThere are more than one connections to download one task on different threads, and when there are Digger causeRefer to public boolean remove(Object o) {
if (o == null) {
for (int index = 0; index < size; index++)
if (elementData[index] == null) {
fastRemove(index);
return true;
}
} else {
for (int index = 0; index < size; index++)
// when there are two threads working on here simultaneously
// It assume the data on this list is [0, 1, 2, 3].
// and assume the first thread want to remove '0', the second thread want to remove '1'
// problem one：when the second thread just check the '0' and it hasn't started to check '1'
// then the first thread is just executed the fastRemove method to remove '0' from the list
// so the list is changed to [1, 2, 3]，then the first thread miss chance to remove '1'.
if (o.equals(elementData[index])) {
fastRemove(index);
return true;
}
}
return false;
}
private void fastRemove(int index) {
modCount++;
int numMoved = size - index - 1;
// problem two: when the two threads are working on here simultaneously, then the numMoved value must be wrong for the next thread.
if (numMoved > 0)
System.arraycopy(elementData, index+1, elementData, index,
numMoved);
elementData[--size] = null; // clear to let GC do its work
}Solutionkeep |
@Gongcong @wanghaihui
多次返回的总进度相同这个是有可能的
因为回调是根据是否字节数有增加，而非整体的进度百分比，而具体配置体现在根据间隔/回调进度等配置进行回调。
但是根据你们( @Gongcong @wanghaihui ) 的描述:
似乎是怀疑下载完成了，但是没有回调
完成对吗？如果是，可以告知下当遇到这种特征情况时（如你们所说在第二次progress=99时):
FileDownloader.getStatus(id, path)返回的状态如何？FileDownloadUtils.getTempPath(task.getTargetFilePath())文件是否存在？task.getTargetFilePath()文件是否存在。P.S. 按照现有代码逻辑是不可能出现下载完成但不回调完成的。只有可能下载进程Crash?或者
error的回调，因此我比较倾向于是否是下载进程Crash或者是网络情况导致The text was updated successfully, but these errors were encountered: