scfhao

每播放一首歌都会产生一个缓存文件，如果这样自己指定目录，那这个目录就会越来越大，那就需要考虑清除缓存的问题了。

建议直接修改 SODownloader 类增加这样的功能

我认为程序没有必要主动删除tmp文件夹中的文件，正在下载中的文件是暂时保存在tmp文件夹下的，可以肯定的是系统会确保在App运行时不删除属于该App的tmp文件夹中的内容，当然关闭App后系统也不会自动清理，只有在需要清理（这个时机是由系统确定的）的时候这个文件夹中的内容才会被清理。 resumeData是一个字典序列化后的数据，这个字典中保存了下载相关的信息，其中也包括了对应的tmp文件的位置。resumeData有独立的版本（即`NSURLSessionResumeInfoVersion`），在版本1时，可以根据`NSURLSessionResumeInfoLocalPath`拿到 tmp 文件的完整路径，在后续几个版本中，只能通过`NSURLSessionResumeInfoTempFileName`拿到 tmp 文件的文件名，然后自行拼接得到完整的 tmp 文件路径，所以在目前的 iOS 版本上是可以做到 App 主动删除 tmp 文件的，但这个逻辑在后续的 iOS 版本上是否有效就无法得到保证了。

你好，感谢你的提交，我下载了你的resumeSave分支，在我的手机上运行了Demo，当我正执行一个下载任务时强制退出App，下次启动App后，下载进度还是从0%的地方开始的。你再试试？

还是回归代码吧，你的思路是通过注册 AFNetworking 中的`AFNetworkingTaskDidCompleteNotification `通知，我们看一下这个通知的发送时机，如下（AFURLSessionManager.m）: ```Objective-C dispatch_group_async(manager.completionGroup ?: url_session_manager_completion_group(), manager.completionQueue ?: dispatch_get_main_queue(), ^{ if (self.completionHandler) { self.completionHandler(task.response, responseObject, error); } dispatch_async(dispatch_get_main_queue(), ^{ [[NSNotificationCenter defaultCenter] postNotificationName:AFNetworkingTaskDidCompleteNotification object:task userInfo:userInfo]; }); }); ``` 上面的代码中可以看到...

更新一下我现在对这个功能的一些想法与大家探讨： 1. 该方案是在 AFNetworking 结束下载通知保存的下载进度，而之所以会有这个通知是因为在 applicationWillTerminate 通知方法中执行了cancelByProducingResumeData 方法，虽然这个地方的保存进度没生效，却导致了下载结束通知的发送。（只要把 applicationWillTerminate 通知方法注释掉，下载结束的通知也就收不到了） 也就是说在收到 applicationWillTerminate 通知后，cancelByProducingResumeData 方法确实执行了，只是取消方法中的异步block参数（保存进度）没有执行，但是 AFNetworking 的 failBlock 会执行，而之前的代码在 failBlock 中对 cancel 的情况忽略了，所以更好的方案是在这个 failBlock 中对由于 App关闭导致的下载取消情况进行保存进度。 2. 该方案会保存所有取消情况下的下载进度，这是不合理的。如果是用户操作的取消下载，不应该保存。 今年有些忙，所以一直没回复，以上是我的观点，不一定是正确的，欢迎继续探讨。 为方便交流 SODownloader...

先回答问题，用readonly是因为这个属性只有getter函数，没有setter函数，声明为readonly可以防止别人调用它的setter函数。 闪退可能是因为模拟器的原因，我在真机上没遇到过，具体的原因我现在也没找到。

@James-Geng @iOSleep 突然觉得有可能是因为楼主遇到的可能是同步队列死锁了，因为停在了`dispatch_async(self.synchronizationQueue, ^{}`block中的第一行，如果在SODownloader 内置的同步队列self.synchronizationQueue中执行`downloadItem:`等下载控制方法时，会发生死锁。 可能出现这个问题的情况是在KVO观察到 downloadItem 的状态发生变化后在相同的线程中又调用了下载控制方法。所以我建议在KVO的回调中仅做保存下载状态的事，不要在这里做多余的事。

@James-Geng 好的，我一般是在展示下载列表的viewController里对这两个keyPath进行KVO，在这样的viewController的dealloc方法中remove observer。

你之前不是说可以吗？你怎么确定不执行的？