Android的设计考虑：AsyncTask的VS服务（？IntentService）
我设计一个Android应用程序，这将需要做以下步骤：
I'm designing an android app which will need to do the following steps:
- 在用户按下按钮或以其他方式表示为同步数据。
- 在同步过程中会使用REST Web服务将数据移入和移出服务器。
- 数据将被储存在本地的SQLite数据库。
- 在同步过程应提供状态更新/消息到UI
- 在用户不应该被允许徘徊关闭的应用程序的其他部分，做更多的工作在同步过程中。
第一次同步进程运行时，可能需要10-20分钟。 初始同步之后，更少的数据将被传输并存储和 我期望的过程需要1-2分钟或更少。
The first time the sync process runs, it may take 10-20 minutes. After the initial sync, less data will be transferred and stored and I expect the process to take 1-2 minutes or less.
我已经做了很多阅读有关Android的的AsyncTask 和使用服务的各种例子......但我不完全理解的设计考虑和贸易选择一个设计比其他的-offs。目前，我有我的演示项目掐灭使用AsyncTask的。后看（大部分）开发Android REST客户端应用程序：http://$c$c.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html#我感到困惑这里所描述的设计模式感到过分
复杂的，也许是因为我就是不明白呢。
I've been doing a lot of reading about android's AsyncTask and various examples of using a Service ... But I don't fully understand the design considerations and trade-offs of choosing one design over the other. I currently have my demo project stubbed out using an AsyncTask. After watching (most of) Developing Android REST client applications: http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html# I'm left confused the design patterns described here feel overly
complex, perhaps because I just "don't get it" yet.
我来自一个java，春天，网络和桌面应用背景。思考和手持设备方面的设计是相当新的给我。以2步回来，如果初始同步将是这样一个长期运行的进程（当屏幕布局发生变化时，会发生什么？当电话铃声响起，而我运行同步，会发生什么？），有没有更好的方法我想想problem->解决方案，用户体验，在手机上运行的应用程序的用户的期望？
I come from a java, spring, web and desktop application background. Thinking and designing in terms of a handheld device is quite new to me. (What happens when the screen layout is changed? What happens when the phone rings while I'm running a sync?) Taking 2 steps back, if the initial sync IS going to be such a long running process, is there a better way for me to think about the problem->solution, the user experience, the user expectations of an application running on a phone?
很想从一些有经验的Android开发人员那里谁已经纠结于这些问题的来信。
Would love to hear from some more experienced android developers out there who have already wrestled with these questions.
在我看来，这是一个主流/平均Android开发的最棘手/努力的一部分。比如黑莓，这是时代更容易。
In my opinion this is the most tricky/hard part of a mainstream/average Android development. For instance on BlackBerry this is IN TIMES easier.
当然你需要使用服务。
的AsyncTask 不适合，因为它是紧紧地绑定到你的活动通过上下文手柄（否则你将无法更新活动的UI 从的AsyncTask ）。然而，一个活动可以通过OS杀死一旦活动进去背景。要去背景可以是来电的例子原因 - 用户切换到手机应用程序，使您的活动将变为不可见。在这种情况下（取决于当前状态的RAM上）的OS可以决定杀背景中的一个（用户看不到的）活动。
AsyncTask does not suit, because it is tightly "bound" to your Activity via a Context handle (otherwise you would not be able to update UI of the Activity from your AsyncTask). However an Activity can be killed by OS once the Activity went in background. An example reason of going to background can be an incoming call - user switches to Phone application so your Activity becomes invisible. In this case (depending on the current RAM state) OS may decide to kill one of the background (invisible to the user) activities.
一些开发者通过设置一个静态的东西对于具有内部一个长期运行的行动解决这个。有人推荐使用应用程序实例。这是因为静态的东西，应用程序存在而整个应用过程中存在。不过这些都是不正确的解决方法。在Android的进程时，操作系统决定是时候也可能被杀死。 Android操作系统都有自己的考虑是什么它可以杀灭和顺序。所有过程都加号分开到5级killability的。 这里是指定这些级别的文档。有趣的是，有阅读：
Some devs workaround this by arranging a static stuff for having a long-running actions inside of. Some recommend to use Application instance. This is because static stuff and Application exist while the whole app process exists. However those are incorrect workarounds. Processes in Android are also may be killed when OS decides it is time to. Android OS have its own considerations about what it can kill and in what order. All processes are devided to 5 levels of "killability". Here is the doc where those levels are specified. It is interesting to read there:
由于运行的服务的过程 排名高于之一，背景 活动，活动发起 一个长期运行的操作可能会做的很好 启动服务的操作， 而不是简单地产生一个线程 - 特别是如果操作 可能拖垮活动。示例 这是玩音乐的 背景和上传图片 相机拍摄到网站。 使用服务，保证了 操作将具有至少服务 过程的优先级，而不管 发生了活动。
Because a process running a service is ranked higher than one with background activities, an activity that initiates a long-running operation might do well to start a service for that operation, rather than simply spawn a thread — particularly if the operation will likely outlast the activity. Examples of this are playing music in the background and uploading a picture taken by the camera to a web site. Using a service guarantees that the operation will have at least "service process" priority, regardless of what happens to the activity.
您活动，用户发起一个长期运行的动作应表现出 ProgressDialog ，以确保用户不会做别的而动作正在运行。该指南这里。
Your Activity where users initiate a long-running action should show a ProgressDialog to make sure user does not do anything else while the action is running. The guide is here.
此外，你很可能希望使用 NotificationManager 的如果你的活动目前是看不到的。这里是 NotificationManager帮助从开始。
Also, you'd most likely want to use the NotificationManager for notifying the user about your long-running action completion (or failure) if your Activity is currently invisible. Here is the NotificationManager info to start from.