????在日常面試過程中，經(jīng)常會問到內(nèi)存泄漏冗澈，內(nèi)存溢出 數(shù)組越界 和ANR相關(guān)的問題纳猪，很多時候可能會分不清內(nèi)存泄漏和內(nèi)存溢出以及數(shù)組越界的區(qū)別，這里就簡單地寫下自己的看法，如果有什么理解上錯誤蚜锨，歡迎大家指出档插。

1.內(nèi)存泄漏

內(nèi)存泄漏 Memory Leak ，對象已經(jīng)在內(nèi)存堆棧中分配了空間亚再，但是出于某些原因已經(jīng)沒有使用的價值郭膛，但是還是直接或者間接被引用到，導(dǎo)致gc無法回收氛悬，如果是一次內(nèi)存泄漏的危害及影響并不大穴肘，并不會導(dǎo)致程序出現(xiàn)閃退現(xiàn)象俄占，而內(nèi)存泄漏的次數(shù)多了就可能會引起內(nèi)存耗盡?進而誘發(fā)內(nèi)存溢出（OOM）猎物，?進而引起程序閃退样傍，為什么說是可能會引起內(nèi)存耗盡呢？因為java有GC機制镜遣，當你的內(nèi)存緊張時會頻繁觸發(fā)GC己肮，而GC是非常耗時的操作，會導(dǎo)致嚴重的卡頓體驗上會極差悲关，另外谎僻，當你的應(yīng)用處于LRU即緩存列表中，即切換到后臺寓辱，變?yōu)楹笈_進程時艘绍，由于內(nèi)存泄漏而消耗了更多內(nèi)存，當系統(tǒng)資源不足而需要回收一部分緩存進程時秫筏，你的應(yīng)用很大可能性會被被系統(tǒng)殺死鞍盗。

內(nèi)存泄漏常見的原因和如何解決

1.資源未關(guān)閉造成的內(nèi)存泄漏?

BraodcastReceiver，ContentObserver跳昼，F(xiàn)ile，Cursor肋乍，Stream鹅颊，Bitmap等資源的使用，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷墓造，避免這些資源將不會被回收堪伍，進而造成內(nèi)存泄漏。

2.謹慎使用static關(guān)鍵字觅闽，萬不能使用static修飾Activity context

? ? static關(guān)鍵字修飾的對象占用內(nèi)存帝雇，并且內(nèi)存一般不會釋放，只有內(nèi)存不夠用的時候才會釋放靜態(tài)內(nèi)存（這里還有個隱患就是 可能會引起訪問全局靜態(tài)錯誤）蛉拙，如果使用static修飾Activity context會導(dǎo)致activity的所有組件對象都存入全局內(nèi)存中尸闸，并且不會被回收。

3.單例造成的內(nèi)存泄漏

單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長，這就說明了如果一個對象已經(jīng)不需要使用了吮廉，而單例對象還持有該對象的引用苞尝，那么這個對象將不能被正常回收宦芦，這就導(dǎo)致了內(nèi)存泄漏宙址。

4.內(nèi)部類造成的內(nèi)存泄漏

尤其是Activity的內(nèi)部類的生命周期，盡量使用靜態(tài)內(nèi)部類代替內(nèi)部類调卑，如果內(nèi)部類需要訪問外部類的成員抡砂，可以用“靜態(tài)內(nèi)部類+弱引用”代替；內(nèi)部類的生命周期不應(yīng)該超出外部類恬涧，外部類結(jié)束前注益，應(yīng)該及時結(jié)束內(nèi)部類生命周期（停止線程、AsyncTask气破、TimerTask聊浅、Handler消息等，移除類變量或長生命周期的線程對Callback现使、listener等的強引用）

更多避免內(nèi)存泄漏要注意的:

1.屬性動畫在Activity銷毀前記得cancel

2.文件流低匙、Cursor等資源用完及時關(guān)閉；

3.Activity銷毀前WebView的移除和銷毀碳锈；

4.使用別人的方法（尤其是第三方庫）顽冶，遇到需要傳遞context時盡量使用ApplicationContext，而不要輕易使用Activity context售碳，因為你不知道別人的代碼內(nèi)部會不會造成該context的泄漏.

常見的分析手段

借助 內(nèi)存泄漏檢測工具LeakCanary 和?內(nèi)存分析工具——MAT

2.內(nèi)存溢出 OOM

系統(tǒng)會給每個APP分配內(nèi)存也就是Heap Size值强重。當APP占用的內(nèi)存加上我們申請的內(nèi)存資源超過了Dalvik虛擬機的最大內(nèi)存時就會拋出的Out Of Memory異常。

內(nèi)存溢出 OOM常見的原因和如何解決

1.大量內(nèi)存泄漏

上面的造成內(nèi)存泄漏原因都有可能導(dǎo)致內(nèi)存溢出贸人，因為大量內(nèi)存泄漏會導(dǎo)致內(nèi)存耗盡從而引發(fā)內(nèi)存溢出间景，根本解決方案就是解決內(nèi)存泄露的問題，如何解決如上

2.頻繁申請內(nèi)存而不釋放無用內(nèi)存

