1.內存泄漏原因：
Java內存泄漏指的是進程中某些垃圾對象已經沒有使用價值了，但是它們卻可以直接或間接地引用到gc roots導致無法被GC回收。無用的對象占據著內存空間，使得實際可使用內存變小，形象地說法就是內存泄漏了。
2.內存泄漏優化：
內存泄漏的優化分為兩個方面，一方面實在開發過程中避免寫出泄漏的代碼，另一方面則是通過一些分析工具MAT,LeakCanary來找出潛在的內存泄漏繼而解決。
3.常見內存泄漏：
1:靜態變量導致的內存泄漏，下面的情況就是activity無法正常銷毀，因為靜態變量Context引用了它。
public class MainActivity extends Activity {
private static Context mContext;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mContext = this;
}
}
上面的代碼我們也可以改造一下，mView是一個靜態變量，他的內部持有當前的activity，所以activity仍然無法釋放，估計這樣好理解點。
public class MainActivity extends Activity {
private static View mView;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mView = new View(this);
}
}
2:非靜態內部類的靜態實例導致內存泄漏,下面的情況可以看得出靜態實例，一直持有當前的activity的引用，我們稱為act1吧。當act1 onDestory（）的時候并沒有被回收，當我們再次創建的時候會出現act2，進程中就會出現兩個act，因此對于launchMode不是singleInstance的activity，因避免這種情況
public class MainActivity extends Activity {
private static ExampleDemo demo;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
demo = new ExampleDemo();
}
}
class ExampleDemo{
void doSomeThing(){
...
}
}
3:單例模式，單例模式應該是設計模式被開發者所喜愛的設計模式，使用簡單粗暴。但是單例模式所帶來的內存泄漏是我們容易忽視的，如下所示提供一個單例模式
public class OrmHelper {
private Context context;
private static OrmHelper ormHelper;
public OrmHelper(Context context) {
this.context = context;
}
public static OrmHelper getInstance(Context context) {
synchronized (OrmHelper.class) {
if (ormHelper == null) {
ormHelper = new OrmHelper(context);
}
}
return ormHelper;
}
}
泄漏的原因是OrmHelper會一直持有context對象，導致當前的activity無法被回收，而單例模式的特點是其生命周期和application保存一直，因此activity對象無法回收。下面是單例模式的優化。使用弱引用。
public class OrmHelper {
private WeakReference<Context> context;
private static OrmHelper ormHelper;
public OrmHelper(Context context) {
this.context = new WeakReference<Context>(context);
}
public static OrmHelper getInstance(Context context) {
synchronized (OrmHelper.class) {
if (ormHelper == null) {
ormHelper = new OrmHelper(context);
}
}
return ormHelper;
}
}
也可以有另一種方式，就是如果這個工具類在app中進程經常被使用可以傳入ApplicationContext。
4:屬性動畫導致內存泄漏，在android3.0開始Google提供了屬性動畫，屬性動畫中又有一種無線循環的動畫，如果在activity中播放此類動畫，沒有在ondestory中進行停止動畫，那么動畫會一直播放，盡管無法再頁面上看到動畫效果，但activity的view 會被動畫持有，而view又持有activity。最終導致activity無法被釋放。解決方法就是在onDestory中調用animator.cancle();下面是一個例子
public class MainActivity extends Activity {
private Button mButton;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mButton = ((Button) findViewById(R.id.sub));
ObjectAnimator animator = ObjectAnimator.ofFloat(mButton,"rotation",0,360).setDuration(2000);
animator.setRepeatCount(ValueAnimator.INFINITE);
animator.start();
// animator.cancel();
}
}
5:注冊某個對象后沒有反注冊,假設我們要監聽電話狀態，需要創建個PhoneStateListener，同時要將它注冊到telephoyManager中。
public class MainActivity extends Activity {
private TelephonyManager tm;
private PhoneStateListener mPhoneStateListener = new PhoneStateListener() {
@Override
public void onCallStateChanged(int state, String incomingNumber) {
switch (state) {
case TelephonyManager.CALL_STATE_IDLE:
break;
case TelephonyManager.CALL_STATE_RINGING: {
break;
}
case TelephonyManager.CALL_STATE_OFFHOOK: {
break;
}
}
super.onCallStateChanged(state, incomingNumber);
}
};
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
tm = (TelephonyManager)getSystemService(Service.TELEPHONY_SERVICE);
tm.listen(mPhoneStateListener,PhoneStateListener.LISTEN_CALL_STATE);
}
}
這種情況就回出現很嚴重的內存泄漏，沒有反注冊。我們在onCreate中進行了注冊，則需要在OnDestory（）進行反注冊，同時把activity的引用緩存弱引用，盡量來避免內存泄漏。
public class MainActivity extends Activity {
private TelephonyManager tm;
private PhoneStateListener mPhoneStateListener = new PhoneStateListener() {
@Override
public void onCallStateChanged(int state, String incomingNumber) {
switch (state) {
case TelephonyManager.CALL_STATE_IDLE:
break;
case TelephonyManager.CALL_STATE_RINGING: {
break;
}
case TelephonyManager.CALL_STATE_OFFHOOK: {
break;
}
}
super.onCallStateChanged(state, incomingNumber);
}
};
private WeakReference<Context> weakReference;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
weakReference = new WeakReference<Context>(this);
new Thread(new Runnable() {
@Override
public void run() {
tm = (TelephonyManager)weakReference.get().getSystemService(Service.TELEPHONY_SERVICE);
tm.listen(mPhoneStateListener,PhoneStateListener.LISTEN_CALL_STATE);
}
}).start();
}
@Override
protected void onDestroy() {
super.onDestroy();
tm.listen(mPhoneStateListener, PhoneStateListener.LISTEN_NONE);
}
}
在這里我們做了兩方面優化，1.引用緩存弱引用，2.創建telephonyManager的時候在線程中創建（通過dump 最終發現是 PhoneStateListener 內部對自己有一個強引用的handler，如果是在主線程中引用PhoneStateListener，那么他將釋放不掉，引發內存泄露）。
6:回調接口，android 4.0已經使用弱引用來解決了這個問題
private WeakReference<IMusicCallBack> callBackWeakReference;
public void setCallBack(IMusicCallBack callBack){
callBackWeakReference = new WeakReference<IMusicCallBack>(callBack);
}
7:集合對象沒有清理造成內存泄漏,我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，如果沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那這種內存泄漏情況就更嚴重了。
8:資源對象沒有手動關閉或處理，資源性對象比如(Cursor，File文件等)往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖不僅存在于 java虛擬機內，還存在于java虛擬機外。如果我們僅僅是把它的引用設置為null,而不關閉它們，往往會造成內存泄漏。因為有些資源性對象，比如 SQLiteCursor(在析構函數finalize(),如果我們沒有關閉它，它自己會調close()關閉)，如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。因此對于資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然后才置為null.在我們的程序退出時一定要確保我們的資源性對象已經關閉。
9:Bitmap使用不當1.及時的銷毀給bitmap分配的內存，recycle。2.有些時候我們需要顯示的圖片區域很小，沒有必要把原圖全部顯示出來，而只需要顯示縮小過得圖片，降低采樣率就行了。這樣大大的減少了內存的使用。
4.總結
在開發中內存泄漏問題，還會有很多種情況，開發中盡量避免寫出有內存泄漏的代碼，但并不是每個內存泄漏都需要解決，我們只是盡量的讓內存泄漏減少，來優化app內存。希望對廣大讀者開發有好的幫助。
