我们正在构建一个需要在不同用户之间进行大量数据交换的应用程序。我们使用 SQLite 存储信息和 Rest api 与服务器交换数据。
为了确保高性能和更少的 CPU/内存占用，同时保持良好的用户体验，我们需要以下建议：
1 我们尝试以 30 秒的频率运行同步，但它占用资源。是否有任何客户端框架可用于将 sqlite 与 MySQL 同步，或者我们只需要计划所有可能的事件
2 Gmail /twitter 等应用程序如何工作 - 它们是仅按需同步还是在后台继续同步。我觉得它是按需的，但不确定。
3 通知应该在服务器端或客户端（基于 sqlite 中的更新）。在whatsapp中我观察到它只是客户端。如果我不点击收到的消息，我会继续收到相同的通知
4 如果我们保留通知服务器端并按需同步。然后在应用程序打开时单击新通知时，我们是否应该进行同步呼叫
需要专家意见，此类应用程序应设计为以不占用资源并为客户提供在线体验的方式管理同步和通知
你的问题很广泛，但我至少会给你一个开始的方向。
我已经在 iOS 和 Android 中运行了超过 100 MB 的本地数据库，没有发生任何事故。如果您正确使用 SQLite，它永远不会成为您的问题。即使有 100,000 行数据，它也是快速高效的。人们遇到麻烦的地方是没有正确索引数据或过度规范化数据。快速搜索可以告诉您如何使用索引来优化您的查询，所以我不再赘述。过度规范化似乎还没有完全理解，所以我会更深入地讨论它。
在设计服务器数据库时，尽量减少重复数据的数量很重要。这通常是通过将单个记录分解为多个表并使用外键来完成的。在 1 GB 的数据库上，这种类型的数据规范化可能会节省 20%，这是相当重要的。这种存储增益是以性能为代价的。顺序查找和连接通常是获取完整数据所必需的。在服务器上，有大量的 CPU 周期和内存，没有人真正注意到请求是否需要额外的一两毫秒。
移动应用程序不是完整的数据库服务器。用户正在积极地盯着屏幕等待应用响应。此外，可用的 CPU 和内存很少，这使得延迟需要更长的时间。雪上加霜的是，移动数据库只是服务器数据库大小的一小部分，重复数据已经非常少。相同的数据规范化可能节省了 200 MB（1 GB 的 20%）服务器大小，现在可能只节省 10 MB 的 5%，即 500 KB。这种微小的收获不值得付出努力或对性能造成影响。
同步时，您不需要每次都使用完整的数据集。您只需要获取自上次同步以来已更改的数据。在许多情况下，这根本不会改变。您应该找到一种方法来识别设备上现在有什么并且只获取更改。
UI 不会因为等待网络请求而停止，这一点很重要。所有网络活动都应在后台线程上完成，并在同步完成后通知 UI 刷新。
最后，我会提到 SQLite不是线程安全的。限制数据库访问的并发性很重要。