我是iOS开发的新手，并开始使用Parse作为服务器的简单消息应用程序教程。他们对它进行编码的方式，每次发送消息时应用程序查询都会解析（以保存消息），但在其免费计划下看到Parse只允许30 req / sec如何制作消息应用程序？是否为每条消息将数据保存到服务器是标准惯例？在一个只能每秒查询30次服务器的应用程序上拥有大量用户群似乎并不实际。
简化的问题是：与简单消息传递应用程序的服务器关系的标准约定是什么？应用程序是否将每条消息保存到服务器，或者是否有使用推送通知的解决方法？ （但即使使用推送通知，也必须打开应用程序以接收它们，至少这是因为我对推送的理解有限）
答案 0 :(得分：2)
对于每秒只有30个查询的消息传递应用程序来说，拥有大量用户群， 不实用。 Parse正在经营一家企业。它们为您提供30个API req / sec，以便您可以尝试他们的服务并查看其工作原理。但是，如果您正在为重要的用户群设计应用程序，那么您肯定必须付费，因为您期望Parse为您运行服务器。
通过这种方式，（典型的）消息传递应用程序每个发送消息至少向服务器发出一个API请求是正常的。服务器负责接收，路由，保存和传递消息。发送的消息导致推送通知以及来自客户端应用程序的API请求以检索消息也是正常的。一般工作流程是：
这是两个API请求和每个已发送消息的推送通知。
除此之外，根据您的消息服务设计，服务器还可以存储所有消息，以便稍后在不同的设备上，用户可以打开应用程序并下载历史记录，以便显示同步。
现在，肯定有办法减少服务器API请求的数量。您的应用可以在本地批量发送消息，您的服务器可以批量推送通知，您的客户端可以批量查询（或者您可以完成所有这三项）。所有这些选项都可以帮助您大幅减少所支付的服务器API请求数量，但它们也会降低消息传递服务的响应能力和用户体验。
您还可以设计一个复杂的点对点通信系统（如过去的Skype）从消息流中删除服务器。但是，您必须设计复杂的身份验证和验证系统，复杂的路由系统，复杂的存储系统等。很多的工作。即使你这样做了，我也不知道Apple是否会在App Store上允许它。大量的时间，工作和不确定性，以避免为服务器支付小额费用。
关于推送通知：推送通知从服务器发送到收件人客户端应用程序。你的iPhone无法推送另一部iPhone的通知。中间总会有一台服务器。您的应用无需打开即可接收推送通知。 iOS将收到它，然后将其发送到您的应用程序。如果您的应用已关闭，iOS将（部分）在后台打开它以传递消息。