tarsin

行 那我有时间从j2k拿过来

> 画廊列表会在导航栏内绘制，右抽屉却不会，感觉也挺别扭 这个从设计上来讲应该是讲究一个主次之分吧 不太懂 而且我觉得这个右抽屉的存在本身就够难看的了

> Hi, I find the code in [CMake](https://github.com/libarchive/libarchive/blob/097ecfb8b2a77e0a1a4eb6643790cb428fa52fb0/libarchive/CMakeLists.txt#L245), libarchive now builds shared and static libraries. Do you only want to build static library? Yes, Android gradle plugin always package any...

新画廊和旧画廊的gid是不同的吗 为什么要另起一个新的下载呢 建议实现里

因为以后所有的下载内容都会以压缩包存储，用libarchive 去实现原地更新压缩包代价会很大。 增量更新的画廊内容有什么规律吗？比如新增的图片全部位于头部/尾部，这样我可以考虑将所有新增的图片放到另一个压缩包里；如果一点规律也没有，我应该也可以考虑生成一个页码与实际位置映射文件。

用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理

#381

先下载到缓存 等全下完再一起压 > > 用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理 > > 还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？

> > 用压缩包管理是出于适配Android 上fuse文件系统考虑 如果像以往那样一堆图片文件直接放文件系统里的访问效率 在CPU 性能足够的情况下 是不如将一整个文件mmap到内存再直接解压快的 在有fuse passthrough的情况下 对这块内存映射的访问与直接访问ext4/f2fs下文件的内存映射效率是差不多的 确实压缩率不会太高，所以我考虑不压缩而是直接进行归档处理 > > 还有现在是可以边看边下，看一张自动下载一张的，直接拉到后面，会发现文件夹里直接出现后面的文件。如果用压缩包储存，要怎么实现？ > > 就算是归档，如何解决使用其他阅读器直接看的问题。毕竟看漫画时其他专业漫画阅读器使用体验可以更方便。 大部分漫画阅读器都支持cbz归档

总之就是 这种一堆图片文件直接放文件系统里 读取起来必然效率低很多 不像app自己的缓存 那个是在/data下 不属于fuse文件系统