Apollo Kotlin 客户端缓存机制深度解析与优化实践

缓存机制架构分析

Apollo Kotlin 作为一款优秀的 GraphQL 客户端框架，其缓存系统采用了分层设计理念。在 iOS 平台上运行时，实际上存在两个独立的缓存层级：

1. 规范化缓存(Normalized Cache)：这是 Apollo 的核心缓存机制，负责存储经过规范化处理的 GraphQL 数据，能够智能地合并相同实体，避免数据冗余。

2. HTTP 缓存层：由 iOS 系统的 NSURLCache 提供支持，属于底层网络缓存，独立于 Apollo 的规范化缓存系统。

问题现象与根源

开发者在使用过程中发现两个关键问题：

1. 即使为 mutation 操作设置了 doNotStore(true) 标志，请求数据仍然出现在系统缓存中。

2. 调用 apolloClient.apolloStore.clearAll() 方法后，缓存并未被完全清除。

经过深入分析，这些问题源于对缓存层级的误解。doNotStore() 和 clearAll() 方法仅作用于 Apollo 的规范化缓存，而不会影响 iOS 系统级别的 HTTP 缓存。

HTTP 缓存机制详解

iOS 平台的 NSURLCache 默认会缓存 HTTP 响应，即使请求策略设置为 NSURLRequestReloadIgnoringCacheData。这一策略仅控制是否从缓存读取数据，而不影响是否写入缓存。这种设计可能导致以下情况：

• 敏感数据可能被意外缓存
• 缓存清除操作不彻底
• 存储空间被不必要的请求占用

解决方案与最佳实践

经过验证，最有效的解决方案是使用临时会话配置：

val client = ApolloClient.Builder()
    .httpEngine(
        DefaultHttpEngine(
            nsUrlSessionConfiguration = NSURLSessionConfiguration.ephemeralSessionConfiguration()
        )
    )
    .build()

这种配置的优势在于：

1. 完全禁用磁盘缓存，确保敏感数据不会持久化
2. 内存缓存仍然可用，保持良好性能
3. 与 Apollo 的规范化缓存完美配合
4. 简化缓存管理，避免多级缓存带来的复杂性

架构设计启示

这一问题的解决过程给我们带来几点重要启示：

1. 分层设计：理解每层缓存的职责边界至关重要，规范化缓存与 HTTP 缓存服务于不同目的。

2. 默认安全性：框架默认配置应优先考虑数据安全性，避免意外缓存敏感信息。

3. 明确文档：需要清晰区分不同缓存层的行为特征，帮助开发者正确使用。

Apollo Kotlin 团队已将此优化方案合并到主分支，未来版本将默认采用更安全的缓存策略，为开发者提供更好的使用体验。