Predidit

其实这部分代码已经写好并提交到仓库了，只是没有启用。 主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。 简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。 但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。 如果有什么好的解决办法，欢迎告诉我。

重新打开此问题以防止重复提问

> 我之前写过一个webdav同步的思路，不一定很好，可以作为参考，大概如下： > - 0.需要同步的数据，创建一张变动表，记录增删改的动作以及对应的变动值，webdav上同步一个变动表的json文件 > - 1.在webdav下创建一个lock.txt文件，在一台设备同步的时候，读取这个文件，当它有值，且值的时间戳在10分钟以内，跳过本次同步，之所以有个10分钟的判断，是为了防止有的设备因为一些问题没有同步成功，导致没有去删除这个时间戳，所以这个时间戳等同于一个带超时的锁 > - 2.在lock.txt没值或者时间戳超出十分钟的时候，往里面写入一个时间戳，并且开始同步：对变动表json进行遍历，与本地的变动表进行对比，如果有相同ID的变动操作，取最近的记录，同时在本地进行相应的增删改操作，并把本地的变动表合并后生成新的json上传到webdav，同时删除lock.txt的值 > - 3.为了避免长时间积累下的json文件过于庞大，新增一个覆盖同步的按钮，这个按钮会清空json内容，并且生成一条删除所有记录的变动，然后创建一个新增本地当前数据的记录，覆盖webdav的json文件 > > 然后缓存的问题，我之前是没有遇到，或许可以试试前面朋友提到的地址加参数的方案？回头我抽时间看看代码，看看有没有办法提供一些帮助 好完整的方案，思路真的非常棒，变动记录应该可以解决大部分问题，我看看怎么实现。如果你对本项目感兴趣的话，可以PR吗。

我正在 @dujianchi 观点的基础上进行原型设计，但是还是遇到了一些问题 我打算只维护变动表而不考虑锁，因为我们需要较高频率的自动同步 这里有一个难以解决的问题，当同时多台设备修改追番列表时将出现竞态 我们将需要在每次修改本地列表前拉取云端变动表以确定云端没有新的变动，这样才能防止在本地生成新变动表并同步到云端，导致云端已有但还没同步到本地的变动丢失 这相当耗时，让每次同步变得缓慢

我想我已经完成了初步的工作和测试 @ErBWs @xxfttkx 可以帮忙在现在的主分支上测试 webDav 同步追番列表的功能吗 除了可能的 bug 之外有如下两个问题 1. 当前的同步设置选项卡非常杂乱，也许我们需要重新设计。追番页面的同步按钮的视觉效果也需要优化 2. 确认可能的运营商缓存的影响

这个报错是正常的，因为第一次同步时云端没有文件。我花了相当多的精力处理这些特殊情况，应该可以正常工作，但是报错被保留以方便调试。 由于同步的步骤很多，耗时很长，我不是很想使用 showloading 。

可以，同步追番的函数封装得很好。 我最终没能实现自动追番同步，同步一次的耗时阻止了我们这样做。追番同步相关开关是为了在未设置相关 webdav 凭据时给出干净的错误提示，但感觉确实可以和 webdav 开关合并。

支持追番列表同步的 1.5.5 版本已经发布

我们没有做过测试，所以并不知道你的感觉是不是正确的，可以的话，你可以做一下对比发在这里。 视频播放器硬件解码时调用 Android Exoplayer 符合最佳实践，问题应该不在播放器，可能是弹幕的实现方式比较消耗性能，但是我不能确定。

之前的弹幕实现有问题，关闭弹幕也会有绘制开销 现在版本都到 1.6.0 了，已经没有这个问题了 不过如果你开超分辨率和弹幕，耗电快是正常的