App调试内存泄露之Context篇(上).docxVIP

App调试内存泄露之Context篇(上)Context作为最基本的上下文，承载着Activity，Service等最基本组件。当有对象引用到Activity，并不能被回收释放，必将造成大范围的对象无法被回收释放，进而造成内存泄漏。下面针对一些常用场景逐一分析。1. CallBack对象的引用 先看一段代码：@Overrideprotectedvoid onCreate(Bundle state){ super.onCreate(state); TextView label =new TextView(this); label.setText(Leaks are bad); setContentView(label);}大家看看有什么问题吗？ 没问题是吧，继续看：private staticDrawable sBackground; @Overrideprotected void onCreate(Bundle state){ super.onCreate(state); TextView label =new TextView(this); label.setText(Leaks are bad); if(sBackground ==null){ sBackground = getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label);}有问题吗？ 哈哈，先Hold住一下，先来说一下android各版本发布的历史： /* 2.2 2010-3-20，Froyo2.3 2010-12-6, Gingerbread3.0 2011-2-22, Honeycomb4.0 2011-10-11 Ice Cream Sandwich*/ 了解源码的历史，是很有益于我们分析android代码的。 好，开始分析代码。 首先，查看setBackgroundDrawable(Drawable background)方法源码里面有一行代码引起我们的注意：public void setBackgroundDrawable(Drawable background) { // ... ... background.setCallback(this); // ... ...} 所以sBackground对view保持了一个引用，view对activity保持了一个引用。 当退出当前Activity时，当前Activity本该释放，但是因为sBackground是静态变量，它的生命周期并没有结束，而sBackground间接保持对Activity的引用，导致当前Activity对象不能被释放，进而导致内存泄露。 所以结论是：有内存泄露！ 这是Android官方文档的例子：/2009/01/avoiding-memory-leaks.html 到此结束了吗？ 我发现网上太多直接抄或者间接抄这篇文章，一搜一大片，并且吸引了大量的Android初学者不断的转载学习。 但是经过本人深入分析Drawable源码，事情发生了一些变化。 Android官方文档的这篇文章是写于2009年1月的，当时的Android Source至少是Froyo之前的。 Froyo的Drawable的setCallback()方法的实现是这样的：public final void setCallback(Callback cb) { mCallback = cb;}在GingerBread的代码还是如此的。 但是当进入HoneyComb，也就是3.0之后的代码我们发现Drawable的setCallback()方法的实现变成了：public final void setCallback(Callback cb) { mCallback = new WeakReferenceCallback(cb);}也就是说3.0之后，Drawable使用了软引用，把这个泄露的例子问题修复了。（至于软引用怎么解决了以后有机会再分析吧） 所以最终结论是，在android3.0之前是有内存泄露，在3.0之后无内存泄露！ 如果认真比较代码的话，Android3.0前后的代码改进了大量类似代码，前面的Cursor篇里的例子也是在3.0之后修复了。 从这个例子中，我们很好的发现了内存是怎么通过回调泄露的，同时通过官方代码的update也了解到了怎么修复类似的内存泄露。2. System Service对象 通过各种系统服务，我们能够做一些系统设计好的底层功能：//ContextImpl.java@Ove