Ios 没有服务器的简单消息应用程序

我是iOS开发新手，并开始学习使用Parse作为服务器的简单消息应用程序。按照他们的编码方式，应用程序在每次发送消息时都会查询解析（以保存消息），但在其免费计划下，解析只允许30个请求/秒。如何制作一个消息传递应用程序？将每条消息的数据保存到服务器是标准惯例吗？在一个每秒只能查询服务30次的应用程序上拥有大量用户似乎并不现实

---

问题是：对于简单的消息传递应用程序，与服务器的关系的标准约定是什么？应用程序是否将每条消息保存到服务器，或者是否有使用推送通知的解决方法？（但即使有推送通知，应用程序也必须打开才能接收它们，至少我对推送的理解有限）

对于一个每秒只有30次查询的消息传递应用程序来说，拥有大量用户群是不实际的。Parse正在经营一项业务。他们每秒给你30个API请求，这样你就可以试用他们的服务，看看它是如何工作的。但是，如果你正在为一个重要的用户群设计一个应用程序，你肯定要付费，因为你希望Parse为你运行服务器

有了这些，一个（典型的）消息传递应用程序对于发送到服务器的每条消息至少发出一个API请求是正常的。服务器负责接受、路由、保存和传递消息。发送的消息产生推送通知和客户端应用程序的API请求以检索消息也是正常的。一般的工作流程是：

用户发送消息

应用程序将消息上载到服务器

服务器确定消息的标题

服务器向收件人发送推送通知

收件人应用程序向服务器查询挂起的邮件

收件人应用程序显示收件人用户的邮件

这是两个API请求和每个发送消息的推送通知

除此之外，根据您的消息服务设计，服务器还可以存储所有消息，以便稍后在不同的设备上，用户可以打开应用程序并下载历史记录，以便显示同步

现在，肯定有办法减少服务器API请求的数量。您的应用程序可以在本地批处理消息，您的服务器可以批处理推送通知，您的客户端可以批处理查询（或者您可以同时执行这三项操作）。所有这些选项都有助于显著减少您付费的服务器API请求数量，但它们也会降低消息传递服务的响应能力和用户体验

您还可以设计一个复杂的点对点通信系统（就像过去的Skype一样），从消息流中删除服务器。但是，您必须设计复杂的身份验证和验证系统、复杂的路由系统、复杂的存储系统等等。这需要大量的工作。即使你这么做了，我也不知道苹果是否会允许它出现在应用商店上。为避免支付服务器的小额成本，需要花费大量时间、工作量和不确定性

---

关于推送通知：推送通知从服务器发送到收件人客户端应用。您的iPhone无法将通知推送到另一台iPhone。中间总是会有一个服务器。您的应用无需打开即可接收推送通知。iOS将接收它，然后将其发送到您的应用程序。如果您的应用程序已关闭，iOS将（部分）在后台打开它以传递消息。

这是一个很好的答案。