Android應用內存泄漏的定位、分析與解決策略

什么是內存泄漏

码报开奖结果本期 www.iwqgw.icu 對于不同的語言平臺來說,進行標記回收內存的算法是不一樣的,像 Android(Java)則采用 GC-Root 的標記回收算法。下面這張圖就展示了 Android 內存的回收管理策略(圖來自Google 2011的IO大會)

圖中的每個圓節點代表對象的內存資源,箭頭代表可達路徑。當圓節點與 GC Roots 存在可達路徑時,表示當前資源正被引用,虛擬機是無法對其進行回收的(如圖中的黃色節點)。反過來,如果圓節點與 GC Roots 不存在可達路徑,則意味著這塊對象的內存資源不再被程序引用,系統虛擬機可以在 GC 過程中將其回收掉。

有了上面的內存回收的栗子,那么接下來就可以說說什么是內存泄漏了。從定義上講,Android(Java)平臺的內存泄漏是指沒有用的對象資源任與GC-Root保持可達路徑,導致系統無法進行回收。舉一個最簡單的栗子,我們在 Activity 的 onCreate 函數中注冊一個廣播接收者,但是在 onDestory 函數中并沒有執行反注冊,當 Activity 被 finish 掉時,Activity 對象已經走完了自身的生命周期,應該被資源回收釋放掉,但由于沒有反注冊, 此時 Activity 和 GC-Root 間任然有可達路徑存在,導致 Activity 雖然被銷毀,但是所占用的內存資源卻無法被回收掉。類似的栗子其實有很多,不一一例舉了。對于 Android(Java)內存回收管理想要再深入了解的童鞋,可以看看下面資源:

泄漏的源頭

了解完內存泄漏的理論知識后,再來歸類一下內存泄漏的源頭。這里我將其歸位以下三類:

  • 自身編碼引起

由項目開發人員自身的編碼造成。

  • 第三方代碼引起

這里的第三方代碼包含兩類:第三方非開源的SDK和開源的第三方框架。

  • 系統原因

由 Android 系統自身造成的泄漏,如像 WebView 、 InputMethodManager 等引起的問題,還有某些第三方 ROM 存在的問題。

泄漏的定位

內存泄漏不像閃退的BUG,排查起來相對要比較困難些,比較極端的情況是當你的應用 OOM 了才發現存在內存泄漏問題,到了這種情況才去排查處理問題的話,對用戶的影響就太大了。為此,我們能夠在編碼中盡早發現到問題就不要拖到上線之后才去填坑,下面介紹一些我比較常用排查內存泄漏的工具。

  • 靜態代碼分析工具 —— Lint

Lint 是 Android Studio 自帶的工具,使用姿勢很簡單 Analyze -> Inspect Code 然后選擇想要掃面的區域即可

對可能引起泄漏的編碼,Lint 都會進行溫馨提示。

這里只是拋磚引玉的介紹 Lint ,實際上玩法還有很多,大家可以自行拓展學習。除了 Lint 外,還有像 FindBugs 、 Checkstyle 等靜態代碼分析工具也是很不錯的。

  • 嚴苛模式 —— StrictMode

StrictMode 是 Android 系統提供的 API ,在開發環境下引入可以更早的暴露發現問題。官方文檔鏈接在下面(需要科學上網):

https://developer.android.com/reference/android/os/StrictMode.html

以官網的示例代碼為栗子,一般 StrictMode 只在測試環境下啟用,到了生產環境就會進行關閉,通常我們都會借助 BuildConfig.DEBUG 來實現。

啟用 StrictMode 后,在過濾日志的地方加上 StrictMode 的過濾 Tag ,如果手機連接著電腦進行開發,定期觀察一下 StrictMode 這個 Tag 下的日志,一般你看到一大堆紅色告警的 Log,就需要好好排查一下是否跟內存泄漏有關了。

  • LeakCanary

Square 公司出品的內存分析工具,官方地址如下:

https://github.com/square/leakcanary/

LeakCanary 和 StrictMode 一樣,需要在項目代碼中集成,不過代碼也非常簡單,如下的官方示例。

build.gradle 引入,Application 中加入兩三行代碼,即可搞定。以上只是簡單的引入,還有更多使用姿勢建議詳細閱讀它的 Wiki 下 FAQ:

