即使asyncTask的doInBackground在后台运行，那么AsyncTask loader的loadInBackground（）方法的优势是什么
问题描述：
与AsyncTask的doInBackground（）类似，asynctask loader的回调方法onLoadFinished（）将在后台运行并获取来自URL的响应，然后将响应发送到LoaderManager的onLoadFinished（）以将响应附加到视图，这些视图可能会或可能不会在主UI线程上运行。类似于onPostExecute（）。如果我使用AsynctaskLoader或LoaderManager，我想知道这里真正的优势是什么即使asyncTask的doInBackground在后台运行，那么AsyncTask loader的loadInBackground（）方法的优势是什么
答
他们有不同的目的。 LoaderManager用户从一些来源加载数据。 AsyncTask只是用来在后台执行某些操作。
Here是对此的一些解释。正如你所看到
- 如果直接在活动或片段获取数据，你 用户将从缺乏响应遭受由于从UI线程执行 可能慢查询。
- 如果你从另一个线程获取数据，也许的AsyncTask， 那么你负责管理线程和UI线程 通过各种活动或片段生命周期事件，如 的onDestroy（）和配置的改变两者。
而且还
装载机解决这些问题，包括其他福利。例如：
加载程序在单独的线程上运行以防止janky或无响应的UI。
当发生事件时，加载程序通过提供回调方法来简化线程管理。
- 加载程序在配置更改中保留并缓存结果以防止重复查询。
- 加载程序可以实现一个 观察器来监视基础数据源中的更改。例如，对于 示例，CursorLoader会自动注册一个ContentObserver到 ，当数据更改时触发重新加载。
'AsyncTask'对于Activity Life Cycle来说并不是一个好兆头。例如，如果'AsyncTask'正在运行，并且用户旋转设备并重新启动活动，则会看到一些奇怪的行为。原因是'AsyncTask'仍然挂在onRotate期间销毁的Activity的前一个实例上。 'AsyncTaskLoader'旨在解决这个问题。 –