Apollo iOS 缓存层扩展性设计与实现

缓存架构现状分析

Apollo iOS 的缓存系统核心是 ApolloStore 类，它负责管理规范化缓存(Normalized Cache)的读写操作。当前实现存在一个重要限制：ApolloStore 是一个封闭的 concrete class，既没有标记为 open 也不符合协议抽象，这使得开发者难以在不修改 Apollo 源码的情况下自定义缓存行为。

扩展需求背景

在实际开发中，开发者经常需要对缓存行为进行定制化。一个典型场景是处理可选字段(optional fields)的缓存读取逻辑。当前实现严格遵循 GraphQL 规范，当缓存中缺少可选字段时会报错，而部分开发者希望在这种情况下返回 null 而非报错。

技术实现方案

架构改进方向

1. 开放类继承：将 ApolloStore 标记为 open，允许子类化
2. 接口协议化：提取 ApolloStoreProtocol 接口，分离实现与抽象
3. SPI 控制：对内部依赖使用 @_spi(Execution) 控制访问权限

关键方法暴露

需要特别开放以下核心方法：

• ReadTransaction.readObject 的四参数版本
• 相关 DispatchQueue 扩展方法
• GraphQLDependencyTracker 依赖管理工具

实现考量

值得注意的是，缓存层扩展并不能改变 GraphQL 执行器的规范校验行为。执行器层面的缺失字段校验是独立于缓存层的，符合 GraphQL 规范要求。缓存扩展主要影响的是从缓存加载数据时的行为。

最佳实践建议

对于需要定制缓存行为的场景：

1. 优先考虑通过缓存策略调整
2. 必要时可继承 ApolloStore 但需注意版本兼容
3. 关键业务逻辑应添加兼容性测试

未来演进

这种架构改进为 Apollo iOS 缓存系统带来了更好的扩展性，使开发者能够在不破坏核心规范的前提下，针对特定业务场景优化缓存行为。同时也为后续可能的官方配置项（如缺失字段处理策略）奠定了基础。