转载

关于 AsyncTask 的常见问题（Common questions on AsyncTask ）

本文由Lin Shen 译自 Common questions on AsyncTask ，原文作者 Colt McAnlis , 转载请务必注明出处！

关于 AsyncTask 的常见问题

我在 Google 工作最喜欢的一点，就是把一些比较复杂的概念，分解成一小部分一小部分，这样就可以确保每一位工程师都能清楚地理解。在我最近的《 Android 性能优化典范》视频中，我提到了一个表面上看上去很直观，但是它的一些属性可能会带来一些万万没想到的负面影响的东西，我是说，毫无悬念，这货就是关于 AsyncTask :

我在这个视频里强调了一些开发者之前在使用 AsyncTask 时可能并不会注意到的事项。多亏了我们有一些非常棒的 android 开发者交流社区，能让我们看到大家反馈的一些问题：

关于 AsyncTask 的常见问题（Common questions on AsyncTask ）

让我们来挖掘其中的一些问题，看看能不能深入展开讨论一下：

对 activity / view 使用 WeakReference?

关于 AsyncTask 的常见问题（Common questions on AsyncTask ）

在 Java 当中， WeakReferences 是一个不错的引用对象的方法，而且当你持有对象的引用的时候，它还能保证不被 GC(garbage-collect) ( 这儿有个关于这个问题不错的讨论)。

这么一来，用 WeakReference 就可以让你的异步任务任意对一个你感兴趣的 UI 对象持有引用，而且还不用担心造成内存泄露。

这确实很棒，因为这似乎直接解决了我们对内存泄露的担心。但是从它自身角度来看，这不是一个完整的解决方案；它并没有解决接下来的一个问题：当你的 UI 对象被销毁的时候，你该怎么办？

假设你持有了一个对 Activity 的引用，解决方案可能就比较简单，只要加几行代码判断一下 WeakReference.get() 是不是返回 null 就行，在一些 Activity 已经被销毁的情况下，这样判断一下你就能知道接下来该怎么做了。

引用一些特定的 View 的时候也可以用相同的办法，但也会随之带来一些精神上的焦虑（至少对我而言），因为你要知道，你持有的这个对象，并没办法知道在异步操作的时候，它的数据状态是不是已经冻结了。举个例子，你正持有的这个对象已经被从 view 层级（view hierarchy）中移除了，或者它的内容已经被你一个已完成的操作给刷新了。这两个例子，只要有其中一种情况，你就仍然要考虑一些策略来应对这些场景。

所以说，使用 WeakReference 会帮助降低潜在的内存泄露风险，如果你愿意多写几行代码，一个对象一个对象地处理 WeakReference.get() 返回 null 的情况的话，那我无话可说。

把一个静态的 AsyncTask 搞成内部类吗?

关于 AsyncTask 的常见问题（Common questions on AsyncTask ）

完全正确。（译著：这里 Colt McAnlis 是想赞同上面这个开发者的评论，这个开发者认为静态嵌套类比内部类更好，而并不是赞同这个副标题）把 AsyncTask 声明成 activity 一个静态嵌套类(static nested class) ，可以消除一些隐式引用带来的七七八八的泄露问题。关于“静态嵌套类(static nested class)”和“内部类(inner class)”的区别， StackOverflow 上这篇文章总结得相当不错:

一个内部类的实例只能在一个外部类的实例中存在，而且对于它的外围实例(enclosing instance)中的方法和属性有直接访问权。

这段话帮助解释了前面说的那些 “七七八八的泄露问题” 是怎么来的。再直接一点的话，静态的嵌套类就不会干这样的事，它们的实例并不需要外部类的实例。

所以，这解决了你的关于“隐式引用”的问题，但没解决 “我们究竟应该怎样持有对 UI 对象的引用” 的问题，这还是讲到目前为止的一个首要问题。

RxJava 怎么样?

关于 AsyncTask 的常见问题（Common questions on AsyncTask ）

从古至今，线程都是个很复杂的问题。一些线程相关的第三方库之所以成功，归功于它们“能将一些细微差别抽象出来”这个事实，而且能从代码层面使线程调度变得容易些。我记得《 Intel Threading Building Blocks 》第一次出版的时候写到: “当我发现有一套‘久经考验’的线程安全容器可以给我使用，而不用我自己去折腾线程调度的时候，简直如释重负。结果也是自然而言，我只要花很少的时间去测试线程，剩下的时间就可以拿来制定我邪恶的计划（译著：美嘉里面的台词，老外写文章都喜欢这样）”

诚然， RxJava 不例外又是一个围绕特定类型的用例和 API 模型设计的线程库。由于它的 API 提供的一些功能，一大帮 Android 开发者发誓“这就是我要的线程库！！！我的线程库时尚时尚最时尚……”。坦率地说，RxJava 对那些把线程相关的问题捧上天的人来讲，或者你的应用里确实有很多线程相关的复杂调度，对于这些人而言，RxJava 确实提供了很多不错的功能。

如果 RxJava 对于而言用着确实不错，，那么请继续跟着节奏摇摆，不要停。

而对于那些持观望态度的人，请容我说几句：

首先， RxJava 说白了是一个纯 java 库。对于 Android 平台而言它没有任何特别的定制或者优化。

对那些用 java 开发服务端和客户端代码的人，这也许是一件幸事。对于服务端的人，这样做对于他们完成这项工作而言，不一定要去改变原来的“心智模式”。然而，客户端这边这么搞就比较麻烦了。我们知道 Android 有自己的线程模型，而 RxJava 在用的时候呢？有些代码或者思想又是必须得保留的。怎样在 Android 里保留这些纯粹为 Java 设计的代码或者思想，你得花一番功夫吧？

坦率地说，RxJava 只是对线程优先级操作进行的一个 API 层级的替换，而对于 Android 特定的一些，比如解决 UI 对象（或者其它对象，如果它们也很重要的话）的线程安全问题，它什么也没做。你依然还是要想着，还是要担心怎么正确地引用一个 UI 对象，而且当配置变化的时候你还是要写额外的代码来处理。

技术层面上讲，现在也有 RxAndroid ，它在 RxJava 的基础上对 Application 的主线程有了更深的理解，使得向主线程发送消息来执行变得更容易。但依然缺少对 UI 对象的认知。

所以就有像 AsyncTaskLoader 这样框架级别的基础类（primitive），能提供比 RxJava/RxAndroid 更好的解决方案。这个类能像一个标准的 AsyncTask 一样工作，但提供了一些其它的回调，来让你看到 activity 发生了什么变化，以便你可以做出反应。它是一个“Android 生命周期有意型基础线程类（Android-lifecycle aware threading primitive）”，意味着它能随时回调给你一大堆有用的值，或者就像这哥们儿说的一样：