Ehviewer
Ehviewer copied to clipboard
Ehviewer-Overhauled
已下载画廊实现增量更新 | Incremental updates for the downloaded gallery
需求 / Requirement
现在有大量 Pixiv / Fanbox / DMM.com 类的画廊，是一直处于动态更新的。 对有新版本的画廊实现增量更新，而非全新下载，减少下载量和 image limit 消耗。
看到一个有相关的需求 #474 ，我在里面提到了这个问题。但是那个问题和这个的内容并不太一样，所以决定开一个独立的 issue。
目前手动实现的增量更新
下载新画廊一两张图就停止，可以得到有所有图片 hash 的.ehviewer文件，然后手动把旧画廊文件夹内的图片剪切到新画廊里。到新画廊点击开始下载，这样就可以直接跳过前面几千张图片，只下载最后面的图片。
但是新图片加在前面的，图片数字会全部后移，就不能这样操作了（手机上不好批量重命名）。
建议实现 / Suggested implements
底层实现
新画廊先生成.ehviewer文件，然后在旧画廊的.ehviewer文件内，查找相同 hash 的图片，并 移动/复制 到新画廊，再开始新画廊的下载。可以按需删除旧画廊。
操作逻辑
- 在旧画廊选择版本的地方，加上一个更新按钮。点击后询问是增量更新，还是保留旧画廊。如果保留旧画廊，新画廊也没必要全新下载，可以复制旧画廊的相同图片过去。
- 下载任意画廊时，都检索是否存在旧画廊，并迁移 / 复制。
- 下载面板的全部开始下面，加入检查画廊更新，然后将全部有更新的画廊更新到最新版本。
- 增量更新的画廊，当前阅读页保持 hash 一致，这样大部分情况下不丢失阅读进度。
同理下载 Image Set 大分类的时候，甚至可以搜索所有画廊，因为一些 Image Set 只是美图集合，会包含其他画廊内的图片。但是这个几率不大，不是必须考虑。
备注 / Addition details
这个功能可能会和以归档为主体的下载逻辑有冲突。 https://github.com/Ehviewer-Overhauled/Ehviewer/issues/429#issuecomment-1320916855
建议归档下载后也解压成独立图片文件，以实现增量更新。
EhViewer 版本号 / EhViewer version code
1.8.4.0-alpha01
EhViewer CI 版本 / EhViewer CI Version
https://github.com/Ehviewer-Overhauled/Ehviewer/actions/runs/3638887754
自查步骤 / Verify steps
- [ ] 如果您有足够的时间和能力，并愿意为此提交 PR ，请勾上此复选框 / Pull request is welcome. Check this if you want to start a pull request
- [X] 您已仔细查看并知情 Q&A 中的内容 / You have checked Q&A carefully
- [X] 您已搜索过 Issue Tracker，没有找到类似内容 / I have searched on Issue Tracker, No duplicate or related open issue has been found
- [X] 您确保这个 Issue 只提及一个功能。如果您有多个功能请求，烦请发起多个 Issue / Ensure there is only one feature request in this issue. Please make mutiply issue for mutiply feature request
- [X] 您确保已使用最新 CI 版本测试，并且该功能在最新 CI 版本中并未按照预期实现 / This feature don't implement correctly in latest CI version
因为以后所有的下载内容都会以压缩包存储，用libarchive 去实现原地更新压缩包代价会很大。 增量更新的画廊内容有什么规律吗？比如新增的图片全部位于头部/尾部，这样我可以考虑将所有新增的图片放到另一个压缩包里；如果一点规律也没有，我应该也可以考虑生成一个页码与实际位置映射文件。
增量更新的画廊内容有什么规律吗？
可能 old to new 可能 new to old，在这基础上可能还会留封面，但主要是看上传者怎么想的
增量更新形式
更新的画廊，是会生成一个新文件夹的
示例A：
在末尾新增图片，.ehviewer差异仅为头部和末尾的新增图片
示例B：
在头部新增图片，.ehviewer差异除了头部，后面的图片序号全部变化
重新排序
编辑画廊时是可以进行排序的。有些人最开始上传的时候没有注意顺序，上传的是乱的。后来只是重新编辑了文件顺序，会导致所有图片的序号改变但是文件不变。 这种只能以 hash 一一对应到新的序号。
关于压缩包储存
不知道你们考虑压缩包储存的原因，我个人反对以压缩包存储。 本身jpg(有损)、png(无损)都是已经压缩过的，再压一遍不能节约空间，反而会造成严重的性能问题。 很多时候并不是一张一张慢慢阅读漫画，而是飞快的不断点击下一张CG直到贤者模式。性能问题会造成很大的阻碍。 但是我赞成以官方的 Arichive Download 下载免费配额的压缩包，然后解压为图片文件，按照传统形式管理。
同时还需要考虑使用外置 microSD 卡来当作下载储存位置的，我专门买的 128G 卡就存图片。 缺点：速度慢于内置 UFS，但是当时我的手机还是 EMMC 优点：
- 不占用手机储存，不消耗储存芯片寿命
- 可迁移，我同一张卡经历了Sony XZs、LG v35、两台LG v40。中间手机坏了没法导出数据，我直接在新手机从卡里恢复数据就是了（顺序会变）。
- 可直接在Windows上编辑和看图。同时换卡也很方便，现在的数据可以往前追述到 LG G4、LG G3上的64G卡。
用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理
用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
就算是归档，如何解决使用其他阅读器直接看的问题。毕竟看漫画时其他专业漫画阅读器使用体验可以更方便。
先下载到缓存 等全下完再一起压
用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
就算是归档，如何解决使用其他阅读器直接看的问题。毕竟看漫画时其他专业漫画阅读器使用体验可以更方便。
大部分漫画阅读器都支持cbz归档
用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？ 就算是归档，如何解决使用其他阅读器直接看的问题。毕竟看漫画时其他专业漫画阅读器使用体验可以更方便。
大部分漫画阅读器都支持cbz归档
正如我前面提到，我是使用外置SD卡来储存，并可能在Windows上读卡直接看内容的。还是希望留一个保留图片文件的 fallback
用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？ 就算是归档，如何解决使用其他阅读器直接看的问题。毕竟看漫画时其他专业漫画阅读器使用体验可以更方便。
大部分漫画阅读器都支持cbz归档
正如我前面提到，我是使用外置SD卡来储存，并可能在Windows上读卡直接看内容的。还是希望留一个保留图片文件的 fallback
那也行 像tachiyomi那样做一个开关 不过默认开启 不过对于非压缩包式读取我不会再提供任何效率优化了
先下载到缓存 等全下完再一起压
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
不知道你说的先下载到缓存是专门的cache还是原来的下载路径。这么多年积累，我有几百没下载完的画廊，文件夹里都是部分图片，哪怕换了手机我随时可以续传。如果下载到专门的cache没下载完不就浪费了吗。
先下载到缓存 等全下完再一起压
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
不知道你说的先下载到缓存是专门的cache还是原来的下载路径。这么多年积累，我有几百没下载完的画廊，文件夹里都是部分图片，哪怕换了手机我随时可以续传。如果下载到专门的cache没下载完不就浪费了吗。
不过事实也是libarchive 这个库不支持对压缩包的修改 只能重新创建 所以没法做到断点续传这种功能 至于最后怎么实现我再考虑
先下载到缓存 等全下完再一起压
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
不知道你说的先下载到缓存是专门的cache还是原来的下载路径。这么多年积累，我有几百没下载完的画廊，文件夹里都是部分图片，哪怕换了手机我随时可以续传。如果下载到专门的cache没下载完不就浪费了吗。
不过事实也是libarchive 这个库不支持对压缩包的修改 只能重新创建 所以没法做到断点续传这种功能 至于最后怎么实现我再考虑
只是为了速度何必用压缩库，直接自己把所有文件连接成一个二进制文件，新增的直接在后面增加，单独存一个json储存页码图片的二进制偏移。
先下载到缓存 等全下完再一起压
还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？
不知道你说的先下载到缓存是专门的cache还是原来的下载路径。这么多年积累，我有几百没下载完的画廊，文件夹里都是部分图片，哪怕换了手机我随时可以续传。如果下载到专门的cache没下载完不就浪费了吗。
不过事实也是libarchive 这个库不支持对压缩包的修改 只能重新创建 所以没法做到断点续传这种功能 至于最后怎么实现我再考虑
只是为了速度何必用压缩库，直接自己把所有文件连接成一个二进制文件，新增的直接在后面增加，单独存一个json储存页码图片的二进制偏移。
不过像你说的 这样别的漫画阅读器就不能读取了 cbz这个标准是通用的
不过像你说的 这样别的漫画阅读器就不能读取了 cbz这个标准是通用的
用别的漫画阅读器我选择直接用非压缩图片文件，这样能保持最大兼容性。每个文件夹对应一个漫画。
如果你用压缩包储存，还得把压缩包移到父文件夹去，不然其他漫画阅读器不能直接访问下一个作品吧。
不过像你说的 这样别的漫画阅读器就不能读取了 cbz这个标准是通用的
用别的漫画阅读器我选择直接用非压缩图片文件，这样能保持最大兼容性。每个文件夹对应一个漫画。
如果你用压缩包储存，还得把压缩包移到父文件夹去，不然其他漫画阅读器不能直接访问下一个作品吧。
非压缩图片文件如果是在app自己的空间那没事 如果是在Android saf框架下会有严重的性能问题 之前说的 fuse的锅
综上cbz还是最好的解决方案 除了要实现增量更新代价会相对大一点
电脑上我用7-zip的时候，往zip里新增文件挺快的。往里面加了一个文件，发现二进制也只是有部分内容改变。是不是该重新找一个库。
综上cbz还是最好的解决方案 除了要实现增量更新代价会相对大一点
电脑上我用7-zip的时候，往zip里新增文件挺快的。往里面加了一个文件，发现二进制也只是有部分内容改变。是不是该重新找一个库。
就读取来讲libarchive 是非常适合漫画的流式读取的
不会考虑使用7zip 因为个人因素 考虑到大多数场景还是一次性下载完 所以libarchive 并没有太大问题 增量更新到时候我做一些小trick吧
cbz就是zip改名而已，甚至扩展名没必要用cbz
嘛 特意标识下自己是个漫画的归档（
官方的归档下载用的是zip，我觉得保持一致较好 当然也有故意不一样方便区分的说法
不会考虑使用7zip 因为个人因素 考虑到大多数场景还是一次性下载完 所以libarchive 并没有太大问题 增量更新到时候我做一些小trick吧
下载50页的可能一次下完，但是下载Manga、Game CG因为比较多，经常有几张到几百张下载失败的。
如果使用的官方归档下载才可能确保一次性下载完。
不会考虑使用7zip 因为个人因素 考虑到大多数场景还是一次性下载完 所以libarchive 并没有太大问题 增量更新到时候我做一些小trick吧
zip库除了 7zip、libarchive 应该还有其他的吧。 如果只是归档不涉及到压缩算法，你甚至可以了解一下zip格式自己手写一个zip结构体。
不会考虑使用7zip 因为个人因素 考虑到大多数场景还是一次性下载完 所以libarchive 并没有太大问题 增量更新到时候我做一些小trick吧
zip库除了 7zip、libarchive 应该还有其他的吧。 如果只是归档不涉及到压缩算法，你甚至可以了解一下zip格式自己手写一个zip结构体。
没有必要重复造轮子 何况libarchive 已经覆盖我们的大部分需求了