https://github.com/square/leakcanary/wiki/FAQ

我對使用 LeakCanary 有以下兩點感受:

  1. 當內存泄漏發生時,LeakCanary 會彈窗提示并生成對應的堆存儲信息記錄,這讓我們對隱蔽的內存泄漏問題有了更加直觀的感覺,但從實際使用來看,LeakCanary 的每個提示也并非是真正存在內存泄漏問題,要想確定是否存在問題我們還需要借助 MAT 來進行最后的確定。

  2. Android 系統本身就存在一些問題導致應用內存泄漏,LeakCanary 的 AndroidExcludedRefs 類幫助我們處理了不少這類問題。

    • Android Memory Monitor

AndroidStudio 提供的工具,用于監控應用的內存使用狀態,在開發中也是非常實用的工具,可以用來打印出內存的狀態信息。

打印獲得的內存信息如下,可以通過右上角的綠色三角形按鈕去分析泄漏的 Activity 和 一些重復的字符串,目前只支持這兩個,希望 Google 后面能夠加入更多可選分析規則

同樣,這里也只是拋磚引玉的簡單介紹,關于它的使用在官方文檔已經說得很詳細了,需要的童鞋自行查看下方鏈接(需科學上網):

https://developer.android.com/studio/profile/am-hprof.html

  • Memory Analyzer (MAT)

老牌子分析工具,可以從 //www.eclipse.org/mat/ 下載獲得,網上關于 MAT 使用的文章好多,大家可以自行查找。上面的 Android Memory Monitor 生成的對儲存信息文件可以配置 MAT 一起來分析使用,由于 Android Memory Monitor 生成的 hprof 文件不是標準格式,所以需要做一下轉換,然后導入 MAT

然后通過 OQL 先定位出泄漏的對象

通過排除除了強引用之外的其他引用鏈,最后分析到 GC Root 的位置

MAT 使用起來相對繁瑣,但不失為定位根源問題的利器。

  • adb shell 命令

使用 adb shell dumpsys meminfo [PackageName],可以打印出指定包名的應用內存信息

使用該命令可以很直觀的觀察到 Activity 的泄漏問題,是我平常分析比較常用的一種方式。除了使用命令外,AndroidStudio 也提供了下面的功能,和使用命令是一樣效果的。

如果對 adb shell 命令感興趣,更多的信息可以看下面提供的資源:

以上就是我在做內存泄漏分析的時候會用到的工具,通常都是結合起來用,畢竟每個工具都有優缺點,通過使用多個工具互補分析問題可以極大的提高我們的效率和最終取得的效果。

泄漏的解決策略

聊完工具,最后來談談內存泄漏問題的解決策略。我把它總結為以下三點:

  • 完成需求功能開發后,再去優化內存泄漏問題;

  • 泄漏源有多處時,核心功能產生的泄漏優先處理,用戶使用頻繁的功能引起的泄漏優先處理;

  • 處理泄漏避免影響原有的代碼邏輯,優化過后最好能夠讓測試童鞋過一遍相關的功能,避免引入未知的BUG;

總結

對于如何在編碼上去解決內存泄漏問題,網絡上有提供了很多場景及其解決方案,大家可以自行借助搜索引擎。通過掌握分析方法和對泄漏場景及其解決方案的積累,相信大家處理內存泄漏問題是游刃有余的。當然,也并不是所有內存泄漏問題我們都能夠進行處理,就例如第二章節提到的泄漏源頭是由第三方代碼引起時,我們就顯得無能為力了。最近在排查的過程中就發現不少第三方 SDK 存在泄漏問題,遇上這種情況就得找找可替代的 SDK 進行更換了。

來源:CSDN

上一篇: 內網穿透——Android木馬進入高級攻擊階段

下一篇: Android 多窗口詳解

分享到: 更多
买彩票稳赚不赔绝技 二人麻将棋牌可兑现 雪缘网足球彩票比分直播 pk10最牛稳赚5码计划全天 超级大乐透胆拖怎么算中奖 彩神广东11选5全能版 如何藏分出款 澳客彩票网 2019年国家女篮比赛视频 明牌牛牛抢庄高手 黑龙江时时玩法 11选5免费预测计划软件破解版 欢乐炸金花赢三张 山东时时五运 网彩 网赌出黑出分技术教程