而在 Android 中如何处理好异步请求,则是一个非常宽泛的话题,从这篇开始的若干篇,都会围绕这个来聊一聊。而这篇要讲的,就是看看界面中的异步回调,经常会引发什么问题,要注意些什么。
要在异步回调中判断界面状态
最典型的问题,就是回调时触碰界面而引发崩溃,一个简单示例如下:
// 发起一个异步请求,执行完成后更新界面状态
requestManager.execute(aRequest, new Callback() {
protected void completed() {
textView.setText("Completed!");
}
});
但其实,解决回调崩溃的问题是知易行难,真实的项目中,情况会非常隐匿,线上崩溃总是由于 "不小心"、"没想到" 而引发的。所以,很多时候把保护放在服务内而不是调用者那里,是更安全可靠的方案。
在豌豆荚一览中,小帆给新用户做了一个非常华美的产品介绍(为了纪念这个一次性的功能,我们还特意在设置里面放了一个 "观看产品介绍" 的入口),它的实现充满了十数次异步动画和网络回调,异步操作满地都是,在修改时一不小心就埋下了潜在的线上崩溃(异步回调崩溃的特点,就是不容易发现...)。小帆不堪忍受这样的画面,于是封装了一个欢迎页面的调度引擎,由它来处理全部回调,它接受当前页面的 Fragment 作为参数,回调前会自行判断 Fragment 的状态(并吃掉异常...),这才避免了在无数异步回调中迷失。
要尽可能的取消异步操作
除了崩溃,和异步形影不离的还有内存泄露,它的隐蔽性很强,总是藏匿在 Activity 等具有 Context 的对象中。比如:
// 执行一个时间很长的操作...
requestManager.execute(aRequest(activity) {
protected void run() {
// wait long long time...
}
});
这个异步操作拿了 Activity 对象,如果它需要执行很长时间,那在这个阶段 Activity 和它上面的各种元素都是无法释放的,在用户离开页面很长时间后,内存依旧在占用,并且反复进出会持续累加直到 Out Of Memory(OOM),这其实也就是引发了内存泄露。而这样长时间的等待,有可能是定时引发、有可能是队列排队引发、有可能卡在了某个操作上(比如网络、IO ...),很多时候,甚至都难于提前判断。
因此,如果我们假设,大部分的异步操作都可能是慢的,需要执行很长时间,那如何来处理呢?使用弱引用是一个办法,把等待回调的界面对象(一般都持有 Context)用 WeakReference 包裹起来,如果用户离开页面,很快也会把它给收了,以此来避免内存泄露。但弱引用本身使用上有很多禁忌,稍有不慎就从一个坑到了另一个坑。比如,弱引用最好不要放到服务内弄成黑盒,而是要调用者自行使用,如果放在服务内调用者很可能会出现傻等回调等不来的状况;而一旦完全交由调用者,又难以保证实现是统一可靠的,依旧会由于 "不小心" 引发问题。
除此之外呢?支持干净的取消可以算是最漂亮的方案之一了,在异步回调未返回但界面要退出之前,把操作给回收了,而这个回收不只是设定一个标志位,而是要将回调中潜在泄露的对象彻底移除,这样才能是干净的、可以避免内存泄露的取消方案。