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