Remotely-Save插件在iOS设备上的同步崩溃问题分析与解决方案

问题背景

近期有用户反馈在使用Remotely-Save插件进行跨设备同步时，在iOS平台（包括iPhone和iPad）上出现了严重的性能问题。具体表现为同步过程长时间停留在"生成同步计划"阶段（约20分钟至1小时），最终导致Obsidian应用崩溃重启。该问题在更新到0.4.16版本后出现，且主要影响文件数量较大的仓库（约10,000+主文件，17,000+包含配置文件的场景）。

技术分析

从技术角度来看，这个问题可能涉及以下几个关键因素：

1. 内存管理问题：iOS平台对应用内存使用有严格限制，当处理大量文件元数据时，如果内存占用过高会导致系统强制终止应用。

2. 同步计划生成算法：在生成同步计划阶段，插件需要对比本地和远程的所有文件差异，对于大型仓库这会创建大量临时对象。

3. WebDAV协议特性：使用InfiniCloud（原TeraCLOUD）作为后端时，WebDAV协议在处理大量文件列表请求时可能产生额外开销。

解决方案

针对这一问题，开发者提供了以下解决方案路径：

1. 启用性能分析工具：

   • 更新到最新版插件（v0.4.21+）
   • 在设置中启用"性能分析打印"和"性能分析记录大小"选项
   • 配合Logstravaganza插件记录详细日志

2. 优化同步配置：

   • 将并发数设置为1（已确认用户尝试过但效果有限）
   • 设置跳过大于5MB的大文件（用户反馈在老版本0.3.25中有效）

3. 仓库结构调整建议：

   • 考虑将大型仓库拆分为多个子仓库
   • 定期清理不需要的旧文件和历史版本
   • 检查并优化.obsidian目录中的配置文件数量

预防措施

对于其他iOS用户，建议采取以下预防措施：

1. 在同步大型仓库前，先关闭其他占用内存的应用程序
2. 定期检查插件更新，及时获取性能优化版本
3. 考虑在桌面端完成主要同步操作，移动端仅进行小规模增量同步

总结

移动端同步大型知识库是一个具有挑战性的技术问题，需要平衡性能、内存使用和用户体验。Remotely-Save团队持续关注这类问题，并通过添加性能分析工具来帮助诊断和优化。对于遇到类似问题的用户，建议按照上述方案逐步排查，同时保持与开发团队的反馈沟通。

注：虽然该问题因用户未继续反馈而被关闭，但开发者已指出减少大文件数量是有效的解决方案方向。用户在实际操作中应根据自身仓库特点选择合适的优化策略。