[Enhancement]: Improved Caching?

[F7Dddd]

Description

Currently, the cache only stores comic images. Could venera consider caching more information for a certain period of time, such as the comic's detail page and the list of images? This wouldn't take up much space, but it could improve smoothness in low-network environments and reduce the number of requests.

目前，缓存只存储漫画图片。venera 能否考虑在一段时间内缓存更多信息，比如漫画的详细页面和图片列表？这样做不会占用太多空间，但可以提高低网络环境下的流畅性，减少请求次数。

Operating System

Android, iOS

picture

No response

[Shapaper233]

I also think it is necessary.

[luckyray-fan]

+1

[wgh136]

Currently, there is an in-memory network cache. For a network request, if there is a previous request with the same URL, there are three possible scenarios:

• If the send times are close (within 5 seconds), the previous response will be used.
• If the difference in send times is less than 1 hour, the app will make a HEAD request to check whether the response headers are the same as the previous ones. If they are the same, the previous response will be used. otherwise, it will not.
• In other situations, the network cache will not be used;

[F7Dddd]

Currently, there is an in-memory network cache. For a network request, if there is a previous request with the same URL, there are three possible scenarios:

• If the send times are close (within 5 seconds), the previous response will be used.
• If the difference in send times is less than 1 hour, the app will make a HEAD request to check whether the response headers are the same as the previous ones. If they are the same, the previous response will be used. otherwise, it will not.
• In other situations, the network cache will not be used;

Thank you for the detailed explanation of the caching. However, the expiration time of this strategy seems a bit short.
In most cases, the detail pages and image lists don't change significantly.
Due to network instability or unreliable comic sources (which may not have SLA guarantees :> ), the "stale-while-revalidate" might be worth considering.

[nief12]

如果我没理解错的话这种效果好像在JHenTai实现了，也是flutter构建的，或许有一定参考价值
https://github.com/user-attachments/assets/32200969-3852-4f17-818a-2e3d59b94720

[wgh136]

如果我没理解错的话这种效果好像在JHenTai实现了，也是flutter构建的，或许有一定参考价值https://github.com/user-attachments/assets/5e8af1b4-e938-4010-9f3a-b98fe2f25167

你用本app对漫画详情页在5s内关闭再打开也是不需要再次加载的, 超过5s会使用HEAD请求验证缓存的有效性

[nief12]

如果我没理解错的话这种效果好像在JHenTai实现了，也是flutter构建的，或许有一定参考价值https://github.com/user-attachments/assets/5e8af1b4-e938-4010-9f3a-b98fe2f25167

你用本app对漫画详情页在5s内关闭再打开也是不需要再次加载的, 超过5s会使用HEAD请求验证缓存的有效性

噢确实，抱歉哈哈哈哈哈，主要是之前用jhentai的时候对他伪加载的印象太大了，直接再利用了未点击前就加载了的封面和标题

[F7Dddd]

I noticed that this issue has been closed and that improvements to the cache were mentioned in the latest version (v1.2). However, after testing, it seems that the behavior remains unchanged from the previous version (v1.1.4).

For example, the comic detail page still undergoes a noticeable reload after a 5-second interval from the previous request. Additionally, I can manually simulate an extreme case: by disconnecting the network, I am unable to access previously viewed comics from the history. This suggests that the comic details and image lists are not being cached for the long term.

Is this the expected behavior?

我注意到这个问题已被关闭，而且最新版本（v1.2）中提到了对缓存的改进。不过，经过测试，该行为似乎与上一版本（v1.1.4）相比没有变化。

例如，从上次请求开始，间隔 5 秒后，漫画详情页仍会进行明显的重新加载。此外，我还可以手动模拟一种极端情况：断开网络连接后，我就无法从历史记录中访问以前浏览过的漫画。这表明漫画细节和图片列表没有被长期缓存。

这是预期的行为吗？

[wgh136]

It's expected. The latest version has increased the cache's keep time and fixed an issue with validating the cache. However, the app still validates the cache by sending a HEAD request after a 5-second interval.