有些代碼并不造成內(nèi)存泄露艺智，但是它們倘要，或是對沒使用的內(nèi)存沒進行有效及時的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內(nèi)存十拣，對內(nèi)存的回收和分配造成很大影響的封拧，容易迫使虛擬機不得不給該應(yīng)用進程分配更多的內(nèi)存，造成不必要的內(nèi)存開支從而誘發(fā)內(nèi)存泄漏夭问，解決方案盡量避免重復(fù)申請內(nèi)存空間以及及時釋放無用的內(nèi)存

3.Bitmap使用不當

眾所周知Bitmap的是比較耗內(nèi)存的泽西，Bitmap對象在不使用時,我們應(yīng)該先調(diào)用recycle()釋放內(nèi)存，然后才它設(shè)置為null.缰趋，在使用過程中盡量采用低內(nèi)存占用量的編碼方式,如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省內(nèi)存

4捧杉，構(gòu)造Adapter時陕见，沒有復(fù)用convertView（即沒有使用緩存的?convertView）

如果不復(fù)用convertView會導(dǎo)致每次getview()都會重新實例化一個新的View對象，導(dǎo)致內(nèi)存增加長時間滑動會導(dǎo)致內(nèi)存耗盡出現(xiàn)OOM ,解決方案復(fù)用convertView

常見的分析手段

借助 內(nèi)存泄漏檢測工具LeakCanary 和?內(nèi)存分析工具 MAT??

3 數(shù)組越界

更多的時候事叫?下標越界?和內(nèi)存溢出的概念很相似糠溜，一不小心就會混淆對比來解釋下加深記憶

數(shù)組越界： 在引用數(shù)組元素時淳玩，使用的下標超過了該數(shù)組下標的應(yīng)有范圍

內(nèi)存溢出： 在初始化數(shù)組(給數(shù)組元素賦值)時，初始化元素的個數(shù)超過了數(shù)組定義時元素的個數(shù)非竿。

數(shù)組越界是在引用是出現(xiàn)問題 內(nèi)存溢出是在初始化時出現(xiàn)問題

出現(xiàn)的場景以及解決方案

1.多線程操作同一個數(shù)組

多線程操作同一個數(shù)組時蜕着，同時進行刪除和引用可能會導(dǎo)致數(shù)組越界，可以在多線程使用是使用同步鎖或者使用線程安全的數(shù)組對象红柱。

2.引用下標超出數(shù)組大小

這種情況就相對簡單承匣，可以在判斷引用的下標是否大于數(shù)組長度-1 ，一般數(shù)組的下標是從0開始的 如果大于的話求放棄引用

4.應(yīng)用程序無響應(yīng)?ANR

ANR全稱：Application Not Responding,也就是應(yīng)用程序無響應(yīng)锤悄。Android系統(tǒng)中韧骗，ActivityManagerService(簡稱AMS)和WindowManagerService(簡稱WMS)會檢測App的響應(yīng)時間，如果App在特定時間無法相應(yīng)屏幕觸摸或鍵盤輸入時間零聚，或者特定事件沒有處理完畢袍暴，就會出現(xiàn)ANR。

ANR的四種類型

InputDispatching Timeout：5秒內(nèi)無法響應(yīng)屏幕觸摸事件或鍵盤輸入事件

BroadcastQueue Timeout：在執(zhí)行前臺廣播（BroadcastReceiver）的onReceive()函數(shù)時10秒沒有處理完成隶症，后臺為60秒政模。

Service Timeout：前臺服務(wù)20秒內(nèi)，后臺服務(wù)在200秒內(nèi)沒有執(zhí)行完畢蚂会。

ContentProvider Timeout：ContentProvider的publish在10s內(nèi)沒進行完淋样。

ANR常見的原因和如何解決

1.主線程進行耗時操作（數(shù)據(jù)庫操作，耗時的網(wǎng)絡(luò)訪問等）

在主線程中進行耗時操作會導(dǎo)致主線程卡頓 出現(xiàn)超過5秒無響應(yīng) 就會出現(xiàn)ANR胁住，應(yīng)該盡量避免在主線程中進行耗時操作趁猴，把耗時操作放到子線程中

2.多線程持死鎖導(dǎo)致的ANR

出現(xiàn)這種情況要去具體分析trace文件分析具有哪個線程死鎖導(dǎo)致主線block 然后分析向上分析出現(xiàn)問題的原因

3.BroadcastReceiver的onReceive進行耗時操作

在執(zhí)行前臺廣播（BroadcastReceiver）的onReceive()函數(shù)時10秒沒有處理完成，后臺為60秒彪见。如果超時就會出現(xiàn)anr 儡司，如果要執(zhí)行耗時操作時應(yīng)啟動一個service，將耗時操作交給service來完成余指，具體問什么不能再onReceive開一個子線程進行處理 詳見為什么不能在BroadcastReceiver中開啟子線程

4.主線程中加載過大數(shù)據(jù)和圖片

有時候我們需要加載很多高清無碼的大圖枫慷，或者加載特別大的數(shù)據(jù)時也會出現(xiàn)anr因為這些都是耗內(nèi)存的操作，但是更新ui的操作又不能放到子線程中浪规，懶漢方法就壓縮圖片,可以在服務(wù)端壓縮也可以在客戶端壓縮，當然Android如果是大數(shù)據(jù)可以分段加載探孝。