android内存泄露

Android虚拟机的垃圾回收采用的是根搜索算法。GC会从根节点（GC Roots）开始对heap进行遍历。到最后，部分没有直接或者间接引用到GC Roots的就是需要回收的垃圾，会被GC回收掉。而内存泄漏出现的原因就是存在了无效的引用，导致本来需要被GC的对象没有被回收掉。

Java内存泄漏指的是进程中某些对象（垃圾对象）已经没有使用价值了，但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。无用的对象占据着内存空间，使得实际可使用内存变小，形象地说法就是内存泄漏了。

常见的内存泄漏

1、使用handler时的内存问题

 

我们知道，Handler通过发送Message与主线程交互，Message发出之后是存储在MessageQueue中的，有些Message也不是马上就被处理的。在Message中存在一个 target，是Handler的一个引用，如果Message在Queue中存在的时间越长，就会导致Handler无法被回收。如果Handler是非静态的，则会导致Activity或者Service不会被回收。 所以正确处理Handler等之类的内部类，应该将自己的Handler定义为静态内部类。

 

HandlerThread的使用也需要注意：

  当我们在activity里面创建了一个HandlerThread，代码如下：

[java]  view plain copy

1. public classMainActivity extends Activity  
2. {  
3.     @Override  
4.     public void onCreate(BundlesavedInstanceState)  
5.     {  
6.         super.onCreate(savedInstanceState);  
7.         setContentView(R.layout.activity_main);  
8.         Thread mThread = newHandlerThread("demo", Process.THREAD_PRIORITY_BACKGROUND);   
9.         mThread.start();  
10. MyHandler mHandler = new MyHandler( mThread.getLooper( ) );  
11. …….  
12. …….  
13. …….  
14. }  
15.     @Override  
16.     public void onDestroy()  
17.     {  
18.     super.onDestroy();  
19.     }  
20. }  

[java]  view plain  copy

 

1. public classMainActivity extends Activity  
2. {  
3.     @Override  
4.     public void onCreate(BundlesavedInstanceState)  
5.     {  
6.         super.onCreate(savedInstanceState);  
7.         setContentView(R.layout.activity_main);  
8.         Thread mThread = newHandlerThread("demo", Process.THREAD_PRIORITY_BACKGROUND);   
9.         mThread.start();  
10. MyHandler mHandler = new MyHandler( mThread.getLooper( ) );  
11. …….  
12. …….  
13. …….  
14. }  
15.     @Override  
16.     public void onDestroy()  
17.     {  
18.     super.onDestroy();  
19.     }  
20. }  

这个代码存在泄漏问题，因为HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了activity生命周期，当横竖屏切换，HandlerThread线程的数量会随着activity重建次数的增加而增加。

应该在onDestroy时将线程停止掉：mThread.getLooper().quit();

另外，对于不是HandlerThread的线程，也应该确保activity消耗后，线程已经终止，可以这样做：在onDestroy时调用mThread.join();

2、注册某个对象后未反注册

注册广播接收器、注册观察者等等，比如：

假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，

同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。

　　但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被GC回收。如果不断的使锁屏界面显示和消失，则最终会由于

大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。

虽然有些系统程序，它本身好像是可以自动取消注册的(当然不及时)，但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

3. activity使用静态成员

以上2个例子的内存泄漏都是因为Activity的引用的生命周期超越了activity对象的生命周期。也就是常说的Context泄漏，因为activity就是context。

 

想要避免context相关的内存泄漏，需要注意以下几点：

·不要对activity的context长期引用(一个activity的引用的生存周期应该和activity的生命周期相同)

·如果可以的话，尽量使用关于application的context来替代和activity相关的context,解决方法可以将new Singleton(context)改为new Singleton(context.getApplicationContext())即可，这样便和传入的Activity没关系了。

·如果一个acitivity的非静态内部类的生命周期不受控制，那么避免使用它；正确的方法是使用一个静态的内部类，并且对它的外部类有一WeakReference，就像在ViewRootImpl中内部类W所做的那样。

现在Android开发基本上是使用Android studio，而AS自带很多工具，现在就记录内存泄漏分析工具的使用

内存泄漏的检测

打开Android Studio，编译代码，在模拟器或者真机上运行App，然后点击，在Android Monitor下点击Monitor对应的Tab，进入如下界面

在Memory一栏中，可以观察不同时间App内存的动态使用情况，点击可以手动触发GC，点击可以进入HPROF Viewer界面，查看Java的Heap，如下图