我目前正在研究加载器以及它们如何克服应用程序生命周期中的屏幕方向等变化，到目前为止，从我读过的内容来看，AsyncTaskLoader与AsyncTask完成的工作甚至更好。因此，不应该将AsyncTask视为过时或者是否为开发人员提供了一些隐藏的优势？
我目前正在研究加载器以及它们如何克服应用程序生命周期中的屏幕方向等变化
Architecture Components对视图模型和LiveData的支持是Google目前解决加载器试图解决的问题的方向。
AsyncTaskLoader与AsyncTask完成相同的工作，甚至更好
请注意，AsyncTaskLoader使用AsyncTask。
不应该将AsyncTask视为过时的
是的，只要我们有其他模式和库可供使用（例如，RxJava，LiveData）。话虽这么说，正确使用AsyncTask是一个不错的选择。挑战在于正确使用它（例如，从保留的片段，小心避免与后台线程上的托管活动交互）。
它为开发人员提供了一些隐藏的优势吗？
你的论点似乎是“远洋班轮比划艇有更多的功能，所以我们不应该认为划艇过时了吗？”。海洋划线员有他们的成本，并且远洋划线员不能做划艇可以做的所有事情（例如，在浅水中旅行，被拖在卡车后面）。
装载机的设计 - 在某种程度上他们曾经有过“设计” - 来：
AsyncTask在后台加载数据并非一切都需要。例如，加载器模式以读取操作为目标（我们实际上“加载”数据），但它对写入操作（我们正在更改数据的位置）没有帮助。然而，即使我们进行配置更改，我们仍然希望异步执行写操作并查找结果。您可以将写入操作压缩到加载器中，但这不是一个自然的选择。使用AsyncTask或其他东西，而不是装载机，会更自然。
这样想，
AsyncTaskLoader可以在AsyncTask所在的任何地方使用。主要优点是能够在生命周期之间持续存在。
如果您使用AsyncTask并调用网络操作从Internet获取一些数据并且用户旋转手机，您的AsyncTask将不得不再次启动任务以获取数据，这可能会对您的应用程序造成潜在危险，因为您可以有内存泄漏。
所以，无论如何，Loaders是AsyncTask的演变，它们基本上是改进的AsyncTasks。
我相信AsyncTask仍然存在，因为当您在后台线程中执行一些简单的任务时，您可以更简单地使用带有匿名内部类的AsyncTask，并将结果立即传递给UI线程。