而在 Android 中如何处理好异步请求，则是一个非常宽泛的话题，从这篇开始的若干篇，都会围绕这个来聊一聊。而这篇要讲的，就是看看界面中的异步回调，经常会引发什么问题，要注意些什么。

要在异步回调中判断界面状态

最典型的问题，就是回调时触碰界面而引发崩溃，一个简单示例如下：

// 发起一个异步请求，执行完成后更新界面状态
requestManager.execute(aRequest, new Callback() {protected void completed() {textView.setText("Completed!");}
});

如果回调时，用户已经离开了界面，textView 可能会由于状态不对抛出异常而引发程序崩溃。因此，只要在页面上做了异步回调，需仔细考虑回调时的页面状态，可能需要调用 Activity.isFinishing 来检查界面是否销毁避免触发状态异常的崩溃；如果在 Fragment 中，就要调用 Fragment.isAdded 进行判断，避免 Activity 解绑后触发空指针；以及，在调用各种 Fragment 的 APIs 时，都需要确定页面是否 Save State 了，否则很多 Fragment 的调用都会出错。当然，简单粗暴的，还能赤果果把回调操作中全部 Runtime 级别开始的全部异常都吃掉，不优雅，但至少比崩溃好...

但其实，解决回调崩溃的问题是知易行难，真实的项目中，情况会非常隐匿，线上崩溃总是由于 "不小心"、"没想到" 而引发的。所以，很多时候把保护放在服务内而不是调用者那里，是更安全可靠的方案。

在豌豆荚一览中，小帆给新用户做了一个非常华美的产品介绍（为了纪念这个一次性的功能，我们还特意在设置里面放了一个 "观看产品介绍" 的入口），它的实现充满了十数次异步动画和网络回调，异步操作满地都是，在修改时一不小心就埋下了潜在的线上崩溃（异步回调崩溃的特点，就是不容易发现...）。小帆不堪忍受这样的画面，于是封装了一个欢迎页面的调度引擎，由它来处理全部回调，它接受当前页面的 Fragment 作为参数，回调前会自行判断 Fragment 的状态（并吃掉异常...），这才避免了在无数异步回调中迷失。

要尽可能的取消异步操作

除了崩溃，和异步形影不离的还有内存泄露，它的隐蔽性很强，总是藏匿在 Activity 等具有 Context 的对象中。比如：

// 执行一个时间很长的操作...
requestManager.execute(aRequest(activity) {protected void run() {// wait long long time...}
});

这个异步操作拿了 Activity 对象，如果它需要执行很长时间，那在这个阶段 Activity 和它上面的各种元素都是无法释放的，在用户离开页面很长时间后，内存依旧在占用，并且反复进出会持续累加直到 Out Of Memory（OOM），这其实也就是引发了内存泄露。而这样长时间的等待，有可能是定时引发、有可能是队列排队引发、有可能卡在了某个操作上（比如网络、IO ...），很多时候，甚至都难于提前判断。

因此，如果我们假设，大部分的异步操作都可能是慢的，需要执行很长时间，那如何来处理呢？使用弱引用是一个办法，把等待回调的界面对象（一般都持有 Context）用 WeakReference 包裹起来，如果用户离开页面，很快也会把它给收了，以此来避免内存泄露。但弱引用本身使用上有很多禁忌，稍有不慎就从一个坑到了另一个坑。比如，弱引用最好不要放到服务内弄成黑盒，而是要调用者自行使用，如果放在服务内调用者很可能会出现傻等回调等不来的状况；而一旦完全交由调用者，又难以保证实现是统一可靠的，依旧会由于 "不小心" 引发问题。

除此之外呢？支持干净的取消可以算是最漂亮的方案之一了，在异步回调未返回但界面要退出之前，把操作给回收了，而这个回收不只是设定一个标志位，而是要将回调中潜在泄露的对象彻底移除，这样才能是干净的、可以避免内存泄露的取消方案。

而怎么做一个支持取消的异步机制？那就下(jie)回(hou)分解了。