什么是內(nèi)存泄漏由驹？
答：在Android程序開發(fā)中邓厕，當(dāng)一個對象已經(jīng)不需要再使用了草讶，本該被回收時洽糟，而另外一個正在使用的對象持有它的引用從而導(dǎo)致它不能被回收，這就導(dǎo)致本該被回收的對象不能被回收而停留在堆內(nèi)存中堕战，內(nèi)存泄漏就產(chǎn)生了坤溃。
內(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汁政。
常見的內(nèi)存泄漏情況：
靜態(tài)變量Activity和View會導(dǎo)致內(nèi)存泄漏，在下面這段代碼中對Activity的Context和TextView設(shè)置為靜態(tài)對象缀旁，從而產(chǎn)生內(nèi)存泄漏记劈。
public classMainActivityextendsAppCompatActivity{
private static Context context;
private static TextView textView;
@Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
context = this;
textView = new TextView(this);
}
}
因為，context诵棵，textView實例的生命周期與應(yīng)用的生命周期一樣抠蚣，而他們都持有當(dāng)前Activity的（MainActivity ）引用，一旦MainActivity 銷毀履澳，而他的引用一直被持有嘶窄，就不會被回收。所以距贷，內(nèi)存泄漏就產(chǎn)出了柄冲。
Android的單例模式非常受開發(fā)者的喜愛，不過使用的不恰當(dāng)?shù)脑捯矔斐蓛?nèi)存泄漏忠蝗。因為單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長现横，這就說明了如果一個對象已經(jīng)不需要使用了，而單例對象還持有該對象的引用阁最，那么這個對象將不能被正辰潇簦回收，這就導(dǎo)致了內(nèi)存泄漏速种。
如下這個典例：
public class TestManager {
private static TestManager instance;
private Context context;
private TestManager(Context context) {
this.context = context;
}
public static TestManager getInstance(Context context) {
if (instance != null) {
instance = new TestManager(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 TestManager {
private static TestManager instance;
private Context context;
private TestManager(Context context) {
this.context = context.getApplicationContext();
}
public static TestManager getInstance(Context context) {
if (instance != null) {
instance = new TestManager(context);
}
return instance;
}
}
這樣不管傳入什么Context最終將使用Application的Context，而單例的生命周期和應(yīng)用的一樣長麸拄，這樣就防止了內(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 classMyAsyncTaskextendsAsyncTask { 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 classMyRunnableimplementsRunnable{ @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í)行浪費資源聪轿。
如果你還是不太清楚，再舉個例子：
Thread猾浦，匿名類陆错，內(nèi)部類
在下面這段代碼中存在一個非靜態(tài)的匿名類對象Thread灯抛，會隱式持有一個外部類的引用MainActivity 。同理音瓷，若是這個Thread作為MainActivity的內(nèi)部類而不是匿名內(nèi)部類对嚼，他同樣會持有外部類的引用。
public classMainActivityextendsAppCompatActivity{ @Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
leakFun();
}
private void leakFun(){
new Thread(new Runnable() {
@Override public void run() {
try {
Thread.sleep(10*1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
}
}
在線程休眠的這10s內(nèi)绳慎，會一直隱式持有外部類的引用MainActivity纵竖，如果在10s之前，銷毀MainActivity杏愤，就會報內(nèi)存泄漏靡砌。同理，若是這個Thread作為MainActivity的內(nèi)部類而不是匿名內(nèi)部類珊楼，也會內(nèi)存泄漏通殃。總而言之：如果Activity在銷毀之前亥曹，任務(wù)還未完成邓了， 那么將導(dǎo)致Activity的內(nèi)存資源無法回收，造成內(nèi)存泄漏媳瞪。
解決辦法：在這里只需要將為Thread匿名類定義成靜態(tài)的內(nèi)部類即可（靜態(tài)的內(nèi)部類不會持有外部類的一個隱式引用）骗炉。或保證在Activity在銷毀之前蛇受，完成任務(wù)句葵！
四：非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實例造成的內(nèi)存泄漏
有的時候我們可能會在啟動頻繁的Activity中，為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源兢仰，會出現(xiàn)這種寫法：
public classMainActivityextendsAppCompatActivity{ private static TestResource mResource = null;
@Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(mResource == null){
mResource = 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)部類默認會持有外部類的引用，而又使用了該非靜態(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)存泄漏問題應(yīng)該說最為常見了，平時在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請求回調(diào)等api都應(yīng)該會借助Handler來處理，對于Handler的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏匈勋，如下示例：
public classMainActivityextendsAppCompatActivity{
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 classMainActivityextendsAppCompatActivity{
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static classMyHandlerextendsHandler{
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)該移除消息隊列中的消息抵拘，更準確的做法如下：
public classMainActivityextendsAppCompatActivity{
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static classMyHandlerextendsHandler{
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。
在屬性動畫中有一類無限循環(huán)動畫充尉，如果在Activity中播放這類動畫并且在onDestroy中沒有去停止動畫飘言，那么這個動畫將會一直播放下去，這時候Activity會被View所持有驼侠，從而導(dǎo)致Activity無法被釋放姿鸿。解決此類問題則是需要早Activity中onDestroy去調(diào)用objectAnimator.cancel()來停止動畫。
public classLeakActivityextendsAppCompatActivity{
private TextView textView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_leak);
textView = (TextView)findViewById(R.id.text_view);
ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(textView,"rotation",0,360);
objectAnimator.setRepeatCount(ValueAnimator.INFINITE);
objectAnimator.start();
}
}
對于EventBus泪电，RxJava等一些第三開源框架的使用般妙，若是在Activity銷毀之前沒有進行解除訂閱將會導(dǎo)致內(nèi)存泄漏。
對于使用了BraodcastReceiver相速，ContentObserver碟渺，F(xiàn)ile，Cursor突诬，Stream苫拍，Bitmap等資源的使用芜繁，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷，否則這些資源將不會被回收绒极，造成內(nèi)存泄漏骏令。
說了這么多，哪有沒有檢測內(nèi)存泄漏的工具呢垄提，當(dāng)我的應(yīng)用出現(xiàn)內(nèi)存泄漏的時候榔袋，我能檢測到具體是哪個地方出現(xiàn)泄漏了，那就好啦铡俐』硕遥回答是肯定的。而且還不止一個审丘。那我就在此簡單吏够，介紹一個吧，是出自 square 公司的 leakcanary滩报。
leakcanary
添加依賴：
dependencies{ debugCompile'com.squareup.leakcanary:leakcanary-android:1.5.1'releaseCompile'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'testCompile'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'}
用法也是很簡單的：
In your Application class:
public classExampleApplicationextendsApplication{
@Override
public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis. // You should not init your app in this process. return;
}
LeakCanary.install(this);
// Normal app init code... }
}
添加好了依賴和代碼初始化后锅知，當(dāng)有內(nèi)存泄漏出現(xiàn)時，在通知欄會有提示脓钾，點擊進入后售睹，就會看到具體的報錯點。leakcanary 的基本情況是惭笑，他在debug下侣姆，是會去檢測你的應(yīng)用內(nèi)存泄漏情況，而在release版下沉噩，不會去檢測的捺宗。關(guān)于更多了解川蒙，大家可以百度一下。
說了這么多昼牛，可能有些人處女座的人就問了康聂，內(nèi)存泄漏恬汁，這個內(nèi)存？java的內(nèi)存回收脊另？到底是個怎么回事呢导狡？那么下面偎痛，我們就一起從更深入的角度，去了解學(xué)習(xí)枚赡，java有關(guān)內(nèi)存的創(chuàng)建标锄，回收的機制茁计。
先附上一張圖：
