Android内存优化之――static使用篇
[csdn地址]:http://blog.csdn.net/ys408973279/article/details/50389200
在Android开发中，我们经常会使用到static来修饰我们的成员变量，其本意是为了让多个对象共用一份空间，节省内存,或者是使用单例模式，让该类只生产一个实例而在整个app中使用。然而在某些时候不恰当的使用或者是编程的不规范却会造成了内存泄露现象(java上的内存泄漏指内存得不到gc的及时回收，从而造成内存占用过多的现象)
本文中我们主要分析的是static变量对activtiy的不恰当引用而造成的内存泄漏，因为对于同一个Activity页面一般每次打开时系统都会重新生成一个该activity的对象(standard模式下)，而每个activity对象一般都含有大量的视图对象和bitmap对象,如果之前的activity对象不能得到及时的回收，从而就造成了内存的泄漏现象。
下面一边看代码一边讲解。
单例模式不正确的获取context
public class LoginManager { private Context context; private static LoginManager manager; public static LoginManager getInstance(Context context) { if (manager == null) manager = new LoginManager(context); return manager; } private LoginManager(Context context) { this.context = context; } 在LoginActivity中
public class LoginActivity extends Activity { private LoginManager loginManager; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_login); loginManager = LoginManager.getInstance(this); } 这种方式大家应该一看就明白问题在哪里了，在LoginManager的单例中context持有了LoginActivity的this对象，即使登录成功后我们跳转到了其他Activity页面，LoginActivity的对象仍然得不到回收因为他被单例所持有，而单例的生命周期是同Application保持一致的。
正确的获取context的方式
public class LoginManager { private Context context; private static LoginManager manager; public static LoginManager getInstance(Context context) { if (manager == null) manager = new LoginManager(context); return manager; } private LoginManager(Context context) { this.context = context.getApplicationContext(); } 修改方式也非常简单我们单例中context不再持有Activity的context而是持有Application的context即可，因为Application本来就是单例，所以这样就不会存在内存泄漏的的现象了。
单例模式中通过内部类持有activity对象
第一种方式内存泄漏太过与明显，相信大家都不会犯这种错误，接下来要介绍的这种泄漏方式会比较不那么容易发现，内部类的使用造成activity对象被单例持有。
还是看代码再分析，下面是一个单例的类：
public class TestManager { public static final TestManager INSTANCE = new TestManager(); private List<MyListener> mListenerList; private TestManager() { mListenerList = new ArrayList<MyListener>(); } public static TestManager getInstance() { return INSTANCE; } public void registerListener(MyListener listener) { if (!mListenerList.contains(listener)) { mListenerList.add(listener); } } public void unregisterListener(MyListener listener) { mListenerList.remove(listener); } } interface MyListener { public void onSomeThingHappen(); } 然后是activity:
public class TestActivity extends AppCompatActivity { private MyListener mMyListener=new MyListener() { @Override public void onSomeThingHappen() { } }; private TestManager testManager=TestManager.getInstance(); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); testManager.registerListener(mMyListener); } } 我们知道在java中，非静态的内部类的对象都是会持有指向外部类对象的引用的，因此我们将内部类对象mMyListener让单例所持有时，由于mMyListener引用了我们的activity对象，因此造成activity对象也不能被回收了，从而出现内存泄漏现象。
修改以上代码，避免内存泄漏，在activity中添加以下代码:`
@Override protected void onDestroy() { testManager.unregisterListener(mMyListener); super.onDestroy(); } AsyncTask不正确使用造成的内存泄漏
介绍完以上两种情况的内存泄漏后，我们在来看一种更加容易被忽略的内存泄漏现象，对于AsyncTask不正确使用造成内存泄漏的问题。
mTask=new AsyncTask<String,Void,Void>() { @Override protected Void doInBackground(String... params) { //doSamething.. return null; } }.execute("a task"); 一般我们在主线程中开启一个异步任务都是通过实现一个内部类其继承自AsyncTask类然后实现其相应的方法来完成的，那么自然的mTask就会持有对activity实例对象的引用了。查看AsyncTask的实现，我们会通过一个SerialExecutor串行线程池来对我们的任务进行排队，而这个SerialExecutor对象就是一个static final的常量。
具体的引用关系是:
1.我们的任务被封装在一个FutureTask的对象中(它充当一个runable的作用)，FutureTask的实现也是通过内部类来实现的，因此它也为持有AsyncTask对象，而AsyncTask对象引用了activity对象，因此activity对象间接的被FutureTask对象给引用了。
2.futuretask对象会被添加到一个ArrayDeque类型的任务队列的mTasks实例中
3.mTasks任务队列又被SerialExecutor对象所持有，刚也说了这个SerialExecutor对象是一个static final的常量。
具体AsyncTask的实现大家可以去参照下其源代码，我这里就通过文字描述一下其添加任务的实现过程就可以了，总之分析了这么多通过层层引用后我们的activity会被一个static变量所引用到。所以我们在使用AsyncTask的时候不宜在其中执行太耗时的操作，假设activity已经退出了，然而AsyncTask里任务还没有执行完成或者是还在排队等待执行，就会造成我们的activity对象被回收的时间延后，一段时间内内存占有率变大。
解决方法在activity退出的时候应该调用cancel()函数
@Override protected void onDestroy() { //mTask.cancel(false); mTask.cancel(true); super.onDestroy(); } 具体cancel()里传递true or false依实际情况而定：
1.当我们的任务还在排队没有被执行，调用cancel()无论true or false,任务会从排队队列中移除，即任务都不会被执行到了。
2.当我们的任务已经开始执行了(doInBackground被调用)，传入参数为false时并不会打断doInBackground的执行，传入参数为true时，如果我们的线程处于休眠或阻塞(如:sleep,wait)状况是会打断其执行。
这里具体解释下cancle(true)的意义：
mTask=new AsyncTask<String,Void,Void>() { @Override protected Void doInBackground(String... params) { try { Thread.sleep(10000); } catch (InterruptedException e) { e.printStackTrace(); } Log.d("test", "task is running"); return null; } }.execute("a task"); try { //保证task得以执行 Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } mTask.cancel(true); 在这样的情况下我们的线程处于休眠状态调用cancel(true)方法会打断doInBackground的执行――即不会看到log语句的输出。
但在下面的这种情况的时候却打断不了
mTask=new AsyncTask<String,Void,Void>() { @Override protected Void doInBackground(String... params) { Boolean loop=true; while (loop) { Log.d("test", "task is running"); } return null; } }.execute("a task"); try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } mTask.cancel(true); 由于我们的线程不处于等待或休眠的状况及时调用cancel(true)也不能打断doInBackground的执行――现象：log函数一直在打印输出。
解决方法：
mTask=new AsyncTask<String,Void,Void>() { @Override protected Void doInBackground(String... params) { //doSomething.. Boolean loop=true; while (loop) { if(isCancelled()) return null; Log.d("test", "task is running"); } return null; } }.execute("a task"); try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } mTask.cancel(true); 这里我们通过在每次循环是检查任务是否已经被cancle掉，如果是则退出。因此对于AsyncTask我们也得注意按照正确的方式进行使用，不然也会造成程序内存泄漏的现象。
以上内容就是在使用static时，我们需要怎么做才能优化内存的使用，当然对于以上3种情况是我们编程中使用static经常遇到的内存泄漏的情况，但仍然还有很多情况我们不易察觉到。比如：如果不做介绍，上面的第三种情况就很难察觉到，这时我们最终的内存泄漏优化方法就是:使用内存泄漏分析工具，在下一篇文章里我会参照第三种情况(AsyncTask)造成的内存泄漏，通过使用MAT工具进行分析，讲解MAT排除内存泄漏的使用方法。