8

我正在开发一个消息传递应用程序，我对如何将数据从服务器发送到客户端感到两难。

我正在使用集中式服务器设计，客户端用于NSURLConnection向服务器发送消息，服务器不保留和管理打开的套接字，也无法为其中一个客户端发送消息。因此客户端使用计时器并每 2 秒查询一次服务器以查看是否有新数据在等待它们。

这种方法的问题是每 2 秒轮询一次服务器似乎会很快耗尽电池电量，所以我想也许不是客户端轮询服务器，而是使用 APNS*，所以当服务器有一些新的信息** 给客户端时，服务器将向客户端发送推送通知 * **，然后客户端将从服务器获取数据。

* 使用 APNS - 如果客户端允许，客户端当然可以禁用此选项。因此，每次应用程序进入前台时，我都会检查是否允许推送，如果没有，我将返回轮询方法。

** 新信息可以是从短信到服务器管理员消息的任何内容。（并且有很多管理员消息......）
例如，在我的应用程序中，用户可以看到他们的朋友状态（在线/离线），所以如果 user1 和 user2 是朋友，并且 user2 只是将他的状态从在线更改为离线，然后服务器需要将此新信息（管理消息 = user2_offline）发送给 user1。

***服务器发送 的推送通知是空的（没有数据/声音），它只是客户端获取新信息的触发器，所以如果向客户端发送推送并且客户端应用程序关闭，他不会注意任何事情。（如果应用程序正在运行，那么它将从服务器获取新信息）

这种方法是否适用于需要大量推送通知使用的大型消息传递应用程序？

更清楚地说，我的主要担忧是：
1. APNS 是否足够可靠，我可以将其用作我的核心服务器到客户端消息传递机制？
2. Apple 是否会批准每天从我的服务器发送的数千或数十万条推送通知？

4

2 回答 2

1

APNS 是否足够可靠，我可以将其用作我的核心服务器到客户端消息传递机制？

没有。为了完整起见，让我重复一下原因。

  1. 苹果自己否认可靠性阅读编程指南
  2. 此外，APNS 有一个 QoS 组件，它可能会以实时为代价提高可靠性（例如，我可以要求 APNS 在 4 周内随时发送通知，如果设备无法访问，则重试），这在您的情况下没有用.

  3. 根据您的要求，如果您发送静默推送（没有用户可见消息的推送），则不能作为高优先级推送发送，这会进一步降低可靠性。这是一个相关的报价

    “静默通知并不是为了让你的应用在后台保持清醒，也不是为了高优先级更新。APNs 将静默通知视为低优先级，如果总数过多，可能会完全限制它们的传递。实际限制是动态的，可以根据条件变化，但尽量不要每小时发送超过几个通知。”

Apple 是否会每天批准来自我的服务器的数千或数十万条推送通知？

一般来说，APNS 在负载方面不会有任何问题，但它有节流，它们可能会限制你的通知，见上面的第 3 点

恕我直言，你应该看看 XMPP，因为这个协议只是像你一样设计用例，并且它们在所有平台上都有广泛的社区支持。我建议您查看类似https://github.com/robbiehanson/XMPPFramework的内容，并在您的后端设置一个 XMPP 服务器，该服务器将处理消息传递和状态消息以及管理消息。

如果你已经评估过 XMPP 并且不想使用它，我建议你需要在 iOS App 中构建一个智能系统，它根据 App State 采用不同的策略，比如下面，你可以有下面的策略

  1. 基于实时套接字的方法 -> 建立永久套接字连接并尽可能保持数据同步（这是当您的应用程序运行到前台或后台时）
  2. 您谈到的轮询系统，可以在调用您的应用程序进行后台获取/位置更新等时使用。
  3. 当您的服务器检测到设备没有活动套接字并且很长时间没有轮询时，将 APNS 与用户可见消息传递 + 自定义数据一起使用
于 2016-11-16T05:21:58.097 回答
-1

我在这个领域工作了一段时间，根据我的经验，我认为你解决问题的方法将无济于事。首先请允许我强调一些关于 APN 特征的重要事实：

  1. APN 不可靠，它们不能 100% 保证到达客户端。
  2. 根据 Apple 的文档，APN 是尽最大努力，所以很多时候它们可能无法达到。
  3. APN 不会在其中保存数据，因此即使它们到达您的客户端应用程序，它们内部也不会为应用程序保存任何数据。
  4. APNs 只是通知用户发生了与您的应用程序相关的事情，而那里的消息（出现在 APN 的警报框中的文本）由 iOS 处理，而不是您的应用程序。这就是为什么使用 iOS 4 的设备显示 APN 的方式与使用 iOS 5 的设备不同，这是操作系统的工作而不是您的应用程序。
  5. 通知到来时出现在您的应用程序图标上的徽章值是您的服务器的责任，而不是设备操作系统的责任。换句话说，当 APN 到达设备时，它应该为您的应用程序提供新的通知计数值。操作系统不会为此做任何事情。

话虽如此，我想解释一下这些应用程序通常是如何设计的。首先，它不是由 URL 连接完成的，并且客户端不会每隔一段时间检查服务器。通常您有一个客户端/服务器架构，其中您的客户端是设备上的应用程序，而服务器是驻留在服务器机器上的真实服务器程序。服务器可以是 Microsoft（例如使用 C#）或 MAC（使用 Objective C）。服务器有一个数据库，它在其中存储信息。一些重要信息（与您的问题相关）是 APN 计数值、您要传递的消息、客户端的在线或离线状态。

当一个客户端喜欢向另一个客户端发送一些东西时，或者当服务器想要向一个客户端（或所有客户端）发送一些东西时，会对接收客户端进行检查以查看他是在线还是离线。如果他在线，则直接发送消息，并且通常在 TCP 套接字上进行通信。如果用户离线，则服务器将存储需要发送给客户端的消息，增加 APN Count 值，向该接收者发送 APN。当该收件人在线时，服务器会注意到（因为建立了连接和握手），因此将从数据库中获取所有未传递的消息并将它们发送给他......

这是一个漫长的过程，我希望我能够向您解释一下。在所有情况下，我都不认为你的方式是实用的或使你能够从事真正的工作。

于 2012-06-10T13:06:39.767 回答