Fragments vs AsyncTask vs IntentService vs Longrunning操作

时间:2015-03-22 17:27:38

标签: java android android-fragments android-asynctask

我有以下设计:

Activity / FragmentA在用户操作时启动AsyncTask以获取一组数据 AsyncTask正在运行时,会向用户显示进度指示器 当AsyncTask完成其任务并获取结果集时,它将其保存在用作共享数据模型的单例类中。

当FragmentA被通知AsyncTask已完成(LocalBroadcastReceiver)时,它会启动ActivityB/FragmentB,它从共享单例中获取结果集并将它们显示在ListView中。

这是有效的,但由于我是Android的新手,我正在努力理解和学习最佳实践 例如。我看到从进度条被关闭到显示ActivityB / FragmentB的UI的时间有一点延迟(在此延迟期间,ActivityA / FragmentA的UI仍然可见)。
此外,我认为,如果从FragmentB而不是FragmentA获取项目,将使FragmentB"自主"
总体而言,有人可以帮助我了解我如何使用Android中更好/标准的做法以及每种方法的优缺点来实现这一点?

1 个答案:

答案 0 :(得分:1)

<强>片段

片段是活动的一小部分,它有自己的生命周期,这为开发人员提供了更多处理UI的灵活性。碎片与后台进程无关。

现在您的主要问题是关于后台流程。

<强>的AsyncTask

这只是具有一些预定义回调的更好的线程版本,当你需要执行一些不超过20秒的网络操作时,之后刷新UI,最好使用asycntask。不要使用服务(避免复杂性,保持简单)。您也可以使用某些第三方库。

<强> IntentService

现在IntentService是更好的服务版本,IntentService的主要目的是避免在mainthread上执行长时间运行操作并为开发人员提供排队系统。如果在运行长时间运行的操作时不需要用户交互,则应使用服务(例如,在每天结束时将应用程序与服务器同步)。

所以结论

  • 用户交互+短时间运行的网络操作= AsyncTask
  • 无用户交互+长时间运行的网络操作= IntentService + Broadcast Receiver,用于通知UI所需的