哪一个最适合连续/时间服务器更新。
有些开发人员使用AlarmManager后跟PendingIntent，有些开发人员也使用Looper和Handler。
所以任何人都可以向我解释哪种方式最适合持续的网络更新以及原因。
答案 0 :(得分：1)
哪一个最适合连续/时间服务器更新？
取决于您的应用程序是否假设当时在后台/前台运行：
假设您从现在起15分钟后通过处理程序安排Runnable
如果用户将“关闭”所有正在运行的活动，如果一段时间后没有运行任何前台服务/活动来回收内存，系统可能会终止您的进程。
在这种情况下 - 您的Runnable永远不会被执行
如果您想连续轮询服务器更新，即使用户离开您的应用程序 - 这个选项显然对您不利。
如果您选择像这样更新服务器 - 至少从已启动的Service上下文中进行更新 - 这样即使用户从一个屏幕导航到另一个屏幕，您的处理程序引用也将保持分配...
另一方面 - 向AlarmManager提供未决意图，确保您的流程处于活动状态时无需提交 - 提供给AlarmManager的意图将唤醒您的应用（以及服务/活动） / broadcast）你提供了未决意图。
关于你的问题 - 我认为这两个都不是获得服务器更新的好方法：
用户可能在他的设备上安装了10-20个应用程序（例如Facebook / Twitter / Whattsap / Viber / Google + ...），从服务器获取更新。 想象一下，他们每个人都会在不同的时间间隔醒来，打开互联网连接，消耗大量宝贵的电池寿命和带宽。 那太疯狂了！你的设备永远不会“睡觉”，所有过程都会一直打开，互联网蜂窝无线电传输也是如此。电池将非常快到0％！
正确的想法是使用GCM API。它还需要服务器端实现，但一般的想法是，当有新数据传递到服务器端时唤醒应用程序的责任，并由此 - 安卓应用程序不需要轮询更新。当服务器通知您时，它会收到通知（如果进程未处于活动状态则唤醒）。 万一你会怀疑 - 这就是它的工作原理 - How does push notification technology work on Android?
我建议你阅读一下 - http://developer.android.com/google/gcm/index.html