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

Question

我是iOS开发新手，并开始使用Parse作为服务器的简单消息应用程序教程。他们编码的方式是，每次发送消息时应用查询都会解析（保存消息），但看到Parse在其FREE计划下只允许30 req/sec，那么人们会怎么做一个消息应用？为每条消息保存数据到服务器是否是标准惯例？对于每秒只能查询30次的应用程序，拥有庞大的用户群似乎并不实际。

简化的问题是：简单的消息应用程序与服务器关系的标准约定是什么？该应用程序是否将每条消息保存到服务器，或者是否存在使用推送通知的工作？ （但即使推送通知应用程序将不得不打开接收它们，至少这是从我有限的理解推动）

Answer 1

它不是实际上有一个消息应用程序的实质用户群，只有30每秒查询次数。解析正在运行一项业务。他们为您提供30个API请求/秒，以便您可以尝试他们的服务并了解其工作原理。但是，如果你正在为一个重要的用户群设计一个应用程序，你一定要付钱，因为你期望Parse为你运行服务器。

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

1. 用户发送消息
2. 应用上传消息给服务器
3. 服务器确定其中消息被为首
4. 服务器发送推送通知收件人
5. 收件人应用查询服务器未决消息
6. 收件人应用程序显示收件人用户的消息

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

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

现在，有办法减少服务器API请求的数量。你的应用程序可以在本地批量发送消息，你的服务器可以批量推送通知，你的客户可以批量查询（或者你可以全部三个）。所有这些选项都可以显着减少您付费的服务器API请求的数量，但它们也会降低消息传递服务的响应能力和用户体验。

您还可以设计一个复杂的点对点通信系统（如Skype过去一样）从消息流中删除服务器。但是，您必须设计复杂的身份验证和验证系统，复杂的路由系统，复杂的存储系统等。lot的工作。即使你做了，我也不知道苹果是否会允许它在App Store上。很多时间，工作和不确定性，以避免为服务器支付小额费用。

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