內(nèi)存泄漏
Java 內(nèi)存分配策略
Java 程序運(yùn)行時的內(nèi)存分配策略有三種,分別是靜態(tài)分配,棧式分配,和堆式分配，對應(yīng)的裸卫，三種存儲策略使用的內(nèi)存空間主要分別是靜態(tài)存儲區(qū)（也稱方法區(qū)）、棧區(qū)和堆區(qū)毁葱。
? ? 靜態(tài)存儲區(qū)（方法區(qū)）：主要存放靜態(tài)數(shù)據(jù)挟秤、全局 static 數(shù)據(jù)和常量。這塊內(nèi)存在程序編譯時就已經(jīng)分配好垢啼，并且在程序整個運(yùn)行期間都存在窜锯。
? ? 棧區(qū) ：當(dāng)方法被執(zhí)行時张肾，方法體內(nèi)的局部變量（其中包括基礎(chǔ)數(shù)據(jù)類型、對象的引用）都在棧上創(chuàng)建锚扎，并在方法執(zhí)行結(jié)束時這些局部變量所持有的內(nèi)存將會自動被釋放吞瞪。因為棧內(nèi)存分配運(yùn)算內(nèi)置于處理器的指令集中，效率很高驾孔，但是分配的內(nèi)存容量有限芍秆。
? ? 堆區(qū) ： 又稱動態(tài)內(nèi)存分配，通常就是指在程序運(yùn)行時直接 new 出來的內(nèi)存助币，也就是對象的實例浪听。這部分內(nèi)存在不使用時將會由 Java 垃圾回收器來負(fù)責(zé)回收螟碎。
為什么會產(chǎn)生內(nèi)存泄漏眉菱？
當(dāng)一個對象已經(jīng)不需要再使用了，本該被回收時掉分，而有另外一個正在使用的對象持有它的引用從而導(dǎo)致它不能被回收俭缓，這導(dǎo)致本該被回收的對象不能被回收而停留在堆內(nèi)存中，這就產(chǎn)生了內(nèi)存泄漏酥郭。
內(nèi)存泄漏對程序的影響华坦？
內(nèi)存泄漏是造成應(yīng)用程序OOM的主要原因之一！我們知道Android系統(tǒng)為每個應(yīng)用程序分配的內(nèi)存有限不从，而當(dāng)一個應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時惜姐，這就難免會導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個系統(tǒng)分配的內(nèi)存限額，這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash椿息。
Android中常見的內(nèi)存泄漏匯總
單例造成的內(nèi)存泄漏
單例模式非常受開發(fā)者的喜愛歹袁，不過使用的不恰當(dāng)?shù)脑捯矔斐蓛?nèi)存泄漏，由于單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長寝优，這就說明了如果一個對象已經(jīng)不需要使用了条舔，而單例對象還持有該對象的引用，那么這個對象將不能被正撤Ψ回收孟抗，這就導(dǎo)致了內(nèi)存泄漏。
如下這個典例：
public class AppManager {
? ? private static AppManager instance;
? ? private Context context;
? ? private AppManager(Context context) {
? ? ? ? this.context = context;
? ? }
? ? public static AppManager getInstance(Context context) {
? ? ? ? if (instance != null) {
? ? ? ? ? ? instance = new AppManager(context);
? ? ? ? }
? ? ? ? return instance;
? ? }
}
這是一個普通的單例模式钻心，當(dāng)創(chuàng)建這個單例的時候凄硼，由于需要傳入一個Context，所以這個Context的生命周期的長短至關(guān)重要：
1捷沸、傳入的是Application的Context：這將沒有任何問題摊沉，因為單例的生命周期和Application的一樣長
2、傳入的是Activity的Context：當(dāng)這個Context所對應(yīng)的Activity退出時亿胸，由于該Context和Activity的生命周期一樣長（Activity間接繼承于Context）坯钦，所以當(dāng)前Activity退出時它的內(nèi)存并不會被回收预皇，因為單例對象持有該Activity的引用。
所以正確的單例應(yīng)該修改為下面這種方式：
public class AppManager {
? ? private static AppManager instance;
? ? private Context context;
? ? private AppManager(Context context) {
? ? ? ? //這樣不管傳入什么Context最終將使用Application的Context婉刀，
? ? ? ? //而單例的生命周期和應(yīng)用的一樣長吟温，這樣就防止了內(nèi)存泄漏
? ? ? ? this.context = context.getApplicationContext();
? ? }
? ? public static AppManager getInstance(Context context) {
? ? ? ? if (instance != null) {
? ? ? ? ? ? instance = new AppManager(context);
? ? ? ? }
? ? ? ? return instance;
? ? }
}
非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實例造成的內(nèi)存泄漏
有的時候我們可能會在啟動頻繁的Activity中，為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源突颊，可能會出現(xiàn)這種寫法：
public class MainActivity extends AppCompatActivity {
? ? private static TestResource mResource = null;
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? if(mManager == null){
? ? ? ? ? ? mManager = new TestResource();
? ? ? ? }
? ? ? ? //...
? ? }
? ? class TestResource {
? ? ? ? //...
? ? }
}
這樣就在Activity內(nèi)部創(chuàng)建了一個非靜態(tài)內(nèi)部類的單例鲁豪，每次啟動Activity時都會使用該單例的數(shù)據(jù)，這樣雖然避免了資源的重復(fù)創(chuàng)建律秃，不過這種寫法卻會造成內(nèi)存泄漏爬橡，因為非靜態(tài)內(nèi)部類默認(rèn)會持有外部類的引用，而又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個靜態(tài)的實例棒动，該實例的生命周期和應(yīng)用的一樣長糙申，這就導(dǎo)致了該靜態(tài)實例一直會持有該Activity的引用，導(dǎo)致Activity的內(nèi)存資源不能正炒遥回收柜裸。正確的做法為：
將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來封裝成一個單例，如果需要使用Context粱锐，請使用ApplicationContext
Handler造成的內(nèi)存泄漏
Handler的使用造成的內(nèi)存泄漏問題應(yīng)該說最為常見了疙挺，平時在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請求回調(diào)等api都應(yīng)該會借助Handler來處理，對于Handler的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏怜浅，如下示例：
public class MainActivity extends AppCompatActivity {
? ? private Handler mHandler = new Handler() {
? ? ? ? @Override
? ? ? ? public void handleMessage(Message msg) {
? ? ? ? ? ? //...
? ? ? ? }
? ? };
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? loadData();
? ? }
? ? private void loadData(){
? ? ? ? //...request
? ? ? ? Message message = Message.obtain();
? ? ? ? mHandler.sendMessage(message);
? ? }
}
這種創(chuàng)建Handler的方式會造成內(nèi)存泄漏铐然，由于mHandler是Handler的非靜態(tài)匿名內(nèi)部類的實例，所以它持有外部類Activity的引用恶座，我們知道消息隊列是在一個Looper線程中不斷輪詢處理消息搀暑，那么當(dāng)這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息，而消息隊列中的Message持有mHandler實例的引用奥裸，mHandler又持有Activity的引用险掀，所以導(dǎo)致該Activity的內(nèi)存資源無法及時回收，引發(fā)內(nèi)存泄漏湾宙，所以另外一種做法為：
public class MainActivity extends AppCompatActivity {
? ? private MyHandler mHandler = new MyHandler(this);
? ? private TextView mTextView ;
? ? private static class MyHandler extends Handler {? ? ? ?
??????? private WeakReference reference;
? ? ? ? public MyHandler(Context context) {
? ? ? ? ? ? reference = new WeakReference<>(context);
? ? ? ? }
? ? ? ? @Override
? ? ? ? public void handleMessage(Message msg) {
? ? ? ? ? ? MainActivity activity = (MainActivity) reference.get();
? ? ? ? ? ? if(activity != null){
? ? ? ? ? ? ? ? activity.mTextView.setText("");
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? mTextView = (TextView)findViewById(R.id.textview);
? ? ? ? loadData();
? ? }
? ? private void loadData() {
? ? ? ? //...request
? ? ? ? Message message = Message.obtain();
? ? ? ? mHandler.sendMessage(message);
? ? }
}
創(chuàng)建一個靜態(tài)Handler內(nèi)部類樟氢，然后對Handler持有的對象使用弱引用，這樣在回收時也可以回收Handler持有的對象侠鳄，這樣雖然避免了Activity泄漏埠啃，不過Looper線程的消息隊列中還是可能會有待處理的消息，所以我們在Activity的Destroy時或者Stop時應(yīng)該移除消息隊列中的消息伟恶，更準(zhǔn)確的做法如下：
public class MainActivity extends AppCompatActivity {
? ? ? ? private MyHandler mHandler = new MyHandler(this);
? ? ? ? private TextView mTextView ;
? ? ? ? private static class MyHandler extends Handler {? ? ? ? private WeakReference reference;
? ? ? ? public MyHandler(Context context) {
? ? ? ? ? ? reference = new WeakReference<>(context);
? ? ? ? }
? ? ? ? @Override
? ? ? ? public void handleMessage(Message msg) {
? ? ? ? ? ? MainActivity activity = (MainActivity) reference.get();
? ? ? ? ? ? if(activity != null){
? ? ? ? ? ? ? ? activity.mTextView.setText("");
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? @Override
? ? protected void onCreate(Bundle savedInstanceState) {
? ? ? ? super.onCreate(savedInstanceState);
? ? ? ? setContentView(R.layout.activity_main);
? ? ? ? mTextView = (TextView)findViewById(R.id.textview);
? ? ? ? loadData();
? ? }
? ? private void loadData() {
? ? ? ? //...request
? ? ? ? Message message = Message.obtain();
? ? ? ? mHandler.sendMessage(message);
? ? }
? ? @Override
? ? protected void onDestroy() {
? ? ? ? super.onDestroy();
? ? ? ? mHandler.removeCallbacksAndMessages(null);
? ? }
}
使用mHandler.removeCallbacksAndMessages(null);是移除消息隊列中所有消息和所有的Runnable碴开。當(dāng)然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來移除指定的Runnable和Message。
線程造成的內(nèi)存泄漏
對于線程造成的內(nèi)存泄漏，也是平時比較常見的潦牛，如下這兩個示例可能每個人都這樣寫過：
? ? ? ? ? ? //——————test1? ? ? ? new AsyncTask() {
? ? ? ? ? ? @Override
? ? ? ? ? ? protected Void doInBackground(Void... params) {
? ? ? ? ? ? ? ? SystemClock.sleep(10000);
? ? ? ? ? ? ? ? return null;
? ? ? ? ? ? }
? ? ? ? }.execute();
? ? ? ? //——————test2
? ? ? ? new Thread(new Runnable() {
? ? ? ? ? ? @Override
? ? ? ? ? ? public void run() {
? ? ? ? ? ? ? ? SystemClock.sleep(10000);
? ? ? ? ? ? }
? ? ? ? }).start();
上面的異步任務(wù)和Runnable都是一個匿名內(nèi)部類眶掌，因此它們對當(dāng)前Activity都有一個隱式引用。如果Activity在銷毀之前巴碗，任務(wù)還未完成朴爬，
那么將導(dǎo)致Activity的內(nèi)存資源無法回收，造成內(nèi)存泄漏橡淆。正確的做法還是使用靜態(tài)內(nèi)部類的方式召噩，如下
static class MyAsyncTask extends AsyncTask{
? ? ? ? private WeakReference weakReference;
? ? ? ? public MyAsyncTask(Context context) {
? ? ? ? ? ? weakReference = new WeakReference<>(context);
? ? ? ? }
? ? ? ? @Override
? ? ? ? protected Void doInBackground(Void... params) {
? ? ? ? ? ? SystemClock.sleep(10000);
? ? ? ? ? ? return null;
? ? ? ? }
? ? ? ? @Override
? ? ? ? protected void onPostExecute(Void aVoid) {
? ? ? ? ? ? super.onPostExecute(aVoid);
? ? ? ? ? ? MainActivity activity = (MainActivity) weakReference.get();
? ? ? ? ? ? if (activity != null) {
? ? ? ? ? ? ? ? //...
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? static class MyRunnable implements Runnable{
? ? ? ? @Override
? ? ? ? public void run() {
? ? ? ? ? ? SystemClock.sleep(10000);
? ? ? ? }
? ? }
? ? //——————
? ? new Thread(new MyRunnable()).start();
? ? new MyAsyncTask(this).execute();
這樣就避免了Activity的內(nèi)存資源泄漏，當(dāng)然在Activity銷毀時候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask.cancel()逸爵，避免任務(wù)在后臺執(zhí)行浪費(fèi)資源具滴。
資源未關(guān)閉造成的內(nèi)存泄漏
對于使用了BraodcastReceiver，ContentObserver师倔，F(xiàn)ile构韵，Cursor，Stream溯革，Bitmap等資源的使用贞绳，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷谷醉，否則這些資源將不會被回收致稀，造成內(nèi)存泄漏。
一些建議
1俱尼、對于生命周期比Activity長的對象如果需要應(yīng)該使用ApplicationContext
2抖单、在涉及到Context時先考慮ApplicationContext，當(dāng)然它并不是萬能的遇八，對于有些地方則必須使用Activity的Context矛绘，對于Application，Service刃永，Activity三者的Context的應(yīng)用場景如下：
*NO1表示Application和Service可以啟動一個Activity货矮，不過需要創(chuàng)建一個新的task任務(wù)隊列。而對于Dialog而言斯够，只有在Activity中才能創(chuàng)建
3囚玫、對于需要在靜態(tài)內(nèi)部類中使用非靜態(tài)外部成員變量（如：Context、View )读规，可以在靜態(tài)內(nèi)部類中使用弱引用來引用外部類的變量來避免內(nèi)存泄漏
4抓督、對于生命周期比Activity長的內(nèi)部類對象，并且內(nèi)部類中使用了外部類的成員變量束亏，可以這樣做避免內(nèi)存泄漏：
將內(nèi)部類改為靜態(tài)內(nèi)部類
靜態(tài)內(nèi)部類中使用弱引用來引用外部類的成員變量
5铃在、對于不再需要使用的對象，顯示的將其賦值為null，比如使用完Bitmap后先調(diào)用recycle()定铜，再賦為null
6阳液、保持對對象生命周期的敏感，特別注意單例揣炕、靜態(tài)對象趁舀、全局性集合等的生命周期
