是否有任何理由继续使用 IntentService 处理 GCM 消息？答案

【问题标题】：Is there any reason to continue using IntentService for handling GCM messages?是否有任何理由继续使用 IntentService 处理 GCM 消息？
【发布时间】：2013-08-24 00:09:24
【问题描述】：

如您所知，最近 Google 更改了他们的 GCM 文档，并声称不再需要 IntentService 来处理到达的 GCM 消息。所有的处理都可以在BroadcastReceiver中完成。

当试图弄清楚是否有任何充分的理由继续使用IntentService 时，我遇到了这个quote：

WakefulBroadcastReceiver 向其传递处理 GCM 消息的工作的服务（通常是 IntentService），同时确保设备在此过程中不会重新进入睡眠状态。 包含 IntentService 是可选的——您可以选择在常规 BroadcastReceiver 中处理您的消息，但实际上，大多数应用都会使用 IntentService。

为什么大多数应用会使用IntentService？是否存在无法直接在BroadcastReceiver 中处理 GCM 消息的情况？

【问题讨论】：

标签： android push-notification broadcastreceiver google-cloud-messaging intentservice

【解决方案1】：

为什么大多数应用会使用 IntentService？

因为您响应消息所做的任何事情很可能需要 1-2 毫秒以上的时间，这意味着您希望从主应用程序线程中完成这项工作。响应广播的常见模式是将工作委托给IntentService。

因此，如果您响应 GCM 消息的工作涉及：

磁盘 I/O
进一步的网络 I/O（例如，从您的 Web 服务中检索其他数据）
大量计算（例如图像处理）

您可能希望使用IntentService 来执行该工作。

【讨论】：

感谢您的回答！因此，如果我理解正确，如果对 GCM 消息的响应仅涉及显示通知，则没有理由使用 IntentService。我说的对吗？
@Eran：这可能是安全的，假设您没有将磁盘 I/O 作为显示 Notification 的一部分（例如，读取一些数据库信息以填充 Notification 内容） .
@CommonsWare 承诺将共享首选项视为 I/O？
@OfekRon：是的，不过请注意apply() 为 I/O 分叉了自己的后台线程。 commit() 是同步的，理想情况下不在主应用程序线程上完成。同样，如果您的请求是此过程中第一次请求它并且必须从磁盘读取首选项，则尝试获取 SharedPreferences 对象（例如，PreferenceManager.getDefaultSharedPreferences()）可能会执行磁盘 I/O。
@CommonsWare 你好，我的应用程序在前台运行时可以通过 Pending Intent（不是 GCM 通知）推送本地通知，但在后台运行时无法推送通知（onPause），android 系统限制吗？我需要Intent Service 来推送本地通知吗？