页面迭代器带来的问题 - Hentioe/mikack-mobile GitHub Wiki

前言

本文介绍的是本项目最大的历史遗留问题，它给客户端体验带来了严重的影响，所以有必要如此庄重的介绍它。同时也是为了让用户搞明白本应用的缺陷本质，会带来什么影响，为什么修复时间会比较长。

什么是迭代器？为什么要设计一个和页面有关的迭代器？

当我们阅读漫画的时候，会一页一页的向下翻，而不是一次性拿到全部页面图片。迭代器就是一个翻页器，它内部维护了当前的翻页状态（例如当前页码、已加载的页面数据、填充了更多信息的漫画数据），当只有手动向下翻页时才加载下一页的数据。

这样做的优势是，当我们通过客户端阅读时，不需要在第一页就得等待全部页面加载完毕。毕竟我们当时不需要全部页面图片，迭代器可以让翻页延迟和内存开销最小化。

因为迭代器是顺序翻页的，所以正常来讲你的操作流程会是：第一页 >翻页> 第二页 >翻页> 第三页。的确，这样做看起来好像没什么问题，是正常人阅读漫画的基本行为。

但却忽略了一个很明显的需求，那就是跳页。即：第一页 >跳转到第 99 页> 第九十九页。顺序迭代器无法做到跳页，为了解决跳页需求，它需要经过这样的流程：第一页 >跳页：（持续翻页，翻 98 次）> 第九十九页。很明显，这样的缺陷太大了，弥补空缺页面需要不断的翻页，导致很高的延迟。

对于跳页需求而言，迭代器就是一个设计错误。至少强制有序的迭代器是一个错误，虽然你可能最终将迭代器改造成支持跳页的无序版本，但是迭代器意义已经不复存在。

我们需要的是一个跳页器（能像迭代器一样在内部缓存避免不必要的加载那是最好的）。

最初的 mikack 项目是一个命令行“下载器”，对于下载器而言其实不需要迭代器，一次性加载全部页面也没有关系。之所以设计迭代器是为了支持例如“加载进度”之类的需求。

因为最初的设计并不是为即时阅读的客户端准备的，所以导致了此问题。

不会很快。让迭代器支持指定页码跳页本身并不难，实际上迭代器也可以看作一个顺序传递页码的跳页器，但可惜的是在背后来源的适配上有很多都是依赖顺序的。

为此，需要对所有来源的页面加载进行轻度改造，让它们的实现“顺序无关”。所以，它不会很快，但是会被逐渐解决。