要获取最新条目，请使用标准的从最新日期降序下载，该下载将从最新条目开始。您将在 XML 结果中收到一个“继续”标记，如下所示：
<gr:continuation>CArhxxjRmNsC</gr:continuation>`
浏览结果，找出任何新的东西。您应该发现，要么所有结果都是新的，要么在某一点上的所有内容都是新的，而之后的所有结果您都已经知道了。
在后一种情况下，你已经完成了，但在前一种情况下，你需要找到比你已经检索到的内容更旧的新内容。通过使用延续来获取从刚刚检索到的集合中的最后一个结果之后开始的结果，方法是在 GET 请求中将其作为c参数，例如：
http://www.google.com/reader/atom/user/-/state/com.google/reading-list?c=CArhxxjRmNsC
继续这样，直到你拥有一切。
The n参数，它是要检索的项目数的计数，非常适合于此，并且您可以随时更改它。如果检查频率是用户设置的，因此可能非常频繁或非常罕见，您可以使用自适应算法来减少网络流量和处理负载。最初请求少量最新条目，例如五个（添加n=5到您的 GET 请求的 URL）。如果全部都是新的，则在下一个请求中，
当你使用延续时，要求一个更大的数字，比如 20。如果这些仍然是新的，要么是提要有很多更新，要么已经有一段时间了，所以以 100 为一组继续，或者其他什么。
但是，如果我错了，请纠正我，您还想知道，在下载一个项目后，其状态是否因使用 Google Reader 界面阅读该项目的人而从“未读”更改为“已读”。
一种方法是：
- 更新 Google 上已本地阅读的所有项目的状态。
- 检查并保存提要的未读计数。 （您需要在下一步之前执行此操作，以便保证在下载最新项目和检查阅读计数之间没有新项目到达。）
- 下载最新项目。
- 计算您的阅读次数，并将其与谷歌的进行比较。如果提要的阅读次数比您计算的要高，您就知道有人在 Google 上阅读了某些内容。
- 如果在谷歌上阅读了某些内容，请开始下载已读项目并将其与未读项目数据库进行比较。你会发现一些谷歌说已读的项目，而你的数据库声明是未读的；更新这些。继续这样做，直到您发现这些项目的数量等于您的阅读计数与谷歌的阅读计数之间的差异，或者直到下载变得不合理。
- 如果您没有找到所有已读项目，这就是生活;将剩余的数量记录为“未找到的未读”总数，您还需要将其包含在您认为未读的本地数量的下一次计算中。
如果用户订阅了很多不同的博客，他也可能对它们进行广泛的标记，因此您可以在每个标签的基础上完成整个事情，而不是针对整个提要，这应该有助于减少数据量，因为如果用户没有在谷歌阅读器上阅读任何新内容，则无需对标签进行任何传输。
整个方案也可以应用于其他状态，例如加星标或未加星标。
现在，正如你所说，这
...这意味着我需要在客户端上保留自己的已读/未读状态，并且当用户登录到在线版本的 Google Reader 时，条目已标记为已读。那对我不起作用。
确实如此。既不保持本地已读/未读状态（因为您无论如何都保留所有项目的数据库），也不标记在谷歌中已读的项目（API 支持）似乎都非常困难，那么为什么这对您不起作用呢？
然而，还有一个进一步的问题：用户可能会在谷歌上将已读的内容标记为未读。这给系统带来了一些麻烦。我的建议是，如果您确实想尝试解决此问题，则假设用户通常只会接触最新的内容，并每次下载最新的几百个左右项目，检查所有项目的状态他们。 （这还不是全部that坏的;下载 100 个项目需要 0.3 秒（300KB）到 2.5 秒（2.5MB），尽管是在非常快的宽带连接上。）
同样，如果用户有大量订阅，他也可能拥有相当多的标签，因此在每个标签的基础上执行此操作会加快速度。实际上，我建议您不仅要按标签进行检查，还要分散检查，每分钟检查一个标签，而不是每二十分钟检查一次所有标签。如果您想降低带宽，您还可以对旧项目的状态更改进行“大检查”，频率低于“新项目”检查的频率，也许每隔几个小时一次。
这有点占用带宽，主要是因为您需要从 Google 下载完整的文章来检查状态。不幸的是，我在可用的 API 文档中看不到任何解决办法。我唯一真正的建议是尽量减少对非新项目的状态检查。
