Android/Java回调机制带来的内存回收问题

最新推荐文章于 2023-07-17 17:29:22 发布

京都盖饭小白领

最新推荐文章于 2023-07-17 17:29:22 发布

阅读量1.5k

点赞数

CC 4.0 BY-SA版权

分类专栏： JVM 文章标签： Android JVM 回调内存回收

本文链接：https://blog.youkuaiyun.com/anjxue/article/details/49358813

JVM 专栏收录该内容

1 篇文章

订阅专栏

本文探讨了安卓开发中流行的回调方法及其潜在问题，特别是内存回收难题。通过示例代码展示了客户端与服务端间的回调机制，并分析了由此引发的内存泄漏风险。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这几年在做安卓开发，不知为何，最近越来越流行方法回调的开发方式。

典型的场景是这样的：

class Client {

		void bind(Server b) {
			Callback c = new Callback() {

				@Override
				public void callback() {

				}

			};
			b.setCallBack(c);

		}

	}

class Server {
	Callback c;

	void setCallBack(Callback c) {
		this.c = c;
	}

}

interface Callback {
	void callback();
}

测试代码如下：

Client a = new Client();
Server b = new Server();
a.bind(b);

（上面为示意代码，实际工程中，Client对应Activity或Fragment，Server对应Service）

我其实不太喜欢回调，一是可读性差，尤其是回调嵌套的时候、二是无法通过方法的返回值来控制流程，比如AsyncTask里就不方便用回调的形式。

而最重要的一点，就是带来的内存回收问题。

我们知道Server的生命周期可能是很长的，而Client却很短，我们做个实验模拟下：

Client a = new Client();
Server b = new Server();
a.bind(b);
a = null;
System.gc()

按常规分析，我以为a设置为null后，就可以被回收了，因为看上去b没有引用到a

但实际测试却发现，a没有被回收。

定位原因后发现了问题：Callback是一个内部类，它会持有a.this，这样就是b->callback->a，导致a无法被回收。

这样带来的问题就可想而知了。