刚刚看到 Google I/O 2010 - Android REST 客户端应用程序，其中说： 从服务开始长时间运行的操作 据我所知（我的英语很差），这样做的主要目的是防止应用程序被系统杀死. 正确的？执行所有长时间运行的操作而不仅仅是来自服务的 Web 操作是一种好习惯吗？
据我了解，如果我在活动中创建一个对象，然后应用程序进程将被终止，我将丢失该对象，但如果我在服务中创建此对象并且在进程将被终止后 - 我的对象仍然是活动的。正确的？
（单独的线程）VS（服务+单独的线程）
在我的问题的背景下有什么不同？
不完全是 ...
你不知何故混合了这些概念Destroyed和Killed
Destroyed
这是你的应用程序应该准备好处理的事情。由于可能不同的原因（即设备方向更改等），操作系统可能会破坏您的活动（通常是onDestroy()预先调用，因此您有机会保存重要的内容）并且您的活动中的所有对象都将丢失。但是，您的应用程序可能包含一个以上的活动和/或服务，并且有一个活动被销毁，并不意味着其他活动也将被销毁。
Killed 操作系统可能出于某种原因决定终止您的应用程序。这是通过终止应用程序使用的进程来完成的，该进程是运行构成应用程序的所有活动和服务的进程。您的应用程序不会有任何警告，也无法阻止这种情况发生。您应用程序中的所有对象（由活动和服务使用）都将丢失。
话虽如此，Service长期活动的优势是什么？
让我们用一个简单的例子：
如果您的活动正在将大文件上传到服务器，并且用户决定更改设备方向，则活动将被破坏并中断上传。即使在活动重新启动时重新开始上传，它也会重新开始。
如果您有服务根据活动的请求执行上传内容，即使您的活动被破坏，该服务仍保持活动状态并且上传继续而不会中断。
注意： 如果您有一个运行时间很长的服务（将运行超过半小时），请将其设置为foregroung service，否则无论如何它都会被杀死。
1. The Service API in Android is one of the key mechanisms for applications to do work in the background.
But it can easily implemented using a simple thread.
BUT: *Once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.*
So as I understand that is difference between a regular thread and a Service for our